Основы 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
Я начинаю цикл ознакомительных и обучающих статей по 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” в параметре ответа появляется ответ от сервера.
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.
Как тестировать 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!
Привет! Меня зовут Игорь Гросс, я руководитель проектов в 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!