Postman для тестировщика: с чего начать, интерфейс, Swagger, GET и POST

Что такое Postman и с чего начать

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

Скачать Postman можно на официальном сайте postman.com, есть версии для Windows, macOS и Linux. Есть и веб-версия, но лучше ставить настольную, потому что в браузере не всё удаётся воспроизвести и иногда сам браузер приходится дополнительно настраивать. После установки создают учётную запись по почте или через Google.

Русского интерфейса у программы нет, документация тоже на английском, и к этому стоит сразу привыкать. Учиться удобнее всего по официальной документации в Learning Center на сайте Postman: инструмент меняется быстро, и самое свежее описание новых версий есть только там. Интерфейс заметно менялся и от одного моего урока к другому, поэтому ниже программа описана по роликам 2025 и 2026 годов.

Интерфейс Postman: что где находится

Сразу после входа Postman показывает много вкладок и кнопок, и в первые дни в них легко потеряться. Для ручного тестирования из них нужны немногие. Вкладки Flows, Mock servers и Monitors на старте можно пропустить: это автоматизация через блок-схемы, заглушки вместо недописанной части сервера и запуск коллекций по расписанию.

Любое изменение сохраняют сочетанием Ctrl+S или Cmd+S. Несохранённый запрос помечается оранжевой точкой на вкладке, и пока его не сохранили, в коллекции остаётся старая версия.

• Workspace

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

• Collections

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

• Environments

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

• History

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

• Import

  Импорт готовой документации, например из Swagger, или команды cURL. Postman сам создаст коллекцию или запрос.

• Окно запроса

  Метод и адрес, под ними вкладки Params для параметров, Authorization для авторизации, Headers для заголовков, Body для тела запроса и Scripts для скриптов до отправки и после ответа. Ниже выводится ответ: статус-код, время, тело и заголовки.

• Шпаргалкаинтерфейс Postman

Swagger: где брать запросы и ожидаемые ответы

Без документации тестировать API трудно: непонятно, что должен вернуть сервер, с каким статус-кодом и что лежит в теле ответа. Документация бывает страницей в Confluence, описанием прямо в Postman, но чаще всего это Swagger – отдельная страница с описанием API, которую ведут разработчики бэкенда. Для тестировщика она играет роль требований, поэтому добиваться её на проекте стоит, даже если вы рядовой тестировщик.

В уроке я разбираю учебный API Petstore. Для работы в Postman из Swagger нужно вот что.

• Базовый адрес

  Общая часть адреса, которая есть в каждом запросе. В Postman её вставляют первой.

• Эндпоинты

  Пути, которые добавляются к базовому адресу, например /pet/findByStatus. В русскоязычных командах их называют ручками.

• Параметры

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

• Тело запроса и модели

  Пример тела в JSON и схема данных. У Petstore идентификатор питомца задан целым числом (integer), а имя строкой. По схеме придумывают проверки: подставить число вместо строки, оставить обязательное поле пустым.

• Ответы

  Статус-коды и примеры тел ответа. С ними сверяют то, что сервер вернул в Postman.

• Try it out

  Запрос можно выполнить прямо в браузере кнопками Try it out и Execute. Swagger покажет адрес, ответ и команду cURL, которую можно импортировать в Postman. Замок у метода означает, что по документации ему нужна авторизация. Учебный Petstore отвечает на такие запросы и без неё, а на рабочем проекте запрос без токена стоит проверить отдельно: сервер должен ответить 401.

• ШпаргалкаSwagger и OpenAPI

GET и POST: в чём разница

Метод говорит серверу, что сделать с ресурсом. GET получает информацию, POST отправляет данные на сервер: регистрацию, вход, загрузку файла, новую карточку товара. PUT обновляет сущность целиком, PATCH меняет только переданные поля, DELETE удаляет.

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

• Тело запроса

  У POST есть тело с полезной нагрузкой: JSON, текст, файл. У GET тела нет, и GET, который принимает тело, считается плохой практикой.

• Параметры

  GET передаёт параметры в адресной строке после знака вопроса, а несколько параметров соединяются знаком &. Поэтому GET-запрос можно сохранить в закладки браузера.

• Длина и кэш

  Длина GET ограничена длиной адреса, и это стоит проверить отдельно. Ответы на GET кэшируются на стороне клиента.

• Что меняется на сервере

  GET только читает данные. POST обычно создаёт новое, и после него в системе появляется запись с новым идентификатором.

• Пример: каталог и вход в магазин

  Поиск по каталогу интернет-магазина уходит GET-запросом вида /products?q=sneakers&sort=price, и ссылку с такими параметрами можно отправить другому человеку. Вход и оплата должны идти POST-запросом с данными в теле. Если пароль или номер карты видны в адресе запроса, они попадут в историю браузера и журналы серверов, и это дефект безопасности.

• СтатьяHTTP для тестировщика: методы и коды ответов

Пример: от первого GET до удаления

Так я прохожу учебную песочницу из своего курса по REST API, где хранятся герои, боги и существа древнегреческих мифов. Перед началом создают рабочее пространство и коллекцию для запросов.

Запросы стоит сразу называть по смыслу и с ожидаемым статус-кодом, например "Получить список – 200 OK". Так позитивные и негативные проверки видно в коллекции с первого взгляда.

