Postman что это

29.08.202228.08.2022 admin 0 Комментариев

Postman что это

Postman — как инструмент тестирования API

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

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

Для чего нужен Postman?

Postman предназначен для проверки запросов с клиента на сервер и получения ответа от бэкенда. Можно описать общение Postman с бэкендом в виде диалога:

Postman: “Дай мне информацию по балансу именно этого пользователя”
Backend: “Да, конечно, запрос правильный, получи информацию по балансу этого пользователя”

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

Postman: “Дай мне информацию по балансу именно этого пользователя”
Backend: “Кто я вообще?”

Postman: “Дай мне информацию по балансу именно этого пользователя”
Backend: “Пользователь не найден.”

Описанные выше ответы от бэкенда имеют свой код ошибки, которые приходят в ответе.

В первом случае — это ошибка с кодом 500 (Internal Server Error) внутренняя ошибка сервера, которая говорит о том, что сервер столкнулся с неожиданным условием, которое помешало ему выполнить запрос.

Во втором — 404 ошибка (Not Found) код ответа HTTP о том, что сервер не может найти данные по запросу, полученному от клиента.

Именно для этого и предназначен Postman — для проверки запросов клиент → сервер по документации, чтобы убедиться, что всё работает на стороне бэкенда.

Как начать?

Для начала — нужно скачать клиентское приложение с официального сайта — https://www.getpostman.com/.

Как пользоваться?

Итак, есть документация, есть Postman, коллекция создана. Что дальше?

Все виды документации по API выглядят примерно одинаково. В любом из видов можно увидеть какой метод нужно использовать, какой URL, какие body, params headers и так далее.

Всё готово, можно отправить первый запрос! Пример запроса будет показан на запросе “GET request” из общедоступной документации postman echo. Метод GET нужен для получения какой-либо информации от сервера.

В данном примере через URL уже переданы параметры запроса, а именно: “foo1=bar1&foo2=bar2”. При вставке URL в поле для ввода URL, автоматически подставляются параметры запроса в вкладку “Params”:

После того, как выбран метод, указан URL и параметры, можно отправить запрос на сервер. После нажатия кнопки “Send” в параметре ответа появляется ответ от сервера.

Метод работает, данные приходят верные, валидные, всё получилось.

Рассмотрим другой метод: POST, который нужен для передачи каких-либо данных с клиента на сервер.
Для данного типа запросов можно воспользоваться https://jsonplaceholder.typicode.com/posts в качестве URL запроса. Это открытый сервис, который можно использовать для имитации работы сервера.

Всё так же, как и при предыдущем методе, только меняется немного параметр запроса:

“title”: “First POST request”,

“body”: “I hope, it’s gonna be work”,

Должно всё выглядеть следующим образом:

В ответе должен прийти текст, который был отправлен в текстовом редакторе из Body, к которому добавится id новой записи, которая была создана на сервере. Также код “201 Created” подтверждает то, что новая запись была создана.

В этой статье были рассмотрены два самых популярных запроса при тестировании API. Метод GET — получить что-либо с сервера, метод POST — отправить что-либо на сервер и увидеть, что данные были отправлены и приняты. Все остальные методы работают по похожему принципу, главное — внимательно читать документацию и всегда указывать нужные Params, Body, URL и метод, которые нужны для успешного запроса. Спасибо за внимание!

В следующей статье будет рассмотрен менеджмент, структурирование, импорт и экспорт коллекций и запросов.

Источник

Postman

Postman — это HTTP-клиент для тестирования API. HTTP-клиенты тестируют отправку запросов с клиента на сервер и получение ответа от сервера.

API (Application Programming Interface) — это интерфейс для обмена данными с сервера между двумя приложениями или компонентами ПО. Тестировщикам Postman помогает в проектировании дизайна API и создании mock-серверов (имитаторов работы приложения). Например, с помощью Postman можно протестировать, как API регистрирует нового пользователя приложения, как добавляет и удаляет данные о нем на сервере.

Использование Postman

С помощью Postman тестировщик может:

Для работы с серверами программа использует протокол HTTP. Тестировщик отправляет тестовые запросы от клиента на сервер и получает ответ, есть ли ошибка в работе API.

Postman доступен в виде приложения для Windows, Linux и macOS, а также в web-интерфейсе (для его работы нужно установить программу Postman Desktop Agent). Вот как выглядит работа с коллекциями запросов:

Коллекция — это файл проекта со связанными запросами. Обычно запросы для тестирования одного API описывают в одной коллекции. Внутри коллекции запросы можно объединить в папки, например по разным версиям API или тестируемым элементам приложения.

В Postman есть инструмент Collection Runner. Он позволяет одновременно выполнять все запросы из коллекции или папки с нужным количеством итераций и в нужном порядке. После выполнения всех запросов Collection Runner выдает отчет с пометками об успешности запросов и кодами статуса.

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

Методы Postman

Чаще всего в работе API используется архитектура RESTful. В этой архитектуре есть четыре стандартных метода запросов к серверам по HTTP:

В Postman можно протестировать запросы по каждому методу: его нужно выбрать на вкладке запроса. После отправки запроса тестировщик получает ответ в виде кода статуса HTTP. Всего таких статусов 40 в пяти категориях; каждый код помогает понять, правильно ли работает API.

Источник

Как пользоваться программой Postman

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

Скачать ее можно с официального сайта – есть дистрибутивы для Windows, macOS и Linux. На последней платформе есть возможность установки утилиты напрямую из Центра приложений. В любом случае использование начинается с регистрации бесплатного аккаунта.

Как тестировать API

Тестирование интерфейса API проводится путем анализа точности выходных данных в зависимости от подаваемых при входном запросе. Этим и занимается Postman: он составляет и отправляет их на указанные URL, получает обратно и сохраняет в базе данных. При желании возможно сохранение типовых запросов в коллекции (для быстрого доступа) и создание для них разного окружения.

Интерфейс приложения Postman

Главное окно программы разделено на четыре области. Разделение на блоки идет по функционалу, что заметно упрощает настройку и управление. Если опыта работы с такими утилитами нет, рекомендуется не трогать непонятные пункты, а пользоваться только простыми (их мы и рассмотрим).

Выполнение запроса

В нижней части страницы появится код страницы (HTML). Здесь имеется несколько вкладок:

