Lista de Verificação de Melhores Práticas para Testes de Carga

# Teste de Carga na Visão de um Engenheiro de Confiabilidade Focado em Performance - Inicie todo teste de carga com uma meta escrita, como latência p95 abaixo de 300 ms a 500 requisições por segundo, não com um vago "ver o que quebra". - Escreva testes de carga como código com k6, Gatling ou Locust e mantenha-os no mesmo repositório do serviço. - Modele tráfego realista a partir de logs de produção: a mistura de endpoints, tamanhos de payload e tempo de espera entre requisições. - Use um modelo de carga aberto com uma taxa de chegada fixa ao testar serviços voltados para a internet, pois modelos fechados escondem atrasos de fila. - Execute tipos de teste separados de propósito: smoke, carga no pico esperado, estresse além do pico, pico súbito e um teste de imersão longo para vazamentos de memória. - Reporte latência como percentis, pelo menos p50, p95 e p99, e nunca confie apenas na média. - Defina limites de aprovação ou reprovação no script de teste para que o CI possa falhar o build automaticamente. - Execute testes de carga contra um ambiente semelhante ao de produção, com os mesmos tamanhos de instância, volume de dados e configuração. - Prepare dados de teste que correspondam à cardinalidade de produção, pois um banco de dados minúsculo faz toda consulta parecer rápida. - Aqueça caches e pools de conexão antes de medir, e exclua o período de aquecimento dos resultados. - Gere carga a partir de máquinas com CPU e rede com folga suficiente, e monitore as métricas do próprio gerador de carga. - Correlacione os resultados do teste com métricas do lado do servidor, rastreamentos e logs para encontrar o gargalo real, em vez de adivinhar. - Acompanhe a taxa de erro e timeouts junto com a latência; uma resposta rápida que retorna um erro não é um sucesso. - Mude uma variável por execução e registre o commit, a configuração e o ambiente com cada resultado. - Execute um teste de smoke de performance curto em cada merge para a main e a suíte completa antes de lançamentos importantes. - Compare os resultados com uma linha de base armazenada e sinalize regressões maiores que uma porcentagem acordada. - Simule ou coloque em sandbox APIs de terceiros que cobram por chamada ou impõem limites de taxa, mas teste suas próprias dependências de verdade. - Encontre o ponto de ruptura e documente como o sistema falha: rejeição graciosa com 429 ou 503 é melhor que colapso. - Verifique se o autoscaling reage a tempo, aumentando a carga gradualmente e medindo quanto tempo a nova capacidade leva para ajudar. - Anuncie testes de carga à equipe e aos engenheiros de plantão, e nunca os aponte para sistemas de produção compartilhados sem aprovação. - Transforme descobertas em planos de capacidade com metas claras de folga, como operar em no máximo 60 por cento do limite testado.