Teste de Performance

Visão Geral do Teste de Desempenho

Um teste de desempenho coloca um número definido de usuários ou requisições simultâneas em um site, aplicativo web ou API, aumenta essa demanda ao longo de uma curva planejada e registra o que muda: tempos de resposta, throughput, taxa de erros e quanta capacidade do servidor, banco de dados e rede o sistema utilizou para acompanhar. O resultado é um conjunto de números comparados com uma meta, não uma impressão de quão rápido o site aparenta ser.

A meta pode ser um site público, uma jornada autenticada através de um portal ou aplicativo SaaS, uma sequência de chamadas API ou um aplicativo web interno protegido por firewall.

O objetivo não é fazer um site rápido em geral. É confirmar que suas páginas, fluxos de trabalho e chamadas API mais importantes atendem aos requisitos definidos nos níveis de tráfego esperados. Um checkout pode funcionar normalmente para um usuário, mas ficar lento ou expirar quando centenas de clientes fazem pedidos ao mesmo tempo.

O teste funcional confirma que uma página ou transação funciona corretamente. O teste de desempenho mede se ela permanece rápida, estável e confiável conforme o tráfego aumenta.

O Que Você Pode Testar em Desempenho?

O teste de desempenho geralmente cobre quatro alvos HTTP/S: sites, aplicativos web, APIs e aplicativos web internos. Cada um requer scripts e medições diferentes.

Por que o Teste de Desempenho é Importante

O valor de um teste de desempenho é uma resposta específica que chega antes que os usuários encontrem o problema:

• Gargalos aparecem antes do lançamento. Uma consulta lenta ou um pool de conexões subdimensionado aparece em um relatório de teste em vez de na fila de suporte.
• Planos de capacidade e escalabilidade são verificados. Regras de autoscaling, configurações de cache CDN e tamanhos de instância são suposições até que o tráfego as comprove.
• As jornadas que geram receita permanecem protegidas. Login, busca, checkout, upload de arquivos e as chamadas API por trás deles são os caminhos a testar primeiro.
• Eventos de pico produzem menos lentidões, erros e interrupções. Lançamentos, campanhas, janelas de inscrição e vendas sazonais geralmente têm padrões de tráfego previsíveis que podem ser testados antecipadamente.
• Regressões são detectadas. Mudanças de código, API, banco de dados, infraestrutura e serviços externos alteram parcialmente o desempenho, e o desvio se acumula ao longo das versões.
• Decisões de lançamento e objetivos de nível de serviço têm evidências. Um número p95 contra uma meta é mais fácil de agir do que uma opinião de que o site “parece lento”.

Tipos de Teste de Desempenho

Cada tipo aplica o tráfego de forma diferente para responder a uma questão específica. A maioria dos programas combina vários tipos.

Teste de resistência e teste soak são dois nomes para o mesmo teste, não dois tipos diferentes. E a linha entre teste de carga e teste de estresse é a que as equipes mais confundem, então tem uma página própria: teste de carga vs. teste de estresse.

Teste de desempenho é a categoria. Cada tipo abaixo altera quanto tráfego chega, quão rápido, e por quanto tempo.

Teste de Desempenho vs. Teste de Carga

Teste de desempenho é a prática mais ampla de avaliar velocidade, estabilidade, escalabilidade e uso de recursos sob diferentes condições. Teste de carga é um tipo de teste de desempenho focado na demanda esperada e de pico.

Os termos são frequentemente usados como sinônimos porque o teste de carga é normalmente o primeiro teste de desempenho que as equipes executam. Outros tipos de teste são necessários para encontrar pontos de ruptura, degradação a longo prazo ou problemas de escalabilidade.

Para uma comparação que também cobre testes de estresse, leia teste de desempenho vs. teste de estresse vs. teste de carga.

Como Realizar Testes de Desempenho

Os passos abaixo aplicam-se a uma landing page, fluxo de checkout ou sequência autenticada de API.

1. Defina a Meta e os Critérios de Aceitação

Declare o que o teste precisa comprovar, em números. Exemplos: tempo de resposta p95 abaixo de 2 segundos para checkout com 1.500 usuários simultâneos; taxa de erro abaixo de 0,5%; a API de pedidos mantém 400 transações por segundo. Um teste sem critérios de aprovação/recusa produz dados, mas não uma decisão.

2. Modele o Tráfego do Site, Aplicação ou API

