Ответ.

История вопроса:

Тестирование восстановления после сбоев (recovery testing) критически важно для систем, в которых значимы оба — целостность данных и устойчивость работы. Исторически данный вид тестирования применяли преимущественно для банковских, финансовых и медицинских систем, где потеря информации недопустима.

Проблема:

Основной вызов — моделирование ситуаций отказа вручную и последующая верификация корректности восстановления данных, процессов или состояний. Ручной подход вписывает в себя ошибки тестировщика при воспроизведении сценариев, недооценку редких ситуаций и отсутствие автоматизированных средств контроля.

Решение:

Оптимальное ручное recovery testing строится по сценарию:

1. Определение критичных данных и операций для восстановления
2. Моделирование отказа: размонтирование диска, отключение сети, аварийное выключение
3. Оценка реакции системы: сохранилась ли целостность данных, возможна ли корректная работа после восстановления
4. Проверка work-flow: приложение должно либо корректно самовосстановиться, либо дать понятную ошибку и инструменты для ручного восстановления

Ключевые особенности:

Необходимость глубокого понимания бизнес-критичных данных
Воссоздание "сломанной" среды
Скрупулёзная сверка инвариантов до и после сбоя

Вопросы с подвохом.

Достаточно ли проверить восстановление только после одного типа сбоя (например, отключение питания)?

Нет, следует моделировать разные сбои — проблемы сети, базы, аппаратные сбои и др. Только комплексное тестирование даст убедительный результат.

Можно ли считать восстановление успешным, если приложение просто запустилось без ошибок?

Нет, важно убедиться, что вся информация и все процессы полностью восстановлены — иначе "тихая" потеря данных возможна и не будет выявлена.

Нужно ли делать backup данных перед recovery testing?

Обязательно! Перед каждым саботажем нужно делать "контрольную точку" всех критических данных. Это позволит сравнить их до и после сбоев.

Типовые ошибки и анти-паттерны

Тестирование только одного частного случая сбоя
Пропуск сверки всей бизнес-логики после рестарта
Работа без резервирования (backup) исходных данных

Пример из жизни

Негативный кейс

Тестировщик смоделировал только отключение питания, не проверяя потерю соединения с базой. В результате после сбоя часть транзакций "потерялась".

Плюсы:

Быстро и просто провести тест

Минусы:

Упущены критичные потери данных в реальной эксплуатации

Позитивный кейс

Тестировщик спланировал разные типы сбоев, сделал бэкапы, провёл ручную сверку и поднял несколько багов с некорректным восстановлением. Все критические процессы сохранены.