На первой вкладке, где отображается тело запроса, есть выбор нескольких вариантов отображения. Так, Pretty интересна для получения JSON-данных – программа отформатирует их в достаточно удобном формате. Если выбрать режим Raw, информация будет представлена «как есть», без каких-либо изменений. Вкладка Preview отображает сайт в том виде, в котором он открывается в браузере.

Передача параметров в Postman

В программу встроен собственный сервис API, который и используется для тестирования внешних ресурсов. Чтобы обратиться к нему, следует кликнуть на «плюсик», выбрать из выпадающего списка тип запроса GET, а вместо домена вставить ссылку на сервис https://postman-echo.com/get.

Затем нужно открыть вкладку Params и в разделе Query Params под строкой Key внести название отправляемого параметра. Следом под строкой Value нужно написать еще одно значение. Количество не ограничено – пользователь вносит столько параметров, сколько ему нужно для тестирования конкретного API.

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

Передача параметров формы и заголовков

В отличие от GET, запрос POST передается не в ссылке на сайт, а в теле запроса. Чтобы проверить работоспособность программы, используется обращение к адресу https://postman-echo.com/post. Во время настройки на вкладке Body нужно включить режим form-data, затем внести схожие параметры и нажать на кнопку Send.

Если взаимодействие по API требует передачи токенов авторизации, понадобится привлечь к этому HTTP-заголовки. Такой формат работы используется, например, в движке Xenforo, написанном на PHP для развертывания форумов. Для передачи в заголовке какой-либо информации нужно зайти на вкладку Headers и добавить любое имя со значением (на выбор пользователя). После отправки информации внизу окна будет отображен ответ сервера.

Передача файла в Postman

Программа Postman позволяет отправлять файлы, а не только текстовые данные, как в приведенных выше примерах. Чтобы сделать это, достаточно перейти на вкладку Body, зайти в раздел form-data и выбрать тип параметра File (вместо Text).

Затем следует нажать на кнопку Select File и выбрать отправляемый файл. После отправки данных на сервер он будет виден в секции files. Ничего сложного в процедуре нет, приведенная выше схема работает со всеми типами файлов.

Авторизация Basic Auth

Если на сайте используется защита с авторизацией по методу Basic Auth, программа Postman дает возможность проверить ее прохождение. В качестве примера обращение будет осуществляться по адресу https://postman-echo.com/basic-auth. Чтобы пройти проверку, понадобится отправить значение имени пользователя postman и пароль доступа password.

Далее в рабочей области надо открыть вкладку Authorization, в разделе Type выбрать значение Basic Auth и заполнить имя с паролем. Если процедура пройдена успешно, тестовый сервер вернет ответ authenticated: true.

История и коллекция запросов

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

Наиболее важные запросы рекомендуется сохранять в коллекции. Чтобы сделать это, достаточно нажать на кнопку New на верхней панели, выбрать пункт Collection и ввести название (на выбор пользователя). Теперь любой запрос будет добавлен в перечень нажатием на кнопку Create и, после заполнения всех данных, кнопку Save (до отправки на сервер).

Источник

Введение в Postman

“Разработка API сложна, Postman делает её лёгкой” © Postdot Technologies, Inc

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

В этой статье мы расскажем о Postman и попробуем написать свой первый скрипт.

Postman

Основное предназначение приложения — создание коллекций с запросами к вашему API. Любой разработчик или тестировщик, открыв коллекцию, сможет с лёгкостью разобраться в работе вашего сервиса. Ко всему прочему, Postman позволяет проектировать дизайн API и создавать на его основе Mock-сервер. Вашим разработчикам больше нет необходимости тратить время на создание «заглушек». Реализацию сервера и клиента можно запустить одновременно. Тестировщики могут писать тесты и производить автоматизированное тестирование прямо из Postman. А инструменты для автоматического документирования по описаниям из ваших коллекций сэкономят время на ещё одну «полезную фичу». Есть кое-что и для администраторов — авторы предусмотрели возможность создания коллекций для мониторинга сервисов.

Введение

1 — коллекция, 2 — папка, 3 — запрос

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

Collection

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

Folder

Папка — используется для объединения запросов в одну группу внутри коллекции. К примеру, вы можете создать папку для первой версии своего API — «v1», а внутри сгруппировать запросы по смыслу выполняемых действий — «Order & Checkout», «User profile» и т. п. Всё ограничивается лишь вашей фантазией и потребностями. Папка, как и коллекция может иметь свои скрипты, но не переменные.

Request

Запрос — основная составляющая коллекции, то ради чего все и затевалось. Запрос создается в конструкторе. Конструктор запросов это главное пространство, с которым вам придётся работать. Postman умеет выполнять запросы с помощью всех стандартных HTTP методов, все параметры запроса под вашим контролем. Вы с лёгкостью можете поменять или добавить необходимые вам заголовки, cookie, и тело запроса. У запроса есть свои скрипты. Обратите внимание на вкладки «Pre-request Script» и «Tests» среди параметров запроса. Они позволяют добавить скрипты перед выполнением запроса и после. Именно эти две возможности делают Postman мощным инструментом помогающим при разработке и тестировании.

1 — вкладки с запросами, 2 — URL и метод, 3 — параметры запроса, 4 — параметры ответа

Скрипты

«Postman Sandbox» это среда исполнения JavaScript доступная при написании «Pre-request Script» и «Tests» скриптов. «Pre-request Script» используется для проведения необходимых операций перед запросом, например, можно сделать запрос к другой системе и использовать результат его выполнения в основном запросе. «Tests» используется для написания тестов, проверки результатов, и при необходимости их сохранения в переменные.

Последовательность выполнения запроса (из оф. документации)

Помимо скриптов на уровне запроса, мы можем создавать скрипты на уровне папки, и, даже, на уровне коллекции. Они называются также — «Pre-request Script» и «Tests», но их отличие в том, что они будут выполняться перед каждым и после каждого запроса в папке, или, как вы могли догадаться, во всей коллекции.

Последовательность выполнения запроса со скриптами папок и коллекций (из оф. документации)

Переменные

Postman имеет несколько пространств и областей видимости для переменных:

