Como associar as ferramentas de teste de performance de API às três perguntas
Capacidade → geradores de carga
Grupos de threads, ramp-up, workers distribuídos.
Rode antes de releases e depois de mudanças de arquitetura. Caro para rodar continuamente.
Regressão → comparação de tempos
Precisa de uma baseline e de um diff, não de alta concorrência.
A mais barata das três e a que mais costuma faltar.
Corretude → verificação funcional
Asserções sobre os corpos das respostas, inclusive diante de entradas problemáticas.
A base que sustenta as outras duas.
A categoria que falta na maioria dos times
Quase todo time que diz fazer teste de performance tem um gerador de carga. Muito poucos têm algo vigiando regressão a cada mudança. Isso está invertido tanto em custo quanto em retorno.
Capacidade raramente muda entre releases, então testá-la continuamente diz pouco. A regressão de performance chega um pull request por vez e, quando uma rodada trimestral de capacidade a detecta, você está olhando para seis meses de commits sem saber qual deles adicionou a consulta sem índice.
O que procurar em cada categoria
Geradores de carga: dá para fazer asserções sobre os corpos das respostas, ao menos em uma amostra. A maioria permite e poucos times habilitam, e é assim que um teste de carga passa limpo enquanto todas as respostas estão vazias.
Ferramentas de regressão: ela compara com o seu próprio histórico em vez de um limite absoluto. Metas emprestadas não dizem nada sobre o seu produto.
Verificação funcional: ela cobre casos de limite. Uma consulta que degrada com um tamanho de página grande é um problema estrutural que você encontra aqui muito antes de um teste de capacidade revelá-lo.
Como ler um percentil com honestidade
As ferramentas de performance reportam percentis, e eles são rotineiramente mal interpretados de um jeito que esconde justamente o problema que você procura.
Um p50 que parece bom fala da requisição mediana e não diz nada sobre a experiência de quem deu azar. Um p99 que parece bom em um endpoint chamado mil vezes por hora ainda significa dez requisições lentas por hora, ou seja, dez usuários irritados. E uma média sobre todos os endpoints é quase sem sentido, porque mistura um health check com a geração de um relatório.
Dois hábitos resolvem a maior parte disso. Olhe os percentis por endpoint em vez de olhá-los agregados, e olhe p95 e p99 em vez da média. Os endpoints que importam costumam ser uma lista curta, e acompanhar esses quatro números ao longo do tempo é mais útil do que qualquer dashboard que mostre tudo de uma vez.
A ordem que economiza dinheiro
Corretude, depois regressão, depois capacidade. Fazer teste de carga em um endpoint que retorna a coisa errada produz um número confiante sobre nada, e essa é a forma mais comum de um programa de performance desperdiçar seu primeiro trimestre.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
A mesma configuração está disponível no dashboard do TestSprite, se você preferir não instalar nada localmente. O restante da superfície da CLI está no repositório da CLI.
Sessões, valores capturados, ordenação e limpeza estão cobertos na documentação de testes de API.
Dois caminhos, e a escolha é, na verdade, sobre quem é o dono do pipeline. Conectar o GitHub App pelo dashboard não exige nenhuma mudança no seu repositório, porque ele reage ao deployment que o seu build já emite. Adicionar um GitHub Actions passo coloca a verificação no repositório, onde ela é revisada como o resto do build.
O que o TestSprite acrescenta
A coluna da corretude, que é a base das outras duas. Ele faz asserções sobre os corpos das respostas em vez de códigos de status, cobre casos de limite que revelam lentidão estrutural e roda em todo pull request.
A cobertura é gerada a partir de uma passagem de descoberta somada à sua especificação. Auto-Authentication mantém as sessões vivas durante a execução, Dynamic Variables levam valores de uma chamada para outra, Dependency Chains derivam a ordem de execução e Auto-Cleanup remove exatamente o que a execução criou.
O valor está em que seus números de capacidade passam a descrever um serviço que funciona. Uma consulta que degrada com um tamanho de página grande aparece aqui por uma fração do que custa descobri-la em uma rodada de carga, e um endpoint que retorna resultados vazios silenciosamente deixa de ir bem em throughput.
O TestSprite se encaixa nessa categoria?
Na coluna da corretude. Ele verifica comportamento, inclusive casos de limite, e não gera carga sustentada.
Uma única ferramenta pode cobrir as três?
Algumas afirmam que sim. Na prática, gerar carga e fazer asserções profundas sobre os corpos das respostas puxam para lados opostos, porque asserções custam throughput no gerador.
Qual é um limite razoável de regressão?
Defina a partir da sua própria variância. Se seus números oscilam dez por cento de uma execução para outra em um ambiente tranquilo, um limite de cinco por cento é ruído.
Precisamos de geração de carga distribuída?
Só quando um único gerador se torna o gargalo. Muitos times compram capacidade distribuída que nunca saturam.
Onde cada um deve rodar?
Corretude e regressão em todo pull request. Capacidade antes de releases e depois de mudanças de arquitetura.
Três perguntas, três instrumentos.
As ferramentas de teste de performance de API se dividem em geradores de carga, comparação de regressão e verificação funcional. A maioria dos times tem a primeira e não tem a segunda, e a corretude é a base das duas.