Тестирование восстановления (англ. Recovery Testing) – это один из методов тестирования программного обеспечения. Его суть в проверке способности ПО восстанавливаться после сбоев (программных, аппаратных, сетевых и т.д.).
Цель тестирования восстановления – определить, может ли программное обеспечение продолжить работу после сбоя или потери целостности. Тестирование восстановления включает в себя возврат программы к точке проверенной целостности и повторную обработку транзакций до точки сбоя.
БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"
Пример Recovery Testing
- Отсоедините соединительный кабель, когда приложение получает данные из сети. Через некоторое время подключите кабель обратно. Проанализируйте способность приложения продолжать получать данные от точки, в которой было разорвано сетевое соединение.
- Перезапустите систему, когда в браузере открыто определенное количество сессий, и проверьте, способен ли браузер восстановить все из них.
В программной инженерии тестирование восстановления является разновидностью нефункционального тестирования. Нефункциональное тестирование затрагивает аспекты, которые могут быть не связаны с конкретной функцией или действиями пользователя, например, масштабируемость или безопасность.
Примечание редакции: о видах тестирования можно почитать здесь.
Время, необходимое для восстановления, зависит от следующих обстоятельств:
- количества точек перезапуска
- объема приложений
- подготовки и навыков людей, осуществляющих восстановление, а также доступных инструментов для восстановления.
При наличии нескольких сбоев тестирование восстановления должно проводиться структурированно. То есть сначала оно проводится для одного сегмента, а затем для другого.
Этим занимаются профессиональные тестировщики. Перед Recovery Testing соответствующие бэкапы данных сохраняются в надежных местах. Это гарантирует возможность продолжения работы даже после аварии.
Жизненный цикл процесса восстановления
Жизненный цикл процесса восстановления можно разделить на следующие пять этапов:
- Нормальная работа
- Возникновение аварийной ситуации
- Нарушение и сбой в работе
- Устранение последствий аварии с помощью процесса восстановления
- Реконструкция всех процессов и информации для приведения всей системы в состояние нормальной работы
Давайте рассмотрим эти 5 шагов подробнее.
- Система, состоящая из аппаратных средств, программного обеспечения и встроенного программного обеспечения, интегрированных для достижения общей цели, вводится в эксплуатацию для выполнения четко определенной и заявленной цели. Система призвана выполнять нормальную работу по выполнению поставленной задачи без сбоев в течение оговоренного периода времени.
- Нарушение работы может произойти из-за сбоя в работе программного обеспечения. Причиной может быть сбой из-за некорректного ввода, сбой из-за отказа оборудования, повреждения в результате пожара и т.п.
- Фаза сбоя – самая болезненная. Она приводит к потерям в бизнесе, потерям возможностей, потерям человеко-часов и непременно к финансовым и репутационным потерям. Каждая компания должна иметь план аварийного восстановления, чтобы фаза сбоя была минимальной.
- Если есть план резервного копирования, а процессы снижения рисков налажены, то восстановление может быть проведено без больших потерь времени и сил. Чтобы избежать длительных сбоев, нужно заранее назначить ответственного за восстановление и распределить роли в его команде.
- Для восстановления всех папок и конфигурационных файлов могут потребоваться несколько сеансов работы. Для правильного восстановления должна быть надлежащая документация и процесс реконструкции.
Стратегия восстановления
Команда, занимающаяся восстановлением, должна иметь стратегию извлечения важного кода и данных для возвращения работы компании в нормальное русло.
Стратегия может быть уникальной для каждой организации и основываться на критичности систем, с которыми они работают.
Возможная стратегия для критических систем может быть представлена следующим образом:
- Бэкапов может быть несколько, но может быть и один.
- Резервные копии могут храниться в одном месте или в разных местах.
- Бэкап может храниться онлайн или офлайн.
- Резервное копирование может выполняться вручную или автоматически, на основе определенных правил.
- Восстановлением может заниматься независимая команда или к этому могут привлекать самих разработчиков.
Каждая из этих стратегий имеет свою цену. Несколько бэкапов потребуют больше ресурсов, независимая команда, занимающаяся восстановлением, – тоже.
Многие компании могут пострадать из-за зависимости их данных и кода от сторонней компании. Например, если Amazon AWS выходит из строя, это приводит к отключению интернета. В таких случаях независимое восстановление имеет решающее значение.
Как проводить тестирование восстановления
При проведении Recovery Testing необходимо учитывать следующие моменты:
- Тестовый стенд нужно делать максимально приближенным к реальным условиям развертывания. Изменения в интерфейсе, протоколе, микропрограмме, аппаратном и программном обеспечении должны быть максимально приближены к реальным условиям, если не совпадать с ними.
- Поскольку исчерпывающее тестирование может занять много времени и быть дорогостоящим мероприятием, следует проводить идентичную конфигурацию и полную проверку.
- Если возможно, тестирование следует проводить на том оборудовании, которое мы собираемся восстанавливать. Это особенно актуально, если мы восстанавливаем на другой машине, а не на той, на которой была создана резервная копия.
- Некоторые системы резервного копирования ожидают, что жесткий диск будет точно такого же размера, как и тот, с которого была сделана резервная копия.
- Необходимо следить за устареванием, поскольку технология дисков развивается быстрыми темпами, и старый диск может быть несовместим с новым. Один из способов решения этой проблемы – восстановление на виртуальную машину. Поставщики программного обеспечения для виртуализации, такие как VMware Inc., могут настроить виртуальные машины таким образом, чтобы они имитировали существующее оборудование, включая размеры дисков и другие конфигурации.
- Системы онлайнового резервного копирования не являются исключением для тестирования. Большинство поставщиков услуг онлайнового резервного копирования защищают нас от проблем с носителями путем использования отказоустойчивых систем хранения.
- Хотя системы онлайн-бэкапов чрезвычайно надежны, нужно протестировать сторону восстановления системы, чтобы убедиться в отсутствии проблем с функциональностью поиска, безопасностью или шифрованием.
Процедура тестирования после восстановления
Большинство крупных корпораций привлекают независимых аудиторов для периодического проведения тестирования восстановления. Но расходы на поддержание и тестирование комплексного плана аварийного восстановления могут быть значительными, а для небольших компаний они могут оказаться непомерно высокими. Маленькие компании могут положиться на собственные бэкапы, которые спасут их в случае аварии.
После восстановления папок и файлов можно выполнить следующие проверки, чтобы убедиться, что файлы восстановлены правильно:
- Переименуйте поврежденную папку с документами.
- Пересчитайте файлы в восстановленных папках и сопоставьте их с существующей папкой.
- Откройте несколько файлов и убедитесь, что они доступны. Обязательно откройте их с помощью приложения, которое обычно их использует. И убедитесь, что вы можете просматривать данные, обновлять их или делать то, что вы обычно с ними делаете.
- Лучше всего открыть несколько файлов разных типов: картинки, mp3, документы, несколько больших и несколько маленьких.
- В большинстве операционных систем есть утилиты, которые можно использовать для сравнения файлов и каталогов.
Заключение
В этой статье мы рассказали, что собой представляет тестирование восстановления (recovery testing), и разобрали основные аспекты этого вида тестирования.
Перевод статьи Thomas Hamilton «What is Recovery Testing? with Example».