Глобальные переменные и переменные окружения можно создать, если нажать на шестеренку в правом верхнем углу программы. Они существуют отдельно от коллекций. Переменные уровня коллекции создаются непосредственно при редактировании параметров коллекции, а локальные переменные из выполняемых скриптов. Также существуют переменные уровня данных, но они доступны только из Runner, о котором мы поговорим позже.

Приоритет пространств переменных (из оф. документации)

Особенностью переменных в Postman является то, что вы можете вставлять их в конструкторе запроса, в URL, в POST параметры, в Cookie, всюду, используя фигурные скобки в качестве плейсхолдера для подстановки.

<> и <> — переменные окружения DNS Checker будут заменены на значения во время выполнения запроса

Из скриптов переменные тоже доступны, но получить их поможет вызов стандартного метода встроенной библиотеки pm:

Collection Runner

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

После выполнения всех запросов формируется отчет, который покажет количество успешных и провальных проверок из скриптов «Tests».

Collection Runner

Console

Пользуйтесь консолью для отладки ваших скриптов, и просмотра дополнительной информации по запросам. Консоль работает, как во время запуска одного запроса, так и во время запуска пакета запросов через Runner. Чтобы её открыть, найдите иконку консоли в нижнем левом углу основного экрана приложения:

Практика

Так как создание коллекций и запросов в конструкторе не должно вызвать затруднений, практическую часть посвятим написанию скриптов, и рассмотрим как создать цепочку запросов с тестами. Перед началом создайте новую коллекцию, назовите её “Habra”, затем создайте новое окружение под названием «Habra.Env»

Шаг 1

Создайте новый запрос, в качестве URL укажите https://postman-echo.com/get?userId=777, а метод оставьте GET. Здесь и далее для простоты и удобства мы будем использовать echo-сервер любезно предоставленный разработчиками Postman. Сохраните запрос в коллекцию «Habra» и назовите “Get user id”, он будет имитировать получение идентификатора пользователя от сервера. Перейдите на вкладку «Tests» и напишите следующий код:

С помощью этого скрипта мы проверили статус и формат ответа, а также сохранили полученный из ответа идентификатор пользователя в переменную окружения для последующего использования в других запросах. Чтобы проверить работу нашего теста, запустите запрос. В панели информации об ответе, во вкладке «Tests» вы должны увидеть зелёный лейбл “PASS”, а рядом надпись “Status is ok, response is json”.

Шаг 2

Теперь давайте попробуем вставить идентификатор нашего пользователя в json запрос. Создайте новый запрос, в качестве URL укажите https://postman-echo.com/post, выберите метод POST, установите тип для тела запроса raw — application/json, а в само тело вставьте:

Сохраните запрос в нашу коллекцию, и назовите «Update username», он будет запрашивать импровизированную конечную точку для обновления username пользователя. Теперь при вызове запроса вместо <> система автоматически будет подставлять значение из переменной окружения. Давайте проверим, что это действительно так, и напишем небольшой тест для нашего нового запроса:

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

Шаг 3

Вы могли заметить, что два тестовых скрипта имеют одинаковую проверку формата и статуса:

Пока мы не зашли слишком далеко, давайте исправим эту ситуацию и перенесем эти тесты на уровень коллекции. Откройте редактирование нашей коллекции, и перенесите проверку формата и статуса во вкладку «Tests», а из запросов их можно удалить. Теперь эти проверки будут автоматически вызываться перед скриптами «Tests» для каждого запроса в коллекции. Таким образом мы избавились от копирования данной проверки в каждый запрос.

Шаг 4

Мы научились записывать и получать переменные окружения, настало время перейти к чему-то потяжелее. Давайте воспользуемся встроенной библиотекой tv4 (TinyValidator) и попробуем проверить правильность схемы json объекта. Создайте новый запрос, в качестве URL используйте https://postman-echo.com/post, установите метод в значение POST, для тела запроса укажите raw — application/json, и вставьте в него:

После запуска запроса echo-сервер должен вернуть нам нашу json модель в качестве ответа в поле «data», таким образом мы имитируем работу реального сервера, который мог бы прислать нам информацию о профиле Боба. Модель готова, напишем тест, проверяющий правильность схемы:

Готово, мы провалидировали схему объекта profile. Запустите запрос и убедитесь, что тесты проходят.

Шаг 5

У нас получился небольшой путь из 3-х запросов и нескольких тестов. Настало время полностью его протестировать. Но перед этим, давайте внесем небольшую модификацию в наш первый запрос: замените значение “777” в URL на плейсхолдер “<>”, и через интерфейс добавьте в окружение «Habra.Env» переменную “newUserId” со значением “777”. Создайте файл users.json на своём компьютере и поместите туда следующий json массив:

Теперь запустим Runner. В качестве «Collection Folder» выберем «Habra». В качестве «Environment» поставим «Habra.Env». Количество итераций оставляем 0, а в поле «Data» выбираем наш файл users.json. По этому файлу «Collection Runner» поймет, что ему нужно совершить 4 итерации, и в каждой итерации он заменит значение переменной «newUserId» значением из массива в файле. Если указать количество итераций больше, чем количество элементов в массиве, то все последующие итерации будут происходить с последним значением из массива данных. В нашем случае после 4 итерации значение «newUserId» всегда будет равно 50000. Наш “Data” файл поможет пройти весь наш путь с разными newUserId, и убедиться, что независимо от пользователя все выполняется стабильно.

Запускаем наши тесты нажатием «Run Habra». Поздравляем вы успешно создали коллекцию и протестировали наш импровизированный путь с помощью автотестов!

Тестирование коллекции «Habra»

Теперь вы знаете, как создавать скрипты и вполне можете написать парочку тестов для своего проекта.

Отдельно хочу отметить, что в реальном проекте мы не держим все запросы в корне коллекции, а стараемся раскладывать их по папкам. Например, в папке «Requests» мы складываем все возможные запросы описывающие наш API, а тесты храним в отдельной папке «Tests». И когда нам нужно протестировать проект, в «Runner» запускаем только папочку «Tests».

Полезно знать

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

Установка и получение переменных

Тестирование или asserts

Создание запросов

Получение ответа для основного запроса

Ответ доступен только во вкладке “Tests”

Работа со встроенными библиотеками

Документация регламентирует наличие некоторого количества встроенных библиотек, среди которых — tv4 для валидации json, xml2js конвертер xml в json, crypto-js для работы с шифрованием, atob, btoa и др.

