Postman и API-тестирование на собеседовании QA: что знать и как тренироваться
Вопросы про Postman быстро показывают разницу между «знаю слова про API» и «умею отправить запрос и понять ответ». Интервьюер смотрит не на кнопку Send, а на ход мысли.
- Метод и URL
- Auth и headers
- Body и параметры
- Статус, схема и данные
Что нужно уметь в Postman
Создать запрос, выбрать GET или POST, добавить query-параметры, отправить JSON в body, поставить Authorization header и прочитать status code с response body.
Для собеседования это важнее продвинутой автоматизации. Кандидат, который понимает один ответ, сильнее кандидата, который выучил названия вкладок.
Какие проверки ждут от тестировщика
У каждого API-ответа проверяй четыре слоя: код, структуру, значения и побочный эффект. 200 с неправильной суммой — баг. 422 с неправильным именем поля — тоже баг.
- Код ответа соответствует ситуации.
- Обязательные поля есть и имеют нужные типы.
- Важные значения соответствуют запросу и требованиям.
- Ошибки не показывают stack trace и внутренние пути.
- Повтор запроса не создаёт случайные дубли.
Проверки авторизации в API
Каждый защищённый запрос проверь с валидным токеном, без токена, с битым токеном и с токеном другого пользователя. Много серьёзных API-дефектов живёт именно в последнем случае.
Если endpoint возвращает данные, спрашивай: чьи это данные? Аутентификация говорит, кто ты; авторизация решает, что тебе можно видеть.
Типичные ошибки на интервью по Postman
Частые ошибки: отправлять только happy path, не смотреть body после 200, забывать headers и не сохранять точный запрос, на котором дефект воспроизвёлся.
Хорошая привычка: после подозрительного ответа сразу записывать method, path, body и response. Это уже половина багрепорта.
Практика перед собеседованием
Возьми любой учебный API и проверь один endpoint с валидными данными, без обязательного поля, с неверным типом, на границе, без токена и с id чужого объекта.
Умение объяснить ожидаемый ответ в каждом случае и написать багрепорт по результату — хорошая база для большинства junior-вопросов про Postman.
Реальные проверки в Tests, а не console.log
Каждый тест должен сообщать, какое обещание нарушено. Отдельные assertions быстрее локализуют причину, чем один большой блок. Сначала проверяй статус и тип ответа, затем схему и бизнес-значения; только после этого сохраняй id для следующего запроса.
Скрипт ниже не доказывает корректность заказа целиком, но создаёт хороший минимальный сигнал: ответ создан, JSON читается, обязательные поля имеют ожидаемый тип, сумма положительна, а id можно безопасно передать дальше.
pm.test("order created", () => pm.response.to.have.status(201));\n\nconst body = pm.response.json();\npm.test("contract and values", () => {\n pm.expect(body).to.have.property("id").that.is.a("number");\n pm.expect(body).to.have.property("status", "new");\n pm.expect(body.total).to.be.a("number").and.above(0);\n});\n\npm.collectionVariables.set("orderId", body.id);
Переменные, цепочки, Runner и CI
Выбирай минимальный scope: local для временного секрета, data variables для строки Runner, environment для адреса и окружения, collection для данных сценария. Не коммить реальные токены в exported collection. Созданные тестом записи помечай уникальным префиксом и удаляй в teardown, если это разрешено.
- Pre-request script создаёт уникальные данные или обновляет токен.
- Tests сохраняет id ответа только после проверки контракта.
- Следующий запрос использует {{orderId}} и проверяет тот же объект.
- Collection Runner повторяет сценарий по CSV/JSON-набору, включая negative data.
- Postman CLI или Newman запускает ту же коллекцию в CI и возвращает ненулевой exit code при падении.
Вопросы, которыми углубляют ответ на интервью
Важно не перечислять вкладки, а разобрать последствия. Почему тест на 200 слабый? Где хранить secret? Как отличить 401 от 403? Что произойдёт при повторе POST после timeout? Как проверить pagination, rate limit и чужой object id?
Сильный кандидат проговаривает oracle: откуда взят expected result. Это OpenAPI, acceptance criterion, RFC, запись после GET, состояние базы или согласованное бизнес-правило. Без oracle даже красивый скрипт лишь закрепляет текущее поведение.
Разбор: заказ создан, но итоговая сумма неверна
Вместо набора несвязанных запросов собери одну воспроизводимую цепочку: вход, чтение каталога, добавление в корзину, применение промокода, создание заказа и повторное чтение. На каждом шаге есть свой oracle — независимое ожидаемое значение, а не только HTTP-код.
- Создать уникальные тестовые данные и авторизоваться.
- Получить цену и сохранить product_id.
- Создать заказ и вычислить ожидаемый total.
- Перечитать заказ и проверить побочные эффекты.
Не скрывай окружение в переменных
Храни base_url и тестовый токен в environment, но не публикуй секреты вместе с коллекцией. Переменная product_id должна появиться из ответа каталога, а не из id случайного старого товара. Для независимых прогонов создай отдельную корзину и уникального пользователя; общий аккаунт заставляет тесты влиять друг на друга. Запиши, какие значения получены динамически и какие фиксированы контрактом.
Проверяй значения, а не только схему
Схема гарантирует, что total является числом, но не то, что оно правильно. Для двух книг по 690 RUB и скидки 10% ожидаем 1 242 RUB, если скидка применяется к обоим товарам и округление согласовано. Тест должен сравнить цену каталога, строки заказа, скидку, итог и валюту. Если формула или порядок скидок не описаны, это вопрос к контракту, а не повод зафиксировать наблюдаемую сумму как истину.
Читай результат после записи
POST может вернуть 201 с красивым JSON, но в базе заказ окажется с другой суммой или без промокода. Выполни GET /orders/{id}, а при наличии доступа проверь записи и количество списаний. Для идемпотентной операции повтори запрос с тем же ключом и убедись, что новый заказ не появился. Но не предполагай, что любой POST обязан быть идемпотентным: это должно быть частью контракта конкретной операции.
Сделай коллекцию диагностируемой
Assertion должен сообщать, что именно расходится: `expected_total=1242, actual_total=1380`, а не только `test failed`. Группируй запросы по сценарию и очищай тестовые данные согласованным способом. В CI запускай коллекцию с отдельным environment и сохраняй отчёт; падение, вызванное старым токеном или общим тестовым пользователем, нужно отличать от дефекта продукта.
const body = pm.response.json();\npm.test("created order has the agreed total", () => {\n pm.response.to.have.status(201);\n pm.expect(body.currency).to.eql("RUB");\n pm.expect(body.total).to.eql(1242);\n});\npm.environment.set("order_id", body.id);\n// Next request: GET /orders/{{order_id}} and compare persisted total.
Где здесь реальный баг?
Если POST возвращает 201 и валидную схему, но `total=1380` вместо 1242 по утверждённому правилу, это функциональный дефект. Если POST вернул 1242, а последующий GET — 1380, это проблема сохранения или чтения. Если оба ответа равны 1242, но списание 1380, ошибка находится ещё дальше в цепочке. Такие различия важнее названия инструмента.
Второй кейс: отрицательные запросы и контракт версии API
Счастливый путь уже работает. Теперь представь, что команда добавила обязательное поле `delivery_address` в POST /orders, а старое мобильное приложение его не отправляет. Это вопрос не только валидации тела, но и обратной совместимости на этапе выкладки разных версий клиента и сервера.
Опиши матрицу версий
Старый клиент + старый сервер — базовая линия. Старый клиент + новый сервер — главный риск при серверном rollout. Новый клиент + старый сервер — риск при откате backend после выпуска приложения. Новый клиент + новый сервер — штатный путь. Не все комбинации реально возможны; выясни порядок выкладки и TTL старых мобильных версий, прежде чем удалять строки из матрицы.
Раздели валидацию и совместимость
Для нового клиента проверь missing, null, пустую строку, пробелы, слишком длинный адрес и неверный тип. Но если старый клиент вообще не знает поле, ответ 422 для него может быть регрессией, хотя формально новая схема валидна. Совместимая стратегия может делать поле необязательным на переходный период или выводить его из сохранённого профиля. Выбор зависит от продукта; QA должен показать конфликт, а не навязать реализацию.
Следи за побочными эффектами ошибки
При отказе 422 заказ, резерв товара и списание не должны возникнуть, если контракт обещает атомарность. Повтори запрос после исправления адреса и проверь, не осталось ли “полузаявки”. Если API отдаёт 400 вместо 422, это не автоматически баг: точный статус определяется опубликованным контрактом и общим соглашением команды. Проверяй также структуру ошибки и указание конкретного поля.
Проверь данные в разных слоях
Response может содержать новый адрес, а сохранённый заказ — старый из профиля. Выполни GET заказа, проверь карточку в UI и downstream событие для службы доставки. Если одна копия поля отсутствует, проблема может появиться только после оплаты. Сохраняй correlation id через всю цепочку и не делай вывод по одному ответу POST.
Закрой кейс контрактным тестом
Добавь проверку старого запроса в коллекцию или consumer-driven contract для реально поддерживаемой версии клиента. В CI можно проверить, что новый сервер принимает старый payload и возвращает поля, на которые клиент опирается. Схема JSON полезна, но сама не описывает семантику optional и default; задокументируй эти договорённости отдельно.
Client v1 + Server v1: baseline\nClient v1 + Server v2: no delivery_address; must follow support policy\nClient v2 + Server v1: rollback path; unknown field handling\nClient v2 + Server v2: valid, missing, null, empty, wrong type\nFor rejected requests: no order, reservation or charge
Что считать результатом исследования?
Матрица поддерживаемых комбинаций, фактические запросы старого клиента, согласованный контракт ошибок и проверка отсутствия побочных эффектов. Это позволяет команде выбрать порядок rollout и дату удаления старого поведения, а QA — написать воспроизводимые проверки вместо расплывчатого “протестировать API”.
Частые вопросы по Postman
Нужно ли учить JavaScript для собеседования manual QA?
Обычно достаточно прочитать JSON, объявить const, обратиться к полю, написать pm.test и pm.expect. Гораздо важнее объяснить, что и почему проверяет assertion. Требования конкретной вакансии могут быть выше.
Postman заменяет проверку базы данных?
Нет. API показывает внешний контракт. Для критичного side effect может понадобиться последующий GET, событие, запись в базе или проверка интеграции. Выбирай наблюдение, доступное на проекте и не нарушающее данные.
Чем Collection Runner отличается от Newman или Postman CLI?
Runner запускает коллекцию интерактивно в Postman. CLI-инструмент запускает её из терминала и CI, где важны environment, reporters и exit code. Проверки должны оставаться одинаковыми.
Postman — не навык сам по себе. Навык — заметить, что сервер обещал, и что он сделал на самом деле.