• 1. Получить список (GET)

  Базовый адрес из Swagger, к нему эндпоинт, метод GET, авторизация не нужна. Ответ – 200 OK и массив объектов, поля которых сверяют с примером в документации. Параметры category и sort на вкладке Params фильтруют и сортируют список.

• 2. Регистрация (POST)

  Тело добавляют на вкладке Body в режиме raw и формате JSON. Повторная регистрация того же пользователя даёт 400 с понятным сообщением, новый пользователь – 201 Created. На запрос без тела сервер ответил 500, и разработчикам стоит предложить код из группы 4xx.

• 3. Вход (POST)

  Те же логин и пароль на эндпоинт входа возвращают 200 OK и токен авторизации.

• 4. Токен на всю коллекцию

  Токен вставляют на вкладке Authorization самой коллекции с типом Bearer Token. Запросы внутри наследуют его от родителя и отправляют в заголовке Authorization.

• 5. Создание (POST)

  Новая сущность создаётся с ответом 201 Created, идентификатор сервер присваивает сам. Пример из документации лучше заменить своими данными, потому что одни и те же тестовые данные со временем перестают находить новые дефекты.

• 6. Изменение (PUT и PATCH)

  Оба запроса идут с идентификатором в адресе. PUT требует все обязательные поля, даже те, что не меняются, и без любого из них возвращает ошибку. PATCH принимает только изменённые поля.

• 7. Удаление (DELETE)

  Тело не нужно, только идентификатор. Удаление своей сущности даёт 204 No Content, повторное удаление даёт 404, а попытка удалить защищённого персонажа заканчивается ответом 403 Forbidden.

• СтатьяПринципы тестирования: парадокс пестицида

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

Когда запросов становится много, базовый адрес выносят в переменную. Его выделяют в строке запроса, выбирают Set as variable и область действия, например коллекцию. Дальше в каждом запросе стоит {{baseUrl}}, и если адрес проекта поменяется, исправить его нужно будет в одном месте. Так же удобно хранить идентификатор и токен.

Окружение – это набор переменных для одной среды: разработки, тестового стенда или продакшена. Если переменная с одним именем есть и в коллекции, и в выбранном окружении, Postman возьмёт значение из окружения.

Ответы не обязательно проверять глазами. На вкладке Scripts в разделе Post-response пишут тесты, и программировать для этого не нужно: Postman предлагает готовые заготовки (snippets) для проверки статус-кода, значения в теле, заголовков и времени ответа. Все запросы коллекции или папки запускаются кнопкой Run. В прогоне задают порядок запросов, число повторов и паузу между ними, и за порядком нужно следить: если DELETE стоит раньше PUT и PATCH, следующие запросы упадут на уже удалённой сущности.

Пример из API интернет-магазина: в Post-response запроса POST {{baseUrl}}/orders стоит заготовка "Status code: Code is 200", где 200 заменено на 201, и строка pm.collectionVariables.set("orderId", pm.response.json().id), которая сохраняет номер нового заказа. Следующий запрос GET {{baseUrl}}/orders/{{orderId}} берёт этот номер и проверяет, что у заказа статус new. Если POST упал, переменная не заполнится и GET упадёт следом, поэтому разбор начинают с первого упавшего запроса.

• Шпаргалкаскрипты и тесты в Postman

Видеоуроки, шпаргалки и задания

Первым уроком я открываю мини-курс "Postman для тестировщика" на YouTube: где учиться по официальной документации и как устроены рабочее пространство и коллекции. Интерфейс с тех пор заметно изменился, поэтому в 2025 году вышли обновлённые уроки об установке, интерфейсе, Swagger, GET и POST, а в 2026 году – полный гайд по тестированию REST API в Postman. Разницу GET и POST и работу в SoapUI я разбираю в 18-м уроке курса "Тестировщик с нуля".

В бесплатном базовом курсе по тестированию тема идёт уроком "Интерфейс Postman. Swagger", и после теории в нём есть задания. В шпаргалках окно Postman и Swagger UI собраны макетами, по которым можно пощёлкать, а в тренажёре запросы уходят на сервер учебной песочницы с героями мифов.

• Урок курсаЭтот урок с заданиями – бесплатно
• Мой видеоурокPostman для тестировщика, с чего начать
• Мой видеоурокPostman для тестировщика 2.0, настройка и интерфейс
• Мой видеоурокPostman для тестировщика 2.0, Swagger, GET и POST
• Мой видеоуроккак тестировать REST API в Postman, полный гайд
• Мой видеоурокобзор функций и интерфейса Postman
• Мой видеоурокPostman для тестировщика, полный курс
• Мой видеоуроккак тестировать API в Postman и SoapUI, отличия GET и POST
• Шпаргалкаинтерфейс Postman
• ШпаргалкаSwagger и OpenAPI
• Тренажёрпрактика API-запросов
• СтатьяТестирование API простыми словами

Курсы по теме

• бесплатный

  Тестирование ПО с нуля. Теория + Практика. Базовый уровень

  Первое рабочее место тестировщика

  89 уроков113 441
• платный

  Тестирование REST API в Postman. Легенды и мифы Древней Греции

  Древняя Греция · REST API

  45 уроков544

Вопросы и ответы