testirovanie-migracii-dannykh-etl.md

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

ETL (Extract, Transform, Load) - это процесс, объединяющий три этапа: извлечение, преобразование и загрузка данных из одного источника в другой, т.е. процесс перемещения данных из одного места в другое, из одного формата в другой или из одного приложения в другое. Как правило, это результат внедрения новой системы или места хранения данных. Бизнес-драйвером обычно является миграция или консолидация приложений, при которых устаревшие системы заменяются или дополняются новыми приложениями, использующими тот же набор данных.

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

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

Пример:

Давайте рассмотрим пример слияния двух компаний - компании A и компании B. После слияния их операции будут объединены, а их клиенты, сотрудники и другие данные будут храниться в единой централизованной базе данных. Предположим, что компания A использует базу данных Oracle для хранения всей информации, а компания B использует MySQL. Теперь для объединения своей информации обе компании могут использовать процесс ETL для переноса данных из своих отдельных баз данных в одну согласованную базу данных. В процессе ETL, поскольку две базы данных различны, данные обеих компаний будут в разном формате, будут использоваться разные соглашения об именах, будут использоваться разные структуры таблиц и так далее. Из-за этих различий компаниям необходимо удостовериться, что перед загрузкой данных в целевую базу данных она была должным образом очищена и может сформировать нужный формат. При тестировании ETL тестировщики должны убедиться, что:

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

Миграция состоит из 7 этапов:

• Premigration planning: Оценить перемещаемые данные на предмет стабильности;
• Project initiation: Определить и проинструктировать ключевых лиц, принимающих решения;
• Landscape analysis: Создайте надежный процесс управления правилами качества данных и проинформируйте бизнес о целях проекта, включая отключение устаревших систем;
• Solution design: Определите, какие данные необходимо переместить, а также качество этих данных до и после перемещения.
• Build & test: Закодируйте логику миграции и протестируйте миграцию с копией рабочей среды.
• Execute & validate: Продемонстрируйте, что миграция соответствует требованиям и что перемещенные данные пригодны для использования в бизнесе.
• Decommission & monitor: Выключите и утилизируйте старые системы.

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

Как разработать стратегию тестирования переноса данных?

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

Следовательно, этапы стратегии тестирования теста миграции, которые будут проводиться , могут быть классифицированы как Pre-Migration Testing; Migration Testing; Post Migration Testing.

Тестирование перед миграцией (Pre-Migration testing)

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

• Установите четкий объем данных - какие данные должны быть включены, какие данные должны быть исключены, какие данные требуют преобразования/конвертации и т. д.;
• Выполнение сопоставление данных (data mapping) между устаревшим и новым приложением - для каждого типа данных в устаревшем приложении сравните соответствующий тип в новом приложении, а затем сопоставьте их - Сопоставление более высокого уровня (Higher level mapping);
• Изучите схему данных нового приложения - имена полей, типы, минимальные и максимальные значения, длину, обязательные поля, проверки на уровне полей и т. д.;
• Изучите интерфейсы в новом приложении и их подключения. Данные, проходящие через интерфейс, должны быть надежно защищены и настроены;
• Подготовьте тестовые случаи, тестовые сценарии и используйте их для новых условий в новых приложениях;
• Выполните набор тестовых случаев с набором пользователей и сохраните результаты, журналы. То же самое необходимо проверить после того, как произошла миграция, чтобы убедиться, что устаревшие данные и функциональность не повреждены;
• Количество данных и записей должно быть четко записано, его необходимо проверить после миграции, чтобы доказать, что никакие данные не были потеряны.

Миграционное тестирование (Migration testing)

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

Запись фактического времени, затраченного на миграцию с момента начала миграции до успешного восстановления системы, является одним из тестовых случаев, которые необходимо выполнить, и, следовательно, «Время, необходимое для миграции системы», должно быть записано в final test report, который будет предоставлен как часть результатов миграционного тестирования, и эта информация будет полезна во время запуска в прод. Время простоя, записанное в тестовой среде, экстраполируется для расчета приблизительного времени простоя в работающей системе. Именно в устаревшей системе будет выполняться миграция.

Во время этого тестирования все компоненты среды обычно отключаются и удаляются из сети для выполнения действий по миграции. Следовательно, необходимо отметить «Время простоя», необходимое для теста миграции. В идеале оно будет таким же, как и время миграции. Как правило, действия по миграции, определенные в документе «Руководство по миграции» (Migration Guide), включают:

