Perguntas frequentes sobre
teste de performance

Quando muitos usuários acessam uma aplicação simultaneamente, diferentes camadas podem atingir seus limites: servidor web, threads do servidor de aplicação, pool de conexões, banco de dados, filas, APIs externas ou recursos de nuvem. A causa não é necessariamente falta de servidores. Uma query lenta, um lock no banco, um limite de threads ou uma integração síncrona pode degradar todo o sistema mesmo quando CPU e memória parecem disponíveis.

Picos de acesso revelam comportamentos que não aparecem em testes leves. A aplicação pode suportar o tráfego médio, mas falhar quando a concorrência aumenta rapidamente, quando milhares de transações disputam o mesmo recurso ou quando uma dependência externa ultrapassa seu limite. Testar antes de uma rematrícula, Black Friday ou lançamento reduz o risco de descobrir o limite em produção.

Não existe um número universal. A capacidade depende da jornada de negócio, do perfil dos usuários, do volume de dados, dos critérios de tempo de resposta, das integrações e da configuração do ambiente. A forma confiável de responder é estabelecer uma baseline de capacidade: uma medição controlada que indique quantos usuários virtuais o sistema suporta mantendo os indicadores definidos.

Escalar a infraestrutura resolve apenas gargalos relacionados ao recurso que foi ampliado. Se o problema está em uma consulta SQL, em contenção de banco, em threads do Tomcat, em serialização de chamadas ou em uma API externa, adicionar CPU ou memória pode aumentar o custo sem remover a causa. O caminho mais seguro é medir antes e depois com telemetria correlacionada.

O erro mais comum é tratar qualquer lentidão como problema de infraestrutura. Aumentar máquinas, clusters ou bancos sem uma baseline pode mascarar gargalos lógicos e criar despesa recorrente. Comece identificando a jornada crítica, o nível de concorrência esperado e os indicadores que caracterizam uma resposta aceitável.

Testes internos frequentemente usam poucos usuários, massas de dados pequenas, jornadas simplificadas e menos integrações. Produção acrescenta concorrência real, dados maiores, chamadas externas, tarefas agendadas e perfis diferentes de acesso. Quanto maior a diferença de topologia, dados e configuração entre ambientes, menor a capacidade de extrapolar resultados.

É necessário transformar o incidente em uma hipótese testável. Registre a jornada afetada, o horário, a concorrência, os erros, os recursos utilizados e as mudanças recentes. Depois, reproduza o padrão em um ambiente controlado e confirme se o gargalo está no código, no banco, na infraestrutura ou em uma dependência. Um plano eficaz combina baseline, testes de carga e estresse, correção priorizada e reteste.

Sim. Ferramentas de inteligência artificial podem acelerar a criação de código, mas o código gerado ainda precisa ser revisado, medido e testado. Uma implementação aparentemente correta pode introduzir consultas repetidas, chamadas sequenciais, alocação excessiva de memória, loops ineficientes ou uso inadequado de conexões. Testes funcionais não garantem desempenho sob concorrência.

O teste de carga avalia como uma aplicação se comporta com um volume definido de usuários, transações ou requisições simultâneas. Ele mede tempo de resposta, taxa de erro, throughput e consumo de recursos para verificar se o sistema atende aos critérios de capacidade. O teste funcional verifica se uma regra de negócio funciona. Uma operação pode funcionar corretamente com um usuário e falhar quando centenas de pessoas executam a mesma jornada ao mesmo tempo.

Teste de carga valida o comportamento no volume esperado. Teste de estresse força o sistema acima do limite esperado para revelar o ponto de ruptura. Teste de resistência (soak) mantém carga por período prolongado para detectar memory leak, exaustão de conexões e degradação gradual. O desenho ideal depende do risco de negócio.

O spike test simula uma mudança brusca de carga em curto intervalo. Ele representa situações como abertura de inscrições, início de uma campanha ou disparo de uma comunicação que concentra acessos. Esse teste verifica se o sistema absorve o aumento, enfileira solicitações, rejeita excesso de forma controlada e retorna ao estado normal depois do pico.

k6 usa scripts em JavaScript e tem boa integração com pipelines — faz sentido quando a equipe quer versionar testes e executá-los no CI/CD. JMeter tem interface visual, ampla adoção e suporte a vários protocolos — útil para acelerar a modelagem inicial. Gatling é orientado a código e eficiente — indicado quando a organização prefere testes como código integrados ao desenvolvimento. A ferramenta não substitui a metodologia.

