Um software que funciona não é o mesmo que um software que funciona sob carga. Uma funcionalidade pode passar em todos os testes funcionais, ser lançada sem problemas e, então, falhar na primeira vez que o tráfego real chega. O teste de desempenho é a disciplina que preenche essa lacuna: ele mede como um sistema se comporta quando está ocupado, não apenas se está correto quando está ocioso.
Este guia explica o que é o teste de desempenho, os principais tipos, as métricas que definem um resultado e como ele se encaixa em um processo de teste moderno.
O que é teste de desempenho
O teste de desempenho avalia a velocidade, estabilidade e escalabilidade de um sistema sob uma carga de trabalho definida. Ele não pergunta “esta funcionalidade funciona?” Ele pergunta “qual a sua velocidade, quanto consegue suportar e o que acontece quando atinge seu limite?”
Essa distinção importa. Testes funcionais e testes de desempenho respondem a perguntas diferentes e detectam bugs diferentes. Um endpoint de login pode retornar o token correto todas as vezes e ainda levar quatro segundos para fazê-lo sob carga. Testes funcionais passam; usuários desistem. O teste de desempenho é o que revela esse segundo problema.
O resultado do teste de desempenho não é um simples passar ou falhar. É um perfil: a essa carga, o sistema responde a essa velocidade, sustenta essa vazão e falha dessa maneira quando levado além desse ponto. Esse perfil é o que permite a uma equipe planejar a capacidade, definir níveis de serviço realistas e detectar regressões antes do lançamento.
Os principais tipos de teste de desempenho
O teste de desempenho é uma família de tipos de testes, cada um aplicando carga de uma forma diferente para responder a uma pergunta distinta.
Teste de Linha de Base (Baseline testing) executa o sistema sob carga normal e esperada e registra o resultado. Esta linha de base é a referência com a qual todos os testes posteriores são comparados. Sem ela, você não consegue dizer se um número é bom, ruim ou simplesmente diferente.
Teste de Carga (Load testing) aplica o tráfego de pico esperado e confirma que o sistema aguenta: os tempos de resposta permanecem dentro do orçamento, os erros ficam próximos de zero. Ele valida que o sistema sobrevive a um dia útil normal.
Teste de Estresse (Stress testing) excede deliberadamente a capacidade, aumentando a carga até que o sistema se degrade ou falhe. O objetivo é encontrar o ponto de ruptura e observar o modo de falha. Degradação graciosa, mais lenta, mas ainda funcionando, é aceitável; perda de dados ou erros em cascata não são.
Teste de Pico (Spike testing) aplica um salto repentino e acentuado na carga e a reduz novamente. Ele modela vendas relâmpago, eventos de notícias e outras rajadas. Um sistema ajustado para tráfego constante ainda pode falhar em um pico porque não consegue escalar rápido o suficiente.
Teste de Capacidade (Capacity testing) encontra a carga máxima que o sistema pode suportar enquanto ainda atende aos seus objetivos. A resposta é um número concreto, usado diretamente para planejamento de capacidade e limites de autoescalonamento.
Teste de Imersão (Soak testing), também chamado de teste de estabilidade ou resistência, mantém uma carga moderada por um período prolongado para expor falhas lentas: vazamentos de memória, exaustão de recursos, lentidão gradual. Estes são invisíveis em execuções curtas e só aparecem ao longo de horas.
A maioria das equipes executa testes de linha de base, carga e imersão como padrão, e adiciona testes de estresse e pico para sistemas com tráfego alto ou imprevisível.
As métricas que definem um resultado
Um teste de desempenho é tão útil quanto as métricas que você extrai dele.
Tempo de resposta (Response time) é a duração do pedido à resposta. Sempre leia como uma distribuição. A média é enganosa; uma média saudável pode esconder um percentil 99 que é dez vezes pior. A cauda lenta é o que os usuários reais notam e reclamam.
Vazão (Throughput) é o volume de trabalho concluído por unidade de tempo, frequentemente requisições por segundo. É calculado como o total de requisições dividido pela duração do teste e representa a verdadeira capacidade do sistema.
Concorrência (Concurrency) é o número de usuários ou conexões simultâneas. A capacidade do sistema é frequentemente indicada como o nível de concorrência no qual o tempo de resposta ultrapassa o limite aceitável.
Taxa de erros (Error rate) é a porcentagem de requisições que falham sob carga. Um sistema que permanece rápido, mas começa a falhar requisições em alta concorrência, não passou; velocidade sem confiabilidade não é desempenho.
Utilização de CPU e memória (CPU and memory utilization) explicam por que os outros números se movem. Se a latência aumenta enquanto a CPU está fixada em 100%, o sistema está limitado por computação. Se a latência aumenta enquanto a CPU está ociosa, o gargalo está a jusante, geralmente um banco de dados, um bloqueio ou uma dependência externa.
Um resultado completo se lê como uma frase: nesta concorrência, a vazão atingiu o pico aqui, o tempo de resposta do percentil 95 foi este, a taxa de erros foi aquela, e o servidor estava limitado por este recurso.
Onde o teste de desempenho se encaixa no processo
O teste de desempenho costumava ser um único portão perto do fim de um projeto, executado uma vez antes do lançamento por uma equipe especializada. Esse modelo falha para sistemas que são lançados continuamente, porque o desempenho regride com quase toda mudança. Uma nova consulta, uma integração adicionada, uma coluna não indexada, cada um adiciona silenciosamente uma latência que nenhum teste funcional detecta.
O modelo melhor trata o desempenho como correção: verificado continuamente, com um orçamento. Defina um orçamento de tempo de resposta e taxa de erros para caminhos críticos. Execute um teste de carga leve em CI/CD para que uma regressão falhe a construção no pull request. Reserve execuções pesadas de estresse e imersão para testes agendados pré-lançamento, onde sua duração mais longa é aceitável.
Para a maioria dos sistemas, o local de maior valor para testar o desempenho é a camada de API. As APIs carregam a lógica central, são rápidas e determinísticas para serem chamadas, e não têm uma UI instável para combater. Testar APIs sob carga fornece números confiáveis e baratos; o teste de desempenho de API aborda essa abordagem focada em detalhes. Manter testes de desempenho ao lado de testes funcionais de API significa que cada mudança é verificada quanto à correção e à velocidade ao mesmo tempo.
Erros comuns em testes de desempenho
É fácil realizar testes de desempenho de uma maneira que produza respostas confiantes, mas erradas. Alguns erros aparecem repetidamente.
Testar contra infraestrutura irrealista. Um teste de carga em um laptop de desenvolvedor, ou contra um ambiente de homologação com uma fração dos recursos de produção, produz números que não significam nada. Teste em infraestrutura que corresponda à produção o mais fielmente possível, dentro do que você pode pagar.
Ignorar os efeitos de aquecimento. Muitos sistemas são lentos nos primeiros segundos de uma execução enquanto os caches são preenchidos e os pools de conexão se abrem. Medir a inicialização a frio e o estado estável juntos produz uma média enganosa. Descarte a janela de aquecimento ou relate-a separadamente.
Ler médias em vez de percentis. Esse erro vale a pena repetir porque é muito comum. Um tempo de resposta médio de 200 ms pode esconder um percentil 99 de três segundos. A média descreve uma requisição que ninguém realmente faz; os percentis descrevem usuários reais.
Usar dados irrealistas. Testar cada requisição com o mesmo ID de usuário ou o mesmo produto significa que o banco de dados serve tudo do cache. O tráfego real se distribui pelo conjunto de dados, atingindo linhas frias e cache misses. Varie os dados de teste para corresponder.
Testar um endpoint isoladamente. Usuários reais se movem por fluxos de trabalho: fazer login, navegar, pesquisar, finalizar compra. Atacar um único endpoint ignora a contenção que aparece quando vários endpoints competem pelo mesmo banco de dados e pool de conexão. Teste cenários realistas de várias etapas, não apenas chamadas individuais.
Tratar o teste como uma única vez. Um único teste de desempenho pré-lançamento fica obsoleto no momento em que a próxima funcionalidade é lançada. O desempenho regride continuamente, então o teste também precisa ser executado continuamente.
Evitar esses seis erros é o que mais diferencia um teste de desempenho que informa uma decisão de um que produz uma marca de verificação verde reconfortante, mas sem sentido.
Executando testes de desempenho com Apidog
Apidog incorpora testes de carga no mesmo espaço de trabalho usado para design de API e testes funcionais, de modo que as verificações de desempenho não exigem uma ferramenta separada ou uma cópia separada da definição da API.
Você pega um endpoint ou um cenário de teste de várias etapas, confirma que ele passa funcionalmente e, em seguida, o executa sob um número configurado de usuários virtuais por uma duração definida. O Apidog aumenta a carga gradualmente e relata os percentis de tempo de resposta, vazão e taxa de erros ao vivo, para que você possa ver o nível exato de concorrência onde o desempenho muda. Para carga além de uma única máquina, o cenário exporta para o JMeter mantendo a mesma definição.
Como o mesmo cenário de teste serve tanto para execuções funcionais quanto de desempenho, você mantém um artefato em vez de dois. Baixe o Apidog para perfilar um endpoint que você já possui.
Perguntas frequentes
Qual a diferença entre teste de desempenho e teste funcional? O teste funcional verifica se o software produz resultados corretos. O teste de desempenho verifica a rapidez e a confiabilidade com que ele faz isso sob carga. Ambos são necessários; nenhum substitui o outro.
Que tipo de teste de desempenho devo executar primeiro? Linha de base, depois carga. A linha de base fornece uma referência em condições normais; o teste de carga confirma que o sistema sobrevive ao tráfego de pico esperado. A partir daí, adicione testes de estresse, pico e imersão.
Por que usar percentis em vez do tempo médio de resposta? A média é puxada para o meio e esconde a cauda lenta. Os percentis 95 e 99 revelam o que as requisições menos afortunadas experimentam, e essa cauda é o que os usuários sentem.
O teste de desempenho pode ser automatizado? Sim. Um teste de carga leve funciona bem em CI a cada alteração, com um orçamento definido que falha a construção em caso de regressão. Testes de estresse e imersão mais pesados são geralmente agendados em vez de executados a cada commit.
Quando no ciclo de desenvolvimento o teste de desempenho deve começar? Mais cedo do que a maioria das equipes pensa. Você não consegue obter números finais de latência sem infraestrutura real, mas pode estabelecer orçamentos e escrever os cenários de teste durante o design. Executar um teste de carga básico assim que um endpoint é funcional detecta problemas enquanto são baratos de corrigir.
Quem é responsável pelo teste de desempenho? Em equipes modernas, é compartilhado. Desenvolvedores executam verificações de carga leves em suas próprias alterações; QA possui os cenários de teste e orçamentos mais amplos; operações ou SRE fornecem a infraestrutura semelhante à produção e as métricas do lado do servidor. Tratá-lo como trabalho de um único especialista é como os problemas de desempenho chegam à produção.
Por quanto tempo um teste de desempenho deve ser executado? Tempo suficiente para passar a janela de aquecimento e atingir um estado estável, geralmente vários minutos para um teste de carga. Testes de imersão são executados por horas ou dias por design, já que seu propósito é expor a degradação lenta que as execuções curtas perdem.