Некоторые из библиотек, например, как tv4 не требуют прямого подключения через require и доступны по имени сразу.

Получение информации о текущем скрипте

Управление последовательностью запросов из скрипта

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

После перехода на следующий запрос Postman возвращается к линейному последовательному выполнению запросов.

Создание глобального хелпера

В некоторых случаях вам захочется создать функции, которые должны быть доступны во всех запросах. Для этого в первом запросе в секции “Pre-request Script” напишите следующий код:

А в последующих скриптах пользуемся им так:

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

Заключение

Основные плюсы, которые подтолкнули нас к использованию Postman в своём проекте:

Среди минусов можно выделить:

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

P.S.:
Основной функционал Postman бесплатен и удовлетворяет ежедневным нуждам, но есть некоторые инструменты с рядом ограничений в бесплатной версии:

Источник

Основы Postman для самых маленьких

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

Расскажу, как с его помощью создавать простейшие автотесты и уменьшать объем рутины с помощью переменных.

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

Инструментов с аналогичным функционалом существует много. Я выбрала Postman, поскольку он самый популярный. Но у него есть и другие преимущества. Postman:

интуитивно-понятен и простой в использовании, не требует какой-то сложной настройки или знания языков программирования;

поддерживает разные API (REST, SOAP, GraphQL);

расширяется под любые нужды с помощью Postman API;

запускается на любых ОС;

поддерживает ручное и автоматизированное тестирование;

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

Тестировщику этот инструмент позволяет:

отправлять запросы и получать ответы;

сохранять запросы в папки и коллекции;

изменять параметры запросов;

изменять окружения (dev, test, production);

выполнять автотесты, используя Collections runner, в том числе по расписанию;

импортировать и экспортировать коллекции запросов и наборы тестов, чтобы обмениваться данными с коллегами.

Перейдем к сути.

Экспериментируем с запросом на обновление

Создадим самый простой запрос на обновление кампании.

Простейший запрос на обновление кампании

При его успешном выполнении мы получим ответ 200 OK.

Напишем самый простой автотест, который будет это проверять. Для этого в интерфейсе Postman переходим на вкладку Tests. Код с этой вкладки будет выполняться после получения ответа на запрос.

Код не обязательно писать с нуля. В Postman есть уже готовый список тестов для проверки API. Любой из них можно отредактировать под свои нужды для экономии времени.

Готовые скрипты (сниппеты) есть в списке справа. Там можно найти код для проверки всего ответа или его части, времени выполнения запроса и множества других вещей.

Список готовых скриптов справа

Сохраняем код и отправляем запрос.

Результат можно найти на вкладке Test Results. Мы видим:

Результат выполнения теста

Давайте проверим, что тест действительно работает. Изменим код ответа на 400.

Сохраним запрос еще раз запустим тест.

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

Ищем соответствующий сниппет и правим его под свою задачу:

Сохраняем и отправляем запрос. Видим, что тест выполнен успешно.

Как и в прошлом примере, мы можем проверить работоспособность теста, исправив искомую строку:

Искать строку можно не во всем теле ответа, а в конкретном поле. Для проверки, что название кампании присутствует именно в поле Name, отредактируем другой сниппет:

Для одного запроса можно создать несколько тестов. Например, так:

Здесь мы проверяем status code, содержание в теле ответа названия кампании и тот факт, что после обновления статус кампании “Draft”.

На вкладке Test Results мы увидим, что все три теста выполнены успешно:

Запуск автотестов с Collection runner

Collection runner запускает не отдельные тесты, а их коллекции.

Новую коллекцию можно создать с помощью значка + на закладке Collections (в каждой такой коллекции можно создать папку с тестами с помощью Add Folder).

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

Чтобы запустить Collection runner, нужно выбрать коллекцию и на открывшейся вкладке нажать Run. Запросы будут выполняться поочередно. После окончания выполнения можно увидеть все результаты:

Аналогично можно посмотреть тело и заголовок ответа. Но для этого необходимо включить логирование (включить галочку Save response перед запуском коллекции).

Также Postman умеет запускать коллекции по расписанию. Нажимаем на название коллекции, открываем меню Action и задаем расписание на вкладке Monitor collection.

Переменные в Postman

В ходе тестирования удобно использовать переменные.

Рандомных переменных в Postman много. Если при написании кода начать вводить парные фигурные скобки, Postman сам подскажет, какие из них доступны.

Подробнее про переменные можно почитать в документации к Postman.

Он выполняется успешно, кампания получает рандомное название.

Чтобы получать уникальные данные, точно так же можно вставлять переменные в header и URL.

Области видимости

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

Области видимости переменных в Postman

Поддерживаются следующие типы переменных:

Переменные коллекции доступны во всех запросах внутри одной коллекции.

Переменные окружения изменяются в зависимости от выбранного окружения.

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

Глобальные переменные не могут иметь дубликаты. А вот локальные переменные могут иметь одни и те же имена, но только если они находятся в разных окружениях. Если Postman встречается с двумя переменными с одинаковыми именами, высший приоритет будет у локальной переменной (она затрет глобальную).

Переменные окружения

Поговорим о переменных окружения. Они позволяют передавать данные из запроса в запрос внутри этого окружения.

Перед началом экспериментов создадим окружение. Для этого в левом меню надо выбрать Environments и нажать либо на плюсик, либо на Create a new environment. На открывшейся вкладке можно задать название окружения. Пусть это будет Environment token.

Зададим в окружении Environment token переменную varBearerToken. В качестве начального значения подставим наш токен. Остается в header запросов заменить значение токена на переменную.

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

Точно также можно выполнять наши запросы на разных стендах. Чтобы в каждом запросе вручную не изменять URL, можно прописать стенд-попеременную. Пусть это будет varStage со значением по умолчанию test.

Аналогично можно было бы прописать dev и другие стенды.

Остается добавить эту переменную в URL. Как и в случае с токеном, Postman будет ее подсвечивать, только если выбрано то окружение, в котором она задана.

Окружение со всеми переменными можно пошарить коллегам через экспорт в файл json. Они смогут открыть его на своем рабочем месте в Postman.

Передача данных между запросами

В предыдущем примере я создала переменную окружения varToken и в неё вручную приписала токен. Но вместо копирования токен можно получить в ответе на запрос авторизации и передать его в другие запросы.

Создадим новое окружение Environment Auth. Не будем на старте прописывать никаких переменных. Просто выберем это окружение и возьмем из списка сниппетов соответствующий скрипт. Прямо в нем объявим переменную varToken и присвоим ей значение токена (для этого парсим JSON ответа):

Для наглядности я добавила еще вывод переменных в консоль, чтобы видеть их значения.

Остается прописать переменную varToken в Header наших запросов на создание кампании.

Поскольку работаем мы внутри окружения Environment Auth, Postman о ней знает.

А теперь усложним пример. Допустим, мы хотим создать рекламную кампанию, выяснить ее ID, а затем обновить кампанию с этим ID.

Запускаем Collection runner и видим, что запросы работают.

Мы получили токен, передали его во все последующие запросы, получили ID кампании и передали его в запрос на обновление. После этого обновили.

Кстати, в окружении, которое мы создавали, все эти переменные будут указаны, вместе с текущими значениями:

Используя возможности Postman, обновление кампании можно выполнять по расписанию.

Переменные данных

В Collection runner можно использовать переменные данных.

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

Создаем файл с расширением csv или json. Postman поддерживает оба типа файлов, вопрос лишь в формате.

В файле csv в первой строке указывается название переменной или нескольких переменных через запятую. Далее на отдельных строках следуют значения (или несколько значений через запятую).

В файле json можно прописать то же самое, но в JSON-формате “ключ-значение”.

Чтобы добавить переменные в Collection runner, нужно нажать кнопку Select File и загрузить любой из этих файлов. Collection runner автоматически посчитает количество значений (и соответственно итераций тестов). Там же можно посмотреть названия и значения переменных, нажав на кнопку Preview Data.

Если запустить Collection runner, а потом проверить названия кампаний, мы увидим, что использованы значения из файлов.

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

Источник

Postman: как пользоваться программой для тестирования API

Бесплатный сервис позволяет писать тесты, поддерживает разные типы API.

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

Как пользоваться Postman

Скачайте бесплатную версию Postman с официального сайта. Приложение адаптировано для Windows, MacOS и Linux.

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

Интерфейс

Главное окно состоит из четырех рабочих блоков:

Как выполнить запрос

В Postman запросы — основная рабочая единица. Чтобы выполнить запрос, нажмите «+» и выберите его тип. Например: «основной — GET». После укажите URL в адресной строке и щелкните Send.

Как передавать параметры

Чтобы проверить передачу параметров, используйте онлайн-сервис postman-echo.

GET-параметры

Нажмите «+», чтобы создать новый запрос → в поле запроса пропишите https://postman-echo.com/get → метод GET.

GET-параметры указывают в разделе Params. Откройте этот раздел под строкой запроса и наберите название параметра в графе Key (например, Foo), а его значение — в Value (например, Bar). Теперь кликните Send и смотрите результат.

Параметры формы

Параметры формы передаются с помощью POST-запросов. Нажмите «+» → POST → в адресную строку добавьте https://postman-echo.com/post. В теле запроса (Body) выберите вкладку form-data и заполните необходимые поля → отправьте (Send).

Передача файла

Для этого в form-data поменяйте тип параметра с Text на File. Полученный ответ будет храниться в разделе Files.

Заголовки

Чтобы отправить данные в заголовке, перейдите в раздел Headers, затем введите сам заголовок и его значение.

Авторизация

Есть много методов и способов, чтобы зарегистрироваться и авторизоваться на сервере. Рассмотрим базовую схему авторизации. При такой схеме логин и пароль передаются в заголовке «Authorization» в незашифрованном виде. С помощью Postman можно убедиться, что протокол работает правильно и, главное, безопасно.

Поменяйте метод на GET. Откройте вкладку Authorization → Нажмите Type → Basic Auth. Введите имя пользователя — postman, пароль — password → Send. Если протокол авторизации работает корректно, сервер выдаст: authenticated: true.

Проверяем авторизацию Basic Auth

История запросов

Если некоторые запросы используете чаще других, необязательно раз за разом вводить новые данные. Можно воспользоваться списком в разделе History. Он хранит предыдущие запросы.

Коллекции запросов

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

Чтобы создать коллекцию: в разделе Collection нажмите «+» → дайте ей название → заполните запросами (Add request).

Как тестировать запросы

С помощью Postman можно отправлять запросы независимо от того, тестируете ли вы собственный API или интегрируетесь со сторонним. Запросы создают в конструкторе — главном рабочем пространстве программы. Вы можете проверить любые параметры — например, заголовки или cookie.

Запрос состоит из URL-адреса и HTTP-метода. Последний указывает тип действия, который запрашивается у API. Вот наиболее распространенные методы:

Например, если вы тестируете API онлайн-планировщика дел, можете использовать: GET-метод — чтобы получить текущий список задач; POS — чтобы создать новую задачу; PUT или PATCH — чтобы редактировать существующую; DELETE — чтобы удалить задачу.

GET-запросы

В качестве примера возьмем API:

Нажмите «+» → Выберите GET-запрос → Задайте URL-адрес https://jsonplaceholder.typicode.com/users → Send.

Если запрос выполнен корректно, в нижней панели появится надпись: «Status: 200 ОК».

POST-запросы

POST-запросы позволяют отправлять новую информацию. Например, данные о пользователе:

Кликните «+» → Выберите POST-запрос → Задайте URL-адрес https://jsonplaceholder.typicode.com/users → Перейдите в раздел Body → Выберите Raw > JSON → Введите данные пользователя → Send.

Если запрос выполнен корректно, вы увидите статус «201 Created».

Создание переменных окружения

Переменные окружения чаще используют, чтобы хранить части URL-адреса. Для работы с ними используют простой синтаксис. После того как создадите переменную, к ней можно обратиться через двойные фигурные скобки, например: <>. При этом появится автозаполнение: программа покажет вам все доступные переменные с таким именем.

Как создать переменную:

Чтобы воспользоваться переменной, в адресной строке откройте две фигурные скобки и наберите json. Вы увидите список доступных переменных, включая ту, которую мы только что создали: <>/posts — для списка постов, <>/users — чтобы получить список пользователей.

Подробнее о доступных методах и конечных точках для этого API смотрите на официальном сайте.

Как создать тесты в Postman

