DEV Community

Cover image for Teste de Performance: Tipos, Métricas e Como Funciona
Lucas
Lucas

Posted on • Originally published at apidog.com

Teste de Performance: Tipos, Métricas e Como Funciona

Um software que funciona em testes funcionais não necessariamente funciona sob carga. Uma API pode retornar a resposta correta em ambiente local, passar no QA e ainda falhar quando centenas ou milhares de usuários acessam ao mesmo tempo. Teste de desempenho é o processo de medir velocidade, estabilidade e escalabilidade quando o sistema está ocupado.

Experimente o Apidog hoje

Neste guia, você verá o que testar, quais métricas acompanhar, como encaixar testes de desempenho no fluxo de desenvolvimento e como executar esse tipo de verificação em APIs.

O que é teste de desempenho

Teste de desempenho avalia como um sistema se comporta sob uma carga definida.

Ele não responde apenas:

“A funcionalidade funciona?”

Ele responde:

“Com que velocidade ela responde, quantas requisições suporta e como falha quando chega ao limite?”

Exemplo prático:

Um endpoint de login pode estar funcionalmente correto:

POST /login
Content-Type: application/json

{
  "email": "user@example.com",
  "password": "secret"
}
Enter fullscreen mode Exit fullscreen mode

Resposta esperada:

{
  "token": "jwt-token"
}
Enter fullscreen mode Exit fullscreen mode

Mas sob carga, esse mesmo endpoint pode apresentar:

  • tempo médio aceitável;
  • percentil 95 muito alto;
  • aumento de erros 500;
  • saturação de CPU;
  • gargalo no banco de dados.

Nesse caso, o teste funcional passa, mas a experiência real do usuário falha.

O resultado de um teste de desempenho não deve ser tratado como um simples “passou” ou “falhou”. O ideal é produzir um perfil do sistema:

  • com X usuários simultâneos;
  • a vazão foi Y requisições por segundo;
  • o p95 ficou em Z ms;
  • a taxa de erro foi N%;
  • o gargalo apareceu em CPU, memória, banco ou dependência externa.

Esse perfil ajuda a definir capacidade, SLAs/SLOs e limites aceitáveis antes do deploy.

Principais tipos de teste de desempenho

Teste de desempenho é uma família de testes. Cada tipo aplica carga de uma forma diferente para responder a uma pergunta específica.

1. Teste de linha de base

O teste de linha de base mede o comportamento do sistema sob carga normal.

Use para responder:

“Como o sistema se comporta hoje em condições esperadas?”

Exemplo:

  • 50 usuários virtuais;
  • 5 minutos de duração;
  • fluxo principal da aplicação;
  • ambiente semelhante à produção.

Resultado esperado:

Usuários virtuais: 50
Duração: 5 min
p95: 320 ms
Taxa de erro: 0.1%
Throughput: 180 req/s
Enter fullscreen mode Exit fullscreen mode

Essa linha de base vira a referência para comparar mudanças futuras.

2. Teste de carga

O teste de carga aplica o tráfego de pico esperado.

Use para responder:

“O sistema aguenta o tráfego máximo esperado em um dia normal?”

Exemplo:

  • pico previsto: 500 usuários simultâneos;
  • limite de resposta: p95 abaixo de 800 ms;
  • taxa de erro máxima: 1%.

Critérios de aceitação:

p95 <= 800 ms
error_rate <= 1%
CPU <= 80%
memory sem crescimento contínuo
Enter fullscreen mode Exit fullscreen mode

Se o sistema cumprir esses limites, ele suporta a carga esperada.

3. Teste de estresse

O teste de estresse aumenta a carga além do esperado até o sistema degradar ou falhar.

Use para responder:

“Onde está o ponto de ruptura?”

Exemplo de rampa:

100 usuários -> 300 -> 600 -> 1000 -> 1500
Enter fullscreen mode Exit fullscreen mode

