Ferramentas de teste de carga: o que verificar antes de precisar de uma

As categorias de ferramentas de teste de carga

• Orientadas a script. Você escreve o cenário em código e executa localmente ou de forma distribuída. Flexível, fácil de revisar e com a manutenção por sua conta.

• Baseadas em plano. Você monta o cenário em uma UI e guarda como arquivo de projeto. Suporte amplo a protocolos, mas incômodo de revisar em um pull request.

• Hospedadas. Outra pessoa executa os geradores a partir de várias regiões. Nenhuma infraestrutura para manter, e você paga por execução.

Para a maioria dos times, a escolha importa menos do que saber se o teste está medindo algo que faça sentido.

Três verificações antes de sequer fazer um teste de carga

• Está correto a uma requisição por segundo? Testar carga em um endpoint quebrado mede a velocidade com que você consegue errar. Esse é o trimestre desperdiçado mais comum em trabalho de performance.

• A execução limpa o que criou? Um teste de carga que cria registros e os deixa por lá muda o comportamento da próxima execução e de tudo o mais naquele ambiente.

• O ambiente é representativo? Resultados de um ambiente com um décimo dos dados são um número, não uma previsão.

A configuração que quase ninguém liga

Faça asserções sobre o corpo das respostas, ao menos em uma amostra das requisições. A maioria das ferramentas de carga suporta isso, e a maioria dos times deixa desligado porque custa throughput no gerador. A consequência é um relatório de carga todo verde enquanto cada resposta traz uma lista vazia.

Rápido e errado é pior do que lento e certo, porque ninguém vai investigar.

O valor está no cenário

Os times gastam muito tempo escolhendo entre ferramentas de carga e pouquíssimo tempo no cenário, o que é o contrário do que deveria ser, porque é o cenário que determina se o número significa alguma coisa.

Mil usuários virtuais martelando um único endpoint é fácil de montar e raramente se parece com alguma coisa. O tráfego real é uma mistura: leituras na maior parte, algumas escritas, um relatório caro de vez em quando, tudo isso contra uma base que já acumula um ano de histórico. Um sistema pode aguentar a versão sintética com folga e cair na versão realista, porque a contenção está em algum ponto que o cenário simples nunca tocou.

Montar uma mistura parecida com o seu tráfego de verdade leva uma tarde olhando logs e vale mais do que qualquer diferença de funcionalidade entre as ferramentas que você está comparando.

Onde entra a verificação funcional

Os planos de API gerados incluem casos de borda e casos com cara de estresse, que revelam as combinações de entrada que deixam um endpoint lento por um motivo estrutural. Uma consulta que degrada com um tamanho de página grande aparece aqui muito antes de um teste de capacidade encontrá-la, e por uma fração do custo.

Isso não é teste de carga e não substitui um. É a camada barata que fica embaixo, e é a camada que a maioria dos times pula no caminho até comprar um gerador de carga.

Se você prefere não instalar nada, o dashboard faz a mesma coisa. Tudo o mais que a linha de comando consegue fazer está no repositório da CLI.

Os detalhes de funcionamento estão na documentação de testes de API.

Cadência

Carga antes dos releases e depois de mudanças de arquitetura. Corretude em todo pull request, porque é aí que corrigir uma regressão sai mais barato.

• 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 muda no seu repositório.

• GitHub Actions coloca o passo dentro do seu próprio workflow, configurado pelo terminal.

O que o TestSprite cobre antes da execução de carga

As três verificações desta página, como produto. Corretude a uma requisição por segundo, por meio de cobertura gerada que faz asserções sobre o corpo das respostas em vez de códigos de status. Limpeza, porque o Auto-Cleanup remove exatamente o que uma execução criou, em vez de fazer correspondência por nome. E os casos de borda que revelam lentidão estrutural, que aparecem aqui muito antes de um teste de capacidade chegar neles.

A cobertura vem do API Discovery mais a sua especificação. O Auto-Authentication mantém as sessões vivas, as Dynamic Variables levam valores de uma chamada para outra e as Dependency Chains derivam uma ordem de execução segura.

Seu gerador de carga continua exatamente onde está. O que você ganha é que o número produzido por ele descreve um serviço que devolve a resposta certa, o que é a diferença entre uma medição e um número confiante sobre coisa nenhuma.