Ключевые моменты при тестировании миграции баз данных

Согласно исследованию 2017 Data Migration Research, 61% респондентов проводили миграцию данных для трёх и более устаревших систем. Это свидетельствует о том, что множество компаний осуществляет миграцию данных. В том же исследовании сообщается, что 69% проектов по миграции данных были успешны. Следовательно, можно предположить, что оставшийся 31% закончился неудачей. Возникает закономерный вопрос: насколько такой результат является следствием незнания необходимых практик тестирования миграции данных?

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

Эта статья рассказывает об основных моментах, которые необходимо учитывать при проведении эффективного тестирования миграции баз данных.

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.

Планирование

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

Также важным аспектом подготовки является создание плана тестирования. В нём должны быть отображены сроки и объёмы тестирования, возможные риски, процедуры отката, количество человек в команде и т. д.

Понимание окружения

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

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

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

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

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

Следующий важный аспект процесса миграции данных — это знание видов тестов, которые предстоит выполнить.

Сравнение схемы в исходной и целевой базе данных

Схема базы данных представляет, как данные существуют в системе управления базой. Чтобы убедиться, что исходная и целевая базы имеют похожий синтаксис, проводится сравнение их схем. Например, базы данных PostgreSQL и IBM DB2 по-разному форматируют даты, и это различие в синтаксисе требует изменений в коде приложения.

Поскольку сравнение схем вручную для сотен таблиц баз данных отнимает много времени и чревато ошибками, можно воспользоваться специальными инструментами, например, Aqua Data Studio Schema Compare Tool. Использование подобных инструментов упростит процесс сравнения и обеспечит логическое соответствие целевой и исходной схем. Это гарантирует, что данные будут храниться так, как задумано, и обеспечит отсутствие недочётов или утерянных данных при использовании исходной базы данных.

Проверка на уровне данных

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

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

Проверка на уровне приложения

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

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

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

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

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

Поддержка после миграции

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

Документация

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

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

Заключение

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

Перевод статьи «Five Things To Consider When Testing Database Migration».

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *