Тестирование миграции данных

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

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

Содержание

Что такое тестирование миграции?
Зачем нужно тестировать миграцию?
Когда проводится тестирование миграции?
Стратегия тестирования миграции данных
Фазы миграции
Тестирование обратной совместимости
Тестирование отката
Сводный отчет о выполнении тестирования миграции
Сложности тестирования миграции данных
Рекомендации по снижению рисков миграции данных
Заключение

Что такое тестирование миграции?

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

Простое представление системы миграции данных может быть отображено следующим образом:

Легаси-система - Миграция - Новая система

Что это означает для тестировщика? С точки зрения тестирования, это означает, что приложение должно быть тщательно проверено на всем пути миграции данных из старой системы в новую. Существующая функциональность должна быть проверена вместе с новой или модифицированной.

В этом случае проводится системное тестирование со всеми данными, которые использовались в старом приложении, а также с новыми данными, их комбинацией, а также старыми и новыми функциями.

Легаси-приложения тоже тестируются, пока новые версии не станут стабильными.

Зачем нужно тестировать миграцию?

Приложение может быть перенесено на новую систему по различным причинам, таким как консолидация систем, замена устаревших технологий, оптимизация и прочее.

При переносе работающей системы в новые условия необходимо:

Избежать любых неудобств для пользователей (или свести эти неудобства к минимуму). Например, не должно быть потери данных, а время, когда система недоступна, должно быть совсем небольшим.
Убедиться, что пользователь после миграции может продолжать использовать все функции программного обеспечения.
Предусмотреть и исключить все возможные сбои/неполадки, которые могут возникнуть во время миграции действующей системы.

Чтобы обеспечить плавную миграцию действующей системы, необходимо провести тестирование миграции в контролируемых условиях. Это особенно важно, когда речь идет о данных.

С технической точки зрения, необходимо выполнить следующие задачи:

Обеспечить совместимость нового/обновленного приложения с аппаратным и программным обеспечением легаси-приложения. Также нужно протестировать совместимость с новым оборудованием и программной платформой.
Убедиться, что все существующие функциональные возможности работают так же, как в легаси-приложении. Не должно быть изменений в способе работы приложения по сравнению с легаси-версией.
Вероятность возникновения проблем из-за миграции очень высока. Особенно в части работы с данными. Они должны быть выявлены и исправлены во время тестирования.
Убедиться, что время отклика системы нового/обновленного приложения такое же или меньше, чем у легаси-приложения.
Проверить, что связь между серверами, аппаратным, программным обеспечением, другими компонентами сохраняется и не прерывается во время тестирования. Поток данных между различными компонентами не должен нарушаться в любых условиях.

Когда проводится тестирование миграции?

Тестирование должно проводиться как до, так и после миграции.

Этапы миграционного тестирования:

Предмиграционное тестирование
Собственно тестирование миграции
Постмиграционное тестирование

В качестве дополнения обычно выполняются тестирование обратной совместимости и тестирование отката.

Приступая к тестированию миграции, тестировщик должен четко понимать следующие вещи:

Что меняется в новой системе (сервер, фронтенд, база данных, поток данных, функциональность и т.д.)
Стратегию миграции (процесс миграции, шаги изменений в бэкенде и скрипты, ответственные за эти изменения).

Следовательно, сначала необходимо изучить обновленную систему и легаси-систему. Затем нужно подготовить стратегию тестирования и соответствующим образом спланировать тест-кейсы и тестовые сценарии.

Стратегия тестирования миграции данных

Стратегия тестирования миграции оговаривает действия, которые позволят минимизировать ошибки и риски, возникающие в процессе переноса данных. Она включает:

1. Формирование специализированной команды

Команда тестирования набирается из специалистов, обладающих необходимыми знаниями и опытом. Членов команды нужно дополнительно познакомить с мигрирующей системой.

2. Анализ бизнес-рисков и возможных ошибок

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

Тестирование должно включать сценарии для выявления этих рисков и проверки эффективности мер их снижения.

Также необходимо провести анализ возможных ошибок, а затем на его основе разработать тесты.

3. Анализ объема миграции

Необходимо определить четкие рамки тестирования миграции, его временные интервалы и направления тестирования.

4. Определение подходящих инструментов

