O que é teste de recuperação? com exemplo

⚡ Resumo Inteligente

Os testes de recuperação verificam se o software consegue retomar o funcionamento normal após uma falha, uma queda de rede ou uma falha de hardware, restaurando o sistema a um ponto de funcionamento conhecido e reprocessando as transações até o momento da falha.

  • 🔁 O que isso comprova: OperaAs ações continuam após um desastre, não se trata apenas de ter um arquivo de backup.
  • 🧩 Onde se situa: Uma técnica não funcional, executada por testadores treinados em dados de backup seguros.
  • ⏱️ Fatores que influenciam o tempo de recuperação: Pontos de reinicialização, volume de dados e as habilidades e ferramentas da equipe de recuperação.
  • 🔄 Formato do processo: Operação normal, desastre, interrupção, recuperação e, em seguida, reconstrução para retorno à normalidade.
  • 💾 Opções de estratégia: Cópias de segurança únicas ou múltiplas, de um ou vários locais, online ou offline, automáticas ou manuais.
  • Após a restauração: Contar arquivos em relação à pasta original, abrir vários tipos de arquivos e comparar diretórios com utilitários do sistema.

O que é teste de recuperação em testes de software? Com ​​um exemplo.

O que é teste de recuperação?

Teste de Recuperação É uma técnica de teste de software que verifica a capacidade do software de se recuperar de falhas como travamentos de software ou hardware e falhas de rede. O objetivo do teste de recuperação é determinar se as operações do software podem ser continuadas após um desastre ou uma perda de integridade. O teste de recuperação envolve reverter o software para o ponto em que a integridade era conhecida e reprocessar as transações até o ponto da falha.

Em engenharia de software, o teste de recuperabilidade é um tipo de testes não funcionais — Abrange aspectos não vinculados a uma função específica ou ação do usuário, como escalabilidade ou segurança. É realizado por testadores profissionais, e dados de backup adequados são mantidos em locais seguros previamente.

Exemplo de teste de recuperação

Dois cenários mostram a técnica em sua forma mais simples. Em cada um deles, uma falha é forçada deliberadamente e, em seguida, o aplicativo é monitorado enquanto é retomado.

  • Interrupção de rede: Enquanto um aplicativo estiver recebendo dados da rede, desconecte o cabo de conexão. Após algum tempo, reconecte-o e analise a capacidade do aplicativo de continuar recebendo dados a partir do ponto em que a conexão foi interrompida.
  • Restauração da sessão: Reinicie o sistema enquanto o navegador tiver um número definido de sessões abertas e verifique se o navegador recupera todas elas.

A ilustração abaixo apresenta a mesma ideia de forma visual.

Conceito de teste de recuperação que demonstra um sistema falhando e sendo restaurado ao funcionamento normal.

O tempo necessário para recuperação depende de:

  • O número de pontos de reinicialização
  • O volume de dados armazenados pelo aplicativo
  • Treinamento e habilidades das pessoas que conduzem atividades de recuperação, e as ferramentas disponíveis para a recuperação.

Quando ocorrem várias falhas, os testes de recuperação devem ser feitos de forma estruturada, em vez de serem realizados todos de uma vez — primeiro um segmento e depois outro.

Ciclo de Vida do Processo de Recuperação

Antes de elaborar os casos de teste, é útil identificar onde um teste de recuperação entra em ação. O ciclo de vida do processo de recuperação possui cinco etapas:

  1. Operação normal
  2. Ocorrência de desastre
  3. Interrupção e falha da operação
  4. Eliminação de desastres através do processo de recuperação
  5. Reconstrução de todos os processos e informações, trazendo todo o sistema de volta ao funcionamento normal.

O fluxograma abaixo mostra essas cinco etapas em sequência.

Fluxograma do ciclo de vida do processo de recuperação, abrangendo operação normal, desastre, interrupção, recuperação e reconstrução.

Vamos discutir esses cinco passos em detalhes:

  1. Operação normal. Um sistema de hardware, software e firmware, integrado para atingir um objetivo comum, executa a função para a qual foi projetado sem interrupções dentro de um período de tempo estipulado.
  2. Ocorrência de desastre. Uma interrupção pode ocorrer devido a mau funcionamento do software, causado por fatores como mau funcionamento iniciado por entrada de dados, falha provocada por defeito de hardware ou danos causados ​​por incêndio, roubo ou greve.
  3. Interrupção e fracasso. Esta é a fase mais dolorosa, que leva a perdas comerciais, rompimento de relacionamentos, perda de oportunidades, perda de horas de trabalho e, invariavelmente, perdas financeiras e de reputação. Um plano de recuperação de desastres minimiza essa fase.
  4. Desobstrução de desastres. Se já existirem um plano de contingência e processos de mitigação de riscos, a recuperação custará muito menos tempo e esforço. Uma equipe designada, com a função de cada pessoa definida antecipadamente, estabelece responsabilidades e evita um longo período de interrupção.
  5. Reconstrução. Isso pode envolver múltiplas sessões de operação para reconstruir todas as pastas, juntamente com os arquivos de configuração. Documentação adequada e um processo de reconstrução definido são necessários para uma recuperação correta.

Estratégia de Restauração

A equipe de recuperação deve ter sua própria estratégia para recuperar códigos e dados importantes a fim de restabelecer as operações normais. Essa estratégia é exclusiva para cada organização, com base na criticidade dos sistemas que ela gerencia, e, para sistemas críticos, se resume a um conjunto de escolhas:

  1. Um único backup ou mais de um.
  2. Vários backups em um único local ou em locais diferentes.
  3. Backup online ou backup offline
  4. Os backups são executados automaticamente de acordo com uma política ou acionados manualmente.
  5. Uma equipe de restauração independente ou a equipe de desenvolvimento que realiza o trabalho.

