Os testes de carga de aplicações web pouco acrescentam se se limitarem a repetir um pedido isolado. Uma página pode responder rapidamente enquanto o processo que inicia falha ao guardar dados, esgota uma dependência externa ou deixa confirmações pendentes. O utilizador não experiencia um URL: completa um objetivo de negócio.
Por isso, um teste útil reproduz percursos representativos, como aceder, pesquisar, criar um registo, atualizá-lo e confirmar uma operação. Não se trata de simular todos os comportamentos possíveis, mas de obter evidência reproduzível sobre o que acontece quando os fluxos que sustentam a operação coincidem no tempo.
Porque é que um único pedido não representa a experiência real
Medir um endpoint isolado pode ser adequado para diagnosticar um componente específico, mas não para responder se uma aplicação suportará a utilização prevista. Um percurso completo introduz elementos que o pedido individual oculta: autenticação, sessões, validações, consultas encadeadas, escrita na base de dados, eventos assíncronos e integrações.
Por exemplo, um fluxo de registo pode exigir a verificação de permissões, a consulta de disponibilidade, a criação de uma entidade, a emissão de uma mensagem e a apresentação de uma confirmação. Se for testada apenas a operação de criação, eliminam-se os custos, as dependências e os estados que podem definir o comportamento real.
A alternativa não é abandonar os testes técnicos de baixo nível. Convém mantê-los para isolar regressões e complementá-los com cenários ponta a ponta para validar a experiência e a capacidade operacional.
Selecionar os percursos que vale a pena testar sob carga
Comece por classificar as ações de acordo com o seu impacto. Dê prioridade às que geram receitas, permitem uma operação crítica, têm prazos limitados ou bloqueiam outros utilizadores. Depois, distinga as ações que têm de continuar a ser interativas daquelas que podem ser processadas em segundo plano ou adiadas sem prejuízo relevante.
- Percursos críticos: acesso, consulta essencial, contratação, pagamento, confirmação ou envio de um pedido.
- Percursos de suporte: atualização de perfil, descarregamento de documentos ou configuração.
- Processos adiáveis: relatórios pesados, sincronizações em massa, notificações ou cálculos não imediatos.
Esta priorização evita uma meta irrealista: que tudo tenha o mesmo desempenho sob qualquer carga. Também permite acordar decisões explícitas. Se houver pressão, poderá ser aceitável atrasar um relatório, mas não impedir uma confirmação já iniciada.
Converter um percurso num cenário verificável
Descreva cada cenário como uma sequência concreta e verificável. Deve incluir o interveniente, os passos, os dados necessários, as dependências envolvidas e o resultado que comprova que a operação foi concluída. Evite utilizar apenas códigos de resposta como sinal de sucesso: um 200 não demonstra que uma reserva, uma encomenda ou uma alteração de estado foi corretamente consolidada.
Interveniente autenticado 1. Inicia sessão 2. Consulta uma lista com filtros 3. Abre um elemento disponível 4. Cria um pedido 5. Confirma o resultado e verifica o seu estado
Defina igualmente o que deve acontecer se uma integração responder lentamente ou não estiver disponível. O comportamento esperado pode ser uma resposta controlada, uma nova tentativa, uma fila ou uma mensagem clara. O importante é que o resultado seja deliberado e verificável, e não um erro ambíguo ou uma operação parcialmente concluída.
Estabelecer a linha de base, os dados e os perfis de utilização
Antes de aumentar a carga, execute o cenário com pouca concorrência num ambiente que se aproxime das condições que se pretende avaliar. Registe tempos por passo, resultados funcionais, utilização de recursos e atividade das dependências. Esta linha de base permite distinguir uma limitação que já existia de uma degradação causada pela pressão aplicada.
Os dados de teste merecem o mesmo cuidado que o guião. Devem ter volume e distribuição suficientes para que as consultas, os índices, as permissões e as regras de negócio se comportem de forma representativa. Reutilizar sempre o mesmo utilizador, registo ou identificador pode criar bloqueios artificiais ou, pelo contrário, ocultar a contenção real. Utilize identidades e entidades isoladas, identifique os dados criados e estabeleça um mecanismo de limpeza seguro.
Não execute cenários destrutivos contra processos de produção, exceto se existir autorização explícita, controlos de âmbito e um plano de reversão. Um ambiente de teste demasiado diferente também não permite extrapolar resultados sem cautela; documente as diferenças de configuração, capacidade, dados e integrações.
O perfil de carga deve expressar a forma como o serviço é utilizado, e não apenas quantos utilizadores simultâneos se pretendem. Defina:
- concorrência-alvo e ritmo de chegada de novas ações;
- combinação de percursos, incluindo consultas e escritas;
- pausas realistas entre passos, quando aplicável;
- duração suficiente para revelar acumulação em filas, pools ou armazenamento;
- aumentos graduais e uma fase estável para observar o sistema.
Um teste breve com muitos pedidos pode revelar um limite de rajada. Um teste sustentado pode revelar fuga de recursos, saturação de ligações ou trabalho assíncrono que cresce mais depressa do que é processado. São questões diferentes e devem ser concebidas como tal.
Medir a degradação, não apenas a latência
Observe a aplicação desde o percurso até aos seus componentes. Combine métricas de sucesso funcional, tempos de resposta por percentil, taxa de erros, novas tentativas, operações incompletas e abandonos do cenário. Relacione-as com a saturação de CPU, memória, ligações, armazenamento, filas, caches e limites dos serviços dependentes.
A rastreabilidade distribuída e os registos correlacionados ajudam a responder onde o tempo é consumido. Sem essa correlação, uma latência elevada pode ser erradamente atribuída à interface quando a origem está numa consulta, numa integração ou numa fila congestionada.
Defina limiares de acordo com o impacto do percurso. Um critério útil combina experiência e correção: por exemplo, que o percurso crítico termine dentro do objetivo acordado para a maioria das execuções, que não ultrapasse uma taxa de falhas definida e que não deixe operações em estados incoerentes. Os valores concretos devem ser acordados com produto, negócio e operação; não existe um número universal válido para todas as aplicações.
Executar incrementos e localizar o primeiro limite relevante
Aumente a carga por etapas e mantenha as mesmas condições de cenário, dados e observabilidade. Quando surgir degradação, não assuma que o primeiro recurso com utilização elevada é a causa. Procure o primeiro componente cuja saturação ou espera coincide temporalmente com o agravamento do percurso.
O estrangulamento pode estar na aplicação, na base de dados, numa integração, na infraestrutura ou numa política de concorrência. Isole hipóteses através de alterações controladas: compare uma consulta instrumentada, desacople uma dependência num ambiente de teste, ajuste o tamanho de um pool ou repita o cenário com uma combinação diferente. Altere uma variável de cada vez para que a evidência continue a ser interpretável.
Decidir a resposta adequada e validar
Corrigir nem sempre significa escalar recursos. Consoante o diagnóstico, poderá ser conveniente otimizar uma consulta, reduzir trabalho redundante, colocar em cache dados que toleram desatualização, limitar uma ação dispendiosa, colocar um processo adiável numa fila ou redesenhar um fluxo para evitar esperas sincronizadas. Escalar pode ser adequado quando a arquitetura o permite e a limitação é de capacidade, mas não resolve uma contenção, uma dependência com limite próprio nem uma operação desnecessariamente dispendiosa.
Após cada alteração, repita a mesma hipótese e compare os resultados com a linha de base. Guarde o guião, a versão do ambiente, a configuração relevante, o perfil de carga, os dados utilizados, as métricas, os rastos e as conclusões. Esta evidência permite verificar que a melhoria não deslocou o problema para outro percurso.
Checklist para alterações e lançamentos
- Os percursos críticos estão priorizados e têm um resultado funcional verificável?
- O perfil representa a concorrência, o ritmo, a duração e a combinação de utilização esperados?
- Os dados estão isolados, são representativos e podem ser limpos sem afetar processos reais?
- Existem limiares acordados para experiência, erros e integridade das operações?
- A observabilidade permite relacionar cada percurso com a aplicação, os dados e as integrações?
- O teste foi repetido após a alteração em condições comparáveis?
- Existe uma decisão documentada se um limiar não for cumprido: corrigir, limitar, adiar, escalar ou redesenhar?
Incorporar estes testes em alterações relevantes transforma a capacidade numa decisão baseada em evidência. O objetivo não é prometer a ausência de incidentes, mas conhecer limites, priorizar riscos e agir antes de o utilizador descobrir a degradação.