что такое постман коллекция

Александр Александров про тренды и технологии тестирования, про влияние Covid19 на рынок QA

Продолжу хвастаться статусом книги.

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

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

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

Про инструменты

Автор: Кристин Джеквони (Kristin Jackvony)

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

Сегодня мы закончим обсуждение типов REST-запросов, разобрав DELETE-запрос и специфику его тестирования. Мы также узнаем, как создать цепочку REST-запросов в коллекции Postman.

Запрос DELETE удаляет запись из базы данных целиком. Чтобы увидеть, как это работает, вернемся в Swagger Pet Store. Для начала откроем запрос GET /pet/. Нажмите на «Try it out» и введите 100 в поле petId. Затем нажмите на кнопку «Execute». Взгляните на ответ сервера. Вернул ли сервер питомца? Если нет, попробуйте другой petId. Ищите, пока не найдете существующую в базе запись.

Теперь, когда у вас есть запись, откройте запрос DELETE /pet/ и нажмите на кнопку «Try it out». В поле petId введите id, который вы использовали для GET-запроса. Нажмите на кнопку «Execute». Сервер должен вернуть успешный код 200.

Как узнать, действительно ли запись удалена? Просто вернитесь к своему GET-запросу, снова введите нужный id в поле petId, и нажмите на «Execute». Вы должны получить ответ «Pet not found». Ура, вы успешно удалили питомца из базы!

Тестировать DELETE-запрос довольно просто. Единственная информация, которую вы передаете – это id записи, которую вы хотите удалить, поэтому вариантов тут немного. Можно проверить, что будет, если ввести id несуществующей записи (должна появиться 404 ошибка), или невалидный id (FOO). Если функциональность удаления в вашем приложении доступна только авторизованным пользователям, попробуйте удалить запись без токена или куки, дающих вам такое право. Можно также попробовать отправить запрос через http-URL вместо https (или наоборот), или URL, который не указывает на id для удаления.

Теперь давайте откроем Postman и попробуем создать цепочки запросов! представьте, что вы создаете набор тестов для Swagger Pet Store. Вы хотите убедиться, что питомца можно добавить, получить данные о нем, редактировать и удалить из базы. Когда вы добавляете питомца в базу, вы хотите удостовериться, что запись действительно добавлена, поэтому вам нужен GET-запрос, убеждающийся в этом. Схожим образом при редактировании питомца вам нужен GET-запрос, чтобы проверить изменения. И, наконец, при удалении питомца нужен GET, чтобы убедиться, что питомец и правда удален. Также тест-набор должен чистить за собой, чтобы вы не добавляли все больше и больше записей в вашу базу ежедневно. Цепочка запросов в коллекции Postman все это позволяет. Вот в каком порядке будут располагаться ваши запросы:

Для создания коллекции Postman нажмите на вкладку «Collections» в верхнем левом углу экрана, а затем – на иконку с папкой и плюсиком:

Дайте вашей коллекции имя (например, «Pet Store»), и нажмите на кнопку «Create». Вы увидите папку с именем вашей коллекции в левой колонке экрана. Теперь нажмите на вкладку «+» в главном окне экрана, чтобы добавить новый запрос. Начнем с запроса POST, добавляющего питомца. Создайте примерно такой запрос:

Headers: Content-Type: application/json

Если что-то из вышеуказанного кажется вам непонятным, перечитайте статью про POST-запросы.

После того, как ваш запрос готов и работает, сохраните его в коллекцию. Нажмите на кнопку «Save» в правом верхнем углу экрана. Появится всплывающее окно. Дайте запросу имя – например, «Add Pet», и выберите созданную вами коллекцию. Нажмите на «Save», и вы увидите запрос в папке коллекции в левой стороне экрана.

Мы можем повторить эту процедуру с запросом GET:

Как только запрос заработает, сохраните его в коллекцию с именем вроде «Verify Add Pet». Мы называем этот запрос так, потому что он будет использоваться для проверки, что предыдущий POST-запрос правильно отработал.

Затем мы отредактируем питомца при помощи запроса PUT:

