Como fazer um teste de carga: guia passo a passo

Para fazer um teste de carga, decida como é um bom resultado, roteirize uma jornada de usuário realista, confira esse script com um único usuário e depois aumente a carga em degraus enquanto observa tempos de resposta e erros. Compare o que você mediu com a meta definida no começo e mude uma coisa de cada vez antes da próxima execução.

O que decidir antes de rodar um teste de carga?

Decida para qual carga você está testando e qual resultado conta como aprovado. Sem as duas coisas, um teste de carga gera números, mas não uma resposta.

Parta do tráfego real se você tiver. Seu analytics ou seus logs de acesso mostram o horário de pico, quantas requisições por segundo chegam e quais páginas ou endpoints recebem a maior parte. Coloque a meta acima desse pico, porque a ideia é saber que você tem folga. Depois escreva os critérios como números, por exemplo: o percentil 95 do tempo de resposta fica abaixo de 500 ms e menos de 1% das requisições falham com 200 usuários virtuais.

Duas decisões práticas também entram aqui. Escolha um ambiente parecido com a produção em tamanho e configuração, porque um servidor de staging com um quarto da capacidade diz pouco sobre a produção. E garanta que você tem permissão para testá-lo: rodar um teste de carga contra um sistema que não é seu, ou que é compartilhado com outros times, sem avisar parece exatamente um ataque.

Como roteirizar uma jornada de usuário realista?

Roteirize o caminho que mais importa para o negócio, passo a passo, com pausas onde uma pessoa de verdade leria ou digitaria. Um script que chama uma única URL o mais rápido possível mede alguma coisa, mas raramente o que importa.

Numa loja pode ser: abrir a página inicial, buscar, abrir um produto, colocar no carrinho. Numa API: fazer login, listar itens, buscar um item. Coloque uma pausa curta entre os passos (tempo de pensamento), use dados de teste variados para que os caches se comportem como na vida real e verifique cada resposta para que uma página de erro não passe por uma resposta rápida.

Este é o script que usamos no exemplo deste guia, escrito para k6. Ele sobe para 10 usuários virtuais, segura a carga e desce, com dois critérios de aprovação embutidos:

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

export const options = {
  stages: [
    { duration: "10s", target: 10 },
    { duration: "20s", target: 10 },
    { duration: "5s", target: 0 },
  ],
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  const res = http.get("http://127.0.0.1:8765/");
  check(res, { "status is 200": (r) => r.status === 200 });
  sleep(1);
}

Uma jornada real tem várias requisições e URLs reais. Esta é minúscula de propósito, para os passos ficarem fáceis de acompanhar.

Por que rodar primeiro um teste de fumaça com um usuário?

Um teste de fumaça com um usuário virtual prova que o script funciona antes de colocar carga de verdade em qualquer coisa. É o jeito mais barato de pegar uma URL errada, um token de login faltando ou uma verificação que sempre falha.

No k6 você pode sobrescrever a carga pela linha de comando, então o mesmo script roda uma vez com um único usuário:

k6 run --vus 1 --iterations 1 script.js

Na nossa execução, a única verificação passou, então o script estava pronto para a carga. Se uma verificação falhar aqui, corrija o script antes de seguir: erros com um usuário viram ruído com cem.

Como subir a carga?

Aumente a carga em degraus e segure cada degrau tempo suficiente para estabilizar, em vez de pular direto para a meta. Uma rampa em degraus mostra a partir de qual nível as coisas começam a piorar.

Um formato comum é subir até um primeiro degrau, segurar alguns minutos, subir para o próximo, segurar de novo e assim por diante até a meta, e depois descer. Olhando cada patamar separado, você vê se os tempos de resposta sobem aos poucos com a carga ou ficam estáveis e depois saltam. Esse salto, o ponto em que cada usuário a mais deixa cada requisição mais lenta, é a coisa mais útil que um teste de carga pode encontrar. Nosso exemplo só sobe para 10 usuários e segura por 20 segundos, o suficiente para mostrar os degraus, mas curto demais para um teste real.

O que observar enquanto o teste roda?

Observe os percentis do tempo de resposta, a taxa de erros e a vazão do lado do gerador de carga, e CPU, memória e carga do banco de dados no sistema testado. As três primeiras dizem como os usuários sentiriam, e as três últimas dizem por quê.

Combine condições de parada antes de começar, por exemplo: parar se a taxa de erros passar de 5% ou se os tempos de resposta chegarem a vários segundos. Continuar forçando um sistema que já caiu não ensina nada, e num ambiente compartilhado atrapalha o trabalho dos outros.

Observe também o gerador de carga. Se ele estiver com a CPU a 100%, as respostas lentas podem estar vindo do seu próprio notebook, e não do servidor.

Como ler os resultados de um teste de carga?

Leia os percentis e a taxa de erros contra os critérios que você anotou no começo. O tempo de resposta médio é o número menos útil do relatório.

Este foi o resultado da nossa execução de exemplo (35 segundos, até 10 usuários virtuais, uma pequena página estática servida num notebook, em 8 de outubro de 2026):

Os números são minúsculos porque o alvo era um arquivo estático na mesma máquina, então eles não servem como benchmark. A lição está no formato: a média ficou acima do percentil 90, porque um punhado de requisições lentas a puxou para cima. Os percentis descrevem o que a maioria das requisições viveu, e o percentil 99 e a requisição mais lenta mostram a cauda que poucos usuários enfrentam. Julgue a execução pelo percentil dos seus critérios e use a cauda para decidir se algo merece um olhar mais de perto.

Se uma execução não bater a meta, mude uma única coisa (uma consulta, uma configuração de cache, um tamanho de instância) e rode o mesmo teste de novo, para saber o que fez a diferença.

Quando rodar o teste a partir da nuvem?

Leve o gerador de carga para a nuvem quando uma máquina não consegue produzir a carga necessária, ou quando importa onde seus usuários estão. Um notebook no Wi-Fi do escritório mede a sua conexão tanto quanto o seu servidor.

O mesmo script k6 pode rodar em infraestrutura que você mesmo opera, no serviço hospedado da Grafana ou na LoadFocus, que roda scripts k6 a partir de 25 regiões na nuvem. Os relatórios dela separam os resultados por localização e mostram o tempo de resposta em relação ao número de usuários virtuais, que é onde o salto descrito acima aparece (como ler os resultados na LoadFocus).

FAQ

Quanto tempo deve durar um teste de carga? O suficiente para segurar a carga da meta por vários minutos depois da subida, para que picos curtos não decidam o resultado. Segurar por pelo menos 10 minutos é um bom começo, e bem mais se você estiver procurando vazamentos de memória ou uma degradação lenta.

De quantos usuários virtuais eu preciso? Calcule a partir do tráfego real. Pegue as requisições por segundo do horário de pico, estime quantas requisições uma jornada faz e quanto tempo ela dura, e dimensione os usuários virtuais para que o teste produza essa taxa com alguma folga.

É seguro fazer teste de carga em produção? Pode ser, com cuidado: teste num horário tranquilo, avise quem opera o sistema, defina condições de parada e comece bem abaixo do pico esperado. Muitos times preferem um ambiente de staging do tamanho da produção, para que um teste que falhe não afete nenhum cliente.

Leituras relacionadas

• Critérios de aprovação de um teste de carga: como definir
• Teste de carga no GitHub Actions: guia prático

As afirmações técnicas deste artigo não foram revisadas de forma independente.