Фичи Postman, которые облегчат жизнь тестировщика: пошаговая инструкция с видео

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

Изначально я ограничивалась базовыми функциями Postman: отправкой запросов и созданием коллекций. Это помогало в работе, но не так уж сильно ускоряло процессы. Когда работаешь в бешеном ритме, появляется миллион вкладок не только в браузере, но и в Postman. А когда у тебя множество запросов, которые еще нужно на три разных энвайронмента продублировать, — получается хаос.

С опытом начинаешь искать варианты, как можно использовать свое время эффективнее. Один из таких вариантов – посетить курсы тестировщиков и на порядок повысить свои знания. Как раз в такой период мне выпала возможность по-другому взглянуть на функционал уже привычного мне инструмента.

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

Для начала — небольшой дисклеймер. На моем проекте не было как таковой документации. Чтобы узнать хедеры, параметры, контент-тайп и тело запроса, приходилось идти на UI и добывать эти данные через консоль. Часто требовалось писать запрос для саб-воркфлоу, который вызывается в теле основного запроса, то есть непрямой запрос, который можно увидеть в консоле.

Мне Postman давал возможность, условно говоря, подготовить ‎«ингредиенты» для тестирования API.

Чтобы исключить вероятность ошибки в коде/при составлении запроса/ошибки компиляции, я использовала Postman для отправки запроса, отсекая лишние погрешности. Он копирует поведение браузера, то есть не нужно отвечать за то, что происходит под капотом при отправке запроса. И только после всех этих манипуляций можно было использовать «‎ингредиенты» для создания запроса, на респонз которого будут писаться автотесты.

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

Шаг первый: настраиваем логирование запросов через Postman

DevTools — очень удобный инструмент, но мы хотим, чтобы отправленные запросы не были потеряны в процессе исследования ресурса. Что для этого нужно? Установленный на локальной машине Postman и установленное в браузере расширение. После того, как указанные тулзовины подготовлены в браузере и в самом Postman, включаем прокси-сервер для логирования запросов, и можно возвращаться к сайту, который нас интересует.

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

Ниже вы увидите полное флоу — от подключения прокси-сервера до момента, когда запросы появятся в History-табке в самом Postman. 

Чем это может быть полезно:

• создавать коллекций запросов;
• отслеживать последовательность запросов по созданию сущностей (это можно будет использовать для одной из фич Postman);
• собирать информацию по запросам.

Шаг второй: создаем коллекции с end-to-end flow

Исследовав ресурс, можно вернуться к Postman и отключить прокси-сервер. Теперь, имея на компьютере сохранившееся запросы, можно проделать с ними некоторые манипуляции.

Очень удобно, что все POST-, PUT-, PATCH-запросы уже сохраняются с телом запроса и его исходными конфигурациями. Если ваш ресурс не требует особенных манипуляций с авторизацией, то по умолчанию вы сможете воспроизвести все запросы, которые вызываются на UI и были собраны прокси сервером через Postman. Таким образом можно делать своего рода карту end-to-end flow для отдельных фич. Из History сохраняем запросы в коллекции, группируя их удобным для себя образом.

Обратите внимание на курсы тестировщиков от наших друзей школы Hillel и Powercode. Опытные специалисты расскажут вам простым языком о сложных механизмах тестирования.

Шаг третий: добавляем авторизацию

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

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

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

Шаг четвертый: добавляем переменные сред

Сейчас я могу совершать операции в Postman, независимо от браузера и использовать только API. Теперь мне хотелось бы отправлять запросы на разные энвайронменты (допустим у меня их два: dev и QA).

В Postman предусмотрена возможность создания переменных для различных уровней рабочего пространства. Для этого я делаю себе пространство переменных (QA), в котором создаю переменную test.

Можно сразу создать переменную и засетить в нее нужное значение. Также в созданную переменную можно задать значение, используя выделение. Таким образом для одной переменной в разных энвах будут существовать разные значения. Теперь нам не нужно модифицировать или дублировать запросы для разных виртуальных сред:

Шаг пятый: тестируем API

Теперь у нас есть все для того, чтобы вручную отправлять запросы на разные энвы. Можно переходить к тестированию API. Postman дает возможность тестировать запросы напрямую. Вот как это выглядит:

Шаг шестой: создаем тестовые сущности и проводим end-to-end тестирование с Postman

Имея набор тестов для создания сущности (аккаунта, продажи и так далее), можно создавать тестовые сущности и тестировать разные энвы, не переключаясь на другие инструменты.

В Postman есть интересная фича — Test Runner. С ее помощью можно отправлять запросы в различной последовательности (по умолчанию они отправляются последовательно) и манипулировать тестовыми данными, количеством запросов и всем, чем необходимо:

С таким подходом можно проводить API-тестирование с использованием Postman и готовить тестовые сущности для мануального тестирования приложения.

А что еще полезного?

• У Postman есть удобная консоль, где подробно описываются хедеры, есть тело запроса и данные о сети.
• Инструмент позволяет сразу сохранять респонз в JSON-файл, который удобно прикреплять к баг-репортам.
• В Test Runner есть возможность передавать значение от предыдущих запросов еще не отправленным, используя pre-request-script.

Обладая user-friendly-интерфейсом, крутым функционалом и понятной документацией, Postman может стать очень мощным инструментом для разработчиков.

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

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

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

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

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