В предыдущих материалах мы уже рассказывали про подход к автоматизации функционального тестирования в ДОМ.РФ и использование 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 уже был реализован механизм связей ручных тест‑кейсов с автотестами, причём по схеме «многие ко многим». С нашей стороны мы реализовали это так же через 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 для автоматизатора — это удобное средство разбора запусков со всеми необходимыми артефактами и ссылками, хранилищем истории и статистики работы автотестов, а для ручных тестировщиков и тест‑менеджеров наш плагин сделал работу с автотестами удобнее и понятнее.