Observe:

  • quando a latência dispara;
  • quando os erros começam;
  • qual recurso satura primeiro;
  • se o sistema degrada de forma controlada;
  • se há perda de dados ou falhas em cascata.

Uma degradação aceitável pode ser:

Sistema mais lento, mas ainda respondendo.
Fila aumentando, mas sem perda de mensagens.
Erros controlados com status 429 ou 503.
Enter fullscreen mode Exit fullscreen mode

Uma degradação ruim:

Banco indisponível.
Timeouts em cascata.
Processos reiniciando.
Dados inconsistentes.
Enter fullscreen mode Exit fullscreen mode

4. Teste de pico

O teste de pico aplica uma subida brusca de carga e depois reduz rapidamente.

Use para responder:

“O sistema aguenta rajadas repentinas?”

Cenários comuns:

  • campanha de marketing;
  • venda relâmpago;
  • notícia viral;
  • início de evento ao vivo;
  • abertura de inscrições.

Exemplo:

50 usuários por 2 min
1000 usuários por 1 min
50 usuários por 2 min
Enter fullscreen mode Exit fullscreen mode

Esse teste verifica se o sistema escala rápido o suficiente e se volta ao estado normal após o pico.

5. Teste de capacidade

O teste de capacidade identifica o limite máximo sustentável do sistema.

Use para responder:

“Quantos usuários ou requisições por segundo o sistema suporta mantendo os objetivos definidos?”

Exemplo de objetivo:

p95 <= 500 ms
error_rate <= 0.5%
CPU <= 75%
Enter fullscreen mode Exit fullscreen mode

Resultado:

Capacidade máxima sustentável: 720 usuários simultâneos
Throughput máximo estável: 2.100 req/s
Enter fullscreen mode Exit fullscreen mode

Esse número pode ser usado para:

  • planejamento de infraestrutura;
  • configuração de autoescalonamento;
  • definição de limites de tráfego;
  • estimativas de custo.

6. Teste de imersão

O teste de imersão, também chamado de teste de estabilidade ou resistência, mantém carga moderada por um período longo.

Use para responder:

“O sistema degrada depois de horas em execução?”

Exemplo:

200 usuários virtuais
Duração: 8 horas
Carga constante
Enter fullscreen mode Exit fullscreen mode

Problemas que esse teste encontra:

  • vazamento de memória;
  • conexões não fechadas;
  • crescimento de filas;
  • exaustão de pool;
  • lentidão progressiva;
  • logs crescendo sem controle.

Testes curtos normalmente não revelam esse tipo de falha.

Quais testes executar primeiro

Para a maioria das equipes, uma sequência prática é:

  1. Linha de base para entender o comportamento atual.
  2. Carga para validar o pico esperado.
  3. Imersão para verificar estabilidade.
  4. Estresse para encontrar o limite.
  5. Pico para sistemas com tráfego imprevisível.

Não comece com um teste extremo. Primeiro estabeleça uma referência confiável.

Métricas que definem um bom resultado

Um teste de desempenho só é útil se você coletar as métricas certas.

Tempo de resposta

Tempo de resposta é a duração entre a requisição e a resposta.

Exemplo:

GET /products/123
Tempo de resposta: 240 ms
Enter fullscreen mode Exit fullscreen mode

Não analise apenas a média. Use percentis.

Métricas úteis:

p50: 120 ms
p90: 300 ms
p95: 450 ms
p99: 1200 ms
Enter fullscreen mode Exit fullscreen mode

A média pode esconder problemas. Um sistema com média de 200 ms ainda pode ter p99 de 3 segundos. Usuários reais sentem essa cauda lenta.

Vazão

Vazão é o volume de trabalho concluído por unidade de tempo.

Normalmente aparece como:

requisições por segundo
transações por minuto
mensagens processadas por segundo
Enter fullscreen mode Exit fullscreen mode

Exemplo:

Total de requisições: 120.000
Duração: 10 minutos
Throughput: 200 req/s
Enter fullscreen mode Exit fullscreen mode

