Postman для тестировщика: как тестировать REST API с нуля

Если ты работаешь Manual QA и пока проверяешь в основном интерфейс, Postman — один из самых полезных инструментов, который можно добавить в работу уже сегодня.

Не потому, что «все учат API». А потому, что большая часть современного веб-приложения живёт не в кнопках и формах, а в запросах между клиентом и сервером. Кнопка «Создать заказ» может выглядеть идеально, но сервер при этом сохранит неправильную сумму, потеряет поле, вернёт чужие данные или создаст два заказа вместо одного.

В свежих вакансиях Manual QA Postman, Swagger, SQL, REST и DevTools регулярно идут рядом даже без слова Automation. Например, в вакансиях Middle Manual QA встречаются требования тестировать API через Postman/Swagger, разбираться в SQL и анализировать запросы через DevTools. Это хороший индикатор того, что API давно перестало быть «навыком автоматизатора».

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

Если ты умеешь проверить API руками, ты уже понимаешь большую часть того, что должен проверять API-автотест. Java и REST Assured меняют способ запуска, а не смысл проверки.

Postman — API-клиент: в нём можно собрать HTTP-запрос, отправить его на сервер и изучить ответ. У запроса можно менять метод, URL, параметры, headers, body, cookies и авторизацию. Запросы сохраняются в коллекции и могут запускаться повторно.

Официальная документация Postman отдельно отмечает, что запросы можно группировать в Collections, добавлять проверки ответа и затем запускать коллекции вручную или автоматически через CLI/CI. То есть граница между «ручной проверкой API» и «автоматизированной проверкой» в самом Postman уже довольно тонкая.

Но для Manual QA главное проще. Postman позволяет отделить backend от UI.

Представь баг:

• ▸1. Пользователь нажал «Оформить заказ».
• ▸2. На экране появился тост «Заказ создан».
• ▸3. После обновления страницы заказа нет.

Без API-инструментов остаётся гадать: баг во frontend, backend, данных или вообще запрос не ушёл. С Postman и DevTools можно за несколько минут сузить причину.

Упрощённо запрос выглядит так:

1POST /api/v1/orders HTTP/1.1
2Host: shawarma.threadqa.ru
3Content-Type: application/json
4Authorization: Bearer <token>
5
6{
7  "recipeId": 42,
8  "qty": 2,
9  "payment": { "method": "CARD" }
10}

Здесь есть пять вещей, которые Manual QA должен научиться видеть:

• ▸method — что хотим сделать: GET, POST, PUT, PATCH, DELETE;
• ▸URL / endpoint — куда отправляем запрос;
• ▸headers — служебная информация, авторизация, тип данных;
• ▸body — данные, которые отправляем серверу;
• ▸response — status code, headers и тело ответа.

Если это пока выглядит страшнее обычной формы — нормально. Через один реальный запрос структура становится очевидной.

Лучший способ учить Postman — не копировать чужой https://jsonplaceholder..., а взять запрос из настоящего приложения.

У ThreadQA есть публичный учебный стенд ShawarmaShop. Открой его, затем DevTools → Network и выполни действие в интерфейсе: открой меню, авторизуйся или создай тестовый заказ, если сценарий доступен на стенде.

• Открыть учебный стенд ShawarmaShop

  Реальный интерфейс приложения для практики UI и поиска запросов в DevTools.

• Открыть Swagger UI ShawarmaShop

  Контракт API, endpoints, request body, schemas и responses.

Ниже примеры сверены с текущей OpenAPI-спецификацией Shawarma Shop API 1.0.0: REST endpoints находятся под /api/v1. При работе через DevTools всё равно сверяй фактический Request URL — именно браузер покажет, какой вызов сделал текущий frontend.

В Network включи фильтр Fetch/XHR и найди запрос, который появился после действия.

Открой его и посмотри:

• ▸Request URL;
• ▸Request Method;
• ▸Status Code;
• ▸Request Headers;
• ▸Payload / Request Body;
• ▸Response.

Если запросов много, очисти Network, повтори ровно одно действие и посмотри, какие строки появились.

Это уже полноценный навык Manual QA: ты связываешь действие пользователя с конкретным вызовом backend.

