Postman инструкция на русском

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

В этом же открывшемся окне выбираем настройки нашего запуска. Можно настроить:

• автоматизацию запуска. В нашем случае, выберем «Run manually» (Запуск произойдет тогда, когда мы сами нажмем кнопку старта). Помимо этого, можно настроить автозапуск выбранных запросов раз в какое-то время, или же настроить вызов прямо из терминала.

• кол-во раз прогона запросов настраивается в поле Iterations.

• задержка между запросами и другие прикольные штуки.

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

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

Переменные можно добавлять как локально для какой-то коллекции (другие коллекции ее видеть не будут), так и глобально для всего окружения.

Для добавления переменных к коллекции необходимо перейти в ее настройки (достаточно просто нажать на коллекцию) во вкладку «Variables».

Там мы придумываем какое-то наименование нашей переменной и в «Current value» добавляем значение (для примера, родительский адрес, чтоб не перепечатывать его постоянно).

Переменные коллекции: Для чего используется «Initial value» и «Current value»: если вы работаете командой, то внеся изменения в «Initial value» — их увидят все и, при шаринге коллекции все будут видеть именно это значение. Если же вы хотите что-то проверить, но менять значение для всех пользователей, имеющих доступ нельзя — вы можете локально изменить «Current value» (эту информацию будете видеть только вы). Так же, в «Initial value» не рекомендуется добавлять какие-то чувствительные данные (например, пароли), тк эта информация, в отличии от «Current value» хранится на серверах постмона + ее видят все участники команды. 

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

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

Environment — это набор каких-то переменных глобальных или для определенного окружения (к примеру, стенд A, стена B, прод). Чтобы посмотреть все окружения, которые сейчас есть — необходимо нажать на кнопку списка с глазом. Там же мы можем создать новое окружение. 

• Если мы выберем «Globals», то данные переменные могут применяться вообще ко всему. Они не привязаны к конкретному окружению и доступны всем. Как пример, можем занести туда информацию о логине (email + pass), если мы его будем часто использовать.

• Мы можем создать свое окружение, к примеру, «stage», в которое занесем данные об email. При выборе этого окружения, на места всех переменных email поставится значение из окружения «stage». При этом, на проде могут быть совсем другие данные => при создании еще одного окружения «production» и занесении туда такой же переменной email с другим значением — мы можем в одно действие менять значения переменных всех запросов на нужное.

Еще одно место, где можно использовать окружения/переменные — при запуске папки/коллекции (можно выбрать окружение, для которого будет выполнен прогон запросов).

Предустановленные тесты от Postman

Тесты можно прописывать во вкладке «Tests» для запроса. Здесь мы можем создавать свои скрипты, делать проверки, смотреть какие-то значение в респонсе (если мы знаем, что они там будут прописаны) и многое другое.

Предустановленные тесты находятся в блоке справа, который называется «Snippets». Мы их можем использовать и настраивать под себя. Один из распространенных тестов — проверка на статус код. Выбираем подходящий шаблон из списка и подставляем его.

Информация о прохождении наших тестов появляется во вкладке «Test Results». Успешные запросы — зелененькие. Если тест не прошел — ожидаемо, красненькие.

Теперь добавим тест на проверку того, что в ответе нам пришло какое-то значение. Из шаблонов выбираем «Response body: JSON value check». Вместо value пишем значение, которое хотим проверить.

Так же, теперь при запуске коллекции мы будем видеть все прошедшие и упавшие тесты:

Переменные в CSV и JSON файлах

CSV: Для начала создадим csv файл, в котором будет содержаться информация о нашем email и password. Вот несколько способов:

Способ 1: на windows можно создать обычный файл с расширением [.txt], которое мы изменим в последствии в проводнике. Либо, если у вас Mac — открываем TextEditor, вводим наши данные, сохраняем и при переименовании файла дописываем [.csv]. В всплывающем окне выбираем «использовать .csv».

Проверить, насколько корректно сохранился файл можно в любом редакторе кода* (открыть с помощью -> ваш редактор) и, если что, там же и подредактировать. [* если же у вас не стоит редактор кода — советую об этом позаботиться, тк ваша жизнь в IT еще ни раз вас подтолкнет им воспользоваться].

Способ 2: сконвертировать csv онлайн (не рекомендуется. В вашем файле могут появиться посторонние символы, которые будут мешать его правильному прочтению).

Способ 3: самый простой и надежный способ — создать файл сразу из редактора кода (далее рассмотрим «Visual Studio Code»). Открываем и выбираем «New File». Сразу вводим «Data.csv» и сохраняем. Далее там же редактируем сам файл и сохраняем изменения (На мой взгляд это куда проще, чем мучиться с созданием через обычный текстовый файл и переживать, а все ли хорошо сохранилось).

Теперь, как же правильно завести данные:

• в первой строке через запятую и без пробелов вводим название наших переменных;

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

Далее переходим в Postman, создадим переменные (в нашем случае — email и password):

Давайте попробуем запустить нашу коллекцию! Перед стартом нажимаем на добавление файла и обязательно проверяем, что «Data File Type» выставился корректно. Если нет, можете поменять значение вручную. Так же здесь мы можем нажать на preview и посмотреть, правильно ли Postman прочитал наш файл.

Запускаем коллекцию и видим, что все 5 запросов успешно улетели. При нажатии на сам запрос можем посмотреть данные, которые мы как раз отправляли и убедиться, что ушло именно то, что хотели. (На статус код 400 в данном случае не обращайте внимания. Это из-за того, что мы используем OpenApi у которого есть свои внутренние ограничения).

JSON: по аналогии с созданием CSV файла — создадим JSON (способы описаны выше).

Как должен выглядеть JSON файл:

1. Данные записываются в виде пар «ключ:значение»

2. Пары данных разделены запятыми

3. Объекты прописываются внутри фигурных скобок {}

4. Массив (в том числе и из объектов) заключается внутри квадратных скобок []

Исходя из этого, заполняем наши тестовые данные.

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

Запросы успешно отправляются!)

Заключение

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

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

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

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

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

Дополнительно:

Как и было обещано, список статус-кодов (самые популярные выделены жирным).

1XX:

• 100 — Continue — Продолжить — этот промежуточный ответ указывает, что запрос успешно принят и клиент может продолжать присылать запросы либо проигнорировать этот ответ, если запрос был завершён.

• 101 — Switching Protocol — указывает, что сервер переключился на протокол, который был указан в заголовке.

• 102 — Processing — сервер получил запрос и обрабатывает его, но обработка ещё не завершена.

• 103 — Early Hints — Ранние подсказки/ранняя метаинформация — разрешение пользовательскому агенту начать предварительную загрузку ресурсов, пока сервер все еще готовит ответ.

2XX:

• 200 — OK — запрос успешно обработан.

• 201 — Created — сервер подтвердил создание ресурса.

• 202 — Accepted — Принято — запрос клиента был получен, но сервер все еще обрабатывает его.

• 203 — Non-Authoritative Information — Не авторитетная информация — аналогично 200, но в этом случае предоставленная информация была не от исходного сервера, а из стороннего источника.

• 204 — No Content — Нет содержимого — сервер обработал запрос, но не предоставил никакого содержимого.

• 205 — Reset Content — Сбросить содержимое — клиент должен обновить документ, который прислал запрос.

• 206 — Partial Content — Частичное содержимое — клиент присылает заголовок диапазона, чтобы выполнить загрузку отдельно, в несколько потоков.

3XX:

• 300 — Multiple Choice — этот код ответа присылается, когда запрос имеет более чем один из возможных ответов. И User-agent или пользователь должен выбрать один из ответов.

• 301 — Moved Permanently — Перемещён на постоянной основе — искомый ресурс был перемещен по другому адресу. Все пользователи и ресурсы будут перенаправлены на него.

• 302 — Found — ресурс временно перемещен на другой URL.

• 303 — See Other — сообщает клиенту, что сервер перенаправляет его не на запрашиваемый ресурс, а на другой.

• 304 — Not Modified — используется для кеширования. Означает, что запрошенный ресурс не был изменен с последнего посещения.

• 305 — Use Proxy — клиент может получить доступ только через прокси, указанном в ответе.

• 307 — Temporary Redirect — Временное перенаправление — искомый ресурс был временно перенесен на другой URL. Различия с 302 — нельзя изменять используемый метод HTTP.

• 308 — Permanent Redirect — искомый ресурс был перемещен по другому адресу. Все пользователи и ресурсы будут перенаправлены на него.Различия с 301 — нельзя изменять используемый метод HTTP.

4XX:

• 400 — Bad Request — Плохой запрос — сервер не понимает запрос из-за неверного синтаксиса.

• 401 — Unauthorized — Неавторизованно — для получения запрашиваемого ответа нужна аутентификация. Статус похож на статус 403, но,в этом случае, аутентификация возможна.

• 402 — Payment Required — Необходима оплата.

• 403 — Forbidden — Запрещено — у клиента нет прав доступа к содержимому, поэтому сервер отказывается дать надлежащий ответ.

• 404 — Not Found — Не найден — сервер не может найти запрашиваемый ресурс. 

• 405 — Method Not Allowed — Метод не разрешён — сервер получил и распознал запрос, но отклонил конкретный метод запроса.

• 406 — Not Acceptable — веб сайт/приложение не поддерживает запрос клиента с определенным протоколом.

• 407 — Proxy Authentication Required — Требуется подтверждение протокола — аналог 401. Различие с 401 лишь в том, что аутентификации должна быть проведена через proxy.

• 408 — Request Timeout — Время ожидания запроса истекло — срок запроса, отправленного клиентом серверу — истек.

• 409 — Conflict — Этот ответ отсылается, когда запрос конфликтует с внутренним текущим состоянием сервера.

• 410 — Gone — запрашиваемый контент навсегда удалён с сервера.

• 412 — Precondition Failed — в заголовках запроса указаны условия, которые сервер не может выполнить.

• 413 — Request Entity Too Large — Размер запроса превышает лимит, объявленный сервером.

• 414 — Request-URL Too Long — URL запрашиваемый клиентом слишком длинный для того, чтобы сервер смог его обработать

• 417 — Expectation Failed — ожидание, полученное из заголовка запроса Expect, не может быть выполнено сервером.

• 418 — I’m a teapot — я чайник.

5XX:

• 500 — Internal Server Error — Внутренняя ошибка сервера — сервер столкнулся с ситуацией, которую он не знает как обработать.

• 501 — Not Implemented — Не реализовано — метод запроса не поддерживается сервером и не может быть обработан.

• 502 — Bad Gateway — Плохой шлюз — сервер, во время работы в качестве шлюза для получения ответа, нужного для обработки запроса, получил недействительный (недопустимый) ответ.

• 503 — Service Unavailable — Сервис недоступен — сервер недоступен и не может обработать запрос клиента.

• 504 — Gateway Timeout — сервер действует как шлюз и не может вовремя получить ответ.

• 505 — HTTP Version Not Supported — HTTP-версия, используемая в запросе, не поддерживается сервером.

• 511 — Network Authentication Required — Требуется сетевая аутентификация — клиент должен пройти аутентификацию в сети, чтобы получить доступ к ресурсу.