"Testa aí pra ver se aguenta." Esse não é um cenário de teste. Um cenário real tem objetivo, contexto, critérios de sucesso e um plano de execução. Este artigo ensina a transformar requisitos vagos em cenários de teste concretos e significativos.
Um bom cenário de teste responde: O quê, Por quê, Como, Quanto e Por quanto tempo.
Anatomia de um Cenário
Componentes essenciais
Cenário de Teste:
Nome: [Identificação clara]
Objetivo: [O que queremos descobrir]
Contexto: [Quando/por que esse teste é relevante]
Pré-condições: [Estado inicial necessário]
Workload: [Carga a ser aplicada]
Duração: [Por quanto tempo]
Métricas: [O que medir]
Critérios de sucesso: [Quando passou]
Critérios de falha: [Quando parar]
Exemplo completo
Nome: Peak Hour Load Test - Checkout Flow
Objetivo: Validar que checkout suporta pico de Black Friday
Contexto: Preparação para evento em 30 dias
Pré-condições:
- Ambiente staging com dados de prod (anonimizados)
- Cache aquecido com top 1000 produtos
- DB com volume similar a produção
Workload:
Virtual users: 5000
Ramp-up: 30 minutos
Think time: 20-60s (log-normal)
Distribuição:
- Browse: 60%
- Search: 25%
- Checkout: 15%
Duração:
- Ramp-up: 30 min
- Steady state: 2 horas
- Ramp-down: 10 min
Métricas:
- Latência p50, p95, p99 por endpoint
- Throughput (req/s)
- Error rate
- CPU, Memory, DB connections
Critérios de sucesso:
- Checkout p95 < 3s
- Error rate < 1%
- Zero 5xx em checkout
- CPU < 70%
Critérios de falha (stop test):
- Error rate > 10%
- p99 > 30s
- Timeout em > 5% dos requests
Tipos de Cenários
1. Load Test (Carga normal)
Objetivo: Validar performance sob carga esperada
Características:
- Carga dentro do esperado
- Duração extendida (1-4 horas)
- Foco em estabilidade
Exemplo:
Nome: Daily Peak Load
Carga: 2x média diária
Duração: 2 horas
Critério: Sem degradação ao longo do tempo
2. Stress Test (Além do limite)
Objetivo: Encontrar o ponto de quebra
Características:
- Carga crescente até falha
- Identificar primeiro gargalo
- Documentar comportamento sob stress
Exemplo:
Nome: Breaking Point Discovery
Carga: Incrementa 10% a cada 10 minutos
Duração: Até falha
Critério: Identificar carga máxima sustentável
3. Spike Test (Pico súbito)
Objetivo: Validar resposta a picos repentinos
Características:
- Aumento abrupto de carga
- Curta duração
- Foco em recuperação
Exemplo:
Nome: Flash Sale Spike
Carga: 0 → 10x normal em 1 minuto
Duração pico: 5 minutos
Critério: Recupera em < 2 min após pico
4. Soak Test (Endurance)
Objetivo: Identificar problemas de longo prazo
Características:
- Carga moderada
- Duração muito longa (8-24h)
- Foco em memory leaks, resource exhaustion
Exemplo:
Nome: 24h Endurance Test
Carga: 1x média diária
Duração: 24 horas
Critério: Sem degradação, sem memory leak
5. Capacity Test (Planejamento)
Objetivo: Determinar capacidade máxima
Características:
- Múltiplas configurações testadas
- Curva de capacidade
- Input para capacity planning
Exemplo:
Nome: Capacity Planning Q4
Testes: 1x, 2x, 3x, 4x, 5x baseline
Output: Gráfico de capacidade vs recursos
Do Requisito ao Cenário
Passo 1: Entender o requisito de negócio
Requisito vago:
"O sistema precisa aguentar Black Friday"
Perguntas para clarificar:
1. Quantos usuários esperamos?
→ "3x o pico normal, ~150K simultâneos"
2. Quais funcionalidades são críticas?
→ "Busca e checkout. Browse pode degradar."
3. Qual latência é aceitável?
→ "Checkout < 5s, busca < 2s"
4. Quanto tempo dura o evento?
→ "Pico de 4 horas, 6-10h total"
5. O que é considerado falha?
→ "Qualquer erro em checkout"
Passo 2: Traduzir para métricas técnicas
Requisito: "150K usuários simultâneos"
Tradução:
- Think time médio: 30s
- Taxa de requisições: 150K / 30 = 5K req/s
- Requests por página: 8
- Total: 40K req/s na API
Passo 3: Definir workload model
Baseado em analytics de produção:
Distribuição de ações:
home: 100%
search: 45%
product_view: 60%
add_cart: 12%
checkout: 4%
payment: 3%
Dados de teste:
- Pool de 10.000 produtos
- 1.000 termos de busca reais
- IDs de usuário únicos
Passo 4: Definir critérios de sucesso
SLOs derivados do requisito:
Latência:
- GET /search: p95 < 2s
- GET /product: p95 < 1s
- POST /checkout: p95 < 5s
- POST /payment: p95 < 3s
Disponibilidade:
- Error rate geral: < 1%
- Error rate checkout: < 0.1%
- Zero timeout em payment
Recursos:
- CPU < 80%
- Memory < 85%
- DB connections < 90% do pool
Template de Cenário
# Cenário: [Nome do Cenário]
## 1. Contexto
**Evento/Motivação**: [Por que esse teste]
**Data planejada**: [Quando vai rodar]
**Ambiente**: [Staging/Perf/Prod-like]
## 2. Objetivo
**Pergunta principal**: [O que queremos descobrir]
**Hipótese**: [O que esperamos encontrar]
## 3. Escopo
**Funcionalidades testadas**:
- [ ] Feature A
- [ ] Feature B
**Funcionalidades excluídas**:
- [ ] Feature C (motivo)
## 4. Workload
### Perfil de carga
| Parâmetro | Valor |
|-----------|-------|
| Virtual Users | X |
| Ramp-up | X min |
| Steady state | X min |
| Think time | X-Y s |
### Distribuição de ações
| Ação | % | Req/s |
|------|---|-------|
| Action A | X% | X |
| Action B | Y% | Y |
### Dados de teste
- Pool de produtos: X items
- Termos de busca: X únicos
- Usuários: X únicos
## 5. Infraestrutura
### Ambiente de teste
| Componente | Spec |
|------------|------|
| App servers | X × [size] |
| Database | [type], [size] |
| Cache | [type], [size] |
### Monitoramento
- [ ] APM configurado
- [ ] Métricas custom
- [ ] Logs centralizados
- [ ] Alertas ativos
## 6. Critérios
### Sucesso (todos devem passar)
- [ ] Latência p95 < X ms
- [ ] Error rate < X%
- [ ] Throughput > X req/s
### Falha (qualquer um para o teste)
- [ ] Error rate > X%
- [ ] Latência p99 > X s
- [ ] OOM ou crash
### Avisos (documentar mas não para)
- [ ] CPU > X%
- [ ] Memory > X%
## 7. Execução
### Pré-requisitos
- [ ] Ambiente provisionado
- [ ] Dados carregados
- [ ] Cache aquecido
- [ ] Stakeholders notificados
### Checklist de execução
1. [ ] Validar ambiente
2. [ ] Rodar smoke test (1 min)
3. [ ] Capturar baseline
4. [ ] Executar teste completo
5. [ ] Coletar resultados
6. [ ] Documentar observações
### Contatos
- **Owner**: [Nome]
- **Infra**: [Nome]
- **On-call**: [Nome]
## 8. Resultados (preenchido após)
- **Status**: [Pass/Fail]
- **Métricas**: [Link para dashboard]
- **Observações**: [Notas]
- **Ações**: [Próximos passos]
Erros Comuns
1. Cenário sem objetivo claro
❌ "Rodar teste de carga"
✅ "Validar que checkout suporta 5000 req/s com p95 < 3s"
2. Critérios de sucesso vagos
❌ "Sistema deve ser rápido"
✅ "p95 latência < 2s, error rate < 0.5%"
3. Workload irrealista
❌ "1000 VUs fazendo checkout em loop"
✅ "1000 VUs com funil: 80% browse, 15% search, 5% checkout"
4. Duração insuficiente
❌ "5 minutos de teste"
✅ "2 horas steady state + 30 min ramp"
5. Ignorar warm-up
❌ "Iniciar teste imediatamente"
✅ "10 min warm-up para JIT, cache, connection pools"
Conclusão
Um cenário de teste bem definido:
- Tem objetivo claro - responde uma pergunta específica
- Reflete a realidade - workload baseado em dados reais
- Define sucesso - critérios objetivos e mensuráveis
- É reproduzível - documentação completa
- É comunicável - stakeholders entendem
Um teste sem cenário definido é apenas barulho. Um cenário bem definido é conhecimento.
Este artigo faz parte da série sobre a metodologia OCTOPUS de Performance Engineering.