Увеличить

Быстрый путь: Copy as cURL

В Chrome DevTools можно нажать правой кнопкой по запросу → Copy → Copy as cURL.

Получится примерно так:

1curl 'https://shawarma.threadqa.ru/api/v1/orders' \
2  -H 'content-type: application/json' \
3  -H 'authorization: Bearer <token>' \
4  --data-raw '{"recipeId":42,"qty":2,"payment":{"method":"CARD"}}'

Postman умеет импортировать cURL. Поэтому вместо ручного переноса десяти headers можно:

• ▸1. скопировать запрос из DevTools;
• ▸2. открыть Postman → Import;
• ▸3. вставить cURL;
• ▸4. отправить запрос ещё раз.

Если запрос из Postman возвращает тот же результат, ты фактически вынес проверку из UI на уровень API.

Увеличить

Новички часто считают так:

200 OK → тест пройден.

Но status code — только один слой.

Допустим, сервер ответил:

1{
2  "id": 7812,
3  "status": "PENDING",
4  "recipe": { "id": 42, "name": "...", "size": "MEDIUM", "price": 445 },
5  "qty": 2,
6  "totalPrice": 890,
7  "placedAt": "2026-08-15T12:00:00Z",
8  "payment": { "method": "CARD", "status": "PENDING" }
9}

Что можно проверить?

HTTP-уровень:

• ▸для POST /api/v1/orders текущий контракт документирует 200 OK;
• ▸время ответа в разумных пределах;
• ▸Content-Type действительно JSON.

Данные:

• ▸id существует и не пустой;
• ▸status соответствует бизнес-сценарию;
• ▸totalPrice рассчитан правильно;
• ▸qty и recipe соответствуют запросу;
• ▸в ответе нет лишних персональных данных.

Бизнес-логика:

• ▸заказ появился в истории;
• ▸для оплаты повторный POST с тем же Idempotency-Key не создаёт второй платёж;
• ▸несуществующий recipeId обрабатывается предсказуемо и не приводит к 500;
• ▸qty меньше 1 не проходит валидацию.

Вот здесь начинается настоящее API-тестирование. Не «научиться нажать Send», а научиться задавать серверу неудобные вопросы.

Не зубри определения отдельно от сценариев.

GET — получить данные

Пример: получить заказ.

1GET /api/v1/orders/7812

Проверяем существующий и несуществующий ID, набор полей и фактическое поведение ошибки. Важно: для GET /api/v1/orders/{id} текущий OpenAPI перечисляет только 200, поэтому конкретный 4xx для отсутствующего заказа нельзя выдумывать — его нужно проверить на стенде и при необходимости зафиксировать как пробел контракта.

POST — создать или запустить действие

1POST /api/v1/orders

Особенно важны негативные проверки: пропущенные обязательные поля, неправильные типы, граничные значения, неизвестные recipeId и недопустимые enum-значения.

PATCH — частично изменить ресурс

В текущем ShawarmaShop PATCH используется для рецепта: PATCH /api/v1/recipes/{id}. UpdateRecipeRequest позволяет передавать name, description и price частично. Отдельно полезно проверить 404 для неизвестного рецепта и 409, если новое имя уже занято.

1{
2  "price": 399
3}

POST как бизнес-действие: pay и cancel

POST не обязательно означает «создать сущность». В ShawarmaShop POST /api/v1/orders/{id}/cancel отменяет PENDING-заказ, а POST /api/v1/orders/{id}/pay запускает оплату. У pay обязательный header Idempotency-Key — отличный сценарий для проверки повторных запросов.

Подробнее про методы и их семантику смотри в отдельном материале: HTTP для тестировщика: методы, коды, headers и cookies.

Три конструкции часто смешиваются.

Path parameter

1/api/v1/orders/7812

7812 идентифицирует конкретный заказ.

Query parameter

1/api/v1/ingredients?lowStock=true

Здесь lowStock=true фильтрует склад и оставляет только ингредиенты ниже порогового запаса. В /api/v1/orders есть отдельные фильтры status, fromDate, toDate, minPrice, maxPrice и recipeId.

Request body

1{
2  "recipeId": 42,
3  "qty": 2,
4  "payment": { "method": "CARD" }
5}

Это данные запроса.

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

Не надо помнить сотни HTTP headers. Начни с нескольких:

1Content-Type
2Accept
3Authorization
4Cookie
5User-Agent
6Origin

Content-Type: application/json говорит, какой формат тела отправляется. Authorization часто несёт Bearer token. Cookie может участвовать в сессионной авторизации. Origin важен при разборе CORS.

Если запрос работает в браузере, но не работает в Postman, сравнение headers — один из первых шагов диагностики.

В текущей спецификации ShawarmaShop используется bearer-jwt. Токен выдаёт POST /api/v1/auth/login, а GET /api/v1/auth/me явно документирует 401 Unauthorized без корректной авторизации.

После логина JwtResponse содержит token, type, username и expiresIn. В Postman сохрани token в environment variable и передавай его как Bearer Token — так не придётся копировать JWT в каждый запрос.

Например:

1Authorization: Bearer eyJhbGciOi...

Но здесь важна безопасность: не публикуй реальные production tokens, cookies и персональные данные в скриншотах, GitHub, публичных Postman collections и статьях.

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

Автоматизатор может быстро написать код. Но если он не умеет придумывать сценарии, код просто быстро проверит малоинтересные случаи.

Попробуй для создания заказа такие варианты:

1{"recipeId":42,"qty":0,"payment":{"method":"CARD"}}

1{"recipeId":42,"qty":-1,"payment":{"method":"CARD"}}

1{"recipeId":999999999,"qty":1,"payment":{"method":"CARD"}}

1{"recipeId":42,"qty":1,"payment":{"method":"CRYPTO"}}

1{"recipeId":42,"qty":1}

А затем спроси:

• ▸какой фактический 4xx возвращается и описан ли он в OpenAPI? Если нет — это contract gap;
• ▸сообщение об ошибке понятно?
• ▸структура ошибки единообразна?
• ▸данные в БД не изменились после невалидного запроса?
• ▸повторный запрос ведёт себя предсказуемо?

Последний пункт уже выводит нас к SQL. В ShawarmaShop заказ сохраняется в реальную таблицу orders: там есть recipe_id, qty, total_price, status, placed_at, paid_at и completed_at. После API-проверки можно взять response.id и одним SELECT убедиться, что persistence совпадает с OrderResponse. Для оплаты проверка продолжается в payments, где хранится order_id, UNIQUE idempotency_key, amount, method, txn_id и status.

Postman позволяет добавить небольшой JavaScript после ответа.

Например:

1pm.test("Create order returns 200", function () {
2    pm.response.to.have.status(200);
3});
4
5pm.test("Order has id", function () {
6    const body = pm.response.json();
7    pm.expect(body.id).to.exist;
8});
9
10pm.test("New order is PENDING", function () {
11    const body = pm.response.json();
12    pm.expect(body.status).to.eql("PENDING");
13    pm.expect(body.qty).to.eql(2);
14});

Это полезный промежуточный шаг. Ты всё ещё работаешь в Postman, но уже формализуешь ожидаемый результат.

Сохрани запросы в Collection. Сделай последовательность:

• ▸1. POST /api/v1/auth/login → сохранить JWT;
• ▸2. GET /api/v1/recipes → выбрать recipeId;
• ▸3. POST /api/v1/orders → получить PENDING-заказ;
• ▸4. GET /api/v1/orders/{id} → сверить заказ;
• ▸5. POST /api/v1/orders/{id}/cancel → отменить PENDING-заказ.

И попробуй запустить коллекцию целиком.

Отдельный сильный сценарий — оплата: создай новый заказ и вызови POST /api/v1/orders/{id}/pay с Idempotency-Key. Затем повтори тот же запрос с тем же ключом. По контракту должен вернуться уже созданный платёж без повторного похода к провайдеру. Сравни id/txnId и GET /api/v1/orders/{id}/payments, а при доступе к PostgreSQL сделай финальную проверку в payments: для этого idempotency_key не должна появиться вторая строка. В реальной схеме ShawarmaShop это поле UNIQUE NOT NULL.

В этот момент обычно происходит важный щелчок: ручная проверка начинает превращаться в повторяемый тестовый сценарий.

Возьмём нашу проверку:

1POST /api/v1/orders
2ожидаем HTTP 200
3ожидаем status в JSON = PENDING

В Java с REST Assured идея остаётся практически той же:

1CreateOrderRequest order = new CreateOrderRequest(
2    42L, 2, new PaymentChoice("CARD")
3);
4
5given()
6    .contentType(ContentType.JSON)
7    .header("Authorization", "Bearer " + token)
8    .body(order)
9.when()
10    .post("/api/v1/orders")
11.then()
12    .statusCode(200)
13    .body("status", equalTo("PENDING"))
14    .body("qty", equalTo(2));

Обрати внимание: бизнес-проверка не изменилась.

В Postman ты выбрал POST, передал JSON и глазами/скриптом проверил ответ. В Java ты описал то же самое кодом.

Зато теперь этот тест можно:

• ▸запускать автоматически после каждого изменения;
• ▸хранить рядом с остальными тестами в Git;
• ▸запускать десятки и сотни сценариев;
• ▸формировать Allure-отчёты;
• ▸подключать к CI/CD;
• ▸вместе с API проверять PostgreSQL, Kafka и внешние интеграции.

Вот почему API — один из лучших мостов из Manual QA в Automation.

Если Postman и HTTP уже перестали выглядеть магией, не нужно ждать момента, когда ты «полностью готов к программированию». На курсе Java QA Automation от ThreadQA путь начинается с основ Java, а затем знакомые QA-проверки переносятся в REST Assured, Selenide, PostgreSQL, Kafka и CI/CD на проекте ShawarmaShop.

Перед тем как закрыть задачу, пройдись по списку:

• ▸правильный HTTP method;
• ▸корректный endpoint;
• ▸обязательные headers;
• ▸позитивный сценарий;
• ▸обязательные/необязательные поля;
• ▸граничные значения;
• ▸неправильные типы;
• ▸пустые значения;
• ▸несуществующие ID;
• ▸права доступа;
• ▸повторный запрос;
• ▸структура успешного ответа;
• ▸структура ошибки;
• ▸состояние данных после запроса;
• ▸поведение UI при API-ошибке.

Не каждый пункт нужен каждому endpoint. Но сам способ мышления пригодится почти всегда.

Если твоя цель — стать сильнее как Manual QA, двигайся так:

HTTP → DevTools → Postman → Swagger/OpenAPI → SQL.

Если цель — Automation:

HTTP → Postman → Java → REST Assured → PostgreSQL → CI/CD.

Следующие материалы к этому гайду:

• ▸HTTP для тестировщика: методы, status codes, headers и cookies
• ▸Swagger/OpenAPI для тестировщика: как читать контракт API
• ▸Chrome DevTools для тестировщика: Network, Console и Application
• ▸SQL для тестировщика: 20 запросов из реальной работы
• ▸XPath Practice Hub — бесплатный тренажёр ThreadQA

Нужно ли Manual QA знать Postman?

Для веб- и backend-продуктов это один из самых практичных навыков. Даже если ты не пишешь автотесты, Postman помогает проверять API отдельно от UI и быстрее локализовывать дефекты.

Нужно ли сначала выучить HTTP?

Не обязательно откладывать практику. Отправь несколько запросов в Postman, а затем разберись с методами, кодами и headers — так теория запоминается быстрее.

Postman — это автоматизация тестирования?

Он умеет выполнять автоматические проверки и запускать коллекции, но в вакансиях под QA Automation обычно ожидают ещё язык программирования, тестовый фреймворк, Git, CI/CD и библиотеки вроде REST Assured.

Что лучше учить после Postman — Java или SQL?

Для Manual QA SQL даст быстрый эффект прямо в текущей работе. Если цель — перейти в Java QA Automation, Java и REST Assured можно начинать параллельно, постепенно подключая SQL и PostgreSQL.

Где потренироваться?

Возьми любое тестовое веб-приложение, открой Network, найди запрос и перенеси его в Postman. В ThreadQA для практики используется ShawarmaShop — реальный учебный backend, вокруг которого построены API, UI, PostgreSQL, Kafka и другие задачи курса.