Необходимо определить инструменты, которые будут использоваться, в соответствии с выбранным видом тестирования. Например, вы можете применять автоматизированный инструмент для сравнения данных исходной и целевой системы.

5. Выбор тестовой среды

Среда выбирается для предварительного и постмиграционного тестирования. Здесь необходимо понимать и задокументировать технические аспекты легаси-системы и обновленной системы, чтобы убедиться, что тестовая среда настроена правильным образом.

6. Составление спецификации

В спецификации тестирования миграции описываются:

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

Все это обсуждается затем со стейкхолдерами (заинтересованными сторонами).

7. Запуск обновленной системы

Требуется проанализировать и задокументировать итоговый список задач для переноса рабочей системы.

Фазы тестирования миграции

1. Предмиграционное тестирование

Перед миграцией данных проводится ряд мероприятий по тестированию. Для простых приложений этот этап можно пропустить. Но в сложных приложениях фаза предмиграционного тестирования является обязательной.

Основные действия на этом этапе:

Установить четкий объем данных. Определите, какие данные должны быть включены, какие – исключены, какие данные требуют преобразования/конверсии и т.д.
Провести маппинг данных между легаси- и новым приложением. Для этого нужно сравнить типы данных в легаси-приложении с их типами в новом приложении (высокоуровневый маппинг).
Если в новом приложении есть поля, обязательные для заполнения поля, а в легаси-приложении такого требования нет, нужно убедиться, что в легаси-приложении эти поля не являются нулевыми (низкоуровневый маппинг).
Изучить схему нового приложения (имена полей, типы, минимальные и максимальные значения, длину полей, обязательные поля, проверки на уровнях полей и т.д.).
Записать количество таблиц в легаси-приложении и затем проверить, были ли какие-либо таблицы удалены или добавлены после миграции.
Записать количество записей в каждой таблице в легаси-приложении и затем проверить обновленном приложении.
Изучить интерфейса и соединения. Данные, проходящие через интерфейс, должны быть надежно защищены и не повреждены.
Подготовить тест-кейсы и тестовые сценарии и использовать их в новом приложении.
Выполнить тест-кейсы и сценарии для части пользователей. Сохранить результаты и логи.

2. Тестирование миграции

Необходимо строго следовать руководству по миграции, подготовленному командой. В идеале, миграционная деятельность начинается с создания резервной копии данных, чтобы легаси-систему можно было восстановить в любое время.

Проверка самого документа “Руководство по миграции” также является частью тестирования миграции данных. Нужно проверить, понятен ли документ и легко ли ему следовать. Все сценарии и шаги должны быть задокументированы правильно, без каких-либо двусмысленностей. Любые ошибки в документации, несоответствия в порядке выполнения шагов крайне важны. О них необходимо сообщить для внесения корректировок.

Скрипты миграции, руководства и другая информация, связанная с миграцией, должны быть взяты из репозитория контроля версий.

Необходимо отметить фактическое время, затраченное на миграцию от ее начала до успешного восстановления работоспособности системы. Время, затраченное на миграцию системы, должно быть записано в окончательном отчете, который будет представлен в качестве результатов тестирования миграции. Эта информация будет полезна при запуске в производство.

Время простоя, зарегистрированное в тестовой среде, экстраполируется для расчета приблизительного времени простоя в реальной системе.

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

Миграционная деятельность, описанная в документе “Руководство по миграции”, включает следующие шаги:

собственно миграция приложения
изменение файрволлов, портов, хостов, аппаратных и программных конфигураций в соответствии с новой системой, на которую переносится легаси-версия
проверка на утечку данных и обеспечение безопасности
проверка связи между всеми компонентами приложения.

Тестировщикам рекомендуется проверить все вышеперечисленное в бэкенде системы или путем тестирования белого ящика.

После завершения миграции, описанной в руководстве, восстанавливаются все серверы и выполняются базовые проверки для подтверждения успешности миграции. Это гарантирует, что все системы соответствующим образом подключены, а компоненты взаимодействуют друг с другом: база данных функционирует, фронтенд успешно обменивается данными с бэкендом. Эти тесты необходимо заранее определить и занести в документ “Спецификация тестирования миграции”.

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

Проверка миграционных скриптов является частью тестирования миграции. Иногда отдельные миграционные скрипты также проверяются с использованием метода белого ящика в отдельной тестовой среде.

