Critérios de aprovação de um teste de carga: como definir

Os critérios de aprovação de um teste de carga são os poucos limites que uma execução precisa cumprir para ser aprovada: um percentil de latência para as requisições que os usuários esperam, uma taxa de erros e uma taxa mínima de requisições, tudo sob uma carga definida. Tire os limites de um objetivo de nível de serviço (SLO), coloque dentro deles limites de regressão vindos de execuções anteriores e deixe o código de saída da ferramenta reprovar a execução só por esses limites rígidos. Todo o resto é um aviso que uma pessoa lê.

Os fatos sobre as ferramentas foram conferidos em 9 de outubro de 2026 na documentação de cada projeto, e todo limite mostrado é um exemplo.

O que faz um teste de carga passar ou falhar?

Uma execução passa quando todos os limites rígidos se mantêm sob a carga planejada e falha assim que um deles é violado. Ela é inválida quando o próprio teste não cumpriu seu papel, sejam quais forem os números.

Um gerador de carga saturado, uma carga que nunca chegou à meta ou um script com erros produzem números sobre a montagem do teste. A LoadFocus, por exemplo, mostra um aviso de saturação do gerador de carga quando algum motor chegou a 80% de CPU ou mais no pico. Os códigos de saída do k6 separam os casos para a CI: 99 indica thresholds violados e 107 uma exceção no script (conferido em 9 de outubro de 2026).

Como transformar um SLO em critérios de teste de carga?

Reescreva cada SLO que a carga pode quebrar, em geral latência e disponibilidade, como um limite sobre o que o teste mede, e deixe esse limite mais rígido que o SLO para que a aprovação tenha folga.

O livro de SRE do Google define um SLO como um valor-alvo ou uma faixa de valores para um nível de serviço medido por um indicador (SLI), com exemplos como: 99% das chamadas Get terminam em menos de 100 ms. Ele pede que um SLO diga como é medido e em que condições vale, e recomenda uma margem de segurança: uma meta interna mais rígida que a prometida aos usuários.

Num teste de carga, essas condições são a carga e o mix de requisições. “95% das chamadas de checkout abaixo de 500 ms” poderia virar, como exemplo, “p95 do checkout abaixo de 400 ms com 300 requisições por segundo durante 15 minutos”. Se ainda não houver SLO, combine um provisório com quem responde pelo produto.

Quais métricas os critérios devem cobrir?

A latência das requisições que os usuários esperam, uma taxa de erros, a taxa de requisições alcançada e, principalmente como avisos, os recursos dos servidores.

• Latência por tipo de requisição. Um percentil global mistura um health check rápido com uma busca lenta. No k6, requisições com tag criam submétricas com limites próprios; no Gatling, details() mira uma requisição ou um grupo. Um teste que freou a própria carga mostra percentis bonitos demais (coordinated omission).
• Erros, no sentido amplo. Um 200 rápido com uma página de erro continua sendo uma falha, então verifique o conteúdo. Uma Response Assertion do JMeter que falha marca sua amostra como malsucedida; os checks do k6 só afetam o código de saída por meio de um threshold.
• Um piso para a taxa de requisições. Num modelo de carga fechado, um sistema lento recebe menos requisições, então uma execução pode cumprir os limites de latência com uma fração da carga planejada (modelo de carga aberto vs fechado).
• Recursos dos servidores. CPU, memória e uso de pools vêm do seu monitoramento. Trate-os como avisos, a menos que um plano de capacidade defina um teto rígido.

Como escolher os números?

O teto vem do SLO e o limite de regressão vem de execuções anteriores do mesmo teste. O SLO diz o que os usuários toleram; as execuções anteriores dizem o que este build costuma fazer.

O livro de SRE desaconselha definir um SLO a partir do desempenho atual. Um limite de regressão existe para notar mudanças, então o desempenho atual é justamente a sua matéria-prima. Rode o build sem alterações várias vezes, com o mesmo ambiente e a mesma carga, anote quanto cada métrica varia e coloque o limite acima da pior execução com alguma folga, sempre abaixo do teto derivado do SLO quando houver um.

Se as execuções de um mesmo build variam mais do que a regressão que você quer detectar, o teste está ruidoso demais para bloquear builds: primeiro alongue a fase estável ou isole o ambiente. Registre novas execuções de referência depois de qualquer mudança intencional.

Quais critérios devem reprovar o build e quais devem só avisar?

Reprove o build nos limites que vêm de um SLO ou que verificam se as respostas estão corretas. Avise sobre percentis de cauda, uso de recursos e desvios lentos, que pedem avaliação; uma barreira que falha por ruído logo acaba desligada.

