As três perguntas dentro do teste de performance de API
| Capacidade | Quanto tráfego simultâneo até a latência degradar. Exige um gerador de carga. Rode antes dos releases e depois de mudanças de arquitetura. |
| Regressão | Este pull request deixou alguma chamada mais lenta do que ela era. Exige uma baseline e comparação, não alta concorrência. |
| Corretude | A resposta está certa, inclusive com entradas esquisitas. Exige asserções sobre os corpos das respostas. É a mais barata das três e a que mais costuma ser deixada de lado. |
Por que a regressão é a primeira que vale automatizar
Teste de capacidade é caro de rodar e raramente muda de um release para outro. Regressão de performance é o oposto: acontece aos poucos, um pull request por vez, e quando um teste de capacidade finalmente percebe, você está olhando para seis meses de mudanças acumuladas sem ideia de qual delas causou aquilo.
Uma comparação simples do tempo de cada chamada contra uma baseline, rodando a cada mudança, pega a consulta dez vezes mais lenta no dia em que ela entra. Isso vale mais do que um relatório trimestral de capacidade.
O piso da corretude
Nenhum número de tempo significa alguma coisa se as respostas estão erradas. Um endpoint que retorna um array vazio é extremamente rápido. Isso parece óbvio e é exatamente assim que um serviço vai para produção com um filtro quebrado e gráficos de latência excelentes.
Então a ordem é corretude, depois regressão, depois capacidade. A maioria dos times faz na ordem inversa, porque teste de capacidade é o que se parece com trabalho de performance.
O que a cobertura gerada acrescenta
Os planos de teste de API incluem casos de fronteira e casos com perfil de estresse, que revelam as combinações de entrada que deixam um endpoint lento por um motivo estrutural, e não por causa de carga. Uma consulta que degrada com um tamanho de página grande aparece aqui muito antes de um teste de capacidade encontrá-la.
Isso não é teste de carga nem substitui um. É a camada barata que fica embaixo.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
Se você preferir não instalar nada, o dashboard faz a mesma coisa. Todo o resto que a linha de comando faz está no repositório do CLI.
Sessão, estado, ordenação e limpeza estão cobertos na documentação de testes de API.
Onde costuma estar a regressão
Quando um endpoint fica mais lento entre releases, a causa é quase sempre uma de três coisas, e conhecê-las encurta bastante a busca.
Uma consulta que perdeu o índice, ou ganhou uma condição que o índice não cobre. Essa é de longe a mais comum e produz uma mudança invisível no diff, porque o SQL parece estar certo.
Uma chamada que antes era uma ida e volta e agora são várias, geralmente porque algum helper passou a buscar os registros relacionados um a um dentro de um laço. O código ficou mais legível do que era, e é por isso que ele passa no review.
Algo que cresceu. Uma resposta que inclui uma coleção que antes tinha cinco itens e agora tem quinhentos, porque o produto deu certo. Nada quebrou, e o endpoint agora está lento para todo mundo.
Cadência
Dois caminhos, e a escolha na verdade é sobre quem é dono do pipeline. Conectar o GitHub App pelo dashboard não exige mudança nenhuma no seu repositório, porque ele reage ao deployment que o seu build já emite. Adicionar um passo do GitHub Actions coloca a verificação dentro do repositório, onde ela é revisada como o resto do build.
O que o TestSprite cobre dos três
O terceiro, corretude, e os casos de fronteira que revelam lentidão estrutural. Uma consulta que degrada com um tamanho de página grande aparece como um caso de fronteira falhando ou lento muito antes de um teste de capacidade chegar nela, e por uma fração do custo.
A cobertura vem do API Discovery somado à sua especificação, com planos que abrangem as categorias funcional, de schema, de autorização, de tratamento de erros e de fronteira. O Auto-Authentication mantém as sessões vivas ao longo da execução, o Dynamic Variables leva valores de uma chamada para outra, o Dependency Chains deriva a ordem de execução a partir do que cada caso precisa e produz, e o Auto-Cleanup remove exatamente o que a execução criou.
O que você ganha é a camada que falta na maioria dos programas de performance: algo rodando a cada pull request que perceberia um endpoint retornando resultados vazios, que é justamente a falha que um gráfico de throughput reporta como excelente.
O TestSprite mede latência?
Ele verifica corretude, não capacidade. Tempo e throughput sob concorrência sustentada pedem uma ferramenta dedicada de performance.
O que é uma baseline razoável?
Os seus próprios números anteriores no mesmo ambiente. Metas absolutas emprestadas de outros produtos dizem muito pouco.
Testes de performance devem bloquear um merge?
Uma regressão grande em um caminho crítico, sim. Variação pequena, não, senão você vai gastar o seu tempo ajustando limiares em vez de entregar.
Por que os nossos números variam tanto?
Normalmente é ambiente compartilhado, cache frio ou volume de dados diferente. Controle isso antes de confiar em qualquer comparação.
Uma única ferramenta dá conta das três?
Algumas dizem que sim. Na prática, a pergunta de capacidade pede um gerador de carga e a pergunta de corretude pede asserções sobre os corpos das respostas, e fazer as duas bem em uma mesma execução é mais raro do que o marketing sugere.
Corretude, depois regressão, depois capacidade.
Teste de performance de API são três perguntas com três respostas. A regressão é a que vale automatizar a cada mudança, a corretude é o piso embaixo de tudo, e a capacidade é a cara, justamente por onde a maioria dos times começa.