Блог
Теория и инструменты тестирования

Postman подробно: коллекции, environments, тесты

Postman — инструмент для тестирования API, и на собеседовании QA уровня Middle его спросят почти наверняка: «Каким инструментом тестировали API?» — ждут ответа именно «Postman». А дальше — что конкретно вы в нём умеете: работать с переменными, писать автотесты, настраивать авторизацию, прогонять коллекции пачками. В отличие от Swagger, который создан для документации API, Postman — рабочий инструмент тестировщика: сохраняет запросы, поддерживает переменные, коллекции, автотесты, импорт и экспорт, массовые прогоны через Runner. Разберём по порядку, из чего он состоит и что в нём реально нужно знать.

Структура Postman: workspace, коллекция, папка, запрос

Интерфейс Postman устроен как вложенная иерархия: workspace (рабочее пространство) содержит коллекции, коллекция — папки, папка — конкретные запросы. Workspace бывает трёх типов: Personal (приватное, бесплатно — обычный вариант для тестировщика-одиночки), Team (для совместной работы, нужна подписка) и Public (доступно всем). Внутри workspace создаётся коллекция — набор запросов, относящихся к одному API, проекту или модулю. Например, коллекция API учебного проекта Quality Academy «Космическая Одиссея» делится на папки: Pilot — все операции с пилотами, Missions — миссии, Token — авторизация. Каждый отдельный запрос настраивается через конструктор: метод (GET, POST, PUT, DELETE, PATCH), URL, и вкладки Params (query-параметры), Authorization, Headers, Body, Pre-request Script, Tests. Для тела запроса чаще всего выбирают raw → JSON — это стандарт для REST API, остальные типы (form-data, x-www-form-urlencoded, binary, GraphQL) нужны реже и под конкретные случаи.

Авторизация: три способа передать токен

Большинство запросов к API требуют токен авторизации, и передать его можно тремя способами. Первый — вручную вписать заголовок Authorization: Bearer <токен> в каждый запрос; неудобно, если запросов пятьдесят. Второй — вкладка Authorization у самого запроса: выбираем тип Bearer Token, вставляем токен без слова Bearer, Postman сам добавит его в заголовок. Кроме Bearer Token там же доступны No Auth, Basic Auth, API Key, OAuth 1.0/2.0, AWS Signature, Digest Auth — знать список полезно для собеседования. Третий способ — самый удобный на практике — Inherit from parent. Он строится на той же иерархии workspace → коллекция → папка → запрос: авторизацию настраивают один раз на уровне коллекции (Bearer Token → {{TOKEN}}), а все папки и запросы внутри просто наследуют её через Inherit from parent. Меняется токен в одном месте — обновляется сразу везде. Если для конкретного запроса нужна другая авторизация, её всегда можно переопределить отдельно.

Переменные — ключевая функция Postman

Проблема, которую решают переменные, простая: URL сервера повторяется в полусотне запросов, и при изменении домена приходится редактировать каждый вручную. Вместо этого домен выносят в переменную {{HOST}} и меняют один раз. У переменных в Postman шесть уровней видимости — от самого узкого до самого широкого: Data (доступна только в одной итерации прогона Runner), Local (в рамках одного запроса, задаётся в Pre-request или Tests скрипте), Collection (внутри коллекции), Environment (внутри выбранного окружения), Global (везде) и встроенные Postman Built-in переменные $randomXxx, которые генерируются на лету. Приоритет между ними часто спрашивают на собеседовании: Data > Local > Environment > Collection > Global — чем уже область видимости, тем выше приоритет.
Environments — отдельная и очень практичная фича: заводим несколько окружений (Prod, Test, Dev), в каждом задаём переменную HOST со своим значением, и переключаемся между ними в правом верхнем углу — все запросы коллекции автоматически подхватывают адрес нужного окружения. Отдельно стоят встроенные переменные вида $randomEmail, $randomUserName, $randomInt, $randomUUID, $isoTimestamp — они подставляют случайные значения при каждой отправке запроса. Например, тело запроса на создание пилота с {"name": "{{$randomUserName}}", "email": "{{$randomEmail}}"} создаёт уникальную сущность при каждом клике Send — не нужно руками придумывать новые имена для тестовых данных.