Таким образом, миграционное тестирование будет сочетанием тестирования как белого, так и черного ящика.

После завершения проверки, связанной с миграцией, и успешного прохождения соответствующих тестов, команда может приступить к постмиграционному тестированию.

3. Постмиграционное тестирование

После успешной миграции приложения начинается постмиграционное тестирование.

На этом этапе проводится сквозное тестирование системы. Тестировщики выполняют тест-кейсы и тест-сценарии с использованием старых и новых наборов данных.

Поскольку объем постмиграционного тестирования приложения очень большой, лучше выделить важные, первоочередные тесты, чтобы убедиться, что миграция прошла успешно, а оставшиеся выполнить позже.

Также рекомендуется автоматизировать сквозные функциональные тесты и другие необходимые тесты, чтобы сократить время и быстро получить результат.

Что нужно проверить в обновленном приложении?

Все ли данные из легаси-приложения перенесены в новое приложение в течение запланированного времени простоя. Чтобы убедиться в этом, нужно сравнить количество записей между легаси и новым приложением для каждой таблицы и их отображение в базе данных. Также нужно записать время, затраченное на перенос, скажем, 10000 записей.
Внесены ли все изменения в базе данных (добавление или удаление полей и таблиц) в соответствии с новыми требованиями.
Данные, перенесенные из легаси-приложения в новое, должны сохранить свое значение, типы и формат, если это не указано в спецификации.
Данные в новом приложении нужно заново протестировать. Здесь необходимо обеспечить максимальный охват, так что целесообразно использовать автоматизированное тестирование.
Безопасность базы данных.
Целостность данных для всех возможных записей выборки.
Корректность работы функциональности в новой системе.
Поток данных в приложении, который охватывает большинство компонентов.
Интерфейс между компонентами необходимо тщательно проверить, так как данные не должны меняться, теряться или повреждаться при прохождении через компоненты. Для проверки можно использовать интеграционные тесты.
Избыточность унаследованных данных. Данные не должны дублироваться во время миграции.
Все проверки на уровне полей в легаси-приложении также должны быть сохранены в новом приложении.
Пользователи легаси-системы должны иметь возможность пользоваться как старыми, так и новыми функциональными возможности, особенно теми, которые связаны с изменениями.
Функциональность обоих приложений, как старого, так и нового, должна корректно работать и допускать создание новых пользователей. Нужно обеспечить проверку функциональности с различными выборками данных (разные возрастные группы, пользователи из разных регионов и т. д.).
Включены ли флаги функций (Feature Flags) для новых функций. Также нужно проверить, действительно ли их включение/выключение позволяет включать и выключать функции.
Не ухудшилась ли производительность ПО в целом (провести тестирование производительности).
Стабильность системы (провести нагрузочные и стресс-тесты).
Не создало ли обновление ПО уязвимостей в системе безопасности. Для этого целесообразно провести тестирование безопасности, особенно в той области, где в систему были внесены изменения во время миграции.
Удобство использования (юзабилити). Если изменился макет графического интерфейса или какая-нибудь функциональность, нужно оценить простоту использования для конечного пользователя по сравнению с легаси-приложением.

Советы по написанию тест-кейсов для постмиграционного тестирования

Миграция не означает, что тест-кейсы для нового приложения нужно писать заново. Тест-кейсы, уже разработанные для легаси-приложения, должны быть применимы и к новому. Поэтому, по возможности, необходимо использовать старые тест-кейсы или обновить их.
Если в новом приложении изменяется какая-либо функция, то тест-кейсы, связанные с этой функцией, должны быть изменены.
При добавлении какой-либо новой функции в приложении для нее разрабатываются новые тесты.
Если в новом приложении отсутствует какая-либо функция, то связанные с ней тесты из легаси-приложения не должны проводиться после миграции. Правильно их пометить как недействительные и хранить отдельно.
Разработанные тесты должны быть надежными и последовательными. В тест-кейсах должна быть предусмотрена проверка критических данных, чтобы ее нельзя было пропустить при выполнении.
Если дизайн UI нового приложения отличается от дизайна легаси, то связанные с UI тест-кейсы должны быть адаптированы к новому дизайну. Решение об обновлении или написании новых тест-кейсов принимается тестировщиком в зависимости от объема произошедших изменений.

Тестирование обратной совместимости

