Stress Test no desenvolvimento mobile: o que é, objetivos e como é realizado

O que é Stress Test?

Stress Test (teste de estresse) é um processo de avaliação da capacidade do sistema de operar em condições que excedem as especificações de projeto. Para uma aplicação mobile, isso pode significar 10.000 notificações push simultâneas com uma norma de 1.000; para um backend, 50.000 RPS contra 5.000 esperados. A principal diferença entre Stress Test e Load Test é que o objetivo não é confirmar o desempenho, mas estudar o comportamento do sistema além de sua capacidade projetada. A Netflix Engineering (2024) define Stress Test como “uma verificação de hipótese de que o sistema falhará de forma previsível.”

O teste de estresse inclui duas etapas obrigatórias: carga até a falha e observação da recuperação. Recuperação é a capacidade do sistema de retornar à operação normal após a remoção da sobrecarga. Um sistema que não se recupera sem uma reinicialização é considerado frágil, mesmo que suporte sobrecarga de curto prazo. De acordo com o AWS Well-Architected Framework (2024), o tempo de recuperação após um Stress Test não deve exceder 5 minutos.

Para clientes mobile, o Stress Test inclui a verificação do comportamento sob encerramento forçado de processos, desconexão de rede e esgotamento de RAM. Android Low Memory Killer pode encerrar um processo em segundo plano quando a RAM é insuficiente — o teste de estresse deve verificar se a aplicação restaura corretamente o estado após tal encerramento. A Apple UIKit (2024) recomenda testar cenários de aviso de memória em cada tela da aplicação.

Objetivos do Stress Testing

Determinação do Ponto de Falha

O primeiro objetivo do Stress Test é determinar o ponto de falha. É o momento em que um dos principais indicadores de desempenho cruza um limite crítico: tempo de resposta p95 excede 10 segundos, taxa de erro HTTP 5XX excede 5% ou Throughput cai abaixo de 50% do baseline. Registrar o ponto de falha permite que a equipe conheca antecipadamente o limite de escalabilidade do sistema. Capacity planning depende especificamente dos dados do Stress Test, não do Load Test, porque o Load Test não verifica condições de limite.

Verificação dos Mecanismos de Recuperação

O segundo objetivo é verificar os mecanismos de recuperação. Após a carga diminuir para níveis normais, o sistema deve retornar aos indicadores de base. Se o pool de conexões do banco de dados não for liberado ou o cache não for invalidado, o Stress Test revelará esse problema. O circuit breaker (Hystrix, Resilience4j) deve disparar sob sobrecarga e restaurar automaticamente a conexão após a estabilização. Os endpoints de Health check ajudam a monitorar o estado de cada serviço durante o teste.

Validação do Auto-Scaling

O terceiro objetivo é validar o auto-scaling. Se a infraestrutura usa Kubernetes ou AWS Auto Scaling, o Stress Test verifica se novos pods ou instâncias são criados com rapidez suficiente. De acordo com o Google Kubernetes Engine (2024), o tempo de implantação de um novo pod não deve exceder 30 segundos a partir do momento em que a métrica HPA (Horizontal Pod Autoscaler) é acionada. HPA deve escalar com base em CPU, memória e métricas personalizadas. O Cluster Autoscaler adiciona novos nós se os atuais não puderem acomodar pods.

Metodologia de Stress Test

Aumento gradual da carga (Ramp-up Stress Test) é o cenário mais comum. A carga inicial é definida em 50% do esperado e, em seguida, aumentada em 10% a cada 2 minutos até que o sistema falhe. Esse cenário permite encontrar o limite exato de estabilidade. Grafana Cloud k6 (2025) recomenda um incremento de não mais de 10% para obter um gráfico suave de tempo de resposta.

Pico repentino de carga (Spike Stress Test) — a carga aumenta de 10% para 500% em 10–30 segundos. Esse cenário simula situações como disseminação viral de conteúdo ou ataques DDoS. O Spike Stress Test testa não tanto o desempenho, mas a capacidade de sobrevivência do sistema: a capacidade de não cair completamente e retornar ao funcionamento após a estabilização. API Gateway deve configurar rate limiting para proteger o backend de picos repentinos.

Retenção prolongada de sobrecarga (Sustained Stress Test) — o sistema é mantido em estado de sobrecarga por 30–60 minutos. Esse cenário revela vazamentos de recursos que não se manifestam em testes curtos. Vazamentos de memória em aplicações Java/Kotlin se acumulam ao longo de 20–40 minutos de trabalho intensivo, e apenas o Sustained Stress Test os detecta.

Análise do Ponto de Falha e Recuperação

O ponto de falha é determinado por três critérios: tempo de resposta, porcentagem de erros e Throughput. O limite de tempo de resposta geralmente é excedido primeiro — as solicitações começam a demorar mais do que o limite estabelecido. Em seguida, a taxa de erro aumenta: o servidor não consegue processar as solicitações e retorna 503. Finalmente, o Throughput cai — o sistema não consegue mais lidar nem com a carga mínima. A métrica do ponto de falha é registrada no perfil de carga para planejamento de capacidade.

