| name | teste-de-recuperacao |
| description | Guia o desenvolvedor a validar como o sistema se comporta e se recupera diante de falhas — crashes, perda de conectividade, indisponibilidade de serviços dependentes, corrupção de dados ou interrupção abrupta. Use esta skill SEMPRE que o objetivo for verificar a resiliência e tolerância a falhas do sistema. Acione quando o usuário mencionar: "teste de recuperação", "recovery testing", "chaos engineering básico", "o que acontece quando o banco cai", "e se o sistema falhar no meio de uma transação", "resiliência do sistema", "fallback", "circuit breaker", "testar tolerância a falhas", "o sistema precisa se recuperar de quedas", "o que acontece em caso de falha". Este é um teste avançado que NUNCA deve ser executado em produção. Requer ambiente isolado com capacidade de restauração rápida. Agnóstico de linguagem.
|
| categoria_ibm | Testes de Confiabilidade |
| nivel_maturidade | Avançado |
| skills_relacionadas | ["teste-de-sistema","teste-de-estresse"] |
Teste de Recuperação
O que é
O teste de recuperação verifica como o sistema se comporta diante de falhas e se ele consegue se recuperar dentro de um tempo aceitável. O objetivo é responder: quando algo inevitavelmente der errado, o sistema falha de forma controlada (gracefully) e volta ao normal automaticamente? Os dados ficam íntegros após a falha?
Quando usar
- Quando o sistema tem requisitos de alta disponibilidade ou SLAs de uptime
- Quando quer validar estratégias de fallback e circuit breaker
- Quando quer verificar o comportamento com dependências indisponíveis
- Quando precisa definir e validar RTO (Recovery Time Objective) e RPO (Recovery Point Objective)
- Antes de systems críticos irem para produção (financeiro, saúde, infraestrutura)
Quando NÃO usar
- Em ambiente de produção (nunca — risco de impacto real aos usuários)
- Sem um ambiente isolado e restaurável disponível
- Como substituto para tratamento de erros no código (é um complemento, não um substituto)
Como funciona — Processo Passo a Passo
Passo 1: Mapear pontos de falha
Quais serviços o sistema depende? (banco de dados, APIs externas, filas, cache, armazenamento). Quais são os RTO e RPO definidos? Se não existirem, defina-os antes de continuar.
Passo 2: Categorizar os cenários de falha
- Falha de infraestrutura: servidor indisponível, rede cai, disco cheio
- Falha de serviço dependente: banco fora do ar, API externa indisponível
- Falha de dados: transação incompleta, dados corrompidos
- Falha de aplicação: erro não tratado, deadlock, vazamento de memória
Passo 3: Para cada cenário — definir o teste
Como induzir a falha? O que o sistema deve fazer? Como verificar a recuperação?
Passo 4: Documentar estado antes da falha
Registre o estado do sistema antes de injetar a falha — dados existentes, usuários ativos, transações em aberto.
Passo 5: Injetar a falha
Em ambiente isolado. Registre o comportamento: o sistema exibe mensagem clara? Mantém dados íntegros? Tenta reconectar automaticamente?
Passo 6: Verificar recuperação
Após resolver a falha: o sistema volta automaticamente? Os dados permanecem íntegros? O tempo de recuperação está dentro do RTO?
Passo 7: Documentar
Cenário → falha injetada → comportamento observado → tempo de recuperação → dados afetados.
Critérios de Qualidade
- RTO e RPO estão definidos antes de executar os testes
- Pelo menos 3 categorias de falha diferentes são testadas
- Cada teste é executado em ambiente isolado (nunca produção)
- A integridade dos dados é verificada após a recuperação
- O comportamento de falha é documentado: graceful (controlado) vs. abrupto (crash)
Exemplo Conceitual
Cenário: Indisponibilidade do banco de dados durante uma transação ativa.
| Fase | O que acontece | Comportamento esperado |
|---|
| Banco indisponível | Usuário tenta salvar um pedido | Exibe mensagem: "Sistema temporariamente indisponível. Tente novamente em alguns minutos." |
| Banco indisponível | Transação em andamento é interrompida | Transação é revertida (rollback) — nenhum dado parcial é salvo |
| Banco volta online | Sistema detecta a reconexão | Reconecta automaticamente sem necessidade de reiniciar |
| Após recuperação | Usuário tenta novamente | Pedido é salvo com sucesso — sem dados corrompidos da falha anterior |
Checklist de Conclusão
Skills Relacionadas
| Skill | Relação | Quando preferir aquela |
|---|
teste-de-sistema | Pré-requisito — sistema funciona em condições normais | Antes de testar falhas, garanta que o sistema funciona normalmente |
teste-de-estresse | Complementar — identifica o ponto de colapso | Quando quer empurrar o sistema além dos limites antes de testar recuperação |
