Seu aplicativo funciona perfeitamente com dez usuários. O que acontece no dia da liquidação, com dez mil? Teste de carga versus teste de estresse descreve duas maneiras diferentes de responder a isso, e misturá-las leva a testes que não comprovam o que você pensa que eles fazem.

Este guia explica o que cada um mostra, os tipos de testes relacionados e como ler os resultados. Executamos o pequeno cálculo de percentil abaixo no Python 3.13, com números simulados. Os scripts k6 são exemplos ilustrativos que não executamos, e as contagens e alvos de usuários são inventados, então substitua-os pelos seus próprios. Execute esses testes apenas em sistemas que você possui ou tem permissão para testar, pois o tráfego intenso pode parecer um ataque e causar interrupções reais.

A resposta curta

Um teste de carga pergunta: podemos lidar com o tráfego que esperamos e atingir nossas metas ao fazê-lo? Um teste de estresse pergunta: quanto podemos aguentar antes de falhar, como falhamos e com que rapidez nos recuperamos?

Pense em uma ponte. Um teste de carga conduz o número esperado de caminhões e confirma que está tudo bem. Um teste de estresse continua adicionando peso para saber seu limite e se ele avisa primeiro. Felizmente, é mais barato quebrar um software do que uma ponte.

Teste de carga versus teste de estresse lado a lado

O que é teste de carga?

O teste de carga simula o tráfego realista esperado e mede como o sistema se comporta. Ele precisa de uma meta para testar, por exemplo: “com 500 usuários simultâneos, 95% das solicitações de checkout terminam em 800 ms, com menos de 1% de erros”.

Aqui está como isso poderia parecer um script k6. Os testes k6 são escritos em JavaScript e thresholds transformam seus alvos em um resultado de aprovação ou reprovação:

import http from "k6/http";
import { sleep } from "k6";

