Comece pelo objetivo e pela autorização

Defina a hipótese, serviço sob teste, janela, perfil de tráfego, dados e critério de sucesso. Execute somente em ambientes próprios ou explicitamente autorizados; carga pode causar indisponibilidade, custos inesperados ou afetar outras equipes. Combine limites de execução, monitoração e contato de operação antes de começar.

Estabeleça uma linha de base sob condições conhecidas e anote versão, hardware, volume de dados, configuração e região. Sem esse contexto, comparar dois números não identifica a causa de uma diferença.

Use thresholds como critérios de aprovação

Thresholds definem condições de sucesso para métricas. Exemplos incluem taxa de erros inferior a um limite e percentil 95 de duração abaixo de um orçamento. Escolha os números a partir de SLOs e requisitos reais, não copie valores ilustrativos:

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  vus: 10,
  duration: '30s',
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<500'],
  },
};

export default function () {
  const response = http.get(`${__ENV.BASE_URL}/api/catalogo`);
  check(response, {
    'retorna status esperado': (r) => r.status === 200,
  });
}

Este smoke/load test curto ilustra uma única rota e usa 500 ms e 1% apenas como exemplos. Configure BASE_URL para um ambiente de teste autorizado. Thresholds falhados fazem a execução terminar com status de falha; checks, isoladamente, não substituem critérios agregados sobre a carga.

Escolha o modelo de tráfego

Usuários virtuais com iterações modelam clientes que iniciam uma nova iteração após terminar a anterior. Um executor baseado em taxa de chegada tenta iniciar iterações em ritmo definido, exigindo capacidade suficiente no gerador para sustentar o ritmo. A escolha muda o que a carga significa: “dez usuários simultâneos” não equivale a “dez requisições por segundo”.

Use cenários separados para workloads com ritmos diferentes, como leitura de catálogo e criação de pedidos. Parametrize o ambiente e evite que muitas chamadas do mesmo usuário de teste causem contenção artificial em uma única conta.

Smoke, carga, stress e soak

  • Smoke: pouco tráfego para verificar conectividade e script.
  • Carga: perfil esperado para medir comportamento no uso projetado.
  • Stress: aumento controlado para explorar limites e degradação.
  • Soak: carga mantida por mais tempo para revelar acúmulo e vazamentos.

Progrida de forma deliberada. Interrompa se o sistema ou o gerador ultrapassar limites de segurança. Não confunda um teste que satura o gerador de k6 com uma medida fiel da capacidade do serviço.

Interprete percentis e métricas do serviço

A média pode esconder uma cauda de respostas lentas. Observe p90/p95/p99 conforme o requisito, taxa de erro, throughput, conexões, CPU, memória, filas e banco. Compare métricas do gerador com traces e telemetria do serviço para separar gargalo de cliente, rede e servidor. Veja também OpenTelemetry, Serilog e Dynatrace.

Contabilize pausas, cache, conexões reusadas e aquecimento no script. Um script que faz mais trabalho em cada iteração não representa o perfil esperado; reprodutibilidade do gerador é parte do experimento.

Integre ao pipeline com prudência

Use testes pequenos e previsíveis no CI, com thresholds revisados, ambiente isolado e concorrência limitada. Testes longos ou de grande carga podem pertencer a uma etapa agendada ou ambiente específico, não a cada pull request. Armazene relatórios associados ao commit sem incluir tokens ou dados sensíveis.

Para a diferença entre carga e outras verificações, consulte o guia de testes. A página testes .NET e k6 combina uma visão introdutória de testes unitários e desempenho. Para otimização do código e diagnóstico do runtime, consulte a série de performance em .NET.

Documentação e leituras relacionadas