Автор: Сватика Визань (Swathika Visagn)
Оригинал статьи
Перевод: Ольга Алифанова

Большинство тестировщиков в курсе, что Postman – один из самых популярных инструментов тестирования API. Я пользовалась им больше, нежели иными аналогичными инструментами, и просто без ума от его интерфейса. По моему опыту, наиболее популярные возможности Postman – это предварительные скрипты, методы авторизации, интеграция библиотеки Faker для случайных тестовых данных, и та, которую я намерена изучить и исследовать – Flows.

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

Метод запуска тестов надо выбирать в зависимости от нужд вашего проекта. Изучая нечто новое, мы всегда начинаем с простого, а затем усложняем. Такой подход обеспечивает нам доскональное понимание происходящего – это как следовать рецепту, готовя еду!

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

Способы запустить коллекции Postman:

• Вручную через Collection Runner
• Настроить расписание для коллекции в Postman
• Отслеживать коллекцию в Postman
• Вручную из командной строки через Postman CLI
• Вручную из командной строки через Newman и HTML-плагина для отчетов
• Через GitHub Actions, используя Postman CLI во фреймворке непрерывной интеграции/поставки.

Способ 1: ручной запуск коллекции из Collection Runner

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

По умолчанию тесты в коллекции или папке прогоняются последовательно. Но их также можно запускать в иных последовательностях, перетаскивая запросы внутри окна Collection runner. Порядок тестов можно менять и при прогоне через Postman CLI, как мы увидим далее.

Интересный факт: метод postman.setNextRequest() во вкладке Test может повлиять на порядок тестов в прогоне через Collection Runner.

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

Запускать коллекции API-тестов из Postman можно, выбрав Run collection из меню коллекции.

В окне Test Runner можно выбрать настройки конфигурации - Run manually (ручной запуск), Schedule runs (запуск по расписанию), или Automate runs via CLI (автоматизация запуска через интерфейс командной строки). Для начала выберем Run manually, а затем нажмем кнопку Run, чтобы запустить коллекцию.

Классная альтернатива – выбрать меню Runner в нижней части интерфейса Postman и перетащить коллекцию, которую нужно запустить, в окно Test Runner!

Результаты и отчеты

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

Окно Run results детально раскрывает каждый тест: тело запроса, заголовки, тело ответа.

С другой стороны, я небольшая поклонница опции Export Results (экспорт результатов) в Postman. Там лишь указывается, прошел тест или упал, хотя детализацию можно выгрузить в JSON.

Test Summary – обзор результатов теста без особых подробностей.

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

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

При прогоне тестов по расписанию на почту придет уведомление, если произошли падения, и можно настроить прогон как угодно. Здорово, правда?

Выбрав коллекцию для запуска, используйте Collection Runner для настройки расписания и частоты прогона, к примеру, с понедельника по пятницу в 8 утра. Как-то раз мне здорово помогла настройка частоты прогона – к утреннему скрам-созвону у меня был на руках готовый отчет. Вы тоже можете выбрать частоту, которая лучше соответствует ожиданиям ваших заинтересованных лиц. Скажем, можно указать день ревью спринта, чтобы иметь возможность поделиться информацией о здоровье API. Более того, Advanced Settings в настройках расписания позволяют задавать задержки между запросами и пробовать повторно, если прогон упал. Это будет полезным для многих тестировщиков.

Когда расписание настроено, его можно увидеть во вкладке Runs на странице информации о коллекции. Если нажать кнопку View, можно увидеть результаты конкретного прогона или запустить коллекцию вручную.

Давайте проверим, пришло ли мне письмо (в случае падений), и посмотрим на результаты на странице Schedule. Результаты гласят, что API здоровы, а также сообщают о времени ответа.

Интересный факт: для настройки расписания и отслеживания URL-эндпойнты должны быть публично доступными. Эндпойнты на localhost использовать нельзя.

Способ 3: отслеживание коллекции в Postman

Выше мы настроили запуск коллекции по расписанию и просмотрели результаты в интерфейсе Schedule. Возможно, у вас появился вопрос, что значит отслеживание, и чем оно отличается от настройки расписания?

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

Выберите Monitors на левой панели рабочего пространства и нажмите Create Monitor.

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

Примечание: при использовании мониторов нельзя наследовать глобальные переменные – вместо этого надо передавать локальную.

В этом примере я выбрала частоту прогона «Каждый час».

Посмотрим на результаты. Несколько прогонов упали – упавшие тесты показали, что время ответа в одном из запросов превышает ожидаемое. Это может указывать на отклонения в поведении конечных точек API.

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

Интересный факт: Мониторы могут интегрироваться и передавать результаты в ряд приложений, включая канал Slack. Вам не придется все время заглядывать в интерфейс Postman.

Способ 4: ручной запуск тестов из командной строки с использованием Postman CLI

Postman CLI (интерфейс командной строки) позволяет запускать любую коллекцию через командную строку. Очень удобно для решений CI/CD.

В окне Collection Runner выберите Automate Runs via Postman CLI. Теперь вы сможете загрузить Postman CLI через cURL.

