Home

Автор: Тамоя Бекфорд, Жизель Тодд (Tamoya Beckford, Giselle Todd)
Оригинал статьи
Перевод: Ольга Алифанова

Исследование миграции данных 2017 года показало, что, согласно 61% респондентов, в среднем три или более легаси-систем причастны к какой-либо форме миграции данных. Можно предположить, что огромное количество компаний занимаются миграцией данных. То же исследование выявило, что 69% мигрировавших проектов были успешными – а что насчет оставшегося 31%? Вот в чем вопрос: насколько этот результат зависит от нехватки хороших практик тестирования?

Недостаточное тестирование было по факту указано как одна из причин провала проектов миграции данных. Работа с любой миграцией данных – это опасное дело, подверженное высокому риску. Мы, на основании нашего опыта, решили пролить свет на пять (5) наиболее важных факторов, которые нужно учитывать, проводя эффективное тестирование миграции базы данных – тогда проект будет успешным.

Провалил планирование – планируй провал

Наверняка знаете поговорку "провалил планирование – планируй провал". Это особенно верно для планирования крупной задачи вроде миграции данных. Проведение такого тест-планирования даст ответы на ряд важных вопросов. Следовательно, вашим приоритетом должно стать подключение всех ключевых заинтересованных лиц и команду, которая будет заниматься миграцией. Другой аспект планирования – это создание плана тестирования. Он подсветит вещи вроде сроков и тест-задач, возможных рисков для этого типа проекта, процедур отката, участников процесса, и т. Д. Клэр демонстрирует в своем "Тест-плане в одну страничку", как можно подготовить простой, но ценный план тестирования.

Изучите ваше окружение

Доступность и резервирование тест-окружений и подходящих инструментов – вот факторы, которые, безусловно, нужно учесть. Именно в тест-окружении вы будете проводить тщательное ревью усилий по миграции. Это включает легаси (существующую базу данных, которая будет мигрировать) и место назначения (новую мигрировавшую базу данных). Следовательно, критически важно, чтобы обе эти базы работали параллельно – если понадобится что-то прояснить, всегда можно обратиться к легаси для проверки того, что в этом нуждается. Лучше тестировать на реплике продуктовых данных. Использование реальных данных помогает повысить тест-покрытие, выявляя наихудшие сценарии, которые можно упустить при использовании ограниченного количества фиктивных данных в обычном тест-окружении. Следовательно, думая о тест-окружении, не забудьте, что очень важно получить копию продуктовых данных.

Теперь стоит также продумать инструментарий, который поможет проводить ряд нужных для миграции данных проверок. В нашем проекте миграции данных мы пользуемся Aqua Data Studio и Apache JMeter (далее в статье мы их обсудим).

Как мы будем это тестировать?

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

Тест сравнения схем между легаси и конечной базой

Схема базы данных отображает логическое существование данных в системе управления базой данных. Сравнение схем нужно проводить, чтобы убедиться, что и легаси, и конечная база имеют схожий синтаксис. К примеру, в ходе одного проекта по миграции, с которым я работала, мы узнали, что базы данных PostreSQL и IBM DB2 по-разному форматируют свои даты, и эта разница в синтаксисе требует изменения кода приложения. Для нашего проекта по миграции базы данных мы использовали инструмент Aqua Data Studio Schema Compare Tool, так как ручное сравнение схем для сотен таблиц базы занимает много времени и склонно к ошибкам. Использование инструмента сравнения схем безусловно упростит вам жизнь и поможет убедиться, что конечная схема логически аналогична исходной. Так вы проверите, что дата будет храниться так, как планировалось, и в базе-источнике нет пробелов или отсутствующих данных. Убедитесь, что вы провели такой аудит и сравнили свои схемы. Короче говоря, подстрахуйтесь – сравнивайте!

Валидационное тестирование на уровне данных

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

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

Валидационное тестирование на уровне приложения

Возможно, важно будет провести end-to-end тестирование систем(ы), связанной с мигрирующей базой. Однако так как полное тестирование – миф, то в наших лучших интересах применить подход к тест-стратегиям на основе рисков. Таким образом мы убедимся, что адекватное функциональное тестирование главных аспектов системы завершено. Сконцентрироваться нужно в основном на критических областях, на которые может повлиять любое изменение SQL-кода после миграции. Также обращайте внимание на интеграционные точки внутри систем – чтобы проверить, что новая база данных связана со всеми компонентами приложения.

Нефункциональное тестирование

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

• Идентифицируйте основные и самые частые SQL-выражения и процедуры, которые используются базой данных. Затем выполните нагрузочные тесты, которые задействуют их, при помощи инструмента вроде Apache JMeter.
• Анализируя результаты нагрузочного теста, вначале определите точку отсчета для сравнения. Эта точка может быть основана на анализе производительности легаси-базы. Другой возможный вариант – согласованный с командой порог на основании стандартов отрасли.
• Выполните сканирование уязвимостей базы, используя специализированные инструменты.
• Подтвердите у производителя, что сервер базы данных обновлен до самой последней версии.

Последующая поддержка

Команда должна быть готова поддерживать пост-миграционную деятельность, которая может включать в себя взаимодействие с клиентами после выкатки изменений – чтобы убедиться, что наиболее важные аспекты работают правильно. Некоторые организации могут принять решение о тестировании изменений на проде, но убедитесь, что это сделано правильно, а риски учтены. Также можно проводить мониторинг производительности и скорости приложения и базы данных. Еще после миграции надо наблюдать за логами приложения и базы данных, чтобы вовремя обнаружить возникающие проблемы. Если там в наличии ошибки, приводящие к неработоспособности системы, стоит предусмотреть стратегию отката, которую вы продумывали при планировании (вот еще почему планировать надо тщательно).

Не забудьте про документацию!

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

Заключение

Готовясь к миграции данных, действуйте пошагово. Планирование – отличный способ выявить риски и познакомиться с инструментарием. Убедитесь, что вы явно проговорили типы необходимого тестирования и выгоду от каждого из них – и вот вы уже на шаг ближе к успешной миграции. После миграции тоже важно предпринять необходимые шаги – команда должна быть готова мониторить и тестировать критически важные компоненты, на которые миграция могла повлиять. К тому же не забывайте о документировании процесса – в будущем вы сможете сослаться на этот проект. И, наконец, признайте, что ваши планы – это именно планы! Жизнь непредсказуема, и это также применимо к вашему проекту миграции данных. Вы столкнетесь с предложениями или событиями, не покрытыми планом. Важно, однако, быть гибкими и готовыми справляться с изменениями. Ретроспектива может помочь команде извлечь из ошибок уроки и стать лучше.

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

Полезные ссылки:

1. Data Migration Testing Tutorial: A Complete Guide
2. Database Testing: How to Regression Test a Relational Database
3. How To Conduct Effective Software Testing When Migrating Data.
4. 8 Hurdles of a Data Migration
5. 7 Reasons Data Migrations Fail
6. Everything to Know About Data Migration
7. One Page Test Plan