Тестирование миграции данных: пошаговые методы и чек-лист для инженеров | AdminWiki
Logo

Тестирование миграции данных: пошаговые методы и чек-лист для инженеров

27 июля 2026 14 мин. чтения
Содержание статьи

Почему тестирование миграции данных - это не просто «проверить, что всё перенеслось»

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

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

Материал построен вокруг трёх фаз тестирования - до, во время и после миграции. Вы получите SQL-запросы для аудита исходных данных, методику создания эталонных метрик, приёмы мониторинга прогресса и полный набор проверок для финальной приёмки. Отдельный блок посвящён автоматизации рутины: скрипты для сверки объёмов и целостности в PostgreSQL, обработки для 1С, а также итоговый чек-лист, который исключает человеческий фактор.

Этап 1: Подготовка и тестирование до миграции

Предварительная подготовка определяет 70% успеха всего проекта. Запускать перенос данных без аудита источника - значит переносить скрытые проблемы в новую среду, где к ним добавятся ещё и ошибки трансформации. Задача этого этапа - найти все нарушения в исходной системе, зафиксировать эталонные метрики и настроить тестовую среду, идентичную продакшену по конфигурации СУБД, версиям библиотек и параметрам ОС.

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

Аудит исходных данных: находим проблемы до того, как они станут фатальными

Исходная база, прожившая несколько лет в продакшене, почти гарантированно содержит нарушения. Орфанные записи, дубликаты по ключевым полям, некорректные форматы дат - всё это всплывёт при попытке накатить строгие constraint'ы на целевой системе или при конвертации типов. Лучше найти эти проблемы сейчас, пока есть доступ к источнику и возможность их исправить штатными средствами.

Для PostgreSQL используйте следующий набор диагностических запросов. Поиск дубликатов по бизнес-ключу:

SELECT inn, COUNT(*)
FROM contractors
GROUP BY inn
HAVING COUNT(*) > 1;

Поиск записей с NULL в полях, которые должны быть обязательными в новой схеме:

SELECT id, full_name
FROM employees
WHERE hire_date IS NULL
   OR department_id IS NULL;

Проверка орфанных записей - дочерних строк без родительских:

SELECT o.id, o.order_date, o.customer_id
FROM orders o
LEFT JOIN customers c ON o.customer_id = c.id
WHERE c.id IS NULL;

Обнаружение некорректных форматов данных, которые могут сломать парсинг при преобразовании типов:

SELECT id, phone
FROM contacts
WHERE phone !~ '^\+7\(\d{3}\)\d{3}-\d{2}-\d{2}$';

Результаты аудита документируйте. Каждый тип нарушения должен получить решение: исправить в источнике, трансформировать при миграции или исключить запись. Без этого решения вы перенесёте мусор в новую систему.

Создание эталонных данных и метрик для последующего сравнения

Чтобы доказать корректность миграции, нужно зафиксировать состояние «до». Метрики снимаются по трём направлениям: объём, содержимое и производительность. Автоматизируйте сбор скриптами - ручной подсчёт неизбежно приведёт к ошибкам.

Подсчёт количества записей по всем таблицам схемы:

SELECT schemaname, relname, n_live_tup
FROM pg_stat_user_tables
ORDER BY schemaname, relname;

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

SELECT md5(string_agg(md5(ROW(t.*)::text), '' ORDER BY id))
FROM orders t;

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

Сохраните планы выполнения эталонных запросов. Они понадобятся на этапе тестирования производительности:

EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
SELECT * FROM orders WHERE order_date BETWEEN '2025-01-01' AND '2025-06-30';
-- сохраните вывод в файл эталонных планов

Все собранные метрики сохраните в отдельной схеме или файловой структуре тестовой среды. Эти данные станут единственным объективным критерием успешности миграции.

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

Фаза активного переноса данных - это не пассивное ожидание завершения скрипта. Даже при использовании проверенных инструментов вроде pg_dump/pg_restore или механизмов 1С:Конвертации данных возможны сбои: обрыв сетевого соединения, переполнение дискового пространства, ошибки трансформации на конкретных записях. Без мониторинга в реальном времени вы рискуете узнать о проблеме спустя часы после её возникновения.

Мониторинг прогресса и обработка ошибок в реальном времени

Настройте детальное логирование на стороне инструмента миграции. Для pg_dump/pg_restore ключевые параметры: --verbose для вывода прогресса и --error-on-continue (или его аналоги в обёртках) для немедленной остановки при критических ошибках. Лог должен писаться в файл с ротацией, а не только в stdout.

