Teste de carga, estresse e diagnóstico de performance: guia técnico

O que é teste de carga e por que é diferente de um teste funcional?

O teste de carga avalia como uma aplicação se comporta com um volume definido de usuários, transações ou requisições simultâneas. Ele mede tempo de resposta, taxa de erro, throughput e consumo de recursos para verificar se o sistema atende aos critérios de capacidade.

O teste funcional verifica se uma regra de negócio funciona. Por exemplo, confirma se um usuário consegue concluir um pagamento. Uma operação pode funcionar corretamente com um usuário e falhar quando centenas de pessoas executam a mesma jornada ao mesmo tempo. Por isso, testes funcionais e de performance são complementares, não substitutos.

Teste de carga, teste de estresse e teste de resistência: qual é a diferença?

O desenho ideal depende do risco de negócio. Uma aplicação sujeita a picos precisa de estresse e spike. Uma aplicação que opera continuamente precisa de resistência. Todos os testes devem ter critérios de segurança e autorização.

O que é um teste de pico (spike test) e quando ele é necessário?

O spike test simula uma mudança brusca de carga em curto intervalo. Ele representa situações como abertura de inscrições, início de uma campanha, divulgação de um produto ou disparo de uma comunicação que concentra acessos.

Esse teste verifica se o sistema absorve o aumento, enfileira solicitações, rejeita excesso de forma controlada e retorna ao estado normal depois do pico. Ele é necessário quando o tráfego pode crescer em segundos ou quando a indisponibilidade de uma janela específica tem impacto financeiro ou reputacional elevado.

k6, JMeter ou Gatling: qual ferramenta faz sentido para o meu caso?

A escolha depende do perfil da equipe, do protocolo, do nível de integração e da forma de manutenção dos scripts.

A ferramenta não substitui a metodologia. Um script mal modelado gera números pouco úteis em qualquer engine.

O que é uma baseline de capacidade e por que toda aplicação crítica precisa de uma?

Uma baseline de capacidade é uma referência medida em condições conhecidas. Ela registra o volume de concorrência que o sistema suporta, os tempos de resposta, a taxa de erro e o consumo de recursos sob uma determinada configuração.

Sem baseline, decisões de infraestrutura e lançamento são baseadas em percepção. Com baseline, a equipe consegue comparar versões, dimensionar a nuvem, estimar margem para crescimento e identificar regressões. A baseline deve ser revisada depois de mudanças relevantes na arquitetura, nos dados ou no comportamento esperado dos usuários.

Locks e deadlocks no SQL Server: o que são e como identificá-los?

Um lock é um mecanismo de controle de concorrência que impede operações incompatíveis de acessar o mesmo recurso ao mesmo tempo. Um deadlock ocorre quando duas ou mais transações ficam esperando recursos umas das outras, formando um ciclo.

Sob carga, locks prolongados aumentam a fila de transações e elevam o tempo de resposta. Para investigar, correlacione a jornada lenta com consultas, duração das transações, bloqueios, deadlocks, índices e plano de execução.

Por que as threads do Tomcat se esgotam sob carga?

O Tomcat usa threads para processar requisições. Elas podem ficar ocupadas por tempo excessivo quando a aplicação aguarda o banco, uma API externa, disco, filas ou operações síncronas demoradas. Com muitas requisições concorrentes, o pool pode atingir o limite e novas chamadas passam a esperar ou falhar.

A correção não é apenas aumentar o número de threads. É preciso verificar tempo de espera, pool de conexões, filas, limites de downstream e comportamento do código.

O que é memory leak em aplicações Java e como ele aparece nos testes?

Um memory leak ocorre quando objetos que não deveriam mais ser usados continuam referenciados e não podem ser liberados pelo coletor de lixo. Em aplicações Java, o efeito pode ser crescimento contínuo do heap, pausas maiores de garbage collection, queda de throughput e, em casos extremos, OutOfMemoryError.

No teste de resistência, o sinal típico é degradação progressiva durante uma carga estável. A análise precisa observar heap, garbage collection, classes, threads e comportamento da aplicação ao longo do tempo.

Como correlacionar tempo de resposta com CPU, I/O e memória para achar a causa-raiz?

Comece alinhando os relógios e os intervalos de coleta. Depois, compare a curva de latência com CPU, memória, I/O de disco, rede, threads, conexões e métricas do banco durante a mesma jornada.

A correlação deve responder a uma sequência simples: qual transação degradou, em que momento, qual recurso mudou e qual componente explica a mudança. CPU alta pode indicar processamento intenso, mas CPU baixa com latência alta pode apontar espera por I/O, locks ou dependência externa.

O que é graceful degradation e por que meu sistema deveria ter isso?

Graceful degradation, ou degradação controlada, é a capacidade de preservar funções essenciais quando a demanda ou uma dependência excede o limite normal. Em vez de derrubar toda a aplicação, o sistema pode limitar operações não essenciais, usar filas, exibir mensagens claras ou responder com uma capacidade reduzida.

Um teste de estresse ou spike deve verificar se os limites, timeouts, retentativas e filas funcionam como projetado, sem criar uma cascata de falhas.

Um diagnóstico automático, como Lighthouse ou PageSpeed, é suficiente?

Não. Lighthouse e PageSpeed são úteis para avaliar aspectos de uma página em uma execução sintética. Eles não certificam a capacidade transacional de uma aplicação com milhares de usuários concorrentes.

Para saber se o sistema suporta produção, é necessário testar jornadas críticas, APIs, autenticação, banco de dados, integrações e concorrência representativa.

---

Próximo passo: escolha a jornada de negócio mais crítica e defina o limite de tempo de resposta que precisa ser preservado durante a carga.