Uma baseline de capacidade é uma referência medida em condições conhecidas. Ela registra o volume de concorrência que o sistema suporta, os tempos de resposta, a taxa de erro e o consumo de recursos sob uma determinada configuração. Sem baseline, decisões de infraestrutura e lançamento são baseadas em percepção. Com baseline, a equipe consegue comparar versões, dimensionar a nuvem e identificar regressões.

Um lock é um mecanismo de controle de concorrência que impede operações incompatíveis de acessar o mesmo recurso ao mesmo tempo. Um deadlock ocorre quando duas ou mais transações ficam esperando recursos umas das outras, formando um ciclo. Sob carga, locks prolongados aumentam a fila de transações e elevam o tempo de resposta. Para investigar, correlacione a jornada lenta com consultas, duração das transações, bloqueios e plano de execução.

O Tomcat usa threads para processar requisições. Elas podem ficar ocupadas por tempo excessivo quando a aplicação aguarda o banco, uma API externa, disco, filas ou operações síncronas demoradas. Com muitas requisições concorrentes, o pool pode atingir o limite e novas chamadas passam a esperar ou falhar. A correção não é apenas aumentar o número de threads.

Um memory leak ocorre quando objetos que não deveriam mais ser usados continuam referenciados e não podem ser liberados pelo coletor de lixo. Em aplicações Java, o efeito pode ser crescimento contínuo do heap, pausas maiores de garbage collection, queda de throughput e, em casos extremos, OutOfMemoryError. No teste de resistência, o sinal típico é degradação progressiva durante uma carga estável.

Comece alinhando os relógios e os intervalos de coleta. Depois, compare a curva de latência com CPU, memória, I/O de disco, rede, threads, conexões e métricas do banco durante a mesma jornada. CPU alta pode indicar processamento intenso, mas CPU baixa com latência alta pode apontar espera por I/O, locks ou dependência externa.

Graceful degradation, ou degradação controlada, é a capacidade de preservar funções essenciais quando a demanda ou uma dependência excede o limite normal. Em vez de derrubar toda a aplicação, o sistema pode limitar operações não essenciais, usar filas, exibir mensagens claras ou responder com capacidade reduzida. Um teste de estresse ou spike deve verificar se os limites, timeouts e filas funcionam como projetado.

Não. Lighthouse e PageSpeed são úteis para avaliar aspectos de uma página em uma execução sintética, como carregamento e experiência percebida. Eles não certificam a capacidade transacional de uma aplicação com milhares de usuários concorrentes. Para saber se o sistema suporta produção, é necessário testar jornadas críticas, APIs, autenticação, banco de dados, integrações e concorrência representativa.

O preço depende do número de jornadas, endpoints, usuários virtuais, integrações, ambiente e profundidade do diagnóstico. No modelo de pacotes da FATTO, as referências são: Essential (uma jornada e até 15 endpoints) por R$ 18.000 em 5 dias úteis; Standard (até três jornadas e 35 endpoints) por R$ 35.000 em 10 dias; Advanced (web, mobile e APIs até 60 endpoints) por R$ 62.000 em 15 dias; e Custom/Enterprise a partir de R$ 85.000.

A ferramenta automática é adequada para triagem, validação inicial ou execução recorrente de scripts já conhecidos. A consultoria especializada faz sentido quando há risco de negócio, incidente recorrente, lançamento próximo, integração complexa ou necessidade de um laudo técnico acionável. As duas abordagens podem coexistir: a consultoria estrutura o diagnóstico e a equipe usa os scripts depois.

Pergunte quais jornadas serão testadas, qual volume de usuários virtuais será simulado, que tipo de massa de dados será usada e quais critérios definirão aprovação ou falha. Confirme se a empresa mede apenas endpoints ou também correlaciona aplicação, banco e infraestrutura. Verifique quais acessos são necessários, como o ambiente será protegido, se existe autorização formal e quais entregáveis serão fornecidos.

Sim, especialmente quando o lançamento tem data fixa, grande exposição pública ou impacto direto em receita. O assessment antecipa o ponto de ruptura e oferece tempo para corrigir, repetir o teste e ajustar a capacidade antes da janela crítica. Começar entre 60 e 90 dias antes é uma prática prudente para eventos sazonais.