Параллельно с основным процессом запустите скрипт периодического контроля. Он раз в N минут подключается к целевой системе и считает количество перенесённых записей по ключевым таблицам. Сравнение с эталонными метриками из первого этапа покажет прогресс в процентах и выявит остановку миграции:

#!/bin/bash
# Пример скрипта мониторинга для PostgreSQL
while true; do
  COUNT=$(psql -h target_host -U migrator -d target_db -t -c "SELECT COUNT(*) FROM orders;")
  echo "[$(date +%H:%M:%S)] Orders migrated: $COUNT / 1_250_000"
  sleep 300
done

Для 1С:Конвертации данных включите расширенное логирование в настройках правил обмена. Номера объектов, на которых произошёл сбой, фиксируйте в отдельный регистр сведений - это позволит после завершения основного прогона точечно обработать проблемные записи, не перезапуская всю миграцию.

При потоковой миграции (логическая репликация, Change Data Capture) добавьте проверку лага - отставания целевой системы от источника. Критический рост лага сигнализирует о проблемах с производительностью целевой стороны или о сетевых задержках.

Этап 3: Тестирование после миграции - полная валидация

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

Проверка объема данных: считаем строки и байты

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

-- Выполнить на исходной и целевой системах, сравнить вывод
SELECT relname, n_live_tup
FROM pg_stat_user_tables
ORDER BY relname;

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

#!/bin/bash
# Сравнение количества строк. Требует установленных утилит psql.
TABLES=$(psql -h source_host -t -c "SELECT tablename FROM pg_tables WHERE schemaname='public'")
for t in $TABLES; do
  SRC=$(psql -h source_host -d source_db -t -c "SELECT COUNT(*) FROM $t")
  TGT=$(psql -h target_host -d target_db -t -c "SELECT COUNT(*) FROM $t")
  if [ "$SRC" != "$TGT" ]; then
    echo "MISMATCH: $t - source: $SRC, target: $TGT"
  fi
done

Проверка целостности ссылочной структуры и данных

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

Для PostgreSQL используйте оператор EXCEPT для построчного сравнения подмножеств данных:

-- Сравнение состава ключевых полей
SELECT id, order_date, customer_id, total_amount
FROM source_db.orders
WHERE order_date >= '2026-01-01'
EXCEPT
SELECT id, order_date, customer_id, total_amount
FROM target_db.orders
WHERE order_date >= '2026-01-01'
UNION ALL
SELECT id, order_date, customer_id, total_amount
FROM target_db.orders
WHERE order_date >= '2026-01-01'
EXCEPT
SELECT id, order_date, customer_id, total_amount
FROM source_db.orders
WHERE order_date >= '2026-01-01';

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

Сравнение контрольных сумм, снятых на первом этапе, - ещё один быстрый метод. Если хеш таблицы на источнике и приёмнике совпадает, данные идентичны с вероятностью, близкой к 100%. Расхождение требует локализации: дели́те таблицу пополам по диапазону ID и пересчитывайте хеши, пока не найдёте расходящийся блок.

Для 1С сверка целостности имеет свою специфику. Проверяйте не только количество объектов метаданных, но и остатки регистров накопления на ключевые даты, обороты регистров бухгалтерии и движения документов. Типовая ошибка - документ перенесён, но его движения по регистрам отсутствуют из-за ошибки в правилах конвертации. Скрипты для такой проверки приведены в разделе автоматизации.

Тестирование производительности: сравниваем скорость до и после

Формально корректная база может работать неприемлемо медленно. Причины: отсутствующая или устаревшая статистика планировщика, неоптимальные планы запросов на новой версии СУБД, другие параметры конфигурации сервера. Сравнение с эталонными метриками, снятыми до миграции, даёт объективную картину.

Методика:

  1. Обновите статистику на целевой системе: ANALYZE;
  2. Выполните эталонные запросы с EXPLAIN (ANALYZE, BUFFERS).
  3. Сравните фактическое время выполнения и планы с эталонными.

Рост времени до 10% допустим и может объясняться различиями в аппаратном обеспечении. Рост в 2-5 раз - сигнал к анализу плана запроса. Типичные проблемы: пропущенный индекс, переключение с Index Scan на Seq Scan из-за изменения параметра random_page_cost, невыгодный Join-алгоритм на новой версии планировщика.

Для 1С тестирование производительности проводится путём замера времени проведения ключевых документов и формирования регламентированных отчётов. Сравните время закрытия месяца на тестовой копии целевой базы с историческими данными о времени закрытия на исходной системе. Значимое замедление - повод для технологического аудита настроек СУБД и пересмотра регламентных заданий по обновлению статистики.

Функциональное тестирование: проверяем работу приложений

Данные целы, связи на месте, производительность в норме. Осталось убедиться, что прикладное ПО корректно работает с новой базой. Этот этап критичен для систем с жёсткой бизнес-логикой на стороне приложения - ERP, CRM, биллингов.

Для 1С функциональное тестирование включает:

  • Тестовое проведение документов всех ключевых видов за выбранный период. Проверьте, что движения формируются корректно, не возникает ошибок контроля остатков.
  • Формирование регламентированной отчётности за предыдущий закрытый период. Сравните показатели с эталонными отчётами, сформированными на исходной базе.
  • Проверку интеграционных интерфейсов: выгрузки в банк, обмены с внешними системами, API-запросы. Убедитесь, что форматы и протоколы не изменились.

Для самописных приложений запустите набор регрессионных тестов, покрывающих критичные бизнес-сценарии. Если такого набора нет, миграция - повод его создать. Минимальный объём: 10-15 ключевых пользовательских сценариев, от входа в систему до формирования финального документа.

Автоматизация валидации: готовые скрипты для PostgreSQL и 1С

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

Скрипты для PostgreSQL: сверка объемов, целостности и производительности

Комплексный скрипт сверки количества записей по всем таблицам схемы. Подключается к двум базам через foreign data wrapper или через раздельные соединения и выводит таблицу расхождений:

-- Предполагается, что на целевой базе настроен foreign server к исходной
CREATE EXTENSION IF NOT EXISTS postgres_fdw;
-- Настройка соединения (выполняется один раз)
-- CREATE SERVER source_srv FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host 'src_host', dbname 'src_db');
-- CREATE USER MAPPING FOR CURRENT_USER SERVER source_srv OPTIONS (user 'src_user', password 'src_pass');
-- IMPORT FOREIGN SCHEMA public LIMIT TO (orders, customers, products) FROM SERVER source_srv INTO source;

SELECT
    'orders' AS table_name,
    (SELECT COUNT(*) FROM orders) AS target_count,
    (SELECT COUNT(*) FROM source.orders) AS source_count
UNION ALL
SELECT
    'customers',
    (SELECT COUNT(*) FROM customers),
    (SELECT COUNT(*) FROM source.customers)
UNION ALL
SELECT
    'products',
    (SELECT COUNT(*) FROM products),
    (SELECT COUNT(*) FROM source.products);

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

SELECT o.id, o.customer_id
FROM orders o
LEFT JOIN customers c ON o.customer_id = c.id
WHERE c.id IS NULL
  AND o.customer_id IS NOT NULL;

Сравнение планов запросов автоматизируйте через сохранение и diff вывода EXPLAIN. Ключевые метрики для сравнения: фактическое время выполнения (actual time), количество прочитанных буферов (buffers read), выбранный алгоритм соединения (Nested Loop / Hash Join / Merge Join).

Скрипты и обработки для 1С: проверка переноса данных

Для платформы 1С:Предприятие автоматизация строится на встроенном языке. Базовая проверка количества объектов метаданных:

// Сравнение количества элементов справочников и документов
&НаСервере
Процедура СверитьКоличествоОбъектов()
    МассивМетаданных = Новый Массив;
    МассивМетаданных.Добавить(Метаданные.Справочники.Контрагенты);
    МассивМетаданных.Добавить(Метаданные.Документы.РеализацияТоваров);
    МассивМетаданных.Добавить(Метаданные.Справочники.Номенклатура);
    
    Для Каждого Мд Из МассивМетаданных Цикл
        Запрос = Новый Запрос;
        Запрос.Текст = "ВЫБРАТЬ КОЛИЧЕСТВО(1) КАК Количество ИЗ " + Мд.ПолноеИмя();
        Результат = Запрос.Выполнить();
        Выборка = Результат.Выбрать();
        Выборка.Следующий();
        Сообщить(Мд.Имя + ": " + Выборка.Количество);
    КонецЦикла;
КонецПроцедуры

Сверка остатков регистров накопления на ключевую дату - критичная проверка для бухгалтерского и складского учёта:

// Сравнение остатков по регистру ТоварыНаСкладах на конец периода
&НаСервере
Процедура СверитьОстатки(ДатаПроверки)
    Запрос = Новый Запрос;
    Запрос.Текст = 
    "ВЫБРАТЬ
    |   ТоварыНаСкладахОстатки.Номенклатура КАК Номенклатура,
    |   ТоварыНаСкладахОстатки.Склад КАК Склад,
    |   ТоварыНаСкладахОстатки.КоличествоОстаток КАК Количество
    |ИЗ
    |   РегистрНакопления.ТоварыНаСкладах.Остатки(&ДатаПроверки, ) КАК ТоварыНаСкладахОстатки";
    Запрос.УстановитьПараметр("ДатаПроверки", ДатаПроверки);
    // Выполнить на исходной и целевой базе, сравнить результат
КонецПроцедуры

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

// Проверка наличия движений у проведённых документов
&НаСервере
Процедура ПроверитьДвиженияДокументов(НачалоПериода, КонецПериода)
    Запрос = Новый Запрос;
    Запрос.Текст =
    "ВЫБРАТЬ
    |   РеализацияТоваров.Ссылка КАК Документ,
    |   РеализацияТоваров.Проведен
    |ИЗ
    |   Документ.РеализацияТоваров КАК РеализацияТоваров
    |ГДЕ
    |   РеализацияТоваров.Дата МЕЖДУ &НачалоПериода И &КонецПериода
    |   И РеализацияТоваров.Проведен";
    // Для каждого документа проверить наличие записей в подчинённых регистрах
КонецПроцедуры

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

Чек-лист тестирования миграции данных: от планирования до приемки

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

До миграции:

  • Полный резервный бэкап исходной системы выполнен и проверен на восстанавливаемость.
  • Аудит исходных данных проведён: дубликаты, орфанные записи, нарушения форматов выявлены и задокументированы.
  • Эталонные метрики сняты: количество строк по таблицам, контрольные суммы, планы эталонных запросов.
  • Тестовая среда развёрнута: версии СУБД, ОС, библиотек и параметры конфигурации идентичны целевой продакшен-среде.
  • Правила трансформации данных задокументированы и согласованы с владельцами систем.
  • План отката (rollback) утверждён и проверен на тестовой среде.

Во время миграции:

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

После миграции:

  • Количество записей по всем таблицам совпадает с эталоном.
  • Контрольные суммы критичных таблиц совпадают.
  • Ссылочная целостность проверена: внешние ключи созданы, орфанные записи отсутствуют.
  • Производительность эталонных запросов не деградировала более чем на 10%.
  • Статистика планировщика обновлена (ANALYZE выполнен).
  • Функциональное тестирование приложений пройдено: ключевые бизнес-операции выполнены без ошибок.
  • Интеграционные интерфейсы проверены: обмены, API, выгрузки работают корректно.
  • Регламентированная отчётность сформирована и сверена с эталоном.
  • Результаты всех проверок задокументированы, акт приёмки подписан.

Типичные ошибки при тестировании миграции и как их избежать

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

Тестирование на усечённом объёме данных. Разработчики отлаживают миграцию на базе с 10% записей, всё проходит гладко. На полном объёме всплывают проблемы с памятью, временем выполнения и блокировками. Решение: тестовый прогон выполняется на копии продакшен-базы. Допустимо маскирование чувствительных данных, но объём и распределение значений должны сохраняться.

Игнорирование нефункциональных требований. Команда проверяет только корректность данных, забывая о времени выполнения миграции и о производительности после неё. Результат: миграция идёт 48 часов при допустимом окне в 8, а после переключения пользователи не могут работать из-за таймаутов. Решение: включить в чек-лист замеры времени всех этапов и нагрузочное тестирование целевой системы до переключения трафика.

Тестовая среда не идентична продакшену. Миграция тестируется на PostgreSQL 15 с дефолтными настройками, а продакшен работает на PostgreSQL 14 с кастомными параметрами shared_buffers и work_mem. Планы запросов различаются кардинально. Решение: тестовая среда должна быть клоном продакшена по версиям ПО и конфигурационным файлам. Контейнеризация (Docker) упрощает создание таких клонов.

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

Отсутствие плана отката. Миграция выполнена, но при приёмке обнаружена критичная ошибка, исправление которой требует дней. Возврат к исходной системе невозможен, потому что за время миграции в неё продолжали вносить изменения. Решение: план отката - это не просто «восстановить из бэкапа». Это процедура обратного переноса данных, накопившихся в целевой системе за время тестирования, обратно в источник. План должен быть проверен на тестовой среде до начала продакшен-миграции.

Системный подход к тестированию миграции данных - это страховка от ночных звонков и авральных восстановлений. Три фазы проверок, автоматизированные скрипты и дисциплина чек-листа превращают хаотичный процесс в управляемый инженерный проект с предсказуемым результатом. Для углубления в смежные темы рекомендуем изучить пошаговый план миграции между СУБД и руководство по планированию миграции инфраструктуры. Если вы управляете проектом целиком, пригодятся материалы по организации миграции как IT-проекта и управлению процессом с контролем типичных ошибок.

Поделиться:
Сохранить гайд? В закладки браузера