Автотесты и TMS: как мы реализовали интеграцию АФТ с Test IT

В предыдущих материалах мы уже рассказывали про подход к автоматизации функционального тестирования в ДОМ.РФ и использование Test IT в качестве Системы управления тестированием (далее — TMS). После этого возникла задача интегрировать с ней наши автотесты (АТ). 

Зачем вообще нужна интеграция АФТ с TMS

Что может быть реализовано:

• Выгрузка автотестов в TMS;

• Публикация результатов запусков автотестов в TMS;

• Связь ручных тест-кейсов с соответствующими им автотестами в единой тестовой модели;

• Проставление в тест-планах ручного тестирования результатов выполнения тестов;

• Проставление результатов выполнения автотестов, связанных с ручными тест-кейсами в тест-планах ручного тестирования;

• Возможность разбора результатов выполнения автотестов в TMS;

• Сбор статистики по результатам выполнения автотестов, числа и регулярности запусков, стабильности прохождения отдельных автотестов / по части функционала / по системе;

• Запуск автотестов из TMS любым участником команды тестирования “по клику”. 

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

• ручные тестировщики получают возможность анализировать запуски автотестов или даже запускать их самостоятельно, участвовать в разборе результатов;

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

• тест-менеджеры получают единый инструмент для планирования, мониторинга и сбора результатов и формирования отчётности о ручном и автоматизированном тестировании.

Что предлагал Test IT в качестве TMS для наших задач

Ранее используемое ДОМ.РФ вендорское решение предоставляло следующий функционал: 

• были реализованы модули ручного тестирования с широкими возможностями управления ручной тестовой моделью, создание тест-планов, прохождение тест-кейсов в их рамках и формирование отчета;

• отдельным модулем были автотесты. Модуль хранил сами сущности автотестов, историю их выполнения, а также имел возможность связывать автотесты с ручными тест-кейсами;

• присутствовали отчеты и дашборды по всему проекту. (На 2020 год для наших задач имелись два таких модуля – про ручное тестирование и автотестирование).

Весь модуль автотестов управлялся только через API: нет возможности вручную ни создать автотест, ни удалить, ни привязать к нему ручной тест-кейс. Это отличительная особенность данной TMS, которая сохраняется и по сей день. 

Готового коробочного решения для интеграции автотестов с TMS по  API на тот момент не было. Сроки предоставления не назывались. А если бы решение и было, вероятно, оно все равно бы потребовало кастомизации под наш фреймворк с нашей стороны. С этого и началась история нашего плагина для интеграции AFTCore с Test IT.

Наши первые шаги к интеграции автотестов с TMS

Со стороны Test IT была предоставлена документация их API, а также swagger. У нас в ДОМ.РФ используется фреймворк автотестирования AFTCore, имеющий с одной стороны стандартный стек (Java, Maven, JUnit, Cucumber). И в то же время фреймворк сильно кастомизирован (работа с профилями, параметрами и переменными через самописный обработчик данных, механизм импорта одних сценариев в другие и проче). Поэтому на первом этапе была задача создать инструмент для выгрузки хотя бы одного автотеста в проект в Test IT, а далее — поэтапно расширять его функционал.

Для изучения возможностей API TMS использовался Postman. После первых успешных попыток собранных коллекций действий был создан отдельный maven проект на Java, REST Assured и Jackson, способный повторить эти действия. 

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

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

В результате нам удалось реализовать Cucumber-plugin для нашего фреймворка, способный реализовать CRUD-процедуры в секции автотестов проекта в Test IT. Мы смогли выгружать все автотесты нашего проекта в одну кучу и именовать их по названия сценария. 

Усложняем задачу: раскладываем сценарии по папкам

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

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

Следующий уровень: механизм управления выгрузкой

Далее нам потребовалось реализовать механизм управления выгрузкой: выгружать только необходимые сценарии, а не все существующие или не все запущенные. А если ранее выгруженный автотест становится ненужным — уметь удалять его из TMS. При этом в web-интерфейсе возможности управлять моделью автотестов не планируется, поэтому делать всё это необходимо в коде проекта автотестов.

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

Так появились первые аннотации, управляющие выгрузкой автотестов: 

• @TestIT — для автотестов, подлежащие выгрузке,

• @TestIT_delete — для удаления неактуальных сценариев из TMS, 

• сценарии без этих двух тегов не отслеживаются плагином.

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

Связываем автотесты с ручными тест-кейсами

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