Essa métrica mostra a capacidade real do sistema.

Concorrência

Concorrência é o número de usuários, conexões ou operações simultâneas.

Exemplo:

100 usuários simultâneos
500 usuários simultâneos
1000 conexões abertas
Enter fullscreen mode Exit fullscreen mode

A pergunta prática é:

“Em qual nível de concorrência o tempo de resposta ultrapassa o limite aceitável?”

Exemplo:

Até 500 usuários: p95 <= 700 ms
A partir de 800 usuários: p95 > 2 s
Enter fullscreen mode Exit fullscreen mode

Nesse caso, o limite operacional está entre 500 e 800 usuários simultâneos.

Taxa de erro

Taxa de erro é a porcentagem de requisições que falham.

Exemplo:

Total: 100.000 requisições
Falhas: 750
Taxa de erro: 0.75%
Enter fullscreen mode Exit fullscreen mode

Inclua erros como:

  • 5xx;
  • timeouts;
  • falhas de conexão;
  • respostas inválidas;
  • violações de assertivas.

Um sistema rápido, mas com alta taxa de erro, não tem bom desempenho.

CPU e memória

CPU e memória ajudam a explicar por que a latência ou os erros aumentam.

Exemplos:

CPU em 100% + latência alta = possível gargalo de computação
CPU baixa + latência alta = possível gargalo em banco, lock ou dependência externa
Memória crescendo continuamente = possível vazamento
Enter fullscreen mode Exit fullscreen mode

Também monitore:

  • uso de disco;
  • I/O;
  • conexões de banco;
  • tamanho de filas;
  • latência de dependências externas;
  • garbage collection;
  • saturação de pool de threads.

Como interpretar um resultado

Evite relatórios vagos como:

O teste passou.
Enter fullscreen mode Exit fullscreen mode

Prefira uma leitura objetiva:

Com 500 usuários simultâneos durante 10 minutos, o sistema manteve 1.200 req/s,
p95 de 620 ms e taxa de erro de 0.2%. A CPU ficou em 72% e a memória permaneceu
estável. O gargalo principal apareceu no banco de dados quando a concorrência
passou de 800 usuários.
Enter fullscreen mode Exit fullscreen mode

Esse formato ajuda o time a tomar decisões:

  • manter a arquitetura atual;
  • otimizar consulta;
  • adicionar índice;
  • aumentar pool;
  • configurar cache;
  • ajustar autoscaling;
  • limitar tráfego;
  • adiar release.

Onde o teste de desempenho entra no processo

Teste de desempenho não deve ser uma etapa única no fim do projeto.

Em sistemas com deploy contínuo, o desempenho pode regredir em pequenas mudanças:

  • uma nova consulta sem índice;
  • um endpoint chamando serviço externo;
  • uma serialização pesada;
  • uma integração adicionada;
  • uma mudança no payload;
  • um aumento no número de chamadas ao banco.

O modelo mais eficiente é tratar desempenho como parte da definição de qualidade.

Defina orçamentos de desempenho

Crie limites para caminhos críticos.

Exemplo:

POST /login
p95 <= 500 ms
error_rate <= 0.5%

GET /products
p95 <= 700 ms
error_rate <= 1%

POST /checkout
p95 <= 1000 ms
error_rate <= 0.2%
Enter fullscreen mode Exit fullscreen mode

Esses limites devem ser conhecidos por devs, QA e operações.

Execute testes leves em CI/CD

Para pull requests, use testes curtos e objetivos.

Exemplo:

Duração: 2 a 5 minutos
Carga: baixa ou moderada
Objetivo: detectar regressões óbvias
Enter fullscreen mode Exit fullscreen mode

Se o orçamento for quebrado, o build deve falhar.

Um fluxo possível:

Pull request
  -> testes unitários
  -> testes funcionais
  -> teste de carga leve
  -> validação de orçamento
  -> merge
