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