Так вот, в Test IT уже был реализован механизм связей ручных тест-кейсов с автотестами, причём по схеме “многие ко многим” (https://en.wikipedia.org/wiki/Many-to-many_(data_model)). С нашей стороны мы реализовали это так же через Cucumber-тег: теперь те автотесты, которые должны иметь связанность с какими-либо ручными тест-кейсами, имели не просто (или не только) тег @TestIT, а ещё и ID ручного тест-кейса в скобках, например, @TestIT[241/5321], где 241 и 5321 — id ручных тест-кейсов. 

Такие тесты теперь в интерфейсе TMS отображаются с иконкой “Ракета”, а не “Рука”, и попадают в статистику автоматизированных ручных кейсов. А в карточке такого кейса можно просмотреть список всех связанных с ним автотестов и перейти к ним по сслыке.

Взлёты (Passed) и падения (Failed): выгружаем результаты выполнения автотестов 

Следующим важным шагом было научить плагин выгружать результаты выполнения автотестов. Для этого мы подключили наш плагин к кукумбер-раннеру нашего фреймворка. Во время выполнения автотестов он логирует каждый шаг. После завершения всех автотестов результаты собирались плагином и с помощью API в Test IT создавался тест-ран, в который загружалась информация о ходе выполнения и статусе запущенных автотестов. 

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

• дату и время начала и завершения сценария,

• результат и время выполнения каждого шага,

• результат с указанием места падения и прикреплением сообщения об ошибке,

• информацию о запуске: система, конфигурация, ссылка на gitlab-job и allure-отчёт.

А позднее с обновлениями в интерфейсе Test IT появился раздел “Запуск автотестов”. В TMS появилась возможность увидеть подробную информацию о прогонах, производить разбор результатов с проставлением причин падения, возможностью персонального комментирования автотестером и прикрепления ссылок на баг-трекер. И если ранее Test IT был главным орудием ручного тестировщика или тест-менеджера, то теперь он стал еще и удобным инструментом для автоматизатора. 

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

В 2021 году один из проектов преподнес нам нетривиальную задачу. Автотесты выполнялись в изолированной среде без доступа к TMS. Стандартный механизм плагина подразумевал выгрузку сразу после выполнения последнего теста и не сохранял служебные данные. 

Нам пришлось расширить его возможности и сохранять результаты выполнения в служебный “Exchange”-файл. Заодно мы добавили некоторую параметризацию выгрузки, например, передачу api-token-а, отличного от того, под которым запускались автотесты. Плюс на этом этапе мы сделали нашу подключаемую библиотеку/плагин исполняемой в версии “fat”.

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

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

Задачка со звёздочкой: единый тест-план

В начале 2021 года со стороны одного из проектов ДОМ.РФ поступила идея по улучшению Test IT: реализовать выгрузку результатов автотестов в созданный руками тест-план, включающий и ручные тест-кейсы. К концу года данную доработку реализовали коллеги из Test IT, а в начале 2022 года мы доработали наш плагин, и сейчас многие команды уже активно используют этот функционал.

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

Идеальный алгоритм выглядит так: 

• тест-менеджер определяет состав тест-плана,

• автотестеры делают запуск через Test IT и контролируют запуск автотестов,

• после выгрузки результатов автотестов ручные тестировщики проходят только те тест-кейсы в составе этого тест-плана, которые не автоматизированы либо по которым автотесты вернули ошибку,

• после завершения ручного тестирования все результаты ручных и автотестов отображаются в одном тест-плане и отчёте.

Вернее, так выглядит почти идеальный алгоритм… 

Нет предела совершенству: планы на развитие

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

Отчасти это возможно уже сейчас: в Test IT реализован механизм hook-ов, содержащих тело и параметры для вызова по API инструментов CI. К сожалению, в данный момент отсутствует возможность кастомизации тела и параметров запроса. В случае с нашим фреймворков с использованием Cucumber-а запрос hook-а всегда включает все шаги сценария и получается весьма объемным. А в качестве CI мы используем Gitlab, который имеет ограничения по объему тела запроса. 

Мы уже передали этот запрос на улучшение разработчикам Test IT и надеемся, что в ближайших релизах получим возможность кастомизировать тело hook-ов, передать собственные параметры, и сможем реализовать запуск автотестов по клику из веб-интерфейса Test IT. 

Подводя итоги

Двухлетний опыт работы позволяет нам в ДОМ.РФ оценивать Test IT как удобный и качественный инструмент для управления тестированием с точки зрения как ручного тестировщика, так и тест-менеджера. Выбор в пользу самописного плагина для интеграции автотестов с TMS позволил сделать его таким же удобным и для автотестеров. 

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