O plugin ensure do Artillery tem um nível de aviso: uma condição com strict: false é opcional, então descumpri-la não muda o código de saída (conferido em 9 de outubro de 2026). No k6, um check sem threshold nunca reprova a execução. Nas outras ferramentas, deixe os avisos fora das assertions.

config:
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 400
      conditions:
        - expression: "http.response_time.p99 < 1200"
          strict: false

Quando um teste de carga deve parar antes da hora?

Quando continuar só pode causar dano ou já não prova nada: erros muito acima do limite, um sistema já fora do ar ou um gerador que não dá conta. Dê à regra um período de carência para que o ruído do início não a dispare.

Deixe as regras de parada mais frouxas que os limites de aprovação: elas protegem um ambiente compartilhado. No k6, abortOnFail interrompe o teste assim que um threshold falha, depois de um delayAbortEval opcional. A documentação do Locust sobre extensões mostra um greenlet em segundo plano que encerra a execução quando a proporção de falhas passa de um limite. No Gatling, crashLoadGeneratorIf para o gerador com um código de falha quando uma condição é verdadeira na sessão de um usuário virtual. Um Thread Group do JMeter pode parar o teste diante de um erro de sampler, o que serve para uma verificação de correção (tudo conferido em 9 de outubro de 2026).

Como cada ferramenta codifica os critérios?

k6 e Artillery transformam um limite rígido violado em um código de saída diferente de zero, o Locust faz isso para qualquer requisição com falha ou para limites que você mesmo programa, e as assertions do Gatling reprovam o build. O JMeter deixa o veredito para uma etapa depois da execução.

k6: os thresholds ficam nas opções do script. Este exemplo reprova pelo p95 das requisições com a tag name: checkout ou por 0,5% de erros, e interrompe o teste após um minuto se os erros passarem de 5%:

export const options = {
  thresholds: {
    "http_req_duration{name:checkout}": ["p(95)<400"],
    http_req_failed: [
      "rate<0.005",
      { threshold: "rate<0.05", abortOnFail: true,
        delayAbortEval: "1m" },
    ],
  },
};

Gatling: as assertions combinam um escopo (global, forAll, details), uma estatística como um percentil ou requestsPerSec, e uma condição. Elas são avaliadas ao fim da execução, e uma única assertion com falha reprova a simulação.

O Locust sai com código 1 quando alguma requisição falhou, e --exit-code-on-error muda esse código. Para uma proporção ou um percentil, defina environment.process_exit_code num listener de quitting; o código-fonte do Locust dá prioridade a esse valor.

O JMeter julga cada amostra com suas assertions, e as suas opções de linha de comando não trazem nenhum limite para a execução inteira. Quem decide é a CI: um script curto sobre o arquivo de resultados, como no nosso guia de GitHub Actions, ou o jmeter-maven-plugin, um plugin de terceiros cujo goal results reprova o build se uma única amostra falhar, a menos que errorRateThresholdInPercent defina uma taxa (conferido em 9 de outubro de 2026).

A LoadFocus avalia as execuções com thresholds de aprovação ou reprovação salvos no teste: tempos de resposta p95 e p99 máximos, taxa de erros máxima e taxa mínima de requisições, cada um opcional. Cada execução recebe um selo PASS ou FAIL com os valores medidos e as metas, e uma API entrega o veredito a um pipeline. A LoadFocus roda cenários do k6 com taxa de chegada usando um número fixo de usuários, então ali um piso de taxa verifica o que esses usuários alcançaram.

FAQ

O tempo de resposta médio deve ser um critério de aprovação? Raramente. O livro de SRE prefere percentis: uma média esconde a cauda longa e pode ficar estável enquanto as requisições mais lentas ficam muito mais lentas.

Quantos critérios de aprovação um teste de carga deve ter? Um punhado de limites rígidos, mais avisos. O livro de SRE recomenda ter o menor número possível de SLOs e diz que, se citar um deles nunca ajuda a vencer uma discussão sobre prioridades, provavelmente não vale a pena mantê-lo. Aplique a mesma regra a cada limite de um teste de carga.

Um teste de carga pode passar com algumas requisições com falha? Sim, se a taxa de erros ficar abaixo do limite. Verifique o comportamento padrão da sua ferramenta: o Locust reprova a execução com uma única requisição com falha.

Leituras relacionadas

• Teste de carga no GitHub Actions: guia prático
• Coordinated omission: o que é e como evitar
• Como fazer um teste de carga: guia passo a passo
• Pontuação Apdex: o que é e como calcular
• SLO vs SLA: a diferença, os SLIs e o orçamento de erros

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