Автотесты: Tests, сниппеты и Postbot

Вкладка Tests запроса содержит JS-скрипт, который выполняется после получения ответа от сервера. Писать тесты с нуля не обязательно — справа есть панель готовых сниппетов: «Status code is 200», «Response time is less than 200ms», «Response has JSON body» и другие — клик добавляет код автоматически. Базовый тест выглядит так:
pm.test("Status code is 201", function () {
pm.response.to.have.status(201);
});
Есть и более быстрый путь — Postbot, встроенный AI-генератор тестов. Кнопки «Test for response» и «More tests» анализируют структуру ответа и сами генерируют проверки: статус-код, время ответа, тип контента, наличие нужных ключей в JSON, непустые значения, соответствие формату. За пару кликов получается набор из 6–8 тестов на один запрос, и знание JavaScript для этого не требуется. Результаты видны сразу после Send во вкладке Test Results — зелёным помечены прошедшие проверки, красным упавшие.

Автоматизация рутины: токен, cURL и Runner

Токен авторизации обычно живёт 24 часа, и вручную копировать его каждый день из ответа /token в Authorization коллекции — трата времени. Решается это скриптом в Tests запроса /token:
pm.test("Token saved to environment", function () {
const token = pm.response.json().token;
pm.environment.set("TOKEN", token);
});
Дальше в Authorization коллекции указывается {{TOKEN}} — и после каждого выполнения /token переменная окружения обновляется автоматически, а все остальные запросы коллекции сразу работают с новым значением.
Если на проекте нет готовой коллекции Postman, но есть рабочий сайт — выручает импорт из cURL: открываем DevTools → Network в браузере, находим нужный запрос, копируем его как cURL, вставляем в Postman через Import → Paste as Raw Text — и запрос со всеми headers, query-параметрами и телом создаётся автоматически. А для массовых прогонов есть Runner: он выполняет серию запросов коллекции подряд, любое число итераций, с задержкой между запросами (важно против rate-limit) и с возможностью подставлять данные из CSV или JSON-файла на каждую итерацию. Runner удобен и для генерации тестовых данных пачками, и для прогона целого end-to-end сценария — от создания сущности до получения финального результата — за секунды вместо ручного повторения одних и тех же шагов.
Освоить весь этот функционал по документации реально, но по-настоящему он оседает в голове, когда собираешь коллекцию для конкретного проекта и объясняешь ментору, зачем выбрал именно Inherit from parent, а не ручной заголовок. На курсе «Инженер по ручному тестированию» работа с Postman — часть практики Спринта 7: своя коллекция, переменные, автотесты через Postbot и прогон через Runner проверяет ментор, а не автоматический чекер, так что видно не только то, что тесты прошли, но и то, насколько разумно построена структура.
-------

Полезные ссылки школы

Сайт Quality Academy:
/main
Telegram-канал:
https://t.me/quality_academy
YouTube-канал:
https://www.youtube.com/@quality_academy
ВКонтакте:
https://vk.com/quality_academy
Канал отзывов учеников (58+ отзывов):
https://t.me/quality_academy_reviews
Задать вопрос менеджеру:
https://t.me/quality_academy_bot
Тест «Подойдёт ли вам тестирование»:
https://quiz.quality-academy.ru
5000+ вопросов с собесов тестировщика — бот-тренажёр:
https://t.me/quality_academy_interview_bot
3 практические задачи и дорожная карта:
https://t.me/quality_academy_tasks_bot
Бесплатные тренажёры — SQL Arena, Playwright Arena, Python Arena:
SQL Arena · Playwright Arena · Python Arena