Headers: Content-Type: application/json

Когда запрос будет готов, сохраните его в коллекцию с именем «Update Pet».

Теперь нам нужен еще один GET-запрос, чтобы убедиться, что запрос PUT отработал верно. У нас уже есть сохраненный GET-запрос, поэтому мы можем его просто продублировать. Наведите курсор на запрос «Verify Add Pet» в левой части экрана, и вы увидите троеточие справа от названия запроса. Нажмите туда и выберите «Duplicate». Теперь под исходным запросом появится его копия, «Verify Add Pet copy». Кликните по запросу, затем на троеточие, и выберите «Переименовать». Переименуйте его в «Verify Update Pet». Так как мы будем использовать его для проверки PUT, зажмите его мышью и перетащите после PUT-запроса.

Теперь мы создадим запрос DELETE:

Request type: DELETE

Сохраните его в коллекцию с названием «Delete Pet».

И, наконец, нам нужен еще один GET-запрос, чтобы убедиться, что удаление сработало. Продублируйте запрос «Verify Update Pet», переименуйте копию в «Verify Delete Pet» и переместите его под DELETE-запрос. Помните, что при прогоне этого запроса после удаления вы должны получить ответ «Pet not found».

Теперь у нас есть коллекция из шести запросов, которые можно использовать для проверки функциональности питомца в Pet Store! Они должны выглядеть примерно так:

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

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

Больше информации по этой теме вы можете получить в курсе Тестирование REST API

Источник

Postman — менеджмент, структурирование, импорт и экспорт коллекций.

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

Менеджмент коллекций

Когда вы тестируете несколько проектов параллельно, чтобы избежать путаницы в списке запросов, логичнее всего будет создать коллекцию для каждого проекта. Важно разделить проекты именно на этапе создания запросов. В примере я создам три проекта и назову их “Test 1”, “Test 2” и “Test 3”.

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

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

Создадим папку внутри коллекции.

Тут начинается самое интересное. Как же назвать папку? Есть несколько способов организовать папки внутри коллекции:

1) По функциональным блокам
2) По user flow
3) По версии API (V1, V2 и т.д.)
4) По критично важной функциональности

Организация коллекций по функциональным блокам

Например, в приложении или на сайте есть следующие функциональности:

и т.д до бесконечности.

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

Организация коллекций по user flow

Папки можно организовать, подумав о наборе шагов, которые обычно проходит пользователь. Например: пользователь логинится, заходит в каталог, добавляет товар в корзину, переходит на оформление заказа, заполняет все данные, переходит к оплате… Это один из user flow пользователя, которых может быть большое количество. Еще пример — пользователь заходит в каталог, добавляет несколько позиций в избранное, проверяет, что в разделе “избранное” эти позиции остались. По таким сценариям и можно оформить папки. Этот вариант подходит, когда стоит задача проверить именно путь пользователя от входа в приложение до его конечной цели. Даже если его цель — поменять пароль, или посмотреть новые акции. На практике этот подход применяется достаточно редко, т.к. такие коллекции крайне специфичны.

Организация коллекций по версии API

Разработка веб-сервиса или приложения состоит из этапов. В случае, когда с клиентом существует договоренность в первом этапе сделать определённый набор функциональностей, таких как регистрация, авторизация, каталог, корзина, оформление заказа, оплата, уместно разбить коллекцию по версиям API, которые от этапа к этапу обновляются. Например API v1, API v2 (где добавятся акции, раздел избранного, бонусные программы), API v3 и т.д. Зачастую, это один из самых распространённых случаев, т.к. в основном тестирование API и создание коллекции в Postman происходит в самом начале разработки.

Организация коллекций по критично важной функциональности

