Teste de Carga em um Site de E-Commerce com Claude + JMeter + MCP (Sem Necessidade de Habilidades em JMeter)

Aqui está a configuração: uma equipe de QA tem quatro casos de teste funcionais, acesso ao ambiente de staging e nenhuma experiência em teste de carga. O marketing quer saber se o site suporta 1.200 compradores simultâneos na Black Friday. Nenhum engenheiro de performance na equipe, nenhuma habilidade em JMeter, nenhum gerador de carga.

Realizamos isso como um experimento real (não uma demonstração) contra uma loja PrestaShop ao vivo, usando Claude conectado ao jmx-mcp, um servidor MCP que fornece a um assistente de IA verbos reais do JMeter: gravar uma sessão, construir um plano, carregá-lo, iniciar uma execução, ler os resultados de volta. Aqui está exatamente como isso foi, incluindo as partes que não funcionaram na primeira tentativa.

Tudo abaixo é verificável: os arquivos JMX, dados de teste, exportações do Datadog e até mesmo a transcrição completa do assistente estão vinculados na parte inferior.

A configuração

$ claude mcp add --transport http jmx-mcp http://localhost:8090/mcp
$ claude "Precisamos saber se nossa loja em https://bench.pflb.us
   sobrevive à Black Friday: o marketing espera 1.200 compradores no site
   ao mesmo tempo. Aqui está o arquivo com nossos casos de teste (test-cases.csv) e
   nossos arquivos de dados de teste (test-data/). Planeje e construa quaisquer testes de carga
   que respondam a essa pergunta — e seja gentil com o site ao longo do caminho."

Essa é toda a entrada humana para a fase de planejamento. Sem grupos de threads, sem cronograma de aumento, sem estrutura de plano — apenas o objetivo e a restrição ("seja gentil"). O assistente propôs três planos do JMeter por conta própria: uma linha de base de 20 minutos com 100 usuários, uma escada de 95 minutos (600 → 1.200 → 2.200 → 600) para realmente testar o requisito, e um ensaio de 10 minutos para verificar de forma econômica o cronograma antes de gastar horas reais de gerador.

De casos de teste funcionais a um teste de carga

A entrada foram quatro casos de teste do Jira, exportados como CSV — navegar pelo catálogo, buscar, checkout de convidado, checkout registrado. Testar isso contra a loja ao vivo em um navegador produziu 47 requisições no total, porque uma "página" nunca é uma requisição (menus, tiles de produtos, o mini-cart todos disparam separadamente).

A parte que realmente importa aqui é a correlação. Sites modernos carimbam cada sessão e formulário com tokens de segurança de uso único; reproduzir um token gravado e o servidor rejeita você. Um plano funcional precisa extrair um token fresco a cada passagem e alimentá-lo na próxima requisição. O assistente lidou com isso, incluindo uma armadilha específica do PrestaShop: o token de checkout se regenera após a etapa de informações pessoais, então o extrator precisa ficar após essa etapa, não antes. Errar isso e todo fluxo de checkout no seu teste de carga falha por um motivo que não tem nada a ver com seu gargalo real.

Os dados de teste vieram de três CSVs que a equipe já tinha: 20 contas, 10 termos de busca, 16 URLs de produtos. Vinte contas, não uma — porque mil compradores virtuais atingindo uma conta estariam apenas testando o cache, não a loja.

Validando antes de gastar horas de gerador

Antes de qualquer carga real, os planos passaram por uma escada curta contra a loja ao vivo, cada degrau um pouco mais pesado:

1.889 requisições, zero falhas, e ninguém da equipe abriu um arquivo JMX.

Executando de verdade

$ claude "O plano da escada está validado. Carregue-o na plataforma PFLB
   com seus arquivos de dados e inicie a execução."
● assistente: Carregado — a plataforma criou o teste e retornou sua
   página: platform.pflb.us/account/tests/…  Iniciando a execução agora.
● execução aceita: 2.200 usuários virtuais no pico, gerador de nuvem AWS
● 13:32 UTC — carga começa
● 15:07 UTC — plataforma para a execução exatamente no cronograma: 95 min cravado

95 minutos, quatro atos, em geradores de nuvem (um laptop obviamente não pode simular 2.200 humanos simultâneos):

A página de execução, ao vivo. A história toda é visível em uma tela: usuários sobem a escada, e uma vez que o platô de 2.200 é atingido, a faixa de erro vermelha e o tempo de resposta sobem logo atrás.

A linha interessante aqui não é o colapso de 2.200 usuários — isso é esperado uma vez que você ultrapassa a capacidade. É a coluna de 1.200 usuários, que é a carga prevista real. Erros com 1.200 usuários foram 0.11%. Qualquer monitor de uptime, qualquer teste de fumaça, qualquer clique manual teria reportado verde. Enquanto isso, o checkout — o único fluxo que realmente gera receita — já estava além de seu alvo de 3,5 segundos. Essa é uma falha silenciosa: não apareceria como um incidente no dia, apareceria três semanas depois como um gráfico de carrinhos abandonados.

Vale a pena destacar para qualquer um que esteja avaliando com base em médias: o tempo de resposta médio com 1.200 usuários era perfeitamente razoável em 0.33s enquanto o p95 já havia triplicado. Médias escondem ativamente essa classe de falha — rastreie a cauda lenta, não a média.

Com 2.200 usuários (um caso de estresse 80% acima da previsão), a média de carga do host atingiu 158 em uma máquina de 8 núcleos, onde saudável é aproximadamente 8. Nesse ponto, o próprio agente de monitoramento do site não conseguiu completar suas consultas ao banco de dados — o observador estava enfileirado atrás do observado.

A recuperação foi o único requisito que a loja passou com clareza: os erros pararam dentro de ~10 segundos após a queda da carga, os tempos de resposta voltaram totalmente ao normal em ~3 minutos.

Identificando a causa com o relatório da IA

Dez métricas do Datadog (CPU do host, média de carga, memória, CPU por contêiner para PHP e MySQL, internos do MySQL) foram exportadas como CSVs simples de timestamp/valor e alimentadas na plataforma