Загрузив CLI на Mac с чипом Apple, вы получите результаты на изображении ниже. Сверьтесь с инструкциями по установке Postman CLI для других устройств.

В Collection Runner сгенерируйте ключ API и скопируйте команду, чтобы запустить коллекцию из командной строки.

Примечание: Храните ключ API в безопасном месте. Не кодируйте его жестко.

Результат будет выглядеть, как на изображении ниже.

Интересный факт: Postman CLI может также запускать локально экспортированные коллекции. Однако они потеряют связь с родительской коллекцией в интерфейсе. Для изменения порядка запуска есть ряд различных CLI-флагов.

Способ 5: ручной запуск коллекций при помощи Newman, и красивые HTML-отчеты

Newman – это инструмент запуска коллекций из командной строки с открытым исходным кодом. Он позволяет запускать коллекции Postman в CI / CD. Выбирайте между Postman CLI и Newman, руководствуясь нуждами проекта.

Лично я предпочитаю Newman, так как там есть плагин HTML Reporter, создающий внушительную HTML-отчетность. Такой отчет можно генерировать для каждой коллекции, и это отличный способ продемонстрировать результаты тестирования API заинтересованным лицам. Разберемся с этим подробнее.

Скачайте Newman на свое устройство при помощи команды:

npm install -g newman

Экспортируйте коллекцию из Postman. Экспортировать также нужно любые переменные окружений. В Newman установите плагин newman-reporter-htmlextra - npm.

Давайте посмотрим, как прогнать коллекцию Postman Demo и посмотреть результаты. Как уже говорилось выше, начните с экспорта коллекции и связанных с ней переменных окружения. Сохраните экспортированные файлы в папку.

Помните, что Newman нужно запускать из того же расположения, где находится коллекция Postman.

newman run collectionName.json -r htmlextra

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

Этот отчет можно генерировать через Newman в CI/CD, но я приберегу это для другой статьи, посвященной именно Newman и его отчетности. Сейчас поговорим о Postman CLI и GitHub Actions для CI/CD.

Способ 6: запуск коллекций при помощи Postman CLI и GitHub Actions

Если ваша компания пользуется CI/CD, вам не нужно говорить об их преимуществах. Вы, возможно, также заметили, как CI/CD помогают инженеру качества эффективнее работать в гибком окружении.

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

Тестировщику не помешает погрузиться в CI/CD и научиться запускать тесты в пайплайне. Postman очень дружелюбно интегрируется с CI/CD разных поставщиков, но в этой статье я ограничусь GitHub Actions.

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

Интеграция Postman с GitHub

Перейдите на домашний экран интерфейса Postman и выберите Integrations.

Выберите GitHub.

Примечание: В GitHub два типа токенов доступа: классический и точный. Классический токен дает доступ ко всем репозиториям этого профиля, а точный дает возможность выбирать, к каким репозиториям предоставить доступ. Грубо говоря, при классическом токене пользователь сможет увидеть все репозитории из списка, а при точном – только выбранные для этого токена.

В окне ниже вы выбираете имя для интеграции, чтобы позднее на нее можно было легко сослаться. Затем выберите рабочую область и коллекцию. И, наконец, выберите репозиторий из списка GitHub. И все! Наша интеграция Demo_Postman_GitHubActions добавлена.

Результат интеграции можно проверить, взглянув на репозиторий. В нем должна появиться ваша папка и коллекция. Теперь любые изменения в коллекции внутри Postman будут загружаться автоматически. Отличный способ для резервного копирования вашей коллекции.

После этого проверьте копию, изменив свои тесты, а затем взглянув, есть ли в репозитории новый коммит.

Я добавила в проверку Postman дополнительную строку, и могу удостовериться, что в GitHub-репозитории она тоже изменилась.

Интеграция Postman с GitHub Actions

Теперь, когда мы синхронизировали коллекцию Postman с GitHub, мы можем добавить эти тесты в GitHub Actions. Когда мы это сделаем, коллекция будет запускаться в пайплайне каждый раз, когда в желаемую ветку поступит пуш.

В Collection Runner выберите Postman CLI, а затем Configure CI / CD.

1. Выберите GitHub Actions и сгенерируйте API-ключ. Ключ, сгенерированный в Postman, можно хранить в секретах репозитория GitHub и передавать при запуске, а не кодировать его намертво в скрипте запуска.

2. Скопируйте конфигурационный файл для GitHub Actions и добавьте его, как yaml-файл для действия в репозитории GitHub. Автоматически сгенерированный шаблонный yaml-файл показан ниже. Этот код нужно скопировать и вставить в yaml-файл в папке  .github/workflows.

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

Конфигурация запустилась, и результаты можно посмотреть во вкладке Actions репозитория.

Прогоны также можно увидеть во вкладке Runs коллекции.

Можно также воспользоваться синтаксисом GitHub Actions, чтобы тонко настроить прогон, задавая ему различные конфигурации. К примеру, можно установить количество итераций.

Примечание: помните – храните секретную информацию вроде API-ключа Postman в секретах репозитория GitHub.

Заключение

Надеюсь, вам понравился аттракцион «Запусти коллекцию Postman всеми способами, от базового до продвинутого».

Обсудить в форуме