В Postman тесты нужны, чтобы определить ошибки в работе API и переписать неправильные фрагменты кода. Чтобы запустить тест, откройте запрос и перейдите в раздел Tests.

Введите следующий код:

Нажмите Send, чтобы Postman запустил тестовый сценарий. Выходные данные появятся на вкладке Tests Results. Если всё выполнено верно, будет написано:

Как запускать коллекции тестов

В Collection Runner

В разделе Collections найдите кнопку Run.

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

Установите значение iterations равным десяти и нажмите Send.

Откроется отчет, который можно экспортировать (Export Results).

В Newman

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

Источник

Как тестировать API, или Postman для чайников

Привет! Меня зовут Игорь Гросс, я руководитель проектов в Test IT — это такая система управления тестированием. В этом посте я расскажу об одном интересном инструменте тестировщика — Postman — а также о том, как с его помощью решать распространённый тип задач — тестирование API.

Что это вообще такое?

API — это Application Programming Interface, или программный интерфейс приложения, с помощью которого одна программа может взаимодействовать с другой. API позволяет слать информацию напрямую из одной программы в другую, минуя интерфейс взаимодействия с пользователем.

Как это работает? Представьте, что вы сидите в ресторане, выбираете блюдо в меню. Подходит официант, и вы делаете заказ. Официант передаёт ваш заказ на кухню, там происходит магия, и через некоторое время перед вами появляется готовое блюдо. API работает по такому же принципу — принимает ваш запрос, передаёт информацию системе, обрабатывает её и возвращает ответ.

Какие бывают? API может быть внутренним, частным — когда программные компоненты связаны между собой и используются внутри системы. А может быть открытым, публичным — в таком случае он позволяет внешним пользователям или другим программам получать информацию, которую можно интегрировать в свои приложения.

Чтобы программам общаться между собой, их API нужно построить по единому стандарту. Одним из них является REST — стандарт архитектуры взаимодействия приложений и сайтов, использующий протокол HTTP. Особенность REST в том, что сервер не запоминает состояние пользователя между запросами. Иными словами, идентификация пользователя (авторизационный токен) и все параметры выполнения операции передаются в каждом запросе. Этот подход настолько прост и удобен, что почти вытеснил все другие.

Как тестировать API?

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

Чтобы рассказать, как использовать Postman, напишем несколько тестов на базе реального проекта, используя для этого API системы управления тестированием Test IT.

Работа с запросами и отправка запросов в Postman

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

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

Создадим запрос на получение проектов. Назовём его соответственно: /api/v2/projects

По умолчанию открывается форма создания GET-запроса:

Для удобства мы указали на иллюстрации выше пункты, соответствующие порядку действий:

1. Выбираем тип запроса. Postman предлагает внушительный список, нам нужен GET.

2. Указываем URL запроса. Первая часть ссылки должна содержать адрес сервера, где развёрнута наша TMC. Мы используем публичное API Test IT, а при составлении запросов опираемся на Swagger-документацию. В нашем случае полная ссылка будет выглядеть так: https://testit.geekbrains.ru/api/v2/projects.

3. На вкладке параметров указываем ключи и значения запроса. Мы хотим получить только удалённые проекты, и API Test IT предоставляет нам такую возможность. Укажем в параметрах isDeleted=true.

4. Переходим на вкладку Authorization, указываем данные для идентификации пользователя. Postman поддерживает множество типов авторизации, параметры для каждого из них отличаются. Используем авторизацию по API Key, полученному из личного кабинета в Test IT.

Мы заполнили все необходимые данные. Теперь выполним запрос, нажав кнопку Send.

Видим, что запрос прошёл успешно: код 200, тело ответа, время ответа и сколько занимают полученные данные. Правда, в нашем случае тело ответа будет пустое, поскольку удалённых проектов у нас нет. Советуем в ключ isDeleted ставить значение true.

Отправляемый запрос или ответ мы можем сохранить с помощью меню справа:

Параметризация запросов, переменные окружения

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

В меню создания выбираем Environment

В ранее созданном запросе выделим в переменные два параметра — URL стенда, к которому мы обращаемся, и токен для авторизации. Назовём наше окружение Test Environment. Создаём две переменные url и token и укажем их значения. На скриншоте ниже их значения скрыты из соображений безопасности.

Сохраняем созданное окружение кнопкой Add. Мы всегда сможем вернуться и отредактировать окружение с помощью кнопки Manage Environments (шестерёнка в правом верхнем углу основного экрана).

Устанавливаем Test Environment в качестве текущего окружения: выбираем из выпадающего списка и вносим параметры в запрос. Переменные указываются в двух фигурных скобках. Postman подсказывает названия переменных окружения при вводе.

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

Запрос вновь прошёл успешно, значит, всё сделали правильно.

Теперь создадим другое окружение, с другими URL и token, и поменяем их с помощью переключения в выпадающем списке. Протестируем продукт на двух разных окружениях, используя одну коллекцию запросов.

Создание тестов в Postman

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

Уже в знакомом нам запросе находим вкладку Tests и переходим в неё.

Открывается окошко для написания кода на JavaScript. Postman предлагает множество готовых сниппетов, которые можно применить для тестирования API. Здесь можно валидировать коды и содержание ответов, парсить и сохранять значения в переменные окружения или глобальные переменные, проверять их соответствие заданным значениям и т.д. Подробнее о написании тестовых скриптов в Postman можно прочитать в документации или статье на Хабре.

Остановимся на создании простого тестового скрипта: проверим, что код ответа 200. Для этого используем готовый сниппет.

Postman автоматически добавил код на JS, который проверяет, что код ответа равен 200.

Помимо этого, напишем проверку. В списке, который мы получили в данном запросе, отсутствуют проекты с параметром isDeleted = false. Надо парсить ответ, в цикле проходить все объекты полученного массива и проверять, что isDeleted = true.

Вот какой код теста получился:

Мы написали в коде false, а не true, потому что у нас есть только созданные проекты, а удалённых нет. Если оставить true, тест будет провален. Если поменять значение на false — тест будет пройден. Отправим запрос и проверим, что тесты прошли. Результаты тестов и их названия отображаются на вкладке Test Results.

В тренировочном запросе два теста. Чтобы создать ещё один GET-запрос, данные для авторизации и проверку на код ответа 200 нужно продублировать. Чтобы сэкономить время, внесём эти данные на уровень всей коллекции.

