{"id":3598,"date":"2021-05-21T17:51:36","date_gmt":"2021-05-21T17:51:36","guid":{"rendered":"https:\/\/www.cesar.org.br\/painel\/?post_type=insight&p=3598"},"modified":"2026-06-09T15:36:51","modified_gmt":"2026-06-09T18:36:51","slug":"teste-de-performance-o-segredo-esta-no-planejamento","status":"publish","type":"insight","link":"https:\/\/www.cesar.org.br\/painel\/insight\/teste-de-performance-o-segredo-esta-no-planejamento\/","title":{"rendered":"Teste de performance: o segredo est\u00e1 no planejamento"},"content":{"rendered":"

F\u00e1bio Correia<\/a>\/Software Test Consultant no CESAR<\/strong><\/p>\n

Em tempos de nuvem, escalabilidade e uso massivo da internet, n\u00e3o \u00e9 incomum que uma simples publica\u00e7\u00e3o em uma rede social caia nas gra\u00e7as de usu\u00e1rios e, atrav\u00e9s de um fluxo massivo e quase sempre desordenado, derrube o servidor ou indisponibilize um servi\u00e7o. Olhando um pouco para o trivial, uma consulta simples a um banco de dados mal estruturado pode ocasionar lentid\u00e3o no uso da aplica\u00e7\u00e3o. Mesmo que n\u00e3o haja a concorr\u00eancia nos acessos, \u00e9 s\u00f3 a massa de dados ser minimamente densa e a escalabilidade do servi\u00e7o ser zero para o problema ganhar vida.<\/p>\n

Ambos cen\u00e1rios citados, e algumas centenas de outros n\u00e3o ponderados neste par\u00e1grafo, podem ocasionar a pior das situa\u00e7\u00f5es: a perda da confian\u00e7a do usu\u00e1rio pelo impacto da impossibilidade de uso, que geralmente \u00e9 premissa b\u00e1sica em qualquer servi\u00e7o.<\/p>\n

Trazendo \u00e0 luz o cen\u00e1rio de redes sociais do primeiro par\u00e1grafo, posso citar um exemplo que tem se tornado corriqueiro para exemplificar o caso: trata-se do \u201cReddit Hug of Death\u201d (O abra\u00e7o da morte do\u00a0Reddit<\/a>\u00a0\u2014 tradu\u00e7\u00e3o literal), que acontece quando um usu\u00e1rio do\u00a0Reddit<\/a>\u00a0faz uma postagem recomendando um site, servi\u00e7o ou publicando uma not\u00edcia espec\u00edfica e essa postagem acaba atingindo a front-page da rede social, gerando uma quantidade de acessos por parte dos usu\u00e1rios t\u00e3o massiva que chega a derrubar o site\/servi\u00e7o referenciado (em grande parte das vezes).<\/p>\n

Servidores, aplica\u00e7\u00f5es web, aplica\u00e7\u00f5es mobile, e todo e qualquer cen\u00e1rio do universo computacional que envolve uma troca ativa de bits e bytes atrav\u00e9s da nossa querida internet, se torna suscet\u00edvel a uma sobrecarga, venha ela de um tsunami de usu\u00e1rios sedentos por algo, ou atrav\u00e9s de crackers mal intencionados buscando prejudicar um servidor atrav\u00e9s de um famigerado\u00a0ataque de nega\u00e7\u00e3o de servi\u00e7o<\/a>\u00a0(cuidado: esse link de mapeamento dos DDoS \u00e9 hipn\u00f3tico!), e pensando nesses cen\u00e1rios eu sempre busco estruturar uma linha de pensamento preventiva, capaz de mensurar atrav\u00e9s de testes de performance, que abrangem testes de carga e estresse, o ponto de quebra dos sistemas testados.<\/p>\n

Come\u00e7ando a fazer as contas<\/h2>\n

N\u00f3s, t\u00e3o apegados a requisitos, sempre come\u00e7amos as nossas jornadas em busca do estado de inexist\u00eancia de bugs persistentes com perguntas. Uma vez que nos debru\u00e7amos nas possibilidades e cen\u00e1rios, isso faz ou deve fazer parte da nossa natureza investigativa. Como engenheiro de testes, eu sempre irei buscar insumos, recheando-os com sentimentos e expectativas, para conseguir entregar a melhor experi\u00eancia aos usu\u00e1rios, validando o c\u00f3digo de forma progressiva, esperando que o mesmo n\u00e3o esconda nenhuma surpresa.<\/p>\n

Mas o que fazer quando n\u00e3o temos n\u00fameros iniciais ou quando as perspectivas ainda s\u00e3o apenas um conjunto de dados e par\u00e2metros ainda abstratos e pouco tang\u00edveis? Bom, o primeiro passo \u00e9 come\u00e7ar de onde voc\u00ea est\u00e1, com o que voc\u00ea tem, fazendo o que der para fazer, e essa linha de iniciativa se aplica de forma bem eficaz para testes de performance.<\/p>\n

\"\"
Voc\u00ea j\u00e1 pensou como a capacidade de carga de uma ponte\/viaduto \u00e9 testada? \u00a9 Copyright Calvin and Hobbes<\/figcaption><\/figure>\n

Com alguns dos cen\u00e1rios ventilados, fazemos uma proje\u00e7\u00e3o al\u00e9m do mec\u00e2nico, precisamos considerar comportamentos, especulando as possibilidades e mensurando o movimento de manada, assim como o cracker mal intencionado. \u00c9 uma boa pr\u00e1tica especular abertamente sobre o in\u00edcio da atividade em si, uma vez que, parametrizar, assim como estimar as situa\u00e7\u00f5es de carga, acabam sendo a parte mais dif\u00edcil da atividade.<\/p>\n

Considere o que pode acontecer caso os stakeholders forne\u00e7am uma estimativa pouco precisa, subestimando a natureza real das cargas, ou como e por quanto tempo haver\u00e1 picos de acesso, considere tamb\u00e9m que por mais que tenhamos n\u00fameros supostamente exatos, para calcular o impacto deles precisaremos idealmente simul\u00e1-los, nos aproximar dos cen\u00e1rios assim como explodir as possibilidades com proje\u00e7\u00f5es algumas vezes bem afastadas da realidade, podendo assim descobrir pontos de quebra, para que depois de muito tempo exercitando os n\u00fameros e com ajuda de muita infraestrutura,\u00a0talvez voc\u00ea n\u00e3o precise mais fazer<\/a>.<\/p>\n

\"\"Uma vez que a nossa conversa e grande parte da experi\u00eancia se d\u00e1 dentro de um universo normal corporativo, e que n\u00e3o come\u00e7aremos tentando conter uma \u201cGenki Dama\u201d como o pessoal do Akamai fez segurando o GitHub, n\u00f3s devemos nos ater a universos corporativos, de tr\u00e1fego moderado, apostando as fichas e considerando as possibilidades de um grande volume em breves espa\u00e7os de tempo e em determinadas situa\u00e7\u00f5es, como um hot site de promo\u00e7\u00f5es, por exemplo, que ser\u00e1 \u201catacado\u201d em um per\u00edodo espec\u00edfico, ao mesmo tempo, n\u00e3o estaremos livres dos bugs funcionais no aspecto l\u00f3gico como chamadas redundantes, cache desestruturado, e\u00a0otras cositas m\u00e1s<\/i>\u00a0tamb\u00e9m precisam ser consideradas.<\/p>\n

J\u00e1 um cen\u00e1rio de fluxo intenso e constante, exige uma dedica\u00e7\u00e3o em n\u00edvel industrial de valida\u00e7\u00e3o, e geralmente a infraestrutura para tal j\u00e1 \u00e9 mensurada de forma escal\u00e1vel tornando os testes de performance como coadjuvantes situacionais, uma vez que voc\u00ea n\u00e3o faz ideia sobre quando um v\u00edrus vai assolar o mundo obrigando tudo e todos a ficarem isolados em suas casas, exercitando cada mil\u00edmetro da camada de infraestrutura de T.I do nosso pequeno e azul planeta.<\/p>\n

Dentro de toda diversidade de cen\u00e1rios, uma coisa \u00e9 fato: a performance do sistema e seus testes dependem de uma dedica\u00e7\u00e3o que se d\u00e1 do come\u00e7o ao fim (se \u00e9 que tem um fim, n\u00e9?!) do projeto, e deve envolver n\u00e3o s\u00f3 testadores pontualmente, mas desenvolvedores, respons\u00e1veis pela infraestrutura e tamb\u00e9m os stakeholders.<\/p>\n

Quando me pedem para explicar de forma mais clara situa\u00e7\u00f5es de estresse e carga de tiro curto, utilizo um v\u00eddeo bem did\u00e1tico para exemplificar, pois ainda n\u00e3o encontrei um jeito mais humano:<\/p>\n