Cada opção acarreta um custo, e backups múltiplos podem consumir mais recursos físicos ou exigir uma equipe independente. A dependência também é importante: as empresas ficam expostas por meio do código e dos dados que mantêm com um único fornecedor, e uma solução em larga escala pode ser prejudicial. AWS A interrupção do serviço já deixou diversos serviços de consumo populares offline simultaneamente. A capacidade de restauração independente é crucial nesses casos.

Como fazer testes de recuperação

Com a estratégia definida, a próxima questão é como o próprio teste será configurado. Os seguintes pontos devem ser considerados ao realizar testes de recuperação.

  • Crie um ambiente de testes o mais próximo possível das condições reais de implantação: a interface, o protocolo, o firmware, o hardware e o software devem ser idênticos aos da produção.
  • Embora testes exaustivos possam ser demorados e dispendiosos, uma configuração idêntica e uma verificação completa ainda devem ser realizadas.
  • Se possível, teste no hardware que será usado na restauração final — especialmente ao restaurar para uma máquina diferente daquela que criou o backup.
  • Alguns sistemas de backup esperam que o disco rígido tenha exatamente o mesmo tamanho daquele de onde o backup foi feito.
  • Gerencie a obsolescência: a tecnologia de discos rígidos avança rapidamente e um disco antigo pode não ser compatível com um novo. Restaurar para um estado anterior pode ser uma boa opção. máquina virtual Isso ajuda, já que o software de virtualização pode simular o hardware existente, incluindo o tamanho dos discos.
  • Os sistemas de backup online não são exceção aos testes. A maioria dos provedores protege os usuários contra problemas de mídia por meio de armazenamento tolerante a falhas, de modo que as falhas só aparecem tardiamente.
  • Embora os sistemas de backup online sejam extremamente confiáveis, o lado da restauração deve ser testado para confirmar que não há problemas com a recuperação, segurança ou criptografia.

Como a recuperação é exercitada de ponta a ponta, essas corridas geralmente são programadas em conjunto com outras. teste do sistema em vez de ao nível da unidade.

Procedimento de teste após a restauração

Restaurar os dados é apenas metade do processo; a cópia restaurada ainda precisa ser comprovada como utilizável. A maioria das grandes corporações contrata auditores independentes para realizar exercícios de recuperação periodicamente. Um plano abrangente de recuperação de desastres é caro para manter e testar, portanto, organizações menores geralmente optam por backups e armazenamento externo.

Após a restauração de pastas e arquivos, as seguintes verificações confirmam que a recuperação foi realizada corretamente:

  • Renomeie a pasta do documento corrompido para que a cópia restaurada não seja confundida com ela.
  • Conte os arquivos nas pastas restauradas e compare essa contagem com a da pasta original.
  • Abra alguns arquivos com o aplicativo que você normalmente usa e confirme se os dados podem ser visualizados e atualizados como de costume.
  • Abra vários arquivos de tipos diferentes — imagens, MP3e documentos, alguns grandes e outros pequenos.
  • Utilize os utilitários de comparação de arquivos e diretórios mais comuns. sistemas operacionais proporcionar.

Perguntas Frequentes

Os testes de failover verificam se o tráfego é transferido corretamente para um nó de espera. Os testes de recuperação vão além e verificam se o serviço original, seus dados e suas transações em andamento retornam a um estado correto.

O RTO (Tempo de Recuperação) é o tempo permitido para restaurar um serviço; o RPO (Ponto de Acerto de Recuperação) é a perda de dados aceitável. Um teste de recuperação mede ambos: o tempo de restauração (RTO) e a comparação dos dados recuperados com o último estado íntegro conhecido (RPO).

Três variantes se repetem: recuperação de desastres para interrupções em todo o site, recuperação de banco de dados para armazenamentos de dados corrompidos e recuperação de ambiente para configurações ou dependências quebradas. Cada uma utiliza o mesmo ciclo de vida, mas com um gatilho de falha diferente.

Os modelos de aprendizado de máquina classificam os serviços com base no histórico de incidentes e na profundidade da dependência, de modo que os caminhos de restauração mais arriscados sejam executados primeiro. A detecção de anomalias nos registros de restauração também sinaliza execuções que foram concluídas, mas produziram dados incompletos.

Copiloto do GitHub O sistema cria rapidamente scripts auxiliares para injeção de falhas, scripts de restauração e asserções pós-restauração. O testador ainda decide qual falha forçar e qual a aparência de um estado recuperado correto, já que ambos seguem regras de negócio.

Exercícios anuais são comuns, com simulações trimestrais para sistemas críticos. Qualquer alteração na ferramenta de backup, plataforma de armazenamento ou arquitetura deve acionar uma nova execução, visto que uma alteração não testada invalida silenciosamente o resultado anterior.

Isso força falhas reais, portanto, se sobrepõe a teste destrutivoMas o objetivo é a restauração, não a quebra. Execute o teste em um ambiente isolado, não em dados de produção reais.

Registre a falha detectada, os horários de início e término, os valores de RTO e RPO medidos, as etapas que necessitaram de intervenção manual e todas as discrepâncias encontradas nos dados restaurados. Adicione as ações corretivas e a data do novo teste.

Resuma esta postagem com: