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

Почему тестирование миграции данных важно #

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

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

Типы миграции #

Процесс тестирования миграции #

Фаза 1: Предмиграционный анализ #

Перед написанием тестов проанализируйте миграцию и создайте документ маппинга.

Фаза 2: Подготовка тестовых данных #

1. Выявить пограничные случаи в исходных данных: NULL-значения, специальные символы, строки максимальной длины.
2. Выбрать репрезентативные данные.
3. Создать известные тестовые записи с предвычисленными ожидаемыми результатами.

Фаза 3: Тесты выполнения миграции #

Проверка количества записей:

-- До миграции
SELECT COUNT(*) FROM legacy_db.users;
SELECT COUNT(*) FROM legacy_db.orders;

-- После миграции
SELECT COUNT(*) FROM new_db.users;
SELECT COUNT(*) FROM new_db.orders;

Проверка агрегированных значений:

SELECT SUM(order_total) FROM legacy_db.orders;
SELECT SUM(amount_usd) FROM new_db.orders;

Фаза 4: Валидация качества данных #

Ссылочная целостность:

SELECT COUNT(*) FROM new_db.orders o
LEFT JOIN new_db.users u ON o.user_id = u.id
WHERE u.id IS NULL;
-- Ожидается: 0

Корректность типов данных:

SELECT legacy_id, legacy_created_at, new_created_at
FROM migration_audit
WHERE ABS(EXTRACT(EPOCH FROM legacy_created_at - new_created_at)) > 1;
-- Ожидается: 0 строк

Фаза 5: Валидация приложения #

После миграции протестируйте приложение на мигрированных данных:

1. Могут ли пользователи войти с существующими учётными данными?
2. Корректно ли отображаются существующие заказы?
3. Могут ли пользователи выполнять новые операции?
4. Генерируют ли отчёты правильные цифры?

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

Каждая миграция нуждается в проверенном плане отката:

1. Проверка бэкапа: Восстановить на тестовом окружении.
2. Скрипт отката: Проверить корректность реверсии.
3. Точка невозврата: Определить, когда откат уже невозможен.
4. Время отката: Измерить длительность.

Тестирование производительности #

Миграции больших датасетов могут занять часы. Тестируйте на production-масштабных данных.

Упражнение: План тестирования миграции данных #

Сценарий #

Ваша компания мигрирует из legacy PostgreSQL в новую систему: 2 миллиона пользователей, 8 миллионов заказов, 25 миллионов позиций заказов.

Задание 1: Создание документа маппинга #

Создайте полный маппинг поле-по-полю между legacy и новой схемой.

Задание 2: Написание запросов верификации #

Напишите SQL-запросы для проверки:

1. Все legacy-пользователи существуют в новой системе.
2. Имена разделены корректно.
3. Коды статусов сопоставлены правильно.
4. Даты конвертированы из строк в timestamp корректно.
5. Суммы конвертированы в USD по правильному курсу.
6. Все foreign key связи целы.

Задание 3: Тестовые данные для пограничных случаев #

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

Задание 4: План отката #

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

Результаты #

1. Полный документ маппинга поле-по-полю.
2. SQL-запросы верификации с ожидаемыми результатами.
3. Тестовые данные пограничных случаев с ожидаемыми результатами миграции.
4. Документ плана отката.