Como planejar um teste de carga que represente as jornadas do sistema

O que você vai levar deste guia

• Construa a carga a partir de tarefas e padrões de chegada observados.
• Verifique sucesso funcional junto de latência e consumo.
• Documente diferenças entre teste e produção antes de extrapolar resultados.

Defina a decisão que o teste vai orientar

Um teste de carga precisa responder a uma pergunta concreta: a configuração atual atende ao pico esperado, uma mudança reduziu capacidade ou a recuperação após acúmulo funciona? Cada pergunta pede um cenário diferente. Não comece escolhendo uma quantidade grande de usuários virtuais apenas para produzir um gráfico. Escreva a decisão que será tomada com o resultado e quais condições devem estar presentes para a evidência ser útil.

No exemplo fictício da plataforma Agenda Compartilhada, a equipe espera um aumento de uso no início do expediente, quando supervisores consultam equipes e confirmam distribuições. A dúvida é se o sistema consegue manter essas tarefas utilizáveis enquanto rotinas de relatório também executam. O teste precisa combinar essas jornadas, e não apenas repetir a página inicial. O objetivo é identificar capacidade e gargalos desse recorte, sem declarar desempenho universal da plataforma.

Defina critérios de aceitação ligados à tarefa. Inclua tempo, taxa de falha e correção dos efeitos, com valores escolhidos para a necessidade local. Uma meta de latência deve indicar qual população e qual janela representa. Evite um único tempo médio como critério de toda a experiência. Registre o volume mínimo necessário para interpretar o resultado e as condições que exigem interromper o teste antes de causar efeitos indesejados.

Modele jornadas e taxa de chegada

Liste as sequências relevantes: autenticar, consultar, selecionar e confirmar, por exemplo. Inclua dependências entre chamadas e pausas coerentes com o uso. Um laço que chama a mesma rota sem espera pode medir um limite técnico específico, mas não representar pessoas trabalhando. Isso pode ser útil se for o objetivo, desde que o relatório não confunda esse ensaio com uma simulação de jornada.

Observe a taxa de início de tarefas e a concorrência resultante. Se o sistema fica lento, um modelo de carga pode reduzir involuntariamente novas chegadas porque cada usuário virtual espera mais. Outro modelo mantém a chegada e revela acúmulo. Escolha conscientemente o comportamento que corresponde à pergunta. Não interprete uma carga que se auto-reduziu como prova de que a plataforma sustentou a demanda pretendida.

Na Agenda Compartilhada fictícia, a equipe prepara cenários de abertura do expediente, uso estável e pico de confirmações. As proporções vêm de dados disponíveis ou de premissas registradas quando ainda não há histórico suficiente. Não transforme uma estimativa comercial em fato medido. O teste pode explorar cenários, mas precisa identificar qual deles é esperado, qual é de estresse e qual serve apenas para investigar uma fronteira.

Prepare dados que exercitem o custo real

Use volumes e distribuições que representem as consultas. Uma base com dez registros não reproduz uma busca que em produção percorre milhares, mesmo que o número de usuários seja igual. Inclua variedade de equipes, períodos e tamanhos de resultado. Evite que todos os usuários virtuais consultem a mesma chave se o uso real é distribuído, porque um cache muito favorável pode esconder o custo de recomposição.

Prepare identidades e recursos isolados para operações de escrita. Se todos tentam alterar o mesmo registro, o teste pode medir contenção artificial; se nunca há concorrência sobre recursos compartilhados, pode deixar de testar um problema real. Defina quais colisões são intencionais. Registre como os dados serão criados, restaurados e limpos para que execuções diferentes sejam comparáveis e não dependam do resíduo de testes anteriores.

Não use dados pessoais de produção sem uma preparação e autorização adequadas. Dados fictícios podem manter relações e distribuição relevantes sem reproduzir informação sensível. Verifique que integrações de saída estão isoladas ou usam destinos de teste. Um teste de carga não deve enviar notificações reais nem executar operações externas repetidas por acidente. O ambiente precisa ser seguro para o volume e os efeitos que serão produzidos.

Instrumente gerador e aplicação

A ferramenta de carga precisa conseguir gerar a demanda planejada. Se o próprio gerador satura, o resultado pode parecer um limite do sistema ou uma carga menor que a pretendida. Observe recursos e taxa efetivamente emitida. Registre falhas do gerador separadamente das respostas da aplicação. A medição deve permitir distinguir atraso antes de enviar de tempo gasto pelo sistema depois de receber.

A documentação do Grafana k6 sobre testes automatizados recomenda organizar cenários e critérios de avaliação de forma reutilizável. No método proposto, isso significa separar a descrição da carga das verificações de resultado e manter configurações comparáveis entre execuções. A ferramenta fornece mecanismos, mas a representatividade do cenário e a interpretação continuam sendo responsabilidade da equipe que conhece a operação.

Relacione os resultados com métricas da aplicação: filas, banco, memória e dependências relevantes. Não colete todos os sinais possíveis sem uma pergunta, mas preserve os necessários para explicar uma degradação. Identifique versão de código, configuração e dados usados. Uma comparação sem essas referências pode atribuir uma diferença à alteração errada, especialmente quando o ambiente é compartilhado com outras atividades.

Verifique o sucesso funcional sob pressão

Uma resposta de sucesso pode conter lista vazia inesperada, mensagem de processamento pendente ou resultado parcial. Escreva verificações que reconheçam a conclusão real da jornada. Para uma atribuição, confira que o recurso foi alterado conforme o pedido e que não houve duplicidade. Para uma consulta, valide elementos necessários ao uso. Não transforme todas as respostas rápidas em sucesso apenas porque o código HTTP está dentro de uma faixa.