export const options = {
  stages: [
    { duration: "5m", target: 500 },   // ramp up
    { duration: "20m", target: 500 },  // hold at expected peak
    { duration: "2m", target: 0 },     // ramp down
  ],
  thresholds: {
    http_req_duration: ["p(95)<800"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/products");
  sleep(1);   // think time, as real users pause
}

O sleep é importante. Sem tempo para pensar, cada usuário virtual sobrecarrega o servidor continuamente, produzindo muito mais tráfego do que o mesmo número de pessoas reais produziria.

O que são testes de estresse?

Os testes de estresse vão deliberadamente além dos níveis esperados. Você não está tentando passar. Você quer respostas para perguntas como:

• Em que nível o desempenho começa a desmoronar?
• Qual componente falha primeiro: o banco de dados, os servidores de aplicativos ou uma chamada de terceiros?
• Ele falha normalmente com erros claros ou trava e perde dados?
• Ele se recupera sozinho quando o tráfego cai?

export const options = {
  stages: [
    { duration: "5m", target: 500 },    // expected peak
    { duration: "5m", target: 1000 },   // beyond it
    { duration: "5m", target: 2000 },   // further
    { duration: "5m", target: 4000 },   // likely to break
    { duration: "10m", target: 0 },     // recovery: does it come back?
  ],
};

Essa fase final de recuperação é frequentemente esquecida e pode ser a mais valiosa. Um sistema que lida bem com falhas, mas nunca se recupera sem uma reinicialização manual, ainda significa uma interrupção para alguém consertar no meio da noite. Idealmente, sob carga extrema, um sistema deve interromper o trabalho de maneira controlada, retornando 503 respostas claras em vez de atingir o tempo limite.

Spike, molho e outros tipos

Os testes de carga e de estresse pertencem a uma família mais ampla de testes de desempenho:

Os testes de absorção detectam problemas que os testes curtos nunca detectam. Um pequeno vazamento de memória pode parecer inofensivo por vinte minutos e só interromper o serviço após dois dias. Os testes de pico são adequados para eventos como vendas relâmpago, onde o tráfego não aumenta gradualmente.

Métricas que importam

Por que as médias enganam

As médias escondem as solicitações lentas das quais as pessoas reais reclamam. Para mostrar isso, geramos 100 tempos de resposta simulados, onde 95 foram rápidos (80 a 200 ms) e 5 foram muito lentos (2,5 a 4 segundos), e então calculamos as estatísticas comuns:

import math, random, statistics

random.seed(3)
times = [random.randint(80, 200) for _ in range(95)] \
      + [random.randint(2500, 4000) for _ in range(5)]

def pct(values, p):
    values = sorted(values)
    return values[math.ceil(p / 100 * len(values)) - 1]

print("avg", round(statistics.mean(times)), "p50", pct(times, 50),
      "p95", pct(times, 95), "p99", pct(times, 99), "max", max(times))

# avg 302 p50 150 p95 199 p99 3740 max 3896

Observe atentamente esses números. A média de 302 ms não descreve ninguém. As solicitações típicas demoravam cerca de 150 ms, enquanto as lentas demoravam mais de 3 segundos. Até o p95 parece saudável em 199 ms, e apenas o p99 revela o problema. Um número como p95 significa que 95% das solicitações foram tão rápidas ou mais rápidas.

E um por cento das solicitações não é um evento raro. Se uma página fizer 50 solicitações, um p99 lento afetará uma grande parte das visualizações de página. Defina metas nos percentis que são importantes para você e analise vários deles juntos.

Ferramentas

Qualquer um deles pode executar testes de carga e de estresse. Escolha aquele que se adapta às habilidades da sua equipe, em vez de buscar uma lista de recursos. Para usar um em seu pipeline, consulte o que é CI/CD.

Como planejar um teste

1. Defina metas. Use análises reais para encontrar seu pico de tráfego e definir metas.
2. Escolha jornadas. Modele comportamentos realistas do usuário, como navegar, pesquisar e finalizar compra, em proporções realistas. Acessar apenas a página inicial prova pouco.
3. Use um ambiente realista. Um pequeno servidor de teste não pode prever a produção. Observe quaisquer diferenças.
4. Prepare os dados. Use volumes realistas, porque uma consulta rápida em 100 linhas pode rastrear 10 milhões.
5. Avise as pessoas. Informe sua equipe de operações e terceiros e não faça testes de carga em um provedor de pagamento por acidente. Simule serviços externos quando apropriado.
6. Comece aos poucos. Execute primeiro um pequeno teste de fumaça para confirmar se seu script funciona.
7. Monitore tudo. Sem as métricas do servidor, você verá que ele ficou lento, mas não por que.
8. Repita. Execute-o novamente após cada correção e mantenha uma linha de base para comparação.

Lendo os resultados

Os bancos de dados são um gargalo comum, portanto, se o problema for consultas, leia nosso guia sobre otimização de consultas SQL. Essa última linha da tabela é uma armadilha importante: verifique sempre também o estado da máquina que gera a carga.

Erros comuns

• Confundir usuários com solicitações. Deixe claro se um alvo significa usuários simultâneos ou solicitações por segundo.
• Deixar de lado o tempo de reflexão. Isso aumenta o tráfego e gera resultados enganosos.
• Teste tarde demais. Uma semana antes do lançamento não sobra tempo para corrigir problemas de arquitetura.
• Usando um único endpoint. O tráfego real combina leituras, gravações e pesquisas.
• O cache esconde tudo. Solicitações repetidas idênticas podem apenas testar seu cache, portanto varie os dados.
• Testando uma vez. O desempenho muda a cada versão, portanto, execute testes regularmente.

Considerações finais

Execute testes de carga para confirmar se você consegue lidar com o tráfego esperado e testes de estresse para saber o que acontece quando você não consegue. Comece aos poucos: escolha a jornada do usuário mais importante, defina uma meta clara e execute um breve teste de teste com monitoramento ativado. Essa primeira execução geralmente ensina algo e você pode construir a partir daí.

Perguntas frequentes

Continue aprendendo