A análise de recuperação inclui três fases: reação imediata (primeiros 30 segundos após a remoção da carga), estabilização (1–5 minutos) e recuperação completa (5–30 minutos). Na fase de reação imediata, o tempo de resposta deve cair abaixo do baseline — o sistema está limpando as filas. Se isso não ocorrer, o problema não é a carga, mas o estado acumulado. Graceful degradation — a capacidade do sistema de manter funcionalidade parcial sob sobrecarga — é um indicador chave de maturidade arquitetônica.

O Chaos Engineering complementa o Stress Test introduzindo falhas deliberadamente: desligar o servidor de banco de dados, latência de rede, parar um microsserviço. Chaos Monkey da Netflix (2024) encerra processos aleatoriamente em produção, testando a resiliência do sistema. Para aplicações mobile, Chaos Engineering significa testar cenários: sem rede, API indisponível, resposta vazia do servidor.

Ferramentas para Stress Test

k6 com ramping-arrival-rate

k6 suporta Stress Test através do módulo `execution` com configuração ramping-arrival-rate. Este modo aumenta o número de solicitações por segundo independentemente do tempo de execução de cada solicitação. Comparado ao Load Test, o Stress Test no k6 requer configuração de thresholds mais agressivos e desabilitação do gracefull-stop para simular falha repentina. O Grafana Cloud detecta automaticamente o ponto de falha pela inflexão no gráfico de tempo de resposta. k6-operator para Kubernetes permite executar Stress Tests distribuídos a partir do cluster.

JMeter com Ultimate Thread Group

JMeter permite configurar Stress Test através do Ultimate Thread Group — um plugin que define o perfil de carga como uma tabela: número de threads, tempo de aquecimento, tempo de retenção, tempo de redução. O Ultimate Thread Group é conveniente para cenários complexos multifásicos. JMeter Backend Listener envia métricas para InfluxDB para plotagem do ponto de falha. Para Stress Test, o JMeter recomenda desabilitar timeouts de conexão para medir com mais precisão o comportamento sob sobrecarga.

Gremlin para Chaos Engineering

Gremlin é uma plataforma de Chaos Engineering para Stress Test de infraestrutura. O Gremlin permite desligar a rede, carregar a CPU, encher o disco e encerrar processos no nível de pods individuais do Kubernetes. As equipes de SRE usam o Gremlin junto com o k6 para Stress Test abrangente: o k6 gera carga, o Gremlin introduz falhas. Game Day — sessões regulares de Stress Test usando Gremlin, documentadas em um “relatório de caos” para analisar a resiliência do sistema.

Exemplo de Stress Test no k6

O script k6 a seguir demonstra o Stress Test com aumento gradual de carga até a falha. Ramping-arrival-rate aumenta o número de solicitações por segundo independentemente do tempo de execução. Os thresholds são configurados para detecção agressiva de degradação: p95 não mais de 2000 ms, taxa de erro não mais de 5%. Quando os thresholds são excedidos, o k6 sai com um código de erro, permitindo que o Stress Test seja integrado ao pipeline CI/CD.

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

export const options = {
    scenarios: {
        stress: {
            executor: 'ramping-arrival-rate',
            startRate: 50,
            timeUnit: '1s',
            stages: [
                { duration: '2m', target: 200 },
                { duration: '5m', target: 500 },
                { duration: '2m', target: 1000 },
            ],
            preAllocatedVUs: 50,
            maxVUs: 200,
        },
    },
    thresholds: {
        http_req_duration: ['p(95)<2000'],
        http_req_failed: ['rate<0.05'],
    },
}

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

Melhores Práticas de Stress Testing

Comece o Stress Test no staging — o teste de estresse em produção requer monitoramento avançado e um plano de reversão. O Google SRE (2024) recomenda realizar o Stress Test em um ambiente 100% isolado que reproduza a produção em arquitetura e capacidade. Após um teste bem-sucedido no staging, você pode passar para a produção sob supervisão do SRE. Feature flag para desabilitar funcionalidade sob sobrecarga é obrigatório.

Automatize o Stress Test no CI/CD para análise de regressão do ponto de falha. Se uma nova versão da aplicação tiver um ponto de falha 20% inferior ao anterior, é uma regressão que deve ser corrigida antes do lançamento. Baseline breaking point é armazenado em métricas e comparado automaticamente com cada resultado de Stress Test. Um alerta é acionado quando o ponto de falha cai 10%.

Documente cada Stress Test: perfil de carga, ponto de falha, comportamento de recuperação e lista de problemas encontrados. A Netflix Engineering (2024) realiza “Game Day” — sessões regulares de Stress Test cujos resultados são documentados em um “relatório de caos.” O relatório de teste de estresse deve conter um gráfico “RPS — tempo de resposta” com o ponto de falha marcado.