Perguntas frequentes sobre
teste de performance

Quando muitos usuários acessam uma aplicação simultaneamente, diferentes camadas podem atingir seus limites: servidor web, threads do servidor de aplicação, pool de conexões, banco de dados, filas, APIs externas ou recursos de nuvem. A causa não é necessariamente falta de servidores. Uma query lenta, um lock no banco, um limite de threads ou uma integração síncrona pode degradar todo o sistema mesmo quando CPU e memória parecem disponíveis.

Picos de acesso revelam comportamentos que não aparecem em testes leves. A aplicação pode suportar o tráfego médio, mas falhar quando a concorrência aumenta rapidamente, quando milhares de transações disputam o mesmo recurso ou quando uma dependência externa ultrapassa seu limite. Testar antes de uma rematrícula, Black Friday ou lançamento reduz o risco de descobrir o limite em produção.

Não existe um número universal. A capacidade depende da jornada de negócio, do perfil dos usuários, do volume de dados, dos critérios de tempo de resposta, das integrações e da configuração do ambiente. A forma confiável de responder é estabelecer uma baseline de capacidade: uma medição controlada que indique quantos usuários virtuais o sistema suporta mantendo os indicadores definidos.

Escalar a infraestrutura resolve apenas gargalos relacionados ao recurso que foi ampliado. Se o problema está em uma consulta SQL, em contenção de banco, em threads do Tomcat, em serialização de chamadas ou em uma API externa, adicionar CPU ou memória pode aumentar o custo sem remover a causa. O caminho mais seguro é medir antes e depois com telemetria correlacionada.

O erro mais comum é tratar qualquer lentidão como problema de infraestrutura. Aumentar máquinas, clusters ou bancos sem uma baseline pode mascarar gargalos lógicos e criar despesa recorrente. Comece identificando a jornada crítica, o nível de concorrência esperado e os indicadores que caracterizam uma resposta aceitável.

Testes internos frequentemente usam poucos usuários, massas de dados pequenas, jornadas simplificadas e menos integrações. Produção acrescenta concorrência real, dados maiores, chamadas externas, tarefas agendadas e perfis diferentes de acesso. Quanto maior a diferença de topologia, dados e configuração entre ambientes, menor a capacidade de extrapolar resultados.

É necessário transformar o incidente em uma hipótese testável. Registre a jornada afetada, o horário, a concorrência, os erros, os recursos utilizados e as mudanças recentes. Depois, reproduza o padrão em um ambiente controlado e confirme se o gargalo está no código, no banco, na infraestrutura ou em uma dependência. Um plano eficaz combina baseline, testes de carga e estresse, correção priorizada e reteste.

Sim. Ferramentas de inteligência artificial podem acelerar a criação de código, mas o código gerado ainda precisa ser revisado, medido e testado. Uma implementação aparentemente correta pode introduzir consultas repetidas, chamadas sequenciais, alocação excessiva de memória, loops ineficientes ou uso inadequado de conexões. Testes funcionais não garantem desempenho sob concorrência.