Teste de carga de API e a pergunta que ele não consegue responder

O que o teste de carga de API realmente mede

Capacidade: quantas requisições por segundo até a latência degradar. Respondida gerando tráfego concorrente e observando tempos de resposta e taxas de erro.

Corretude: a resposta traz o conteúdo certo. Respondida com asserções sobre o corpo da resposta comparado a uma expectativa.

Um teste de carga que verifica apenas códigos de status vai reportar uma execução limpa enquanto todas as respostas trazem uma lista vazia. O serviço foi rápido e errado, e rápido e errado é pior do que lento e certo, porque ninguém vai investigar.

O que uma suíte funcional diz sobre carga e o que ela não diz

Planos de teste de API gerados incluem casos de limite e casos com perfil de estresse: payloads grandes demais, valores fora do intervalo, combinações incomuns de parâmetros. Eles pegam uma classe real de falha e não são teste de carga. Exercitam as bordas uma de cada vez, em vez de medir o comportamento sob concorrência sustentada.

Então a divisão honesta é esta. Use uma ferramenta de carga dedicada para capacidade. Use verificação funcional para corretude, incluindo os casos extremos que só aparecem com entradas estranhas. Nenhuma substitui a outra, e rodar as duas sai mais barato do que descobrir a lacuna em produção.

Três coisas que vale a pena verificar antes mesmo de fazer teste de carga

Corretude em condições realistas

A lacuna que vale fechar não é entre teste de carga e teste funcional. É que a maioria das suítes funcionais roda contra um ambiente limpo e ocioso, então nunca vê as falhas que aparecem quando o volume de dados é grande ou o estado está bagunçado. Rodar verificações funcionais contra um ambiente que já foi usado é um jeito barato de encontrá-las.

A mesma configuração está disponível no dashboard do TestSprite, se você preferir não instalar nada localmente. O resto da superfície da CLI está no repositório da CLI.

As quatro coisas que decidem se uma suíte de API dura — sessões, valores capturados, ordenação e limpeza — estão na documentação de testes de API.

Como ler um resultado de carga com honestidade

Resultados de carga são superinterpretados mais do que quase qualquer outra saída de teste, normalmente em duas direções.

Um número vindo de um ambiente que não corresponde ao de produção é um ponto de comparação para a sua próxima execução e nada além disso. Metade do banco de dados, um décimo dos dados, nenhum outro tráfego, um tamanho de instância diferente. Apresentar esse número como capacidade é o que faz equipes serem surpreendidas no dia do lançamento por um valor que achavam ter medido.

A outra direção é tratar um teste aprovado como prova de saúde. Se a execução fez asserções apenas sobre códigos de status, você mediu que o serviço responde rápido sob carga, algo que ele faz com muita eficiência quando uma consulta está retornando um conjunto vazio. Ative asserções sobre o corpo das respostas em uma amostra das requisições e a mesma execução passa a dizer alguma coisa.

Rode a verificação de corretude a cada mudança

Teste de carga cabe em um agendamento ou antes de um release. Corretude cabe em cada pull request, porque é aí que uma regressão sai mais barata de corrigir.

• O GitHub App é um webhook que você configura no dashboard do TestSprite. Ele escuta o evento de deploy que seu pipeline já produz, então nada no seu repositório muda.

• GitHub Actions coloca a etapa dentro do seu próprio workflow, configurada pelo terminal.

Onde o TestSprite se encaixa em torno de uma execução de carga

O TestSprite cobre a camada de corretude que faz um número de capacidade significar alguma coisa. Ele exercita a API contra o comportamento que você espera, incluindo casos de limite e de autorização, e reporta o que de fato voltou, não apenas com que rapidez.

A cobertura é gerada a partir de uma passagem de descoberta sobre o serviço em execução, somada à especificação que você tiver, então as entradas estranhas entram sem ninguém precisar escrevê-las. Auto-Authentication mantém as sessões vivas ao longo da execução, Dynamic Variables levam valores de uma chamada a outra, Dependency Chains derivam a ordem de execução a partir do que cada caso precisa e produz, e Auto-Cleanup remove exatamente o que a execução criou.

O ganho é um piso sob o seu trabalho de performance: antes de gastar um dia medindo throughput, você já sabe que o endpoint devolve a coisa certa. A concorrência sustentada continua com o seu gerador de carga, e os dois rodam em cadências diferentes sem interferir um no outro.