Enter fullscreen mode Exit fullscreen mode

Você pode integrar esse processo ao seu pipeline de CI/CD.

Agende testes pesados fora do PR

Testes de estresse, pico e imersão são mais longos e caros. Execute em janelas agendadas:

  • antes de releases importantes;
  • durante a noite;
  • semanalmente;
  • antes de campanhas com tráfego previsto;
  • após mudanças de infraestrutura.

Por que testar desempenho na camada de API

Para muitos sistemas, a camada de API é o melhor ponto para começar.

APIs são boas candidatas porque:

  • concentram regras de negócio;
  • são mais estáveis que interfaces gráficas;
  • permitem cenários automatizados;
  • têm respostas fáceis de validar;
  • produzem métricas consistentes;
  • são adequadas para execução em pipeline.

Exemplo de cenário de API:

1. Criar usuário
2. Fazer login
3. Buscar produtos
4. Adicionar item ao carrinho
5. Finalizar pedido
6. Validar resposta
Enter fullscreen mode Exit fullscreen mode

Esse tipo de fluxo é mais realista do que testar apenas um endpoint isolado.

O teste de desempenho de API permite medir a experiência real do backend sem depender da UI. Manter esses testes junto com testes funcionais de API ajuda a validar correção e velocidade no mesmo ciclo.

Erros comuns em testes de desempenho

Alguns erros tornam o resultado do teste pouco confiável.

1. Testar em infraestrutura irrealista

Um teste em um laptop ou em homologação subdimensionada não representa produção.

Evite:

Ambiente local
Banco pequeno
Cache diferente
Poucos recursos
Configuração fora do padrão de produção
Enter fullscreen mode Exit fullscreen mode

Prefira:

Ambiente semelhante à produção
Dados representativos
Mesmas configurações críticas
Monitoramento habilitado
Dependências próximas do cenário real
Enter fullscreen mode Exit fullscreen mode

Se não for possível replicar produção, documente as diferenças.

2. Ignorar aquecimento

Muitos sistemas são mais lentos no início:

  • caches ainda vazios;
  • pools de conexão abrindo;
  • JIT aquecendo;
  • índices e páginas sendo carregados;
  • autoscaling ainda não ativado.

Não misture aquecimento com estado estável.

Exemplo de abordagem:

Primeiros 2 minutos: aquecimento
Próximos 10 minutos: medição oficial
Enter fullscreen mode Exit fullscreen mode

3. Usar média em vez de percentis

A média esconde a cauda lenta.

Compare:

Média: 200 ms
p95: 900 ms
p99: 3000 ms
Enter fullscreen mode Exit fullscreen mode

Nesse exemplo, muitos usuários ainda terão uma experiência ruim.

Sempre reporte pelo menos:

p50
p90
p95
p99
Enter fullscreen mode Exit fullscreen mode

4. Usar dados irreais

Testar sempre com o mesmo usuário, produto ou payload pode mascarar gargalos.

Evite:

{
  "userId": 1,
  "productId": 1
}
Enter fullscreen mode Exit fullscreen mode

em todas as requisições.

Prefira variar dados:

[
  { "userId": 101, "productId": 9001 },
  { "userId": 235, "productId": 8420 },
  { "userId": 879, "productId": 1203 }
]
Enter fullscreen mode Exit fullscreen mode

O tráfego real atinge diferentes linhas, índices, caches e partições.

5. Testar apenas um endpoint isolado

Usuários não fazem apenas uma chamada. Eles percorrem fluxos.

Em vez de testar somente:

GET /products
Enter fullscreen mode Exit fullscreen mode

teste um cenário:

POST /login
GET /products
GET /products/{id}
POST /cart
POST /checkout
Enter fullscreen mode Exit fullscreen mode

Isso revela contenção em recursos compartilhados, como banco de dados, cache e pools de conexão.

6. Tratar teste de desempenho como evento único

