Load Test no desenvolvimento móvel — o que é, cenários e como é realizado

O que é Load Test?

Load Test é um processo de verificação de como um sistema se comporta sob um número esperado de requisições ou usuários simultâneos. No contexto do desenvolvimento móvel, o Load Test é aplicado tanto ao backend (API, banco de dados, cache) quanto ao cliente (processamento de notificações push, sincronização de dados). A principal diferença dos testes de estresse é que o Load Test simula uma carga real, não extrema. De acordo com o AWS Well-Architected Framework (2024), os testes de carga devem ser realizados usando perfis de carga baseados em análises de uso real.

O Load Test pode ser realizado no nível de requisições HTTP à API, conexões WebSocket ou transações de banco de dados. O objetivo é garantir que o tempo de resposta de cada requisição não exceda um limite específico (geralmente 500–1000 ms para API) e que o throughput (RPS — requisições por segundo) atenda aos requisitos. O Google Cloud Armor (2024) define valores limite com base em percentis: o tempo de resposta p95 não deve exceder 2 segundos para endpoints críticos.

O teste de carga de um backend móvel inclui a simulação de cenários típicos: registro, autenticação, carregamento de feed, envio de formulários. Os cenários são registrados como arquivos HAR (HTTP Archive) e reproduzidos pela ferramenta de teste de carga. De acordo com a documentação do k6 (2025), a conversão HAR pode reduzir o tempo de preparação do Load Test em 60%.

Objetivos do teste de carga

O primeiro objetivo do Load Test é confirmar o throughput do sistema. Se a especificação exige o processamento de 1000 RPS, o teste de carga deve confirmar isso com uma margem de 20%. De acordo com o Netflix Tech Blog (2024), os testes de carga na Netflix são realizados com uma margem de 2x da carga de pico: se 10000 RPS são esperados, o teste verifica 20000 RPS. Essa abordagem garante estabilidade durante picos repentinos de tráfego.

O segundo objetivo é identificar gargalos (bottlenecks) na arquitetura. Gargalos típicos em backends móveis são o banco de dados (consultas lentas), o cache (estratégia de invalidação incorreta) e APIs externas (serviços de terceiros lentos). O rastreamento distribuído (Jaeger, Zipkin) ajuda a localizar o problema no nível de um serviço ou requisição específica.

O terceiro objetivo é determinar o ponto de saturação (saturation point). Este é o momento em que adicionar novos usuários não aumenta mais o throughput. Em aplicativos móveis, o ponto de saturação geralmente ocorre a 70–80% de carga de CPU nos servidores de banco de dados. O auto-escalonamento deve ser acionado antes de atingir este ponto.

Cenários de teste de carga

Teste de pico (Spike Test) — simula um aumento repentino de atividade, como uma campanha de notificações push matinal ou o lançamento de uma campanha publicitária. De acordo com o Grafana k6 (2025), o Spike Test simula um crescimento de carga de 100 a 10000 RPS em 30 segundos. O sistema deve lidar com isso sem perder requisições e sem exceder o tempo de resposta em mais de 50%.

Teste de resistência (Endurance Test) — verifica a estabilidade do sistema durante operação prolongada sob carga. A duração típica é de 1 a 4 horas. O Endurance Test revela vazamentos de memória em aplicações de servidor, problemas com o pool de conexões do banco de dados e degradação do desempenho do cache. O pool de conexões PostgreSQL sob carga prolongada sem configuração adequada pode esgotar as conexões disponíveis em 2–3 horas de operação.

Teste de carga escalonado (Step Load Test) — aumento gradual da carga com incrementos de 10–20% a cada 2–5 minutos. Este cenário ajuda a encontrar o limite exato após o qual o sistema degrada. InfluxDB e Prometheus coletam métricas em cada etapa para construir um gráfico de tempo de resposta versus RPS.

Métricas de Load Test

Tempo de resposta