При миграции системы тестировщику необходимо проверить обратную совместимость.

Обратная совместимость предполагает, что:

Новая система поддерживает функциональность, которая была обеспечена в двух предыдущих версиях.
Система может успешно мигрировать с двух предыдущих версий без каких-либо проблем.

Важно проверить обратную совместимость системы, выполнив специальные тесты. Они должны быть разработаны отдельно и включены в спецификацию.

Тестирование отката

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

Чтобы проверить это, необходимо разработать сценарии тестирования сбоя миграции, а также протестировать механизм отката. Общее время, необходимое для возврата к легаси-версии, также должно быть зарегистрировано и отражено в результатах тестирования.

После отката следует провести тестирование основной функциональности и регрессионное тестирование (автоматизированное), чтобы убедиться, что миграция ни на что не повлияла и откат прошел успешно.

Сводный отчет о выполнении тестирования миграции

После завершения тестирования составляется сводный отчет. Он должен включать в себя краткое описание проведенных тестов/сценариев в разрезе фаз миграции с указанием статуса результата (прошел/не прошел) и журнал тестирования.

В отчете необходимо указать:

общее время миграции
время простоя приложения
время, затраченное на миграцию 10000 записей
время, затраченное на откат.

В дополнение к этому можно также добавить любые замечания и рекомендации.

Сложности тестирования миграции данных

Обычно, проблемы, возникающие при тестировании, связаны с данными. Вот несколько возможных проблем:

1. Качество данных

Мы можем обнаружить, что данные, используемые в старом приложении, имеют низкое качество в новом/модернизированном приложении. В таких случаях качество данных должно быть улучшено, чтобы соответствовать бизнес-стандартам.

Такие факторы, как допущения, преобразование данных после миграции, невалидность данных в легаси-приложении, некачественный анализ данных и т.д., приводят к снижению качества данных. Это влечет за собой высокие операционные затраты, увеличение рисков интеграции данных и отклонение от целей бизнеса.

2. Несоответствие данных

Данные, перенесенные из легаси-приложения в новое, могут оказаться неподходящими для нового. Это может быть связано с изменением типа данных, формата хранения данных, изменения цели использования.

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

3. Потеря данных

При миграции данные могут потеряться. Это может касаться как обязательных, так и необязательных полей. Если данные потеряны для необязательных полей, то запись для них все еще будет действительна и может быть обновлена снова.

Но если потеряны данные обязательных полей, то сама запись становится недействительной и не может быть восстановлена. Это приведет к огромной потере данных, и их придется извлекать либо из резервной копии базы данных, либо из логов, если они зафиксированы правильно.

4. Объем данных

Большие объемы данных требуют много времени для миграции в пределах окна простоя. Например, карты с предоплатой в телекоммуникационной отрасли. В данном случае проблемой является то, что к моменту очистки старых данных создаются огромные объемы новых, которые также требуют миграции. Тут следует прибегнуть к автоматизации.

5. Симуляция реальной среды

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

Поэтому выборка данных, репликация реальной среды, определение объема данных, участвующих в миграции, очень важны при проведении тестирования миграции данных.

6. Симуляция объема данных

Команда должна очень тщательно изучить данные в реальной системе и продумать типичный анализ и выборку данных. Например, пользователи в возрастной группе до 10 лет, 10-30 лет и т.д.

По возможности необходимо получить реальные данные. В противном случае – создать их в тестовой среде. Для создания большого объема данных необходимо использовать автоматизированные инструменты. Если объем данных не может быть смоделирован, можно использовать экстраполяцию.

Заключение

Тестирование миграции данных проводится в условиях, когда небольшая ошибка в любой сфере проверки приведет к росту риска провала миграции приложения. Поэтому очень важно провести тщательное и всестороннее изучение системы до и после миграции. Нужно планировать и разрабатывать эффективную стратегию миграции с использованием надежных инструментов, а также привлекать квалифицированных и обученных тестировщиков.

Миграция оказывает огромное влияние на качество приложения, поэтому вся команда должна приложить максимальные усилия для проверки всей системы по всем аспектам, включая функциональность, производительность, безопасность, удобство использования, доступность, надежность, совместимость и т.д. Правильное тестирование миграции – залог ее успеха.

Перевод статьи Nandini & Gayathri S. «Data Migration Testing Tutorial: A Complete Guide».