Меня зовут Александр Акименко я занимаюсь автоматизацией тестирования в Solit Clouds. В этой статье я хотел бы поделиться нашей историей создания прототипа по интеграции Postman и Test IT.

Postman — популярный инструмент для работы с API, который позволяет тестировать бекэнд с помощью отправки запросов и валидации ответов. Инструмент удобен тем, что имеет простой в освоение UI, позволяющий сконфигурировать REST запрос, а также содержит списки уже готовых скриптов проверки ответов, любой из которых можно отредактировать под свои нужды для экономии времени. Поэтому QA инженерам не составляет труда освоить инструмент, а его функциональности зачастую хватает для тестирования сервиса, построенного на REST архитектуре.

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

Всё хорошо, но…

…как поддерживать в актуальном состоянии тестовую документацию? Требования к функциональности сервисов, а следовательно и тесты в Postman — могут изменяться. Каждый раз лезть руками в описание тестов и изменять шаги или ожидаемый результат, а также редактировать структуру папок в Test IT — задача не самая увлекательная.

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

Перед командой автоматизации тестирования стоит две задачи:

  1. Синхронизировать Postman тесты с Test IT

  2. Реализовать их запуск из Test IT

Начнём с конца :)

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

Тестовая документация на момент начала работы над задачей уже была описана. И Postman коллекции уже были готовы. Были и тест-планы, с заветной кнопкой запуска автотестов.

Решение первой проблемы. Как запустить постман из Test IT?

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

Выглядит просто, но где в postman взять id соответствующего тест кейсу в Test IT? На первом этапе мы просто добавили их руками в название папок, содержащих тест кейсов.

Отлично, id есть! Но подождите… для запуска определенной папки newman требует указания полного имени, а не только id.
Мы посчитали, что поддерживать имена в Test IT и в Postman на данном этапе будет рискованно, поэтому решили отделить каждый кейс в отдельные postman коллекции, где будет хранится только папка, предназначенная для запуска. А сама коллекция будет называться по id тест-кейса, чтобы однозначно указать в строке запуска её имя.

Строка запуска:

newman run 124112.postman_collection.json -r cli,@danvargas46/allure,json-summary --suppress-exit-code

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

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

Когда запуск готов, осталось реализовать отчёт в Test IT. Для этого был реализован скрипт, который использует Test IT REST API для проставления результатов

Ссылка на скрипт

Далее добавим шаг предоставления отчётов в нашу схему.

Таким образом решается вторая поставленная задача по реализации запуска тестов из Test IT.

Автотест как самодокументирующийся тест-кейс

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

Но что если это будет делаться автоматически.

Решение на самом деле лежит на поверхности –  postman коллекция хранится в виде json, который удобно парсить и всю информацию можно загрузить в Test It при помощи REST API.

С реализацией вы можете ознакомиться по ссылке

 Общая, финальная схема взаимодействия между Postman и Test IT выглядит следующим образом:

При наличии 100% покрытия автотестами (а для бэкэнд сервиса, это зачастую так и есть) вам не нужно вести документацию в Test IT руками.QA команда просто сохраняет автотесты в репозиторий, затем настроенные скрипты синхронизируют их содержимое с Test IT, где мы получаем уже все удобства по организации запуска и хранения истории.
При этом работа во всех проектах видна централизованно, и можно довольно легко изучить наборы тестов соседних команд для заимствования наработок.

Заключение

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

Ссылка на репозиторий с описанными скриптами - https://github.com/SolitClouds/test_it_postman_integration

Также можно ознакомится с изложенным в статье в видео версии, рассказанной на митапе “QA в корпорациях: автоматизация, нагрузка, качество” https://www.youtube.com/watch?v=B7YevcWveYc&t=10749s

Комментарии (0)