Миграция между системами управления тестированием - перенос тестовых данных из одной системы в другую: структуры проектов и наборов тестов, тест-кейсов с шагами и атрибутами, пользовательских свойств, вложений и, по решению команды, истории тестовых прогонов и связей с требованиями и дефектами. Миграция заканчивается, когда новая система используется для тестирования и подтверждено, что её данные соответствуют источнику.
Стандарта, который задавал бы формат обмена тест-кейсами между системами управления тестированием, нет. Системы выгружают и загружают данные в форматах общего назначения: CSV и электронных таблицах, собственных форматах XML или JSON, через свои API. В двух соседних областях общие форматы есть: JUnit XML для результатов автотестов и ReqIF, Requirements Interchange Format консорциума Object Management Group, для требований. Сущности, которые переносятся, описаны в статье Что такое система управления тестированием.
Почему миграция - не копирование
Основные сущности в большинстве систем управления тестированием похожи, но модели данных различаются в деталях, и каждая деталь влияет на перенос:
- Шаги. В одной системе шаг - отдельная запись с действием и ожидаемым результатом, в другой шаги - одно текстовое поле.
- Поля. Наборы стандартных полей различаются, как и их значения: три уровня приоритета в одной системе, четыре в другой.
- Пользовательские свойства. Типы полей (список, множественный выбор, число, дата, пользователь) и их допустимые значения задаются в каждой системе и каждом проекте.
- Форматирование. Текст может храниться как HTML, Markdown или простой текст, а таблицы, изображения и ссылки внутри текста кодируются по-разному.
- Идентификаторы. Целевая система присваивает свои идентификаторы. Всё, что ссылалось на старые идентификаторы, в том числе автотесты, дефекты в баг-трекере и документы, нужно обновить или сопоставить.
- История. Результаты прошлых прогонов ссылаются на версии тест-кейсов, пользователей и окружения. Не каждая система умеет импортировать результаты с исходными датами и исполнителями.
Поэтому миграция - это преобразование данных из одной модели в другую с решениями о том, что переносится, как и что остаётся.
Что переносится
Таблица перечисляет виды данных и вопросы, которые решают по каждому из них до миграции:
| Данные | Что нужно решить |
|---|---|
| Структура: проекты, наборы, папки | Сохраняется ли дерево как есть или реорганизуется? Как отображаются вложенные уровни, если глубина ограничена? |
| Тест-кейсы | Какие статусы переносятся: только актуальные или и устаревшие? Какие версии: последняя или все? |
| Шаги и ожидаемые результаты | Переносятся ли шаги отдельными записями или текстом? Что делать с общими шагами и вызываемыми тест-кейсами? |
| Стандартные поля | Как сопоставляются приоритеты, типы и статусы между двумя наборами значений? |
| Пользовательские свойства | Какие нужны в новой системе? Созданы ли их типы и значения до импорта? |
| Вложения | Переносятся ли файлы вместе с тест-кейсами и результатами? Что делать с изображениями, встроенными в текст? |
| Тестовые прогоны и результаты | История переносится, остаётся в старой системе как архив или выгружается в файлы? |
| Связи с требованиями | Остаются ли требования в том же инструменте? Восстанавливаются ли связи по идентификатору? |
| Связи с дефектами | Остаются ли дефекты в баг-трекере? Восстанавливаются ли связи результатов с дефектами? |
| Пользователи | Как авторы и исполнители сопоставляются с учётными записями в новой системе? |
Тестовые прогоны и их история
История - самая дорогая часть миграции. Результаты ссылаются на тест-кейсы, окружения, сборки и пользователей, и всё это должно существовать в целевой системе до импорта результатов. Некоторые системы не позволяют создать результат с исходной датой или от имени другого пользователя.
Распространены три подхода:
- полный перенос: прогоны и результаты импортируют с датами и исполнителями там, где это позволяет целевая система;
- перенос итогов: импортируют только последний результат каждого тест-кейса или результаты последнего релиза;
- архив: история остаётся в старой системе в режиме только для чтения или выгружается в файлы, а новая система начинает с новых прогонов.
Выбор зависит от того, для чего используется история: аудиты и нормативные требования, анализ нестабильных областей, сравнение с прошлыми релизами.
Форматы обмена
CSV и электронные таблицы
CSV - формат, который умеет выгружать и загружать почти любая система управления тестированием. Его общепринятое описание - RFC 4180 (октябрь 2005 года), у которого статус информационного документа, а не стандарта. По RFC 4180 записи заканчиваются переводом строки CRLF, необязательная первая строка содержит названия полей, а поле с запятой, двойной кавычкой или переводом строки заключается в двойные кавычки; двойная кавычка внутри такого поля записывается дважды.
Тест-кейсы часто содержат многострочный текст, поэтому эти правила важны. Тест-кейс с двумя шагами в одной записи CSV:
ID,Title,Priority,Steps,Expected Result
TC-13,"Pay with an expired card",High,"1. Open the cart and click ""Checkout""
2. Click ""Pay""","The message ""Card expired"" is shown"RFC 4180 не фиксирует кодировку символов: он называет US-ASCII распространённым вариантом и допускает другие наборы символов через параметр charset типа данных. На практике кодировку, разделитель (запятая или точка с запятой) и формат дат согласуют между выгрузкой и загрузкой, иначе текст не на латинице и даты искажаются.
Из структуры CSV следуют два ограничения. Запись плоская, поэтому шаги в виде отдельных записей кодируют либо одним многострочным полем, либо несколькими строками одного тест-кейса - в зависимости от того, что ожидает импортирующая система. Вложения в CSV поместить нельзя, их переносят отдельно.
Так же используют электронные таблицы в формате Office Open XML (XLSX, стандартизован как ECMA-376 и ISO/IEC 29500). Они избавляют от проблем с разделителями и кодировками, но структура у них такая же плоская.
Выгрузки в XML и JSON
Многие системы выгружают проект в собственном формате XML или JSON, который сохраняет структуру: наборы, тест-кейсы, шаги отдельными элементами, пользовательские свойства, иногда вложения. Такой формат документирует производитель исходной системы. Целевая система может его импортировать, если поддерживает формат именно этого источника, или скрипт преобразует его в формат импорта целевой системы.
API
API даёт доступ ко всем данным, которые хранит система, в том числе к тем, которых нет в выгрузке. Миграция через API читает данные из источника и записывает их в целевую систему скриптом. Такой скрипт учитывает ограничения API: постраничную выдачу списков, ограничения на число запросов в минуту, порядок создания (набор раньше его тест-кейсов, тест-кейс раньше его результатов) и повторные попытки после ошибок.
Форматы соседних областей
Результаты автотестов в большинстве случаев не переносят как историю. После миграции конвейер CI отправляет новые результаты в новую систему, обычно в формате JUnit XML. Автотесты, у которых в именах или атрибутах есть идентификаторы тест-кейсов, переводят на новые идентификаторы.
Требования, которые переносят вместе с тест-кейсами, можно передавать в ReqIF, если оба инструмента его поддерживают. ReqIF - XML-формат OMG; его текущая версия 1.2 вышла в июле 2016 года.
Сопоставление полей
Сопоставление полей (field mapping) - таблица, которая для каждого поля источника указывает, куда оно попадает в целевой системе и как преобразуется его значение. Её пишут до первого пробного импорта, и это основной документ миграции.
| Поле источника | Поле в целевой системе | Преобразование |
|---|---|---|
| ID | Пользовательское свойство «Legacy ID» | Копируется как есть |
| Title | Название | Копируется как есть |
| Priority: Critical, High, Medium, Low | Приоритет: High, Medium, Low | Critical и High становятся High |
| Status: Draft, Ready, Obsolete | Статус: Draft, Active, Deprecated | Один к одному по смыслу |
| Component (текст) | Пользовательское свойство «Component» (список) | Значения нормализуют и создают в списке до импорта |
| Steps (HTML) | Шаги (отдельные записи) | Текст делят по пунктам нумерации, HTML преобразуют в разметку целевой системы |
| Automation (yes, no) | Пользовательское свойство «Automation status» | yes становится Automated, no - Manual |
Сопоставление, которое объединяет значения, теряет информацию: после объединения Critical и High разницу между ними в целевой системе не восстановить. Если разница важна, исходное значение сохраняют в отдельном поле.
Значения, которые сопоставление не покрывает, встречаются в каждой миграции: неизвестный статус, компонент с опечаткой, пустое обязательное поле. Скрипт сообщает о них, а не заполняет молча значениями по умолчанию, и по каждому случаю принимают решение.
Идентификаторы и связи
Целевая система присваивает новые идентификаторы. Старый идентификатор сохраняют в пользовательском свойстве, например «Legacy ID», чтобы люди и документы, которые ссылаются на старый идентификатор, находили тест-кейс. Таблицу соответствия идентификаторов (mapping of identifiers) старых новым сохраняют отдельно после импорта.
По таблице соответствия обновляют всё, что ссылалось на старую систему:
- связи результатов и тест-кейсов с дефектами в баг-трекере и обратные связи дефектов с тест-кейсами;
- связи требований с тест-кейсами;
- идентификаторы тест-кейсов в коде автотестов и в конфигурации конвейера CI;
- ссылки в документах: тест-планах, отчётах, страницах вики.
Связи внутри переносимых данных - например, тест-кейс, который вызывает другой тест-кейс, или результат, который принадлежит прогону, - восстанавливают при импорте в порядке зависимостей: сначала объекты, на которые ссылаются, затем те, что ссылаются.
Ход миграции
Миграция тестовых данных обычно проходит такие этапы:
- Инвентаризация. Подсчитывают объём данных: проекты, наборы, тест-кейсы по статусам, пользовательские свойства, вложения и их общий размер, прогоны и результаты.
- Объём. Команда решает, что переносится, а что остаётся: устаревшие тест-кейсы, история, вложения старых прогонов.
- Сопоставление. Пишут сопоставление полей, создают пользовательские свойства и их значения в целевой системе.
- Пробная миграция. Часть данных, например один проект или один набор с тест-кейсами всех видов, переносят в тестовое пространство и проверяют.
- Исправления. По итогам пробы исправляют сопоставление и скрипт и повторяют пробу, пока проверка не пройдёт.
- Заморозка. На время полной миграции изменения в исходной системе прекращают или записывают изменения, сделанные во время миграции, и переносят их после.
- Полная миграция. Переносят все данные в пределах объёма.
- Проверка. Результат сверяют с источником, как описано ниже.
- Переключение. Тестирование переходит в новую систему, конвейер CI отправляет результаты туда, старую систему переводят в режим только для чтения или архивируют.
Проверка после миграции
Проверка сравнивает целевую систему с источником на нескольких уровнях.
Количества. Сравнивают число объектов по проектам и наборам: тест-кейсы по статусам, шаги, вложения, прогоны, результаты. Расхождение в количествах находят и объясняют до всего остального.
Выборочное сравнение. Выборку тест-кейсов сравнивают поле за полем: название, все шаги и ожидаемые результаты, каждое пользовательское свойство, вложения. В выборку включают трудные случаи: длинные тексты, таблицы и изображения в тексте, символы не на латинице, тест-кейсы с большим числом шагов, тест-кейсы со всеми заполненными пользовательскими свойствами.
Вложения. Сравнивают число и общий размер файлов, выборку файлов открывают. Изображения, встроенные в текст тест-кейсов, проверяют отдельно: на них ссылается текст, и они теряются, если ссылку не преобразовали.
Связи. Для выборки тест-кейсов проходят по связям с требованиями и дефектами в обе стороны. Для автотестов запускают прогон в CI и проверяют, что результаты попадают в нужные тест-кейсы новой системы.
Использование. До переключения тестировщики выполняют небольшой прогон в новой системе. Он проверяет то, чего не проверяют количества и выборки: что тест-кейсы читаются, что фильтры и отчёты работают с перенесёнными пользовательскими свойствами.
Миграция с историей и без неё
Решение об истории влияет на стоимость и длительность миграции сильнее любого другого.
| С историей | Без истории | |
|---|---|---|
| Что переносится | Тест-кейсы, структура, прогоны и результаты с датами и исполнителями | Тест-кейсы и структура; прогоны начинаются заново |
| Требования к целевой системе | Импорт результатов с исходными датами и пользователями | Только импорт тест-кейсов |
| Трудозатраты | Высокие: окружения, сборки, пользователи и версии тест-кейсов воссоздаются | Ниже |
| Где хранится история | В новой системе | В старой системе в режиме только для чтения или в выгруженных файлах |
| Отчёты через момент переключения | Возможны в одной системе | Требуют объединения данных из двух источников |
История в старой системе доступна, пока хранится старая система или её выгрузка. Когда старую систему отключают, выгрузка истории становится единственной копией, и её формат и читаемость проверяют до отключения.
Термины
| Термин | Значение |
|---|---|
| Миграция между системами управления тестированием | Перенос тестовых данных из одной системы в другую с преобразованием в модель данных целевой системы |
| Сопоставление полей (field mapping) | Таблица, которая для каждого поля источника указывает, куда оно попадает в целевой системе и как преобразуется его значение |
| Таблица соответствия идентификаторов | Таблица соответствия идентификаторов объектов в источнике и в целевой системе |
| Пробная миграция | Перенос части данных в тестовое пространство для проверки сопоставления и скрипта |
| CSV | Comma-separated values: текстовый формат таблиц, описанный в RFC 4180 |
| ReqIF | Requirements Interchange Format: XML-формат OMG для обмена требованиями между инструментами |
Источники
- RFC 4180, Common Format and MIME Type for Comma-Separated Values (CSV) Files, октябрь 2005(откроется в новой вкладке) (на английском)
- ECMA-376, Office Open XML file formats, Ecma International(откроется в новой вкладке) (на английском)
- Requirements Interchange Format (ReqIF), version 1.2, OMG(откроется в новой вкладке) (на английском)
- Common JUnit XML format and examples, Testmo(откроется в новой вкладке) (на английском)