# Тестирование миграции данных (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](https://blog.qatestlab.com/2021/08/11/what-is-data-migration-testing/)

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

* Как QA в управлении хранилища данных эволюционировал: [часть 1](https://habr.com/ru/company/tinkoff/blog/543416/), [часть 2](https://habr.com/ru/company/tinkoff/blog/547990/)
* [Top 20 ETL Testing Interview Questions & Answers](https://www.softwaretestingmaterial.com/etl-testing-interview-questions/)
* [ETL Testing or Data Warehouse Testing Tutorial: What is ETL?](https://www.guru99.com/utlimate-guide-etl-datawarehouse-testing.html)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://vladislaveremeev.gitbook.io/qa_bible/testirovanie-v-raznykh-sferakh-oblastyakh-testing-different-domains/testirovanie-migracii-dannykh-etl.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.