¿Qué son las pruebas de recuperación? con ejemplo

⚡ Resumen inteligente

Las pruebas de recuperación verifican que el software pueda reanudar su funcionamiento normal después de un fallo, una caída de la red o un fallo de hardware, restaurando el sistema a un punto en el que funcionaba correctamente y reprocesando las transacciones hasta el momento del fallo.

  • 🔁 Lo que demuestra: OperaLas acciones continúan después de un desastre, no solo que exista un archivo de respaldo.
  • 🧩 Dónde se encuentra: Una técnica no funcional, ejecutada por evaluadores capacitados contra datos de respaldo protegidos.
  • 🇧🇷 Factores que influyen en el tiempo de recuperación: Puntos de reinicio, volumen de datos y las habilidades y herramientas del equipo de recuperación.
  • 🔄 Forma del proceso: Operación normal, desastre, interrupción, recuperación y posterior reconstrucción para volver a la normalidad.
  • 💾 Opciones estratégicas: Copias de seguridad individuales o múltiples, en un solo sitio o en varios, en línea o fuera de línea, automáticas o manuales.
  • Después de restaurar: Cuenta los archivos en la carpeta original, abre varios tipos y compara los directorios con las utilidades del sistema.

¿Qué son las pruebas de recuperación en las pruebas de software? (Con un ejemplo)

¿Qué son las pruebas de recuperación?

Pruebas de recuperación La recuperación de datos es una técnica de prueba de software que verifica la capacidad del software para recuperarse de fallos como caídas de software o hardware y fallos de red. El objetivo de las pruebas de recuperación es determinar si las operaciones del software pueden continuar después de un desastre o una pérdida de integridad. Las pruebas de recuperación implican restaurar el software al estado en el que se conocía su integridad y reprocesar las transacciones hasta el punto de fallo.

En ingeniería de software, las pruebas de recuperabilidad son un tipo de pruebas no funcionales — Cubre aspectos no vinculados a una función o acción específica del usuario, como la escalabilidad o la seguridad. Lo realizan evaluadores profesionales y se guardan copias de seguridad adecuadas en ubicaciones seguras con antelación.

Ejemplo de prueba de recuperación

Dos escenarios muestran la técnica en su forma más simple. En cada uno, se provoca un fallo deliberadamente y, a continuación, se observa cómo se reanuda la aplicación.

  • Interrupción de la red: Mientras una aplicación recibe datos de la red, desconecte el cable de conexión. Después de un tiempo, vuelva a conectarlo y analice si la aplicación puede seguir recibiendo datos desde el punto en que se interrumpió la conexión.
  • Restaurar sesión: Reinicie el sistema mientras el navegador tenga un número determinado de sesiones abiertas y compruebe si el navegador las recupera todas.

La siguiente ilustración presenta la misma idea de forma visual.

Concepto de prueba de recuperación que muestra un sistema que falla y luego se restablece a su funcionamiento normal.

El tiempo necesario para recuperarse depende de:

  • El número de puntos de reinicio.
  • El volumen de datos que contiene la aplicación
  • La formación y las habilidades de las personas que realizan actividades de recuperación, y las herramientas disponibles para la recuperación.

Cuando se producen varios fallos, las pruebas de recuperación deben realizarse de forma estructurada, en lugar de llevarlas a cabo todas a la vez, primero en un segmento y luego en otro.

Ciclo de vida del proceso de recuperación

Antes de diseñar los casos de prueba, es útil ver dónde interviene una prueba de recuperación. El ciclo de vida del proceso de recuperación tiene cinco pasos:

  1. Operación normal
  2. Ocurrencia de desastre
  3. Interrupción y fallo de la operación
  4. Eliminación de desastres a través del proceso de recuperación
  5. Reconstrucción de todos los procesos e información, para que todo el sistema vuelva a funcionar con normalidad.

El diagrama de flujo que aparece a continuación muestra esas cinco etapas en secuencia.