Homologação é geralmente a opção mais segura quando reproduz a arquitetura, configuração, dados e integrações relevantes. Produção pode ser necessária quando não existe um ambiente equivalente, mas exige janela aprovada, autorização formal, limites de carga, monitoramento, plano de interrupção e comunicação com as áreas responsáveis.

O prazo inclui discovery, setup, acessos, criação ou adaptação de scripts, preparação da massa, execução, análise e emissão do laudo. No modelo FATTO: Essential tem prazo de cinco dias úteis, Standard de dez e Advanced de quinze. Escopos Custom são definidos sob consulta. A execução pode ser atrasada se o cliente não liberar ambiente, credenciais, dados ou telemetria.

Gráficos mostram o que aconteceu, mas nem sempre explicam por que aconteceu ou qual correção deve ser priorizada. Um relatório útil conecta a transação afetada ao componente limitante — uma query, lock, pool, thread, chamada externa ou configuração de infraestrutura. A qualidade do laudo depende da instrumentação e do contexto.

Mapeie a jornada completa de rematrícula, incluindo login, consulta de dados, seleção, confirmação e geração de cobrança. Estime a concorrência por minuto, modele uma massa de dados representativa e valide o ambiente com carga, estresse e, se necessário, teste de pico. A baseline deve registrar quantos alunos conseguem concluir a jornada com tempo de resposta previsível.

Teste as jornadas que concentram receita: acesso, busca, página de produto, carrinho, checkout e pagamento. Use carga para validar o volume esperado e estresse ou spike para verificar o comportamento quando a demanda cresce rapidamente. Avalie também filas, timeouts, retentativas e mecanismos de degradação controlada. O objetivo é identificar o limite antes da Black Friday.

Modele a jornada completa, desde autenticação e criação do pedido até a geração, consulta e confirmação do PIX. O teste deve diferenciar o tempo da aplicação do tempo das instituições e APIs externas. Observe pool de conexões, locks, filas, idempotência, timeouts e retentativas. Uma falha em um provedor não deve necessariamente bloquear todo o checkout.

Comece pelas jornadas que afetam o atendimento: login, agenda, confirmação, entrada na consulta, troca de mensagens e acesso a dados autorizados. Considere concorrência de pacientes e profissionais, picos no início dos turnos e dependências como vídeo e autenticação. O teste precisa preservar privacidade e segurança com dados sintéticos ou anonimizados.

O processo deve combinar análise de arquitetura, volume de dados, integrações e padrões de concorrência dos dois ambientes. Crie uma baseline do ambiente atual e projete cenários de crescimento. Teste migração, sincronização, consultas críticas e jornadas de negócio em um ambiente controlado. O laudo deve registrar capacidade, gargalos e riscos residuais para apoiar a decisão do conselho.

Use os 60 dias para trabalhar de trás para frente. Defina a data do lançamento, reserve tempo para diagnóstico, correções, reteste e contingência. O primeiro passo é selecionar as jornadas críticas e estimar o maior volume de usuários simultâneos. Execute carga e estresse em um ambiente autorizado, correlacione latência com infraestrutura e banco e priorize as correções por impacto.

A contratação de especialistas não substitui uma hipótese baseada em evidências. O gargalo pode estar na interação entre aplicação, banco, infraestrutura e dependências externas, e não em uma única camada. Verifique se a equipe tem uma baseline, se os testes reproduzem a jornada real e se os relógios e métricas estão correlacionados.

Um assistente de IA generativa pode acrescentar chamadas externas, processamento variável, consumo de tokens, recuperação de contexto e novas sessões concorrentes. Esses componentes aumentam a latência e podem consumir conexões, threads, memória e limites de taxa do provedor. Teste diferentes tamanhos de prompt, concorrência, duração de sessão e avalie filas, timeouts e circuit breakers.

A queda de um concorrente é um alerta de risco, não uma prova de que seu sistema terá o mesmo comportamento. Faça um inventário das jornadas que concentram receita, estime o pico mais provável e teste o ambiente antes da data crítica. Combine teste de carga, spike e estresse. O resultado deve ser uma baseline documentada, um plano de correção e uma data para reteste.

O teste deve representar concorrência, tamanho e variabilidade dos prompts, tempo de resposta do modelo, chamadas de recuperação de contexto, integrações externas, consumo de tokens, limites de taxa e comportamento de fallback. Como agentes de IA generativa têm dependências variáveis e podem envolver APIs de terceiros, esse escopo exige planejamento específico e autorização dos provedores.