Автор: Константин Сахчинский (Konstantin Sakhchinskiy)
Оригинал статьи
Перевод: Ольга Алифанова

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

Что такое тестирование миграции данных?

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

В процессе миграции происходит перенос всех существующих данных (как системных, так и пользовательских) в новую базу данных. Конечная задача — чтобы приложение эффективно работало с данными в новой структуре и с текущими данными. Для этого необходимо убедиться, что:

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

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

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

Ключевые моменты при тестировании миграции:

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

Вкратце о стратегии тестирования миграции данных

Этапы тестирования миграции данных

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

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

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

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

Проблемы миграции данных

• Обработка больших объёмов данных
• Обеспечение согласованности данных
• Устранение потенциальных ошибок, возникающих в процессе миграции системы
• Данные, представленные в разных кодировках
• Одновременная миграция данных и внедрение новых функций
• Правильное сокрытие персональных данных пользователей
• "Перемещаемость" набора данных, содержащего скрытые персональные данные и идентификаторы пользователей

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

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

Сценарий первый: многонациональный зеркальный веб-сервис

Представьте себе сложный веб-сервис, интегрированный с несколькими микросервисами и сторонними приложениями. Можно представить, что это служба поддержки клиентов крупной компании.

Система работает по всему миру: в Европе, Африке, Азии, а также в Северной, Центральной и Южной Америке. Каждая из этих версий – это зеркало всей системы для конкретного региона.

Вот в чём подвох: компания хочет сократить расходы. Запуск отдельных систем для разных регионов стоит дорого. Нужно больше серверов, возникают сложности с обновлениями и управлением, да и сторонние приложения недешевы. Поэтому план — объединить всё в одном экземпляре: одна система, управляющая данными всех регионов. Система должна без проблем обслуживать все регионы.

Очевидно, что это большая задача. Нельзя просто свалить все данные вместе. Данные каждого региона должны оставаться в своих пределах. Крайне важно, чтобы система понимала, откуда пришли данные, и сохраняла их упорядоченными согласно правилам и требованиям каждого региона. Хоть всё и работает на одной системе, данные каждого региона продолжают соответствовать своим собственным правилам.

Как бы я тестировал этот сценарий

Используйте смесь реальных и сгенерированных тестовых данных. Как определить, какой тип использовать? В моём случае я предпочитал использовать реальные данные, когда это было возможно, но создавал синтетические данные для конкретных тестовых случаев, которые иначе не покрывались бы.

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

Используйте несколько промежуточных стейджинг-сред, чтобы эмулировать разные регионы.

Создайте копию ваших продакшен-данных. В моём случае я смог получить все необходимые данные из продакшен-среды через API. Система была интегрирована с внешним решением (Zendesk), поэтому я использовал REST API Zendesk для получения всех нужных данных без необходимости писать множество сложных SQL-запросов и делать громоздкие дампы базы данных.

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

• Вам нужно будет решить, удалять или обфусцировать данные. Например, если у вас есть имена пользователей и адреса электронной почты, нельзя просто удалить их и оставить поля пустыми. Вместо этого исходные данные удаляются, а на их место подставляются случайно сгенерированные имена и почты на основе этих имён.
• Хорошая новость: эти задачи можно автоматизировать.

Создавайте синтетические тестовые данные там, где это необходимо. В некоторых случаях это может быть не нужно, особенно если сущности в вашей базе данных просты и их немного. Но синтетические данные могут понадобиться для покрытия конкретных тестовых сценариев. Например, база данных службы поддержки клиентов, включающая названия продуктов компании, может содержать много данных, связанных с продуктами Adobe, такими как «Photoshop» и «Illustrator». Нет смысла тратить время на получение этих данных из продакшен-базы, но эти названия всё равно нужны, поскольку к ним будут привязаны многие другие сущности.

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

Добавьте данные в каждую тестовую (стейджинг) среду. Если у вас есть API, как было у меня (Zendesk), задача значительно упрощается.

• Сложность здесь — сопоставить ID тестовой среды с ID продакшен-среды, так как многие сущности невозможно напрямую мигрировать. Например, если у вас есть таблица с действиями пользователей на сайте, где в качестве первичного ключа используется UUID пользователя, то этот UUID должен быть сопоставлен с другими таблицами и сервисами, где используются те же UUID.
• Без этого сопоставления возникнут несоответствия, и часть функционала системы может работать некорректно или вообще не работать. Из-за большого количества интеграций с разными сервисами просто сделать дамп и использовать его «как есть» невозможно.