Diagrama de flujo del ciclo de vida del proceso de recuperación que abarca el funcionamiento normal, el desastre, la interrupción, la recuperación y la reconstrucción.

Analicemos estos cinco pasos en detalle:

  1. Operación normal. Un sistema compuesto por hardware, software y firmware, integrado para lograr un objetivo común, realiza la función para la que fue diseñado sin interrupciones dentro de un período de tiempo estipulado.
  2. Ocurrencia de desastre. Puede producirse una interrupción debido a un mal funcionamiento del software, por causas tales como un mal funcionamiento provocado por la entrada de datos, un fallo del sistema causado por un fallo del hardware o daños por incendio, robo o huelga.
  3. Interrupción y fracaso. Esta es la fase más dolorosa, que conlleva pérdidas económicas, relaciones deterioradas, oportunidades perdidas, horas de trabajo desperdiciadas e, invariablemente, pérdidas financieras y de reputación. Un plan de recuperación ante desastres minimiza esta fase.
  4. Limpieza tras el desastre. Si ya se cuenta con un plan de respaldo y procesos de mitigación de riesgos, la recuperación requiere mucho menos tiempo y esfuerzo. Un equipo designado, con el rol de cada miembro definido de antemano, establece responsabilidades y evita un período prolongado de interrupción.
  5. Reconstrucción. Esto puede requerir varias sesiones de operación para reconstruir todas las carpetas y los archivos de configuración. Para una recuperación correcta, se requiere documentación adecuada y un proceso de reconstrucción definido.

Estrategia de restauración

El equipo de recuperación debe tener su propia estrategia para recuperar el código y los datos importantes y así restablecer la normalidad en las operaciones. Esta estrategia es única para cada organización, en función de la criticidad de los sistemas que gestiona, y para los sistemas críticos se reduce a una serie de decisiones:

  1. Una sola copia de seguridad, o más de una
  2. Múltiples copias de seguridad en un mismo lugar o en lugares diferentes.
  3. Copia de seguridad en línea o copia de seguridad fuera de línea
  4. Las copias de seguridad se ejecutan automáticamente según una política o se activan manualmente.
  5. Un equipo de restauración independiente o el equipo de desarrollo que realiza el trabajo.

Cada opción conlleva un factor de costo, y las copias de seguridad múltiples pueden consumir más recursos físicos o requerir un equipo independiente. La dependencia también importa: las empresas están expuestas a través del código y los datos que almacenan con un solo proveedor, y una gran escala AWS En repetidas ocasiones, las interrupciones del servicio han dejado fuera de servicio simultáneamente a servicios de consumo muy conocidos. La capacidad de restablecer el servicio de forma independiente es crucial en estos casos.

Cómo hacer pruebas de recuperación

Definida la estrategia, la siguiente pregunta es cómo se configura la prueba en sí. Se deben tener en cuenta los siguientes puntos al realizar las pruebas de recuperación.

  • Cree un entorno de pruebas lo más parecido posible a las condiciones de implementación reales: la interfaz, el protocolo, el firmware, el hardware y el software deben coincidir con los de producción.
  • Aunque las pruebas exhaustivas pueden ser largas y costosas, se debe realizar una configuración idéntica y una verificación completa.
  • Si es posible, realice la prueba en el hardware en el que finalmente se restaurará el sistema, especialmente si la restauración se realiza en una máquina diferente a la que creó la copia de seguridad.
  • Algunos sistemas de copia de seguridad esperan que el disco duro sea exactamente del mismo tamaño que aquel del que se realizó la copia de seguridad.
  • Gestionar la obsolescencia: la tecnología de las unidades avanza rápidamente y una unidad antigua puede no ser compatible con una nueva. Restaurar a un máquina virtual Esto resulta útil, ya que el software de virtualización puede imitar el hardware existente, incluidos los tamaños de los discos.
  • Los sistemas de copia de seguridad en línea no son una excepción a las pruebas. La mayoría de los proveedores protegen a los usuarios de los problemas con los medios de almacenamiento mediante sistemas tolerantes a fallos, por lo que los fallos se manifiestan tardíamente.
  • Aunque los sistemas de copia de seguridad en línea son extremadamente fiables, es necesario probar el sistema de restauración para confirmar que no haya problemas con la recuperación, la seguridad o el cifrado.

