Как ответить на вопрос «Как вы работаете в Postman» на собеседовании QA

Зачем это спрашивают

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

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

Как построить сильный ответ

Расскажите о работе как о процессе, от организации до запуска.

Организация

• Коллекция — набор запросов к сервису, разбитый на папки по сущностям или сценариям: «Авторизация», «Каталог», «Заказы».
• Импорт — коллекцию не обязательно собирать руками: Postman умеет создавать её из описания OpenAPI, которое лежит за Swagger, или из cURL, скопированного в DevTools.
• Авторизация настраивается на уровне коллекции или папки, а запросы её наследуют. Токен не дублируется в каждом запросе.

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

В запросах вместо конкретных значений стоят ссылки: {{baseUrl}}/api/products/{{productId}}. Значения живут в нескольких областях:

Окружение заводится на каждый стенд: dev, test, stage. Переключили — и та же коллекция работает с другим сервером. У переменной есть общее значение, которое видит команда, и локальное, которое остаётся только у вас; секреты держат в локальном.

Скрипты и проверки

Postman выполняет JavaScript до отправки запроса и после получения ответа (в новых версиях это вкладка Scripts, разделы Pre-request и Post-response; раньше вторая называлась Tests). После ответа пишут проверки и сохраняют значения для следующих запросов:

pm.test("Заказ создан", () => {
  pm.expect(pm.response.code).to.be.oneOf([200, 201]);
});

const body = pm.response.json();
pm.test("В ответе есть id заказа", () => {
  pm.expect(body).to.have.property("id");
});
pm.environment.set("orderId", body.id);

Так строится цепочка: вход сохраняет токен, создание заказа сохраняет его id, следующий запрос читает заказ по {{orderId}} и проверяет, что он сохранился.

Запуск

Collection Runner прогоняет коллекцию или папку целиком, в том числе с файлом данных — удобно для одного запроса с десятком наборов входных значений. Для запуска вне интерфейса есть Newman:

newman run shop.postman_collection.json -e test.postman_environment.json

Пример ответа

В Postman я сначала собираю коллекцию: импортирую описание из Swagger, раскладываю запросы по папкам по сущностям. Адрес стенда, тестового пользователя и токен выношу в переменные окружения, а в запросах использую только ссылки на них, поэтому коллекция переключается между стендами одним выбором окружения. Секреты храню в локальных значениях, чтобы они не попали в общую коллекцию. Авторизацию настраиваю на уровне коллекции, чтобы не копировать токен. В скриптах после ответа пишу проверки: статус, обязательные поля, типы. Оттуда же сохраняю id созданного объекта и использую его в следующем запросе — так получаются сценарии «создал — прочитал — удалил». Коллекцию запускаю через Runner, при необходимости через Newman.

Частые ошибки

• Рассказывать только о кнопке Send и ручном просмотре ответа.
• Хранить адрес и токен в каждом запросе вместо переменных.
• Выгружать коллекцию с реальными паролями и токенами в общее рабочее пространство или репозиторий.
• Путать окружение с коллекцией и не уметь объяснить, зачем нужны разные области переменных.
• Писать проверку только на статус: тест с одним status 200 пропустит пустое или неверное тело.

Пример на MarketCove

Как бы вы собрали коллекцию для учебного магазина MarketCove:

1. Импортируйте описание API из Swagger на /api/docs и создайте окружение с переменной baseUrl, указывающей на магазин.
2. Найдите в группе /api/shop/auth/* запрос входа. В его скрипте после ответа сохраните токен в переменную окружения, а авторизацию коллекции настройте на эту переменную.
3. Папка «Каталог»: GET /api/products с проверкой, что пришёл массив и у каждого товара есть цена; сохраните id первого товара в productId.
4. Папка «Заказы»: оформление через /api/shop/orders с {{productId}}, сохранение id заказа, затем GET /api/orders с проверкой, что заказ появился.
5. Негативная папка: GET /api/users/me без токена и с испорченным токеном (ожидаемо 401), GET /api/products/{id} с несуществующим id (404), оформление без обязательного поля адреса — с проверками ожидаемых 4xx. Учтите, что запрос оформления без токена негативом не считается: магазин разрешает гостевые заказы.

Помните, что магазин хранит заказы и аккаунты в памяти сервера: после перезапуска данные могут исчезнуть, поэтому цепочка должна сама создавать всё, что ей нужно, а не опираться на старые id.

Задание для практики

Соберите описанную коллекцию из трёх папок для API-песочницы или магазина и добейтесь, чтобы она проходила целиком через Collection Runner без ручных правок. Затем создайте второе окружение с неверным адресом и убедитесь, что меняется только окружение, а не запросы. Чтобы решить, какие проверки добавить в скрипты, используйте чек-лист тестирования API.