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

Alexander Kuvshinov
Jan 9 · 7 min read

В предыдущей статье была затронута тема менеджмента коллекций, как лучше всё разложить по полочкам и какие виды коллекций можно создать. Также коснулись темы импорта и экспорта. Эта статья расскажет вам, как сделать предустановки для запросов, как менять окружения, на которые будут отправляться запросы. Рассмотрим способ предавторизации перед запросом, а также попробуем разобраться с инкрементом значений в теле запроса.

Смена окружений с помощью переменных

Обычно у проекта есть несколько окружений, как минимум dev + production, в лучшем случае — больше. И существуют ситуации, когда API следует протестировать на нескольких окружениях, но есть ли смысл создавать коллекции под каждое окружение? В случае с Postman — нет, так как там существует поддержка окружений (environments).

Чтобы использовать окружения, следует каждое из них настроить. Например, есть production окружение (я буду использовать открытое API от разработчиков Postman — Postman Echo https://postman-echo.com) и для настройки нужно выполнить следующие шаги:

  • Во-первых, нажать на иконку шестеренки в правом верхнем углу интерфейса клиента.
Image for post
Image for post
  • Далее нужно создать окружение кликнув на кнопку “Add” (или если никаких окружений ещё не добавлено, кликнуть на надпись “Create an environment”)
  • На экране добавления окружения следует назвать новое окружение
Image for post
Image for post
1) Это как будет называться само окружение, при выборе его в правом верхнем углу в выпадающем меню 2) Как будет в строке URL запроса вызываться нужное окружение 3) Ссылка на API нужного окружения.
  • Нажать на кнопку “Add”

Готово, окружение создано. Чтобы его использовать, необходимо иметь уже готовую коллекцию с заполненными запросами. Покажу всё на той же коллекции запросов к API Postman-Echo.

  • Открыть коллекцию
Image for post
Image for post
Скачать коллекцию себе можно по ссылке: https://docs.postman-echo.com/?version=latest справа вверху нажав на оранжевую кнопку “Run in Postman”)
  • Выбрать любой из запросов. Пусть это будет “GET request” из папки “Request Methods”
  • В правом верхнем углу выбрать нужное окружение
Image for post
Image for post
(на Postman-Echo нет тестового окружения в открытом доступе, поэтому окружение “QA” в списке для наглядности)
  • После выбора окружения следует указать в URL запроса переменную, которую мы указывали при создании окружения. (Под цифрой “2”) А именно {{prod}} через двойные фигурные скобки.
Image for post
Image for post
  • Выполнив запрос кнопкой “Send”, можно убедиться, что окружение настроено правильно и приходит верный ответ.
Image for post
Image for post

Также можно установить любое другое предустановленное окружение (Development, QA и т.д), нужно только выбрать его в правом верхнем выпадающем меню и изменить переменную, которая будет подставлять нужный Base URL.

Установка авторизации перед запросом

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

Представим, есть запрос на получение информации о пользователе. Сам запрос представляет из себя схему GET->URL без всяких Params, в которых иногда можно прописывать Username и Password. В нашем случае в “Params” эти переменные отсутствуют. Залогиниться в таком случае поможет вкладка “Authorization”.

Image for post
Image for post

При переключении на эту вкладку сразу видно, какой тип авторизации будет использован. В основном логин происходит либо по Token, либо по связке Username — Password (что в итоге тоже приводит к получению токена, но архитектура API может работать по-разному). В примере авторизация будет успешной по связке Username — Password. В левой части окна нужно выбрать тип “Basic Auth” и в правой части указать валидные Username и Password. После ввода этих данных и нажатия на кнопку “Preview Request”, получившийся token подставится во вкладку Headers и будет доступен. После этого, можно отсылать запрос и получить информацию о пользователе.

Image for post
Image for post

Теперь во всех запросах этой коллекции будет предустановлен полученный token при предавторизации.

Рассмотрим вид авторизации по токену. Он мало чем отличается от предыдущего метода, но для него нам предварительно понадобится получить токен пользователя через отдельный Login запрос.

- Выполнить запрос Login для получения токена

Image for post
Image for post

Теперь в любом другом запросе, где нужно, чтобы пользователь был изначально залогинен, во вкладке Authorization нужно выбрать тип авторизации — bearer token, ну а справа ввести тот токен, который был получен в запросе авторизации.