Debido a que la recuperación se realiza de principio a fin, estas carreras suelen programarse junto con... prueba del sistema en lugar de a nivel de unidad.

Procedimiento de prueba después de la restauración

Restaurar los datos es solo la mitad del proceso; aún hay que demostrar que la copia restaurada es utilizable. La mayoría de las grandes corporaciones contratan auditores independientes para que realicen simulacros de recuperación periódicamente. Un plan integral de recuperación ante desastres es costoso de mantener y probar, por lo que las organizaciones más pequeñas suelen recurrir a copias de seguridad y almacenamiento externo.

Una vez restauradas las carpetas y los archivos, las siguientes comprobaciones confirman que se han recuperado correctamente:

  • Cambie el nombre de la carpeta del documento dañado para que la copia restaurada no se confunda con ella.
  • Cuenta los archivos en las carpetas restauradas y compara esa cantidad con la de la carpeta original.
  • Abra algunos archivos con la aplicación que normalmente utiliza y confirme que los datos se pueden consultar y actualizar como de costumbre.
  • Abra varios archivos de diferentes tipos: imágenes, MP3y documentos, algunos grandes y otros pequeños.
  • Utilice las utilidades de comparación de archivos y directorios que la mayoría sistemas operativos proporcionar.

Preguntas Frecuentes

Las pruebas de conmutación por error verifican si el tráfico se transfiere correctamente a un nodo de reserva. Las pruebas de recuperación van más allá y comprueban si el servicio original, sus datos y sus transacciones en curso vuelven a un estado correcto.

El RTO es el tiempo permitido para restablecer un servicio; el RPO es la pérdida de datos aceptable. Una prueba de recuperación mide ambos: cronometra la restauración para el RTO y compara los datos recuperados con el último estado correcto conocido para el RPO.

Se presentan tres variantes recurrentes: recuperación ante desastres para interrupciones generalizadas del sistema, recuperación de bases de datos para almacenes de datos dañados y recuperación del entorno para configuraciones o dependencias defectuosas. Cada una utiliza el mismo ciclo de vida con un desencadenante de fallo diferente.

Los modelos de aprendizaje automático clasifican los servicios según su historial de incidentes y la profundidad de sus dependencias, de modo que las rutas de restauración más riesgosas se ejecutan primero. La detección de anomalías en los registros de restauración también señala las ejecuciones que finalizaron pero produjeron datos incompletos.

Copiloto de GitHub Crea rápidamente scripts auxiliares para la inyección de fallos, scripts de restauración y aserciones posteriores a la restauración. El probador sigue decidiendo qué fallo forzar y cómo debe ser un estado recuperado correcto, ya que ambos siguen las reglas de negocio.

Es habitual realizar simulacros anuales, con pruebas trimestrales para los sistemas críticos. Cualquier cambio en la herramienta de copia de seguridad, la plataforma de almacenamiento o la arquitectura debe dar lugar a una nueva ejecución, ya que un cambio no probado invalida silenciosamente el resultado anterior.

Fuerza fallos reales, por lo que se superpone con pruebas destructivasPero el objetivo es la restauración, no la destrucción. Ejecútelo en un entorno de prueba aislado, no con datos de producción reales.

Registre la falla detectada, las horas de inicio y finalización, el RTO y el RPO medidos, los pasos que requirieron intervención manual y cualquier discrepancia encontrada en los datos restaurados. Añada las acciones correctivas y la fecha de la nueva prueba.

Resumir este post con: