Uma API pode passar em todos os testes funcionais e ainda falhar em produção. Ela retorna os dados corretos, com o código de status certo, contra o esquema adequado, e então falha no momento em que mil usuários a acessam simultaneamente. O teste funcional diz que a API está correta. O teste de desempenho diz que ela está correta e rápida o suficiente para sobreviver ao tráfego real.
Este guia explica o que é o teste de desempenho de API, os tipos de teste importantes, as métricas a serem observadas e como executar um teste de desempenho passo a passo no Apidog.
O que é teste de desempenho de API
O teste de desempenho de API mede como uma API se comporta sob carga: quão rápido ela responde, quantas solicitações consegue gerenciar e em que ponto se degrada ou falha. Não se trata de verificar se a resposta está correta; isso é teste funcional. Trata-se de verificar se a resposta chega rapidamente e de forma confiável quando o sistema está sob pressão.
O objetivo é encontrar os limites antes que seus usuários o façam. Toda API tem um limite máximo, um ponto onde os tempos de resposta aumentam, erros aparecem ou o serviço para de responder. O teste de desempenho localiza esse limite em um ambiente controlado para que você possa aumentá-lo, planejar a capacidade em torno dele ou, pelo menos, saber que ele existe.
APIs são um bom alvo para testes de desempenho porque são determinísticas e rápidas de chamar. Não há navegador para renderizar, nem interface de usuário para esperar. Você envia uma solicitação, mede a resposta. Isso torna os testes de desempenho de API mais baratos de executar e mais estáveis do que os testes de carga completos de ponta a ponta.
Os tipos de teste de desempenho
"Teste de desempenho" é um termo abrangente. Sob ele, existem vários tipos de testes distintos, cada um respondendo a uma pergunta diferente.
Teste de carga (Load testing) aplica o tráfego que você realmente espera, seu volume normal e de pico de requisições, e confirma que a API o gerencia dentro de tempos de resposta aceitáveis. Este é o teste base que a maioria das equipes executa primeiro.
Teste de estresse (Stress testing) vai além do tráfego esperado, aumentando a carga até que a API se degrade ou falhe. O objetivo é encontrar o ponto de ruptura e ver como ela quebra. Ela desacelera graciosamente ou retorna erros e perde dados?
Teste de pico (Spike testing) aplica um salto súbito e acentuado no tráfego, o tipo que uma promoção relâmpago ou um momento viral produz, e verifica se a API o absorve ou colapsa. Um sistema que lida com carga constante ainda pode falhar em um pico.
Teste de exaustão (Soak testing), também chamado de teste de resistência, mantém uma carga moderada por um longo período, horas ou dias, para expor problemas lentos: vazamentos de memória, exaustão de pools de conexão, arquivos de log enchendo um disco. Estes nunca aparecem em um teste de carga de cinco minutos.
Teste de fumaça (Smoke testing) é a pré-verificação leve: uma pequena carga para confirmar que a API e a configuração do teste estão funcionando antes de você se comprometer com uma execução longa e cara.
A maioria das equipes precisa de testes de carga, estresse e exaustão, no mínimo. O teste de pico é importante se o seu tráfego for em rajadas.
As métricas que importam
Um teste de desempenho produz números. Estes são os que devem ser lidos.
Tempo de resposta (Response time) é o tempo que a API leva para receber, processar e retornar uma requisição. Observe os percentis, não apenas a média. A média pode parecer saudável enquanto o 95º e o 99º percentil, os 5% e 1% mais lentos das requisições, são inaceitáveis. Usuários reais sentem a cauda.
Taxa de transferência (Throughput) é o número de requisições que a API completa por segundo. Isso informa a capacidade real do sistema, independente de quantos usuários estão conectados.
Usuários concorrentes (Concurrent users) ou usuários virtuais é quantos chamadores simultâneos o teste simula. A capacidade é frequentemente expressa como a concorrência máxima que a API sustenta antes que os tempos de resposta ultrapassem seu limite.
Taxa de erro (Error rate) é a porcentagem de requisições que falham sob carga. Uma API que permanece rápida, mas começa a retornar 500s em alta concorrência, ainda falhou no teste.
Utilização de recursos (Resource utilization), CPU e memória no servidor, informa por que o desempenho se degrada. Se os tempos de resposta aumentam enquanto a CPU está em 100%, você está limitado por computação; se a CPU está ociosa, mas a latência aumenta, o gargalo está em outro lugar, geralmente um banco de dados ou uma chamada a jusante.
Um bom relatório de desempenho relaciona tudo isso: a essa concorrência, a taxa de transferência atingiu o pico, o tempo de resposta do percentil 95 foi este, e a taxa de erro foi aquela.
Como executar um teste de desempenho de API no Apidog
Apidog inclui testes de carga incorporados no mesmo ambiente de trabalho onde você projeta e testa funcionalmente suas APIs, então você não precisa de uma ferramenta separada para começar.
Passo 1: Escolha o endpoint ou cenário a ser testado. Escolha um único endpoint crítico, ou um cenário de teste com várias etapas que espelhe um fluxo de usuário real, como login seguido por uma busca de dados. Testar um fluxo realista fornece números mais honestos do que martelar um endpoint isoladamente.
Passo 2: Confirme se ele passa funcionalmente primeiro. Execute a requisição com suas asserções uma vez. Não há valor em testar a carga de um endpoint que retorna dados incorretos; corrija a exatidão antes de medir a velocidade.
Passo 3: Configure a carga. Defina o número de usuários virtuais e a duração do teste. O Apidog permite aumentar a carga gradualmente, simulando usuários entrando ao longo do tempo em vez de todos de uma vez, o que produz uma imagem mais realista e ajuda a identificar o nível de concorrência onde o desempenho muda.
Passo 4: Execute o teste. O Apidog executa a carga e relata ao vivo: tempos de resposta, taxa de transferência, taxa de erro e como cada métrica muda à medida que a concorrência aumenta. Observe o ponto de inflexão onde o tempo de resposta começa a aumentar mais rápido que a carga.
Passo 5: Leia os resultados e encontre o gargalo. Se o tempo de resposta do percentil 95 exceder seu limite em 300 usuários concorrentes, esse é o seu teto atual. Faça um cruzamento com a CPU e memória do servidor para entender a causa. Reexecute após uma correção para confirmar que o teto se moveu.
Passo 6: Para necessidades mais pesadas, exporte para o JMeter. Quando você precisar de geração de carga distribuída além de uma única máquina, o Apidog pode exportar o cenário para o JMeter, para que você mantenha a mesma definição de teste enquanto dimensiona a fonte de carga.
Baixe o Apidog para executar seu primeiro teste de carga em um endpoint que você já possui.
Interpretando um resultado de desempenho real
Números sem interpretação são ruído. Pegue uma execução concreta: você testa a carga de GET /products com usuários virtuais aumentando de 0 para 500 em cinco minutos.
Para os primeiros 200 usuários, o tempo de resposta do percentil 95 se mantém estável em torno de 180 ms e a taxa de transferência aumenta em linha com a carga. Esta é a zona saudável; a API está acompanhando. Em aproximadamente 280 usuários, o tempo do percentil 95 começa a subir, 240 ms, depois 400 ms, depois 900 ms, enquanto a taxa de transferência se achata em vez de subir. Esse achatamento é o sinal: a API atingiu seu teto. Adicionar mais usuários agora produz respostas mais lentas, não mais trabalho concluído. Acima de 420 usuários, a taxa de erro ultrapassa 1% à medida que as requisições começam a expirar.
O veredito é concreto. Esta API atende confortavelmente cerca de 250 usuários concorrentes dentro de um orçamento de 200 ms. Seu teto prático está próximo de 280, e ela começa a falhar em torno de 420. Se você espera um pico de tráfego de 200 usuários concorrentes, você tem folga. Se você espera 350, você tem um problema para corrigir antes do lançamento, não depois.
É isso que um teste de desempenho oferece: não "passar" ou "falhar", mas um mapa claro de onde a API está confortável, onde ela se esforça e onde ela quebra.
Gargalos comuns de desempenho de API
Quando um teste expõe um teto, a causa é geralmente um dos seguintes culpados conhecidos.
Consultas lentas ao banco de dados (Slow database queries) são as mais comuns. Uma coluna não indexada, um padrão de consulta N+1 ou um limite de consulta ausente transforma um endpoint rápido em lento no momento em que o volume de dados ou a concorrência aumentam. Se a latência aumenta enquanto a CPU do servidor permanece baixa, suspeite primeiro do banco de dados.
Chamadas externas bloqueadoras (Blocking external calls) arrastam um endpoint para a velocidade de sua dependência mais lenta. Uma API que chama um provedor de pagamento ou um serviço de terceiros de forma síncrona herda a latência e as interrupções desse serviço.
Exaustão do pool de conexões (Connection pool exhaustion) aparece sob carga sustentada: a API fica sem conexões de banco de dados ou clientes HTTP e as requisições ficam em fila esperando. Este é um achado clássico de teste de exaustão.
Serialização ineficiente (Inefficient serialization) de grandes cargas de resposta consome CPU. Retornar mais dados do que o cliente precisa torna cada resposta mais lenta para construir e mais lenta para transferir.
Um teste de desempenho aponta onde está o teto; combiná-lo com métricas do lado do servidor informa por que.
Integrando testes de desempenho ao seu processo
Uma execução de teste de desempenho feita uma vez antes de um grande lançamento é útil. Um teste de desempenho que é executado regularmente é muito mais valioso, porque o desempenho regride silenciosamente. Uma nova consulta ao banco de dados, uma chamada a jusante adicionada ou uma coluna não indexada podem adicionar latência que nenhum teste funcional percebe.
Defina um orçamento de tempo de resposta e taxa de erro para seus endpoints críticos, e trate uma violação como uma falha, da mesma forma que você trata uma asserção quebrada. Execute um teste de carga mais leve como parte da CI/CD para que uma regressão apareça na solicitação pull, e reserve execuções pesadas de estresse e exaustão para testes agendados de pré-lançamento.
Mantenha os testes de desempenho próximos aos testes funcionais. Quando os dois convivem, cada alteração na API é verificada tanto pela correção quanto pela velocidade, e "funciona" e "funciona rápido o suficiente" deixam de ser perguntas separadas e facilmente esquecidas.
Perguntas Frequentes
Qual a diferença entre teste de carga e teste de estresse? O teste de carga aplica o tráfego esperado e confirma que a API o gerencia. O teste de estresse vai além disso para encontrar o ponto de ruptura. O teste de carga verifica a operação normal; o teste de estresse mapeia o modo de falha.
Devo observar os tempos de resposta médios ou os percentis? Percentis. A média esconde a cauda lenta. O percentil 95 e 99 mostram o que seus usuários menos sortudos realmente experimentam, e é isso que gera reclamações.
Posso testar o desempenho de uma API antes que o backend esteja finalizado? Você pode testar o contrato e o design, mas números significativos de latência precisam de infraestrutura real. Use um servidor mock para trabalhos funcionais iniciais e execute testes de carga contra a implementação real.
Com que frequência os testes de desempenho devem ser executados? Execute um teste de carga leve na CI a cada alteração em endpoints críticos, e testes completos de estresse e exaustão antes de cada grande lançamento. O desempenho regride silenciosamente, então verificações regulares são melhores do que uma grande execução pré-lançamento.