Quem já trabalhou com QA ou desenvolvimento já ouviu os termos 'teste de carga' e 'teste de stress' sendo usados como se fossem a mesma coisa. Mas não são. E confundir os dois pode levar a conclusões erradas sobre a saúde do sistema. Enquanto o teste de carga verifica se o sistema aguenta o tranco do dia a dia, o teste de stress empurra ele até o limite para ver onde quebra. A diferença não é só de nome: é de objetivo, métrica e momento de aplicação.
Objetivo principal
Teste de carga: mede o desempenho sob demanda esperada. Você simula um número típico de usuários simultâneos (ex.: 500 acessos por minuto) e observa tempo de resposta, uso de CPU e memória. O objetivo é garantir que o sistema funcione dentro dos SLAs acordados.
Teste de stress: avalia a resiliência sob condições extremas. Você aumenta a carga gradualmente até o sistema falhar, ou aplica um pico súbito muito acima do normal. O objetivo é identificar o ponto de ruptura, o comportamento durante a falha e a capacidade de recuperação.
Quando aplicar cada um
| Critério | Teste de carga | Teste de stress | |---|---|---| | Momento | Antes de lançar versão, após mudanças de infra | Antes de eventos sazonais, após falhas anteriores | | Carga usada | Dentro do esperado (média + 20%) | Acima do esperado (2x, 5x, 10x) | | Métrica principal | Tempo de resposta, throughput | Ponto de falha, tempo de recuperação | | Risco de aplicar | Baixo (sistema não deve quebrar) | Médio (pode causar instabilidade temporária) |
Métricas que importam
No teste de carga, as métricas são de desempenho: tempo de resposta médio, percentis 95/99, throughput e taxa de erro. Se alguma métrica ultrapassa o limite aceitável, o sistema precisa de ajuste.
No teste de stress, as métricas são de resiliência: em qual carga o sistema começa a apresentar erros? Quanto tempo leva para se recuperar depois que a carga volta ao normal? O sistema reinicia sozinho ou precisa de intervenção manual?
Ferramentas comuns
Ambos os testes podem usar as mesmas ferramentas, como JMeter, k6, Gatling ou Locust. A diferença está na configuração: no teste de carga, você define um número fixo de usuários e mantém por um período; no stress, você aumenta progressivamente ou aplica picos.
Veredito: qual escolher?
Para quem precisa garantir que o sistema aguenta o uso diário sem lentidão, o teste de carga é o caminho. Para quem quer saber até onde o sistema vai antes de cair e como ele se comporta em situações extremas, o teste de stress é indispensável. O ideal? Fazer os dois em momentos diferentes do ciclo de desenvolvimento.
FAQ
Teste de carga e teste de stress são a mesma coisa?
Não. O teste de carga mede desempenho sob condições esperadas; o teste de stress avalia resiliência sob condições extremas. Eles têm objetivos, métricas e momentos de aplicação diferentes.
Qual teste devo fazer primeiro?
Geralmente, o teste de carga vem primeiro, durante o desenvolvimento ou antes de um lançamento. O teste de stress é feito depois, especialmente antes de eventos de pico (Black Friday, lançamentos) ou após falhas.
Posso usar a mesma ferramenta para ambos?
Sim. Ferramentas como JMeter, k6 e Gatling servem para os dois tipos. A diferença está na configuração do cenário: carga constante vs. carga crescente ou em pico.
O que é ponto de ruptura em teste de stress?
É o momento em que o sistema não consegue mais atender às requisições dentro de um critério aceitável, seja por timeout, erro 500, ou queda total. Identificar esse ponto ajuda a planejar capacidade e failover.
Teste de stress pode quebrar o sistema em produção?
Sim, se mal planejado. Por isso, testes de stress geralmente são executados em ambientes de staging ou pré-produção, com monitoramento ativo e plano de rollback.
Como saber se meu sistema passou no teste de stress?
Não existe nota de corte universal. O critério é definido pelo time: por exemplo, o sistema deve se recuperar em menos de 5 minutos após a carga voltar ao normal, ou não deve perder dados mesmo durante a falha.