- Суть
- Подробнее
- Жизненный цикл восстановления
- Несколько примеров
- Пишем поэтапный план и тестируем
- Полезности и подводные камни
Суть
Сегодня рассмотрим один из видов тестирования, типологически относящийся к тестированию производительности. Речь пойдёт о тестировании на отказ и восстановление, далее просто тестирование восстановления (recovery testing).
Всякая система, созданная человеком, уязвима к ошибкам человека и непредвиденным обстоятельствам, и может претерпеть временный сбой или полный отказ. Нет способов обеспечить абсолютную, полную устойчивость системы и ее пользователей. Один из более-менее работающих способов смягчить последствия — это попытаться предвидеть такие ситуации, и отработать «пути выхода».
Это и есть цель тестирования восстановления, которое «воссоздает возможные пути» некорректного состояния системы, и анализирует поведение системы. То есть искусственно моделируются условия, при которых система может претерпеть отказ, смотрят как система себя ведет, и в дальнейшем делают выводы — корректируя систему, делая ее более устойчивой.
«Крэши» могут быть в диапазоне от неприятного, но кратковременного сбоя который проходит сам собой — и система возвращается в свое обычное состояние, не требуя особенного обслуживания; и до тотального катастрофического системного отказа, который устраняется усилиями нескольких команд на протяжении нескольких дней например.
В любом случае цель QA-команды: обеспечить, чтобы система была достаточно надежной, выдерживающей такие ситуации, была способной вернуться к своему стандартному рабочему состоянию как можно скорее.
Важно помнить, что устойчивость системы является одним из факторов, определяющих конкурентность приложения на рынке.
Подробнее
Начнем с определений. По справочнику ISTQB, тестирование восстановления является оценкой способности системы восстановиться после отказа. Система искусственно переводится в состояние, при котором должен случиться отказ — чтобы изучить ее показатели при восстановлении, и/или оценить время, нужное на восстановление.
Это даст возможность верифицировать, что система безопасна для использования даже в условиях серьезных ошибок и отказов, а также определить необходимые действия команды.
Причины сбоя могут моделироваться как внутренние, так и внешние. Например, отключение электричества, сервер перестал отвечать, потеря сигнала сети, файл не найден, неправильные или зловредные действия пользователя, и так далее.
В процессе тестирования на отказ и восстановление как правило создается соответствующее тестовое окружение для реалтайм-сценариев.
Важный момент при тестировании восстановления состоит в контроле целостности данных (в частности пользовательских личных и платежных).
Чаще всего тестирование восстановления проводится как одна из завершающих стадий системного тестирования (здесь подробнее о системном).
Жизненный цикл тестирования восстановления ПО
В целом принято выделять 5 этапов:
- Стандартные операции в стандартном состоянии
Система в своем «дефолтном», обычном состоянии. Этап просто для оценки baseline-работоспособности. Все софт- и хард-функции ПО работают, как прописано в требованиях. Все хорошо, а потом
- Случается «катастрофа»
Собственно проверка. Симулируются, в тестовом окружении, условия для, например:
- Отказа «железа»
- Файл не найден
- Системный крэш (ОС компьютера на котором установлено приложение)
- Сервер приложения недоступен
- Непредсказуемое проблемное прерывание стандартного пользовательского процесса (user flow)
- Тяжелые физические условия (температура, например)
- Потеря электроснабжения
- Оценка последствий нарушения стандартного процесса с финансовой и репутационной точек зрения
Все финансовые потери, бизнес-потери, недополученная прибыль, разрушенные отношения с клиентами, уничтоженная репутация на рынке — оцениваются на этом этапе.
Идеальная компания уже давно имела в готовом виде, и теперь лишь вводит в действие — план восстановления, Disaster Recovery Plan, чтобы смягчить все эти негативные «волны». При тестировании восстановления подготовка такого плана позволяет оценить примерный масштаб потерь. В конце концов, психологическая готовность команды тоже играет роль (и знание, что план существует).
- Восстановление
В реальной ситуации, если план был готов, быстро активирован, показал свою эффективность, то всё быстро восстановится. При тестировании восстановления — изучают подробности процессов бэкапа и восстановления важных пользовательских данных, и других активов.
Готовый recovery-план, который спокойно вводится в действие — значительно снижает количество времени, усилий, и денег на этапе восстановления.
Хорошей практикой является предварительный подбор «команды восстановления».
- Rebuild-этап
Последний этап — условный ребилд, или «пересборка» приложения после отказа. Все критически важные файлы и активы проверяются и восстанавливаются; изучается возможность восстановления потерянных данных после реального отказа.
Также готовится документация для пошагового восстановления системы в случае серьезного отказа.
Примеры
- Представим на простейших примерах из жизни. Мы можем симулировать для нашего приложения перебои с сетью, банально выдернув сетевой кабель, по которому оно получает данные. Если после того как кабель вставили назад, данные «пошли как обычно», то есть «продолжились с той же точки», это показывает, что наше приложение обладает неплохими характеристиками восстановления.
- Еще пример: началась закачка большого файла на смартфон по Wi-Fi. Человек уходит из зоны покрытия этой точки, в место где Wi-Fi нет. Чтобы проверить одну из характеристик восстановления системы, человек возвращается в зону покрытия. И если закачка беспроблемно продолжилась с того же места (а не выдала ошибку и закрылась), это ОК восстанавливаемость (recoverability).
- Пример с ноутбуком: внезапная потеря электропитания, при общем отключении электричества в доме, или домашнее животное буйствовало и каким-то образом сумело выдернуть шнур из розетки, или штекер из ноутбука. Оцениваем восстанавливаемость системы: если после включения ноутбука все приложения, бывшие открытыми при отключении — без проблем открылись снова, и все веб-страницы загрузились, то такую систему по праву назовём damage-proof.
Этапы в плане
Итак, на практике, как и при всяком тестировании, командой должен создаваться план тестирования (тест-план). Наши действия будут примерно такие:
Предварительный анализ возможностей восстановления
Перед началом процесса предварительно оценить (письменно) возможности системы к восстановлению, и действия. Включая, например, аллокацию дополнительных серверов или других нужных в данном случае аппаратных ресурсов.
Предварительная оценка результатов отказа и путей выхода из ситуации.
Написание тест-плана
Собственно, составление плана тестовых действий, с учетом анализа из предыдущего этапа.
Подготовка окружения
В котором будет проходить тестирование.
Подготовка бэкапов
Следующий этап будет состоять из проверки существующих / создания бэкапов важных данных, связанных с тестируемым приложением. Данные бэкапятся в разные локации, или же в одной надежной, могут быть онлайн- или офлайн-типа.
Собственно тестирование
Которое зависит от приложения/проекта.
Формирование команды спасателей
Когда с данными порядок, в безопасности, настало время подобрать будущую команду восстановления, как правило из опытных сотрудников, хорошо информированных и прошедших инструктаж, что и как им делать «в случае, если».
Документация
Последний этап — документирование процессов и итоги в виде тестовых отчетов, в которых описаны выполненные этапы, наблюдения, анализ ситуаций.
Как часть тестирования производительности / системного тестирования, тестирование на отказ и восстановление обычно предваряет другие типы нагрузочного (например стрессовое и стабильности) — и они проводятся уже с учетом результатов проведенного тестирования отказоустойчивости (это еще один русскоязычный вариант нашего Failover and Recovery Testing).
Преимущества и недостатки
Хорошо тем, что:
- Повышает общую, «генеральную» надежность системы
- В подобной критической ситуации находят баги в подсистемах безопасности
- И производительности — повышая производительность после коррекции системы с учетом результатов тестирования
- Позволяет наладить бэкапы
Недостатки:
- Редко бывает быстрым процессом, по объективным причинам
- И обычно обходится недешево
- Требует опыта от команды
- Нельзя предусмотреть абсолютно все возможные критические ситуации
***