Inclua verificações após o teste para efeitos acumulados. Contagem de operações confirmadas, relações e estados finais podem revelar perdas que não aparecem em uma chamada individual. A amostra deve ser proporcional ao cenário, com critérios explícitos. Se um erro é esperado por conflito deliberado, registre essa classe separadamente. Misturar rejeições válidas e falhas do sistema impede interpretar a taxa de erro.

Na plataforma fictícia, duas solicitações concorrentes para a mesma distribuição podem receber uma confirmação e uma resposta de conflito, conforme a regra. Isso não é necessariamente defeito. Porém duas confirmações incompatíveis são um problema, mesmo que ambas tenham sido rápidas. A Tironi Tech pode desenvolver verificações de jornada e estado para que o teste de desempenho não premie um caminho que ganha velocidade ao deixar de proteger o comportamento correto.

Execute aquecimento, sustentação e recuperação

Escolha fases de teste que respondam à pergunta. Um aquecimento pode revelar diferenças de cache e inicialização; uma fase sustentada mostra comportamento além de um pico breve; uma recuperação observa o sistema depois de reduzir a carga. Não trate uma execução curta como prova de estabilidade prolongada. Vazamentos, acúmulos e tarefas atrasadas podem precisar de outra duração para aparecer, conforme os sinais investigados.

Estabeleça critérios de interrupção. Um ambiente de teste ainda pode compartilhar recursos ou gerar custos, e continuar após uma falha clara pode não produzir informação adicional. Defina o que preservar ao parar: resultados, estado das filas e referências de execução. A interrupção deve ser uma decisão prevista, não um abandono que deixa tarefas em andamento e torna a próxima execução incomparável.

Observe a recuperação sem reiniciar automaticamente tudo. Se a fila continua crescendo depois da redução de carga, há uma condição importante a investigar. Se o sistema volta ao normal apenas após intervenção, registre esse fato. O objetivo não é obter um gráfico bonito, mas conhecer como a aplicação responde e se recupera. Reinícios podem ser parte de um experimento específico, desde que não apaguem a evidência do comportamento original.

Compare resultados com premissas equivalentes

Ao testar uma mudança, mantenha cenário, dados e configuração comparáveis ou explique diferenças. Registre a taxa realmente atingida, não apenas a configurada. Compare distribuições e classes de tarefa, porque uma melhora em consultas pode esconder piora em confirmações. Se a amostra é pequena, mostre essa limitação e evite conclusões precisas demais. O relatório deve facilitar uma decisão, não exagerar a certeza.

Relacione gargalos a evidências. CPU alta pode acompanhar a degradação, mas não demonstra sozinha sua causa. Uma fila longa pode resultar de trabalhadores insuficientes ou de uma dependência lenta. Use os sinais para formular um experimento de correção e repetir apenas o necessário. Não altere várias dimensões simultaneamente sem registrar a dependência, porque fica difícil saber qual intervenção ajudou e qual acrescentou custo.

Na Agenda Compartilhada fictícia, a conclusão pode indicar que a carga prevista foi atendida nas condições examinadas, mas que a recomposição simultânea de relatórios causou espera acima da meta. Isso orienta uma mudança específica de capacidade ou isolamento. Não converta o resultado em “suporta qualquer quantidade de clientes” nem em um número de usuários sem explicar o perfil que cada um representa.

Transforme o ensaio em uma referência de evolução

Guarde o cenário, os dados de preparação e os critérios que continuam relevantes. Uma versão menor do teste pode acompanhar mudanças frequentes, enquanto ensaios mais extensos ficam ligados a alterações de capacidade ou arquitetura. Evite rodar um teste caro sem decisão associada. A rotina deve detectar regressões úteis e manter seu custo proporcional ao risco do sistema.

Revise o modelo quando o uso mudar. Uma nova funcionalidade pode alterar a mistura de tarefas e tornar o cenário antigo pouco representativo. Compare observação de produção com as premissas do ensaio, preservando privacidade e contexto. Se o teste passa e a operação continua lenta, investigue essa diferença em vez de tratar o resultado como autoridade absoluta. O modelo é uma aproximação que precisa ser mantida.

Finalize com a capacidade observada, condições, gargalos e limitações. Registre o próximo experimento apenas quando houver uma pergunta não resolvida. Um teste de carga bem planejado produz evidência sobre tarefas reais e sua correção sob pressão. Ele ajuda a dimensionar e evoluir o software porque explica o que foi exigido, o que aconteceu e até onde a conclusão pode ser aplicada.

Perguntas frequentes

Mais usuários virtuais significa mais realismo?

Não necessariamente. O comportamento, a taxa de chegada e a mistura de tarefas precisam corresponder ao cenário que você quer avaliar.

Respostas HTTP de sucesso bastam?

Não. Verifique conteúdo e efeitos relevantes, porque uma resposta rápida pode representar uma operação incompleta ou um resultado incorreto.

Posso converter o resultado diretamente em número de clientes suportados?

Somente com premissas e limites claros. Clientes têm perfis de uso diferentes, e o ambiente de teste pode não reproduzir todas as dependências e condições de produção.

Avalie a capacidade do seu sistema com cenários reais

A Tironi Tech pode modelar jornadas, preparar testes e analisar os limites observados para orientar evolução e dimensionamento do software.

Artigos relacionados

• Como modernizar um sistema legado substituindo um módulo de cada vez
• Como diagnosticar a lentidão de uma exportação antes de aumentar o servidor
• Como evitar que duas pessoas sobrescrevam a mesma edição em um sistema

Fontes consultadas

• Grafana k6 — Automated performance testing