Согласно теории тестирования программного обеспечения, невозможно обеспечить отсутствие дефектов в разрабатываемом продукте. Особенно в случае сжатых сроков (ну куда же мы без дедлайнов когда наш клиент внезапно хочет сделать демо своим клиентам, потому что его бизнес идея раскрутилась?). В таких случаях нам необходимо убедиться, что основные или наиболее часто используемые части продукта работоспособны и исправны. То есть мы выделяем критичную функциональность и фокусируемся только на ней. Можно использовать этот метод при проведении приёмки минорного релиза, либо для создания коллекции в Postman, где будет отдельная папка с критичной функциональностью. В этом случае тестирование займет меньше времени за счёт фокусировки на конкретной части продукта, дешевле для клиента, но при этом клиент не будет терять деньги из-за того, что фичи типа “сканер штрих-кода товара” или “редирект на сайт из приложения” работают, а оплата отвалилась, т.к. она проверяется намного чаще, потому что входит в скоуп критично важной функциональности.

Экспорт

Коллекция создана, формат коллекции удобен, вдруг менеджер проекта или другой QA спрашивает “А есть коллекция в постмане? Хочу тоже посмотреть”. Коллекция есть, и для того, чтобы поделиться коллекцией и существует экспорт, чтобы по несколько раз не делать разным людям в команде одну и ту же работу. Да, можно импортировать коллекцию из Swagger’a, но ведь не всегда в Swagger’e указаны нужные параметры и прочие необходимые вещи для успешного запроса. В этом и есть огромный плюс Postman’a. Можно создавать и хранить кастомизированные запросы на основе документации (указывать необходимые ID, предустанавливать токен пользователя и т.д.). В онлайн инструментах типа Swagger’a тоже можно кастомизировать параметры или тело запроса, но нельзя сохранить эти шаблоны для последующего использования.. Также, не у всех сервисов хранения документации по API есть экспорт, иногда это вообще простыня из запросов и методов.

Вы великолепны! Файл создан, можно его скидывать заинтересованным людям.

2. С помощью URL ссылки:

Готово! 🙂 Ссылка получена, можно её скопировать и отправить кому нужно.

Импорт

Вот и всё, коллекция добавлена и доступна в вашем списке коллекций.

2. Импорт с помощью сгенерированного URL:

Теперь вы имеете представление о менеджменте коллекций и способах их экспорта и импорта. Конечно, можно вести коллекции так, как удобно вам. Материалы в этой статье лишь демонстрируют возможности организации коллекций и работы с ними. Зато теперь после вопроса “Скинь мне свою коллекцию”, вы не будете тратить время на то, чтобы разобраться как это сделать, ведь вы уже всё знаете!

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

Источник

Создание коллекции Postman для пользовательского соединителя

Эта статья входит в серию руководств по созданию и использованию пользовательских соединителей в Azure Logic Apps, Power Automate и Power Apps. Обязательно прочитайте обзор настраиваемых соединителей, чтобы понять процесс.

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

В этой теме вы создаете коллекцию, которая включает запрос и ответ от API анализа текста Cognitive Services. В связанной теме вы создадите соединитель, используя эту коллекцию.

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

Создание HTTP-запроса для API

В приложении Postman на вкладке Построитель выберите метод HTTP, введите URL-адрес запроса для конечной точки API и выберите протокол авторизации, если требуется.

Введите пары «ключ-значение» для заголовка запроса. Стандартные заголовки HTTP можно выбрать в раскрывающемся списке.

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

Поле ответа содержит полный ответ от API-интерфейса, включая результат или ошибку, если таковая произойдет.

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

Сохранение коллекции

Нажмите Сохранить.

В окне Сохранение запроса укажите имя и описание запроса. Настраиваемый соединитель использует эти значения для сводки и описания операций API.

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

Сохранение ответа на запрос

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

Над окном ответа выберите Сохранить ответ.

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

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

Если ваш API-интерфейс содержит дополнительные возможности, продолжайте создание коллекции Postman с дополнительными запросами и ответами.

Экспорт коллекции Postman

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

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

Выберите для экспорта формат Коллекция вер. 1, выберите Экспорт и перейдите к расположению, в котором хотите сохранить JSON-файл.

В настоящее время вы можете использовать только коллекции версии 1 для пользовательских соединителей.

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

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

Источник

Как пользоваться программой 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 (до отправки на сервер).

Источник