Меня зовут Александр Акименко я занимаюсь автоматизацией тестирования в Solit Clouds. В этой статье я хотел бы поделиться нашей историей создания прототипа по интеграции Postman и Test IT.
Postman — популярный инструмент для работы с API, который позволяет тестировать бекэнд с помощью отправки запросов и валидации ответов. Инструмент удобен тем, что имеет простой в освоение UI, позволяющий сконфигурировать REST запрос, а также содержит списки уже готовых скриптов проверки ответов, любой из которых можно отредактировать под свои нужды для экономии времени. Поэтому QA инженерам не составляет труда освоить инструмент, а его функциональности зачастую хватает для тестирования сервиса, построенного на REST архитектуре.
Для управления автотестами у себя на проекте мы используем систему Test IT.
TMS помогает нам в первую очередь агрегировать ручные и автотесты в одном месте. Причем автотесты могут быть написаны на разных фреймворках. Также в Test IT мы храним статистику по запускам и строим отчеты для выпуска версий.
Всё хорошо, но…
…как поддерживать в актуальном состоянии тестовую документацию? Требования к функциональности сервисов, а следовательно и тесты в Postman — могут изменяться. Каждый раз лезть руками в описание тестов и изменять шаги или ожидаемый результат, а также редактировать структуру папок в Test IT — задача не самая увлекательная.
Все тестировщики знают о необходимости поддерживать тестовую документацию, так как тесты переиспользуются при составлении новых тест-планов. Более того, у Test IT есть возможность запускать тесты напрямую из интерфейса, в том числе выборочно, что довольно удобно.
Перед командой автоматизации тестирования стоит две задачи:
Синхронизировать Postman тесты с Test IT
Реализовать их запуск из 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