Tempo de resposta é a métrica principal do Load Test. É medido em milissegundos e analisado por percentis: p50 (mediana), p95 e p99. O Google SRE (2024) recomenda um limite p95 de não mais de 1000 ms para REST API e não mais de 200 ms para gRPC. Os percentis são mais importantes que as médias porque mostram o comportamento das piores requisições, que os usuários notam primeiro. Apdex (Índice de Desempenho de Aplicação) é uma métrica composta que considera a proporção de usuários satisfeitos, tolerantes e frustrados.

Throughput

Throughput — o número de requisições bem-sucedidas por unidade de tempo. É medido em RPS (requisições por segundo) ou TPS (transações por segundo). O gráfico de Throughput nas coordenadas “tempo — RPS” deve ser linear até o ponto de saturação. Uma queda acentuada no Throughput com o aumento da carga é um sinal de atingir o limite do sistema. Apache Bench e wrk são ferramentas CLI simples para verificações rápidas de Throughput durante o desenvolvimento.

Taxa de erro

Taxa de erro (Error Rate) — a proporção de respostas com status HTTP 4xx ou 5xx em relação ao total de requisições. O limite aceitável é inferior a 1%. Erros 429 (Muitas Requisições) e 503 (Serviço Indisponível) sob alta carga indicam a necessidade de configurar limitação de taxa e auto-escalonamento. Um limitador de taxa no API Gateway protege o backend contra a superação da carga permitida. A política de repetição com backoff exponencial ajuda os clientes a lidar corretamente com erros temporários.

Ferramentas para Load Test

k6 (Grafana)

k6 — a principal ferramenta Open Source de teste de carga da Grafana. Os scripts são escritos em JavaScript, com suporte para cenários modulares, limites (thresholds) e integração com Prometheus e InfluxDB. O k6 pode ser executado tanto em CLI quanto na nuvem Grafana Cloud k6. Grafana Cloud constrói automaticamente painéis a partir dos resultados do Load Test e os compara com dados históricos. O k6 suporta Protocol Buffers e gRPC através do módulo k6/net/grpc.

Apache JMeter

Apache JMeter — uma ferramenta clássica de Load Test com interface gráfica. Suporta uma ampla gama de protocolos: HTTP, JDBC, JMS, FTP e TCP. O JMeter é mais adequado para cenários complexos com muitos tipos diferentes de requisições, mas requer mais configuração manual em comparação com o k6. Os plugins do JMeter estendem a funcionalidade para testes WebSocket e gRPC. Para execução distribuída, o JMeter usa uma arquitetura mestre-escravo com um controlador.

Locust

Locust — uma ferramenta baseada em Python que permite descrever cenários de carga em código. O Locust é conveniente para equipes que usam Python como sua principal linguagem de automação. Ao contrário do k6 e JMeter, o Locust suporta execução distribuída nativamente: um nó mestre coordena vários nós trabalhadores. A execução distribuída permite gerar carga de até 100000 RPS a partir de várias máquinas. O Locust também suporta testes WebSocket através de extensões personalizadas.

import http from 'k6/http'
import check from 'k6'
import sleep from 'k6'

export const options = {
    stages: [
        { duration: '2m', target: 100 },
        { duration: '5m', target: 100 },
        { duration: '2m', target: 200 },
    ],
    thresholds: {
        http_req_duration: ['p(95)<500'],
        http_req_failed: ['rate<0.01'],
    }
}

export default function() {
    const res = http.get('https://api.example.com/users')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
    sleep(1)
}

Exemplo de escrita de Load Test em k6

O script k6 mostrado acima demonstra uma estrutura típica de teste de carga. Options define o perfil de carga: aumento gradual por 2 minutos até 100 usuários, depois 5 minutos de carga constante e outro aumento até 200 usuários. Os thresholds definem os critérios de aprovação do teste: tempo de requisição p95 não mais de 500 ms, taxa de erro inferior a 1%. Se os thresholds forem excedidos, o k6 sai com um código diferente de zero — isso permite integrar o Load Test no CI/CD.

No desenvolvimento móvel, o Load Test do backend é especialmente importante ao lançar novas funcionalidades que criam carga adicional: curtidas, comentários, streaming. Recomendação — realize um Load Test em cada staging antes de implantar em produção. Criar um perfil de carga base durante a fase de design da API ajuda a evitar problemas arquitetônicos em estágios posteriores.