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

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

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

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

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

• Во-первых, нажать на иконку шестеренки в правом верхнем углу интерфейса клиента.

• Далее нужно создать окружение кликнув на кнопку “Add” (или если никаких окружений ещё не добавлено, кликнуть на надпись “Create an environment”)

• На экране добавления окружения следует назвать новое окружение

1) Это как будет называться само окружение, при выборе его в правом верхнем углу в выпадающем меню 2) Как будет в строке URL запроса вызываться нужное окружение 3) Ссылка на API нужного окружения.

• Нажать на кнопку “Add”

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

• Открыть коллекцию

Скачать коллекцию себе можно по ссылке: https://docs.postman-echo.com/?version=latest справа вверху нажав на оранжевую кнопку “Run in Postman”)

• Выбрать любой из запросов. Пусть это будет “GET request” из папки “Request Methods”
• В правом верхнем углу выбрать нужное окружение

(на Postman-Echo нет тестового окружения в открытом доступе, поэтому окружение “QA” в списке для наглядности)

• После выбора окружения следует указать в URL запроса переменную, которую мы указывали при создании окружения. (Под цифрой “2”) А именно {{prod}} через двойные фигурные скобки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Вынесем нужный запрос в отдельную коллекцию, которую я назвал “Effective”:

• После этого, нужно создать .CSV файл. По сути, можно сделать это через google.docs или старый добрый Excel. В первой ячейке столбца нужно написать ту переменную, которую мы будем передавать в body запроса (об этом позже) и далее нужно указать значения, которые нужно подставлять при каждом следующем запросе. Если это 10 e-mail адресов, указывайте 10 разных e-mail адресов, если цифры — тогда цифры и так далее. Я указываю в первой строке название переменной “Effective”, и ниже идут 10 значений, которые будут подставляться по очереди. В каждой итерации запроса — новое значение для подстановки:

• Сохранить документ как .CSV

• Проверить запрос на правильность. Отправить неотредактированный запрос из коллекции, который мы вынесли отдельно. Убедиться, что ответ приходит тот, который нужен.

В ответе находится тот же самый текст, который мы передавали. Значит всё отработало верно.

• После этого, во вкладке “raw”, вместо дефолтного текста нужно подставить переменную {{…}} такого вида. В моём случае эта переменная будет {{Effective}}, т.к. в таблице .CSV первая строчка в столбце называется именно так. Помимо этого, нужно в формате данных указать JSON (либо на вкладке headers указать “content-type: application/json” вместо “content-type: text/plain”) + после этого нужно сохранить измененный запрос кнопкой “Save”.

• Далее нужно выбрать свою коллекцию: в правой части нажать на кнопку “>” (1) и нажать на кнопку “Run” (2)

• Откроется Postman Collection Runner. На экране раннера в поле “Data” нужно выбрать тот самый .CSV файл, который был создан ранее. При этом количество итераций автоматически изменится на то количество строк, которое есть в документе. (Первая строка не берётся в расчёт, т.к. это название переменной, и только после неё идут значения для подстановки). Также можно указать задержку (Delay) между запросами, если это требуется.

• Нажать на кнопку “Run *collection name*”

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

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

• Postman — как инструмент тестирования API https://medium.com/effective-developers/6c0f76358cf2
• Postman — менеджмент, структурирование, импорт и экспорт коллекций https://medium.com/effective-developers/125c6de936d7

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

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