Переходим в редактирование коллекции.

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

А на вкладку Tests перемещаем проверку, что код ответа равен 200.

В запросе убираем продублированную проверку, а на вкладке авторизации укажем «Inherit auth from parent». Сохраняем запрос и отправляем.

Запрос прошёл: с авторизацией всё в порядке, и у нас отображаются 2 теста, хотя один из них мы удалили. Мы вынесли авторизацию и один тест на уровень всей коллекции, и теперь авторизация и тест на код ответа 200 будут применяться ко всем тестам внутри этой коллекции.

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

Запуск коллекций тестов в Postman

В Postman есть встроенный компонент Collection Runner, с его помощью можно запустить наполненную запросами и тестами коллекцию.

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

Укажем значение Iterations равным 10 и пройдём наши тесты.

Далее можно посмотреть на результаты тестов по каждому запросу, экспортировать результаты по кнопке Export Results либо пролистать их в кратком виде по кнопке Run Summary.

Заключение

Итак, мы познакомились с базовыми возможностями инструмента Postman:

Это только малая часть полезных и интересных функций Postman, при помощи которых можно тестировать API. Понравилась статья — поделитесь с коллегами 😉

Если вы хотите освоить не только Postman, но также и другие инструменты ручного и автоматизированного тестирования ПО — приглашаем вас на факультет тестирования ПО GeekUniversity!

Что это вообще такое?

Как тестировать API?

Работа с запросами и отправка запросов в Postman

Создадим запрос на получение проектов. Назовём его соответственно: /api/v2/projects

По умолчанию открывается форма создания GET-запроса:

Для удобства мы указали на иллюстрации выше пункты, соответствующие порядку действий:

1. Выбираем тип запроса. Postman предлагает внушительный список, нам нужен GET.

Мы заполнили все необходимые данные. Теперь выполним запрос, нажав кнопку Send.

Отправляемый запрос или ответ мы можем сохранить с помощью меню справа:

Параметризация запросов, переменные окружения

В меню создания выбираем Environment

Запрос вновь прошёл успешно, значит, всё сделали правильно.

Создание тестов в Postman

Уже в знакомом нам запросе находим вкладку Tests и переходим в неё.

Postman автоматически добавил код на JS, который проверяет, что код ответа равен 200.

Вот какой код теста получился:

Переходим в редактирование коллекции.

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

А на вкладку Tests перемещаем проверку, что код ответа равен 200.

Запуск коллекций тестов в Postman

Укажем значение Iterations равным 10 и пройдём наши тесты.

Заключение

Итак, мы познакомились с базовыми возможностями инструмента Postman:

Источник

Использование Postman с API Microsoft Graph

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

Вы можете использовать коллекцию Microsoft Graph Postman, чтобы начать работу с API Microsoft Graph в считанные минуты.

В этой статье рассказывается о том, как быстро приступить к работе с Postman и Microsoft Graph. Кроме того, вы можете просматривать API Microsoft Graph непосредственно в веб-браузере с помощью песочницы Graph.

Чтобы узнать, как использовать Postman, выполните действия, указанные в данной статье, или посмотрите видео Начало работы в Microsoft Graph Postman.

Шаг 1. Разветвите коллекцию Microsoft Graph Postman.

Чтобы использовать коллекцию Postman, необходимо разветвить ее в рабочей области Postman. Сделайте это из браузера.

Вы перенаправлены на вилку главной коллекции Microsoft Graph Postman в своей рабочей области.

Шаг 2. Загрузите агент Postman (необязательно — только веб-браузер Postman)

Чтобы использовать эту конкретную коллекцию Postman в своем веб-браузере, скачайте классический агент Postman. Без этого вы не можете использовать Postman для Интернета из-за ограничений CORS в веб-браузере.

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

Шаг 3. Создайте приложение Azure AD.

Чтобы использовать эту коллекцию в своем клиенте разработчика, создайте приложение Azure Active Directory (Azure AD) и предоставьте ему соответствующие разрешения для запросов, которые вы хотите вызывать. Если у вас нет клиента разработчика, вы можете зарегистрироваться для получения одного из них в программе для разработчиков Microsoft 365.

Теперь приложение имеет два настроенных разрешения. Mail.Read добавляется как делегированное разрешение, которое является разрешением, требующим авторизации пользователя. Приложение может читать почту от имени пользователя. User.Read.All добавляется в качестве разрешения приложения, которое является разрешением, не требующим авторизации пользователя. Приложение может читать пользователей в Azure AD.

Действие 4. Настройка проверки подлинности

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

Шаг 5. Получение маркера делегированного доступа

Так как вы впервые выполняете запрос в виде делегированного потока проверки подлинности, вам потребуется получить маркер доступа.

Теперь у вас есть действительный маркер доступа для использования в делегированных запросах.

Шаг 6. Выполнение первого делегированного запроса

В папке Делегировано расположены запросы различных рабочих нагрузок Microsoft Graph, которые вы можете вызвать.

Вы успешно выполнили вызов Microsoft Graph с помощью делегированной проверки подлинности.

Действие 7. Получение маркера доступа приложения

Так как вы впервые выполняете запрос в виде потока проверки подлинности приложения, вам потребуется получить маркер доступа.

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

Шаг 8. Выполнение первого запроса приложения

В папке Приложение расположены запросы различных рабочих нагрузок Microsoft Graph, которые вы можете вызвать.

Вы успешно выполнили вызов Microsoft Graph с помощью проверки подлинности приложения.

Чтобы осуществить другие запросы в Microsoft Graph, можно выполнить следующие действия. Помните, что для функционирования других запросов необходимо добавить разрешения в приложение Azure AD; в противном случае в ваших откликах будут возникать ошибки с отказом в получении разрешений.

Добавление в коллекцию

Если вы хотите внести собственные запросы, вам потребуется лицензия Postman. Вы можете внести изменения в разветвленную коллекцию, а затем навести курсор на верхний узел коллекции и выбрать пункт Create pull request (Создать запрос на вытягивание).

Известные проблемы

Ошибка проверки подлинности: «Вы не сможете добраться отсюда»

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

Источник

Учебник. Подписание и создание запросов с помощью Postman