Image for post
Image for post

Запрос на авторизацию так же будет происходить перед выполнением основного запроса, как и в случае с введенными Username + Password. Остальные типы авторизации работают примерно по такому же сценарию.

Инкремент значений в теле запроса

Есть задача: создать кучу аккаунтов, но разных, чтобы не повторялась почта пользователя. Как сделать так, чтобы вручную каждый запрос не редактировать под свою задачу, а за один прогон сразу создать 10 аккаунтов с разной почтой? В этом поможет такая функциональность Postman, как Collection Runner, который из таблицы .CSV будет брать заранее прописанные данные.

В примере разберу запрос из коллекции Postman-echo “POST Raw Text” из папки “Request Methods” где нужно отправить в запросе POST текст, который вернётся в ответе от сервера вместе с другой информацией о создании записи.

  • Вынесем нужный запрос в отдельную коллекцию, которую я назвал “Effective”:
Image for post
Image for post
  • После этого, нужно создать .CSV файл. По сути, можно сделать это через google.docs или старый добрый Excel. В первой ячейке столбца нужно написать ту переменную, которую мы будем передавать в body запроса (об этом позже) и далее нужно указать значения, которые нужно подставлять при каждом следующем запросе. Если это 10 e-mail адресов, указывайте 10 разных e-mail адресов, если цифры — тогда цифры и так далее. Я указываю в первой строке название переменной “Effective”, и ниже идут 10 значений, которые будут подставляться по очереди. В каждой итерации запроса — новое значение для подстановки:
Image for post
Image for post
  • Сохранить документ как .CSV
Image for post
Image for post
  • Проверить запрос на правильность. Отправить неотредактированный запрос из коллекции, который мы вынесли отдельно. Убедиться, что ответ приходит тот, который нужен.
Image for post
Image for post
В ответе находится тот же самый текст, который мы передавали. Значит всё отработало верно.
  • После этого, во вкладке “raw”, вместо дефолтного текста нужно подставить переменную {{…}} такого вида. В моём случае эта переменная будет {{Effective}}, т.к. в таблице .CSV первая строчка в столбце называется именно так. Помимо этого, нужно в формате данных указать JSON (либо на вкладке headers указать “content-type: application/json” вместо “content-type: text/plain”) + после этого нужно сохранить измененный запрос кнопкой “Save”.
Image for post
Image for post
  • Далее нужно выбрать свою коллекцию: в правой части нажать на кнопку “>” (1) и нажать на кнопку “Run” (2)
Image for post
Image for post
  • Откроется Postman Collection Runner. На экране раннера в поле “Data” нужно выбрать тот самый .CSV файл, который был создан ранее. При этом количество итераций автоматически изменится на то количество строк, которое есть в документе. (Первая строка не берётся в расчёт, т.к. это название переменной, и только после неё идут значения для подстановки). Также можно указать задержку (Delay) между запросами, если это требуется.
Image for post
Image for post
  • Нажать на кнопку “Run *collection name*”
Image for post
Image for post

Если всё сделать верно, все 10 итераций пройдут успешно. Тут можно добавить, что количество итераций, если выбирать их вручную, должно быть равно количеству строк в .CSV документе, иначе прогон не запустится. Открыв Request Body можно увидеть, что все body в запросах были разными, следовательно один запрос был отправлен много раз с разными данными. Также можно добавить невалидные данные для негативных проверок, т.е. вместо условного e-mail указать символы, текст и т.д. и посмотреть, как сервер отреагирует на данные, которые он не ожидает увидеть. Это можно использовать в большом количестве ситуаций, всё зависит от вашего настроя и желания.

Спасибо за прочтение статьи. Рекомендую ознакомиться с предыдущими статьями на тему Postman:

Я надеюсь, эти статьи помогут тебе в дальнейшем развитии в тестировании API. Успехов!

Если вам нужно разработать качественное мобильное приложение или веб-сервис, смело обращайтесь к нам в Effective, мы готовы сотрудничать с вами в любом виде, как на проекте целиком так и на аутстаф — contact@effective.band

Image for post
Image for post

Effective Developers

Collection of posts from Effective engineers.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store