• Фактическая миграция приложения;
• Брандмауэры, порты, хосты, аппаратные и программные конфигурации - все они изменяются в соответствии с новой системой, на которую переносится старая версия;
• Утечки данных, проверки безопасности;
• Проверяется связность между всеми компонентами приложения;

Тестировщикам рекомендуется проверить вышеизложенное в бэкенде системы или путем проведения тестирования белого ящика. После завершения миграции все серверы будут запущены, и будут выполнены базовые тесты, связанные с проверкой успешной миграции, что гарантирует, что все сквозные системы правильно подключены и все компоненты взаимодействуют друг с другом, БД запущен и работает, фронт успешно взаимодействует с бэком. Эти тесты должны быть идентифицированы заранее и записаны в документе «Спецификация тестов миграции» (Migration Test Specification document). Есть вероятность, что программное обеспечение поддерживает несколько разных платформ. В таком случае Миграцию необходимо проверять на каждой из этих платформ отдельно. Проверка сценариев миграции будет частью теста миграции.

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

Тестирование после миграции (Post-Migration testing)

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

• Все устаревшие данные перенесены в новое приложение в течение запланированного времени простоя. Чтобы убедиться в этом, сравните количество записей между устаревшим и новым приложением для каждой таблицы и представлений в базе данных;
• Все изменения схемы (поля и таблицы добавлены или удалены) в соответствии с новой системой обновлены;
• Данные, перенесенные из устаревшего приложения в новое, должны сохранять свое значение и формат, если только это не указано отдельно. Чтобы убедиться в этом, сравните значения данных между устаревшей и новой базами данных приложения;
• Перенесенные данные в новом приложении. Охватите здесь максимальное количество возможных причин. Для обеспечения 100% охвата проверки переноса данных используйте инструмент автоматизированного тестирования ;
• Безопасность базы данных;
• Целостность данных для всех возможных записей выборки;
• Ранее поддерживаемые функции в устаревшей системе работают должным образом в новой системе;
• Поток данных в приложении, который охватывает большинство компонентов;
• Интерфейс между компонентами должен быть тщательно протестирован, поскольку данные не должны изменяться, теряться и искажаться при прохождении через компоненты. Для проверки этого можно использовать интеграционные тестовые случаи;
• Избыточность устаревших данных. Никакие устаревшие данные не должны дублироваться во время миграции;
• Случаи несоответствия данных, такие как изменение типа данных, изменение формата хранения и т. д.;
• Все проверки на уровне поля в устаревшем приложении также должны выполняться в новом приложении;
• Любое добавление данных в новое приложение не должно отражаться на устаревшем;
• Обновление данных устаревшего приложения через новое приложение должно поддерживаться. После обновления в новом приложении оно не должно отражаться на устаревшем;
• Удаление данных устаревшего приложения в новом приложении должно поддерживаться. После удаления в новом приложении оно также не должно удалять данные в устаревшем;
• Убедитесь, что изменения, внесенные в устаревшую систему, поддерживают новые функции, предоставляемые как часть новой системы;
• Убедитесь, что пользователи устаревшей системы могут продолжать использовать как старые, так и новые функциональные возможности, особенно те, которые связаны с изменениями. Выполнение тестовых случаев и результатов тестирования, сохраненных во время тестирования перед миграцией;
• Создайте новых пользователей в системе и проведите тесты, чтобы убедиться, что функциональность как старого, так и нового приложения поддерживает вновь созданных пользователей и работает нормально;
• Проведите тесты функциональности на различных выборках данных (разные возрастные группы, пользователи из разных регионов и т.д.);
• Также необходимо проверить, включены ли «Флаги функций» для новых функций, а их включение/выключение позволяет включать и выключать функции;
• Тестирование производительности важно для того, чтобы убедиться, что переход на новые системы/программное обеспечение не ухудшил производительность системы;
• Также требуется проведение нагрузочных и стресс-тестов для обеспечения стабильности системы;
• Убедитесь, что обновление программного обеспечения не открыло никаких уязвимостей в системе безопасности, и, следовательно, проведите тестирование безопасности, особенно в той области, где в систему были внесены изменения во время миграции;
• Удобство использования - это еще один аспект, который необходимо проверить, в котором, если макет графического интерфейса пользователя / интерфейсная система изменились или изменилась какая-либо функциональность, какова простота использования, которую конечный пользователь чувствует по сравнению с устаревшей системой;

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

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

Источники:

• What is Data Migration Testing

Доп. материал:

• Как QA в управлении хранилища данных эволюционировал: часть 1, часть 2
• Top 20 ETL Testing Interview Questions & Answers
• ETL Testing or Data Warehouse Testing Tutorial: What is ETL?