Выполните статическое и функциональное тестирование каждой тестовой среды. Проверьте, что данные выглядят корректно, всё работает, и на каждой среде нет сбоев.

Тестируйте саму миграцию. Это тест крупной продакшен-миграции. Шоу начинается!

• Запустите миграции для всех регионов (перенос данных из разных тестовых сред в единую новую среду).
• Проверьте, что всё работает с «старыми» (мигрировавшими) данными и с новыми данными, убедитесь, что нет конфликтов, ошибок и сбоев.
• Проверьте работу с новыми свежими данными (созданными уже в новой системе).
• Убедитесь, что данные из разных регионов (Европа, Азия) по-прежнему принадлежат своим оригинальным регионам, что никакие данные не потеряны и что все данные доступны, их можно изменять, удалять или обновлять согласно логике приложения.
• Протестируйте остальные функции: проведите полный регрессионный тест.
• Если какой-либо этап не прошёл, возвращайтесь назад, вносите исправления и повторяйте. Когда я сталкивался с некорректной миграцией, у меня уже были все скрипты для генерации данных, создания и обфускации, поэтому можно было легко очистить базу новой тестовой среды и повторить миграцию с исправлениями.

Сценарий второй: Облачный инструмент для управления расширениями браузера

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

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

Владелец продукта хочет улучшить этот инструмент управления расширениями, добавив новые функции и больше возможностей для установки расширений из разных источников, таких как Chrome Web Store, файлы .crx или .zip, а также распакованные расширения. Конечный пользователь должен иметь возможность устанавливать расширения без необходимости открывать браузеры для каждой установки. Пользователь также сможет удалять расширения или использовать разные (старые) версии расширений.

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

Как мы поймём, что миграция прошла успешно? Очевидно, что мы не хотим потерять никакие пользовательские данные. Все расширения и их конфигурационная информация, включая расширения, отсутствующие в Chrome Web Store, должны быть доступны и работать после миграции. Новые функции, например, возможность удаления расширений, должны работать с уже существующими расширениями.

Как бы я тестировал этот сценарий

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

Создайте тестовую среду, идентичную планируемой производственной среде.

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

Сгенерируйте тестовые данные, охватывающие большинство известных случаев.

• Используйте реальные данные в качестве источника статистики и конкретных деталей.
• Добавьте различные расширения и их версии, включая популярные, сложные, с разными разрешениями и т. п.
• Используйте разные способы добавления расширений: из Web Store, .crx-файлов и распакованных расширений.
• На этом этапе важно, чтобы тестовая среда была идентична производственной.

Протестируйте обратную совместимость. Обновите серверный код и проверьте, что устаревшее клиентское приложение работает корректно. Убедитесь, что все пользовательские данные доступны и приложение с ними взаимодействует, как ожидается. На этом этапе у вас будет три набора схожих данных:

• Данные из первого шага, которые не использовались никак
• Данные из первого шага, с которыми проводились тесты (обновлялись, удалялись и т. п.)
• Новые данные, созданные на этом шаге.

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

Заключение

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

Ключ к успешной миграции данных — качество тестовых данных. По возможности используйте реальные данные (обфусцированные). Используйте реальные данные и статистику как эталон, чтобы охватить все тестовые случаи и создать надёжные наборы тестовых данных.

Тестируйте обратную совместимость — это не всегда обязательно, но часто добавляет множество дополнительных тестов и генерацию дополнительных тестовых данных.

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

Для этого потребуется некоторый навык работы с базами данных и скриптами.

• Я использовал Python: у меня был некоторый опыт программирования, но в своих скриптах я использовал функции, а не весь набор объектно-ориентированных структур.
• Среди инструментов, которые я применял: PyCharm для разработки и библиотека Zendesk REST API. Я использовал множество Python-библиотек - requests, uuid, names, random, json.
• Также я работал с базами данных, писал SQL-запросы и использовал инструменты PgAdmin и Postman для отладки запросов и ответов.

Убедитесь, что вся команда понимает и принимает ваш план по тестированию миграции данных.

Обсудить в форуме