Recolha análises web, logs de acesso, dados APM e previsões de negócio. Identifique as páginas ou jornadas críticas, como o tráfego se divide entre elas, pico de simultaneidade, taxas de requisição, tempo de reflexão entre etapas, mix geográfico e chamadas API por sessão. Visualizações de página não são usuários simultâneos: 100.000 visualizações diárias podem significar um pico de algumas centenas de sessões simultâneas, e o modelo deve indicar quais.

3. Prepare um Ambiente de Teste Representativo

Combine o stack web de produção, build da aplicação, tamanho do banco, comportamento de CDN e cache, dependências da API, integrações e regras de escalabilidade o mais próximo possível. Use contas de teste seguras e sandboxes de pagamento. Onde o ambiente deve ser diferente, registre a diferença para que ninguém interprete o resultado como garantia de produção.

4. Escolha o Tipo de Teste e o Método de Teste

Escolha carga, estresse, pico, resistência, volume, escalabilidade ou uma combinação com base na questão do passo 1. Depois escolha como gerar tráfego. Testes HTTP/S enviam requisições diretamente e são eficientes para volume alto contra páginas e APIs. Testes em navegadores reais executam JavaScript e seguem comportamentos multi-etapas do usuário, medindo o que a pessoa espera. Muitas equipes executam testes via protocolo para escala e um grupo menor de usuários em navegador real para experiência do usuário.

5. Estabeleça uma Linha de Base

Execute um teste controlado com carga moderada antes de mudar qualquer coisa. Isso confirma que o script completa, os dados de teste são válidos e os geradores de carga não são gargalos. Registre o resultado e as condições do teste porque diferenças no cache, dados de teste ou ambiente podem tornar comparações posteriores pouco confiáveis.

6. Execute o Teste e Monitore Todo o Sistema

Aumente a demanda ao longo da curva de carga planejada (rampa constante, passo ou pico súbito) em vez de aplicar um número não explicado de usuários ao mesmo tempo. Capture dados do servidor web, aplicação, infraestrutura, banco, rede e serviços externos junto com os resultados do teste. Sem dados do servidor, você saberá que algo ficou lento, mas não o que.

7. Analise os Gargalos

Compare resultados com os critérios de aceitação primeiro. Depois correlacione transações lentas ou erros com CPU, memória, banco, cache, fila, pool de conexões, rede e comportamento de dependências na mesma janela temporal. Pare quando puder nomear o componente e a condição sob a qual se degrada, não quando tiver um tempo médio de resposta.

8. Corrija, Reteste e Automatize

Mude uma variável importante de cada vez quando possível, reexecute o mesmo cenário e compare com a linha de base. Depois adicione testes de regressão menores ao CI/CD para que transações críticas rodem a cada build, e agende testes maiores antes de lançamentos principais, campanhas e picos sazonais.

Métricas Chave para Testes de Desempenho

Métricas de teste descrevem o que os usuários experimentariam. Métricas do sistema ajudam a explicar porquê. Você precisa de ambos para os mesmos minutos do teste para chegar à causa.

Métricas de teste identificam sintomas. Dados do servidor, banco e observabilidade localizam a causa. Relatórios de desempenho do LoadView cobrem o lado do teste, desde gráficos resumidos até gráfico cascata para cada sessão. Mas o lado do servidor deve vir do seu próprio monitoramento ou APM, alinhado à linha do tempo do teste.

Como Ler Resultados de Testes de Desempenho

Alguns padrões se repetem na maioria dos sistemas web. Nenhum prova uma causa raiz sozinho, mas indica onde investigar a seguir.

Quando o throughput se estabiliza e o tempo de resposta começa a subir, o sistema provavelmente atingiu um limite de capacidade.

Quando Executar Testes de Desempenho

Teste de desempenho não é uma tarefa única antes do lançamento. Os gatilhos úteis:

• Logo no início do design, enquanto arquitetura e jornadas importantes ainda estão sendo definidas e mudanças são baratas.
• Após mudanças significativas no código, esquema de banco, infraestrutura ou integrações, incluindo mudanças em scripts externos e configuração de CDN.
• No CI/CD, como verificações curtas de regressão nas transações mais críticas.
• Antes de lançamentos principais, campanhas, picos sazonais e migrações, no nível de tráfego previsto para o evento.
• Após incidente em produção, para confirmar que o conserto mantém sob as condições que causaram o problema.
• Em agenda, para detectar deriva de desempenho que nenhuma versão isolada explicou.

Teste de Desempenho vs. Teste de Velocidade de Site

Um teste de velocidade de site carrega uma página ou sessão em um momento, geralmente sem outro tráfego no site, e relata quanto tempo levou. É útil para otimização de front end e para comparar uma build com outra.

O teste de desempenho aplica níveis variados de tráfego ou usuários simultâneos para ver como um site, aplicativo ou API se comporta conforme a demanda aumenta. Ambos reportam tempo de página ou resposta. O teste de desempenho adiciona o que um teste de velocidade não responde: quantos usuários o sistema suporta, taxa de erro no pico, onde o throughput fica estável e quanto tempo o sistema permanece estável. E uma página que pontua bem em um teste de velocidade pode falhar com 500 sessões simultâneas.

Como Escolher uma Ferramenta de Teste de Desempenho

Avalie uma ferramenta de teste de desempenho e carga na nuvem baseada nos testes que você precisa executar, não na quantidade de características:

• Suporta sites, aplicações web multi-etapas e os protocolos de API que você usa, incluindo fluxos de autenticação.
• Pode modelar tráfego realista: jornadas de navegador, sequências de API, tempo de reflexão, variação de dados e curvas de carga ajustáveis.
• Fornece escala suficiente para seu pico, de locais que combinam onde seus usuários estão.
• Suporta testes de protocolo, testes em navegador real ou ambos, dependendo do que você precisa medir.
• Produz percentis utilizáveis, detalhes de erros, resultados por transação e relatórios que você pode compartilhar com pessoas que não executaram o teste.
• Integra-se com CI/CD e com suas ferramentas de monitoramento ou observabilidade para o lado servidor.
• Suporta aplicações web internas quando o teste por trás do firewall é requerido.
• É mantida pelas pessoas que criarão e reexecutarão os testes.

Melhores Práticas em Testes de Desempenho

• Comece com uma pergunta específica de negócio ou engenharia, depois desenhe o teste que a responde.
• Construa cargas baseadas em análises, logs e previsões em vez de suposições.
• Teste login, busca e transações de checkout, não apenas a homepage.
• Use volumes de dados realistas e ambientes que correspondam à produção quando possível, e documente onde diferem.
• Separe problemas no sistema testado de limites na configuração de geração de carga. Verifique CPU e rede do gerador de carga antes de culpar a aplicação.
• Acompanhe percentis, erros, throughput e recursos do servidor juntos para a mesma janela de teste.
• Altere uma variável principal de cada vez ao diagnosticar melhorias.
• Salve linhas de base e compare o mesmo cenário após cada mudança.
• Inclua dependências externas e latência geográfica quando elas afetam a jornada do usuário, já que usuários em produção não as evitam.

Teste de Desempenho com LoadView

O LoadView é uma plataforma de teste de carga na nuvem para medir o desempenho de sites, aplicações web multi-etapas e APIs sob tráfego. A carga vem de uma nuvem gerenciada, então não há infraestrutura de geração de carga para construir ou manter.

Onde o volume de requisições é a questão, testes HTTP/S enviam milhares de requisições simultâneas e relatam tempos de resposta, throughput e erros por endpoint. Onde a jornada do usuário é a questão, teste de carga de aplicação web executa scripts em navegadores reais, então execução de JavaScript e tempo de renderização são parte da medição. Scripts são gravados com o EveryStep Web Recorder clicando a jornada uma vez. Teste de carga de API cobre endpoints REST e SOAP, incluindo sequências autenticadas e multi-etapas.

As curvas de carga são ajustáveis: uma curva em passos aumenta usuários simultâneos gradualmente em um período definido, uma curva baseada em meta gera uma taxa de transação requerida dentro de um intervalo fixo, e uma curva dinâmica ajustável permite que equipes mudem a carga de usuários enquanto o teste roda. O tráfego pode vir de mais de 40 zonas na rede geograficamente distribuída, então latência regional e comportamento de CDN fazem parte do resultado.

Relatórios mostram o plano de execução, transações por minuto, tempos de resposta e erros por tipo, com gráfico cascata para cada sessão para rastrear uma transação lenta até uma requisição específica. LoadView integra-se com Jenkins, Azure DevOps e CircleCI. Jenkins e CircleCI podem usar um Limite de Sessões Falhadas para sinalizar builds quando a porcentagem permitida de sessões falhadas é excedida. Aplicações internas podem ser testadas via IPs estáticos liberados ou um injetor de carga instalado localmente com teste por trás do firewall.

FAQ de Teste de Desempenho