В этом руководстве мы будем настраивать и использовать Postman для выполнения запросов к Службам коммуникации Azure с помощью HTTP. По завершении работы с этим руководством вы отправите SMS с помощью Служб коммуникации и Postman. Затем вы сможете использовать Postman для изучения других API в Службах коммуникации Azure.

В этом учебнике мы выполним следующее:

Предварительные требования

Скачивание и установка Postman

Postman — это классическое приложение, способное выполнять запросы API к любому API HTTP. Он обычно используется для тестирования и изучения API-интерфейсов. Мы скачаем последнюю версию для настольных систем с веб-сайта Postman. Существуют версии Postman для Windows, Mac и Linux, поэтому скачайте версию, соответствующую вашей операционной системе. После скачивания откройте приложение. Появится окно с начальным экраном, в котором будет предложено выполнить вход или создать учетную запись Postman. Создание учетной записи является необязательным. Его можно пропустить, щелкнув ссылку Skip and go to app (Пропустить и перейти к приложению). При создании учетной записи параметры запроса API будут сохранены в Postman, что позволит вам применять запросы на других компьютерах.

После создания учетной записи или пропуска этого шага отобразится главное окно Postman.

Создание и настройка коллекции Postman

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

Затем щелкните Create new Collection (Создать коллекцию), чтобы начать процесс создания коллекции. В центральной области Postman откроется новая вкладка. Присвойте коллекции любое имя. Здесь коллекция называется «Службы коммуникации Azure»:

После создания коллекции и присвоения ей имени можно приступать к ее настройке.

Добавление переменных коллекции

Для обеспечения проверки подлинности и упрощения запросов мы укажем две переменные коллекции в только что созданной коллекции Служб коммуникации. Эти переменные доступны для всех запросов в коллекции Служб коммуникации. Чтобы приступить к созданию переменных, посетите вкладку Variables (Переменные) в разделе Collections (Коллекции).

На вкладке Collections (Коллекции) создайте две переменные:

Введите эти значения в столбец Initial Value (Начальное значение) на экране Variables (Переменные). После входа нажмите кнопку Persist All (Сохранить все) над таблицей справа. При правильной настройке экран Postman должен выглядеть примерно так:

Дополнительные сведения о переменных см. в документации по Postman.

Создание скрипта, выполняемого перед запросом

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

Мы создадим этот скрипт в коллекции так, чтобы он выполнялся по любому запросу в коллекции. Для этого на вкладке Collections (Коллекции) щелкните вложенную вкладку Pre-request Script (Скрипт перед запросом).

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

Написание скрипта, выполняемого перед запросом

Сначала создадим строку в формате UTC и добавим ее в заголовок HTTP «Дата». Мы также сохраним эту строку в переменной, чтобы использовать ее позже при подписывании:

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

После этого можно создать строку, которая будет подписываться для HTTP-запроса. Для этого потребуются несколько ранее созданных значений:

Наконец, необходимо подписать эту строку с помощью нашего ключа Служб коммуникации, а затем добавить ее в наш запрос в заголовке Authorization :

Окончательный скрипт, выполняемый перед запросом

Готовый скрипт, выполняемый перед запросом, должен выглядеть примерно так:

Введите или вставьте этот окончательный скрипт в текстовую область на вкладке Pre-request Script (Скрипт перед запросом):

Затем нажмите клавиши CTRL+S или кнопку Save (Сохранить), чтобы сохранить скрипт в коллекции.

Создание запроса в Postman

Теперь, когда все настроено, создадим запрос Служб коммуникации в Postman. Чтобы начать работу, щелкните значок плюса (+) рядом с коллекцией Служб коммуникации:

Будет создана новая вкладка для нашего запроса в Postman. После создания его следует настроить. Мы выполним запрос к API отправки SMS, поэтому обязательно ознакомьтесь с документацией по этому API. Давайте настроим запрос Postman.

Настройте тип запроса POST и введите <>/sms?api-version=2021-03-07 в поле URL-адреса запроса. Этот URL-адрес использует ранее созданную переменную endpoint для автоматической отправки ее в ресурс Служб коммуникации.

Теперь выберите вкладку Body (Текст) запроса и переведите переключатель в положение RAW. Справа отображается раскрывающийся список Text (Текст). Измените его на JSON:

Будет настроен запрос на отправку и получение сведений в формате JSON.

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

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

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

Отправка запроса

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

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

Мобильный телефон, которому принадлежит номер, указанный в значении to (кому), должен также получать SMS. Теперь у вас есть функциональная конфигурация Postman, которая может взаимодействовать со Службами коммуникации Azure и отправлять SMS.

Дальнейшие действия

Кроме того, вам может понадобиться следующее:

Источник

Postman что это

Что пишут в блогах

Что пишут в блогах (EN)

Spacing in Galleries

Разделы портала

Онлайн-тренинги

Автор: Михаль Димек (Michal Dymek)

Перевод: Ольга Алифанова

Сидел я как-то раз, работал, и внезапно (ну, как обычно) один из наших проектных менеджеров возник передо мной с вопросом:

— Не можешь ли ты помочь с нашим внутренним проектом?

— Конечно, почему нет! – сразу же откликнулся я.

Я только начинал свой путь в QA, и многого еще не знал, но если опытный сотрудник просит твоей помощи, что еще остается сделать?

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

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

Итак, начнем с самого начала.

Из описания, предоставленного разработчиками, мы узнаем, что:

«Postman – это мощный набор инструментов тестирования API, ставший необходимым для многих разработчиков. Мы делаем прекрасные продукты, помогающие создавать потрясающие API и улучшать производительность труда разработки. Postman используется более чем миллионом разработчиков по всему миру, и это число постоянно растет. Мы планируем разработку других продуктов, чтобы предоставить разработчикам наиболее мощное решение для разработки и тестирования API».

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

Давайте пробежимся по его лучшим особенностям!

Если вы устанавливаете Postman впервые, команда разработки предоставляет вам коллекцию «Postman Echo». Это набор сохраненных запросов (и ответов), организованных логически. Postman Echo сделан для легкого старта тестирования API с заранее настроенными запросами, от которых вы можете отталкиваться.

Если открыть этот набор, перейти в «Методы запросов» и затем в «Запросы GET», все сохраненные данные отобразятся в центральной части окна Postman. Теперь нажмите «Отправить».

Поздравляю! Вы отправили ваш первый запрос и получили первый ответ. Все просто.