Home

Тестирование миграции данных – неклассическая задача инженеров по тестированию ПО, но с повсеместным распространением «больших данных» она встречается все чаще.

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

Итак, начнем.

Миграция данных – перенос данных на новый ресурс/окружение.

Казалось бы, что может быть проще, чем перенести данные из системы А в систему Б? Но на деле часто оказывается, что системы А и Б имеют разную архитектуру и функциональность. Данные различия, в свою очередь, вызывают потерю данных, перенос нерабочих компонентов, нарушение прав доступа.

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

Описание проекта

В A1QA обратился заказчик, которому требовалась поддержка в рамках проекта по переходу на новую систему хранения данных. Целевая система – Confluence, которая, уверены, знакома многим тестировщикам не понаслышке. Задача – обеспечить корректный перенос 300 тысяч страниц, с сохранением всего контента, ссылок, разметки, вложений. Для этого была сформирована команда по тестированию миграции.

Хочется отметить две особенности проекта, которые в дальнейшем окажут влияние на выбор стратегии тестирования:

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

Выбор подхода к тестированию

Как же протестировать вручную такой объем данных? Напомним, что страниц было 300 000 и на 11 языках. Поэтому просто прокликать все страницы и визуально проверить корректность переноса данных было невозможно. К тому же ситуацию усложняло отсутствие доступа к старому хранилищу данных.

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

В тестировании качество – понятие конкретное и измеримое.

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

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

Так что же такое «качество» при миграции данных?

Обсудив эти вопросы с заказчиком, наша команда предложила тестировать следующие аспекты:

1. Контент страниц:

• Полнота контента;
• Правильность отображения языков;
• Стили/шрифты.

2. Права доступа пользователей.

3. Доступность дополнительных ресурсов:

• Изображения;
• Работоспособность внутренних и внешних ссылок. Внутренние ссылки – ссылки на другие страницы в системе, внешние – ссылки на сторонние проекты и файлообменники;
• Хранилище для внешних ресурсов.

4. Бизнес-правила от клиента (для конкретных страниц и типов данных).

Итак, стратегия разработана и согласована. Переходим к тестированию.

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

А теперь непосредственно о тестировании.

В исходной системе данные хранились в XML-формате. Помимо текста в старой системе была также HTML-разметка, разнообразные элементы, которые также требовалось учесть.

Чтобы понять, как страницу видит обычный пользователь, мы использовали онлайн-редактор HTML.

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

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

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

Как же сделать это все оптимально: обеспечить достаточное покрытие и сократить число тестов?

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

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

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

Далее в редакторе смотрели, как страница выглядела в старой системе, сверяли с ее отображением в Confluence и делали вывод, правильно ли осуществился перенос информации.

Проверка данных на разных языках

Законный вопрос: как проверить правильность страниц на разных языках? Тут нам помог онлайн-ресурс DiffChecker.

Например, у нас была вот такая страница на китайском языке.

Первым делом мы приводили ее в читабельный вид, убирая разметку.

Получалось вот что.

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

На основе этих проверок делали выводы о качестве переноса данных.

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

Тут нашей командой был использован классический подход:

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

Аналогично проверяется общий доступ к странице для нескольких групп пользователей.

Тестируем перенос вложенных ресурсов и ссылок

Естественно, открыть каждую страницу и проверить, есть ли на ней нужные изображения и работают ли ссылки, было невозможно. Эти проверки также нужно было оптимизировать. Мы использовали специальный онлайн-ресурс для проверки ссылок – утилиту Xenu.

Утилита брала все страницы из Confluence по порядку, проверяла все ресурсы, которые были на странице, и указывала на отсутствующие изображения, нерабочие ссылки.

Тем самым мы быстро смогли отловить большинство ошибок, потратив не очень много времени.

Что еще?

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

Так что не забывайте про специфические проверки, которые обусловлены особенностями целевой системы.

Подводим итог.

В результате оптимизации проверок команде A1QA удалось сэкономить 40% времени, отведенного на тестирование. Естественно, заказчик и сама команда остались довольны.

Что же позволило команде успешно провести тестирование миграции большого объема данных?

• Знание SQL, HTML, XML-технологий.
• Разработка грамотного подхода к тестированию, определение аспектов качества.
• Использование стороннего ПО (HTML-редактор, утилита Xenu).

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

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