Um teste feito antes do lançamento fica obsoleto rapidamente.

O desempenho muda quando o código muda. Por isso, os testes devem ser repetíveis e automatizados.

Um processo mínimo:

A cada PR: teste leve
Antes do release: teste de carga completo
Semanalmente: teste de imersão
Antes de campanhas: teste de pico
Enter fullscreen mode Exit fullscreen mode

Executando testes de desempenho com Apidog

O Apidog permite trabalhar com design de API, testes funcionais e testes de carga no mesmo espaço de trabalho. Isso evita manter uma definição separada da API apenas para desempenho.

Um fluxo prático:

  1. Escolha um endpoint ou cenário de teste.
  2. Valide primeiro se o cenário passa funcionalmente.
  3. Configure usuários virtuais.
  4. Defina a duração do teste.
  5. Execute com aumento gradual de carga.
  6. Acompanhe percentis, vazão e taxa de erro.
  7. Identifique em qual nível de concorrência o desempenho muda.
  8. Compare o resultado com seu orçamento.

Exemplo de objetivo para um cenário:

Cenário: login + busca + checkout
Usuários virtuais: 300
Duração: 10 minutos
p95 máximo: 1000 ms
Taxa de erro máxima: 0.5%
Enter fullscreen mode Exit fullscreen mode

Como o mesmo cenário pode ser usado para execuções funcionais e de desempenho, você mantém um único artefato de teste. Para cargas maiores que uma única máquina, o cenário pode ser exportado para o JMeter mantendo a mesma definição.

Você pode baixar o Apidog e começar por um endpoint crítico que já existe no seu sistema.

Perguntas frequentes

Qual é a diferença entre teste de desempenho e teste funcional?

Teste funcional verifica se o software retorna o resultado correto. Teste de desempenho verifica a rapidez, estabilidade e confiabilidade desse resultado sob carga.

Os dois são necessários. Um não substitui o outro.

Que tipo de teste de desempenho devo executar primeiro?

Comece com linha de base e depois teste de carga.

A linha de base mostra o comportamento atual em condições normais. O teste de carga valida se o sistema aguenta o pico esperado. Depois, adicione testes de estresse, pico e imersão conforme a criticidade do sistema.

Por que usar percentis em vez de tempo médio de resposta?

Porque a média esconde a cauda lenta.

Percentis como p95 e p99 mostram o que usuários menos favorecidos experimentam. Essa é a parte que normalmente gera reclamações, abandono e incidentes.

Teste de desempenho pode ser automatizado?

Sim.

Uma boa prática é executar testes leves em CI para detectar regressões. Testes mais pesados, como estresse e imersão, costumam ser agendados porque consomem mais tempo e infraestrutura.

Quando o teste de desempenho deve começar?

O mais cedo possível.

Mesmo sem infraestrutura final, você já pode:

  • definir orçamentos;
  • escrever cenários;
  • identificar caminhos críticos;
  • preparar dados de teste;
  • automatizar validações básicas.

Assim que um endpoint estiver funcional, execute um teste de carga simples para encontrar problemas enquanto ainda são baratos de corrigir.

Quem é responsável pelo teste de desempenho?

Em equipes modernas, a responsabilidade é compartilhada.

  • Desenvolvedores validam impacto de suas mudanças.
  • QA mantém cenários e critérios.
  • SRE ou operações fornece infraestrutura, observabilidade e métricas.
  • Produto ajuda a definir fluxos críticos e expectativas de uso.

Quando o teste de desempenho fica restrito a um único especialista no fim do ciclo, os problemas tendem a chegar à produção.

Por quanto tempo um teste de desempenho deve rodar?

Depende do objetivo.

Para teste de carga, execute tempo suficiente para passar o aquecimento e atingir estado estável, normalmente alguns minutos.

Para teste de imersão, rode por horas ou dias, porque o objetivo é encontrar degradação lenta, vazamento de memória e exaustão de recursos.

Top comments (0)