Как проверить перенос одного типа записей в новую версию системы
Подготовлено
Проверка переноса записей должна сравнивать их содержание, связи и рабочий смысл. Равное количество строк не доказывает сохранность каждого объекта. Для ограниченного переноса сначала выберите один тип записи, согласуйте соответствия и подготовьте контрольные примеры.
Определите один тип объекта
В учебном примере в новую версию системы переносится заявка с состоянием и историей решений. Все записи вымышлены. В состав проверки не входят все базы компании, документы других типов и дальнейшая перестройка процессов.
Опишите, что пользователь должен узнать и сделать с перенесённой заявкой: открыть состав, увидеть действующее решение и связанную историю. Наличие новой строки в базе ещё не подтверждает этот результат.
Опишите соответствия и исключения
Для каждого поля и связи укажите, что сохраняется, что преобразуется по согласованному правилу и чего в источнике нет. Изменение названия состояния не должно незаметно менять его смысл. Отсутствующее старое значение нельзя заполнить догадкой ради обязательного нового поля.
| Источник | Новая запись | Проверяемый смысл |
|---|---|---|
| Идентификатор З-84 | Связанный новый идентификатор | Можно найти исходную заявку |
| Принятая версия состава | Состав соответствующей версии | Решение относится к тем же данным |
| История решения | Связанные события | Понятно, кто и что подтвердил |
| Поле отсутствовало | Явное неизвестное по правилу | Нет выдуманного подтверждения |
Выберите контрольные записи
Возьмите обычную заявку, неполную и историческую с несколькими решениями. Размер набора зависит от вариантов реального процесса и согласованной проверки. Для ознакомления нужны разрешённые обезличенные данные или подходящие учебные образцы.
Каждый пример должен иметь ожидаемый результат до проверки. Если историческая запись не укладывается в новую модель, сначала нужно решение владельца, а не скрытая потеря неудобного события.
Сравните содержание, а не только количество
Проверяйте выбранные поля, принадлежность, связи и последовательность значимых событий. Одинаковые итоги могут скрыть потерянную связь и лишнюю дублирующую запись. Подтверждение количества — только одна часть наблюдения.
Затем пройдите нужное действие пользователя на контрольном объекте. Например, открывается ли принятое решение именно по нужной версии? Создание реестра из таблицы описано в связанном материале; здесь проверяется сохранение смысла уже существующих записей.
Сохраните список расхождений
У каждой строки расхождения нужны исходный объект, ожидаемое значение, наблюдение, ответственный и условие закрытия. Формулировка «данные перенесены» не должна скрывать непроверенную историю или отсутствующий объект.
Если часть исходников не получена, итог остаётся ограниченным доступным составом. Успешный разбор одной записи не устраняет открытые строки. Исправление подтверждают конкретным повторным сравнением затронутого объекта.
Как принять ограниченный перенос
Согласуйте принимающего, контрольные примеры и свидетельства результата. Отдельно укажите, где выполнена проверка и какие условия ещё нужны до реального переключения. Статья не запускает миграцию и не разрешает удалять источник.
Тип объектов / граница переноса: Источник и целевая версия системы: Исходный ID — новый ID — основание связи: Поле или история — правило соответствия: Согласованное исключение / неизвестное: Контрольные обычная, неполная и историческая записи: Ожидание — факт — расхождение: Ответственный / свидетельство исправления: Пользовательское действие / принимающий / остаток:
Для оценки доработки действующей системы такой лист определяет конкретный результат. Решение о переключении и сохранении источника требует отдельного подтверждённого порядка.
Если такой участок есть в вашем проекте, опишите одно действие и нужный результат. Первый разговор бесплатный; готовое ТЗ не обязательно. Обсудить свою задачу.