Введение в тестирование API в Postman: первые запросы и базовые проверки

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

Ниже — авторский учебный набор из GET и POST к публичному Postman Echo. Сервис отражает переданные данные; условный «заказ» в JSON не создаёт реальную покупку. На таком примере удобно разобраться с настройками клиента, прежде чем подключать рабочий стенд и его авторизацию.

Коллекция и окружение решают разные задачи

Создайте учебную коллекцию Echo Lab. В неё сохраним два запроса: GET — параметры и POST — JSON. В имени сценария полезно видеть назначение, а не только метод: через неделю набор из пяти вкладок «New Request» мало поможет вспомнить ожидания.

Создайте окружение Training Echo и переменную base_url со значением https://postman-echo.com. Сохраните значение в доступном поле редактора переменных и выберите это окружение для отправки запросов. Конкретные подписи полей зависят от версии Postman, но смысл одинаков: переменная должна иметь значение в выбранной области.

{{base_url}}/get?batch=demo17

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

В этом упражнении секретов нет. Для рабочего API хранение credentials и доступ участников к ним организуются отдельно. Переименование окружения само по себе не меняет сервер: значение base_url нужно проверить перед отправкой.

GET: передаём параметр и читаем ответ

Создайте GET к указанному адресу. Во вкладке Params убедитесь, что batch имеет значение demo17. Body в этом опыте пустой. Нажмите Send и сохраните запрос в Echo Lab.

Посмотрите три части ответа. Статус сообщает результат HTTP-обработки. Заголовки описывают ответ, например формат Content-Type. Тело содержит возвращённые данные; у Echo найдите объект args и значение batch. Наше ожидание — строка demo17, потому что этот запрос проверяет отражение текстового query-параметра.

Отдельно заметьте время и размер ответа, которые показывает клиент. Они полезны для наблюдений, но не становятся нормативом скорости API сами по себе. Если у проекта есть требование к времени, сравнивайте с ним при оговорённых условиях, а не с произвольной цифрой из учебного примера.

POST: отправляем именно JSON

Второй запрос направим на {{base_url}}/post с методом POST. В Body выберите raw и формат JSON, затем введите:

{
  "orderId": "demo-17",
  "quantity": 2,
  "isGift": false
}

Проверьте заголовок Content-Type: application/json. Посмотрите фактически отправляемые настройки и убедитесь, что вручную не задан конфликтующий заголовок. Нажмите Send.

При контрольной отправке этого JSON 4 ноября 2026 года endpoint вернул HTTP 200, а поле json содержало orderId: "demo-17", quantity: 2 и isGift: false. Эти наблюдения используем как исходные ожидания нашего учебного опыта; при повторении сначала проверьте фактический ответ сервиса. Это важно: POST не означает обязательный 201 для любого сервиса. В нашем упражнении сервис возвращает запрос, а не сообщает о создании настоящего ресурса. Ожидание статуса определяется контрактом конкретного endpoint.

В отражённом объекте orderId должен остаться строкой, quantity — числом 2, isGift — логическим false. Если отправить "2" в кавычках, это будет другой JSON-тип. На Echo изменение может успешно отразиться; отклонение неверного количества нужно проверять на API, где такое бизнес-правило действительно задано.

Небольшие проверки после ответа

В актуальных версиях Postman откройте Scripts → Post-response у POST-запроса. В прежних материалах этот раздел часто называют вкладкой Tests. Поместите туда два именованных теста:

pm.test('Echo POST вернул 200', () => {
    pm.response.to.have.status(200);
});

pm.test('JSON заказа отражён с нужными типами', () => {
    const response = pm.response.json();
    pm.expect(response.json).to.be.an('object');
    pm.expect(response.json.orderId).to.eql('demo-17');
    pm.expect(response.json.quantity).to.be.a('number');
    pm.expect(response.json.quantity).to.eql(2);
    pm.expect(response.json.isGift).to.eql(false);
});

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

Измените quantity в запросе на строку "2" и отправьте повторно. Для этого упражнения статус может остаться успешным, а проверка числового типа должна перестать проходить. Это намеренная учебная смена данных, а не найденный дефект Echo. Верните число 2 и снова убедитесь, что исходный сценарий проходит.

Если тело вообще не является JSON, pm.response.json() не сможет его разобрать. Сначала посмотрите сырой ответ и Content-Type. Не подменяйте анализ проверкой, что слово quantity где-то встречается в тексте: такая строка может находиться на HTML-странице ошибки и ничего не говорить о структуре объекта.

GET тоже можно проверить, но ожидания другие

В Post-response первого запроса добавьте отдельную короткую проверку:

pm.test('GET отразил batch', () => {
    const response = pm.response.json();
    pm.expect(response.args.batch).to.eql('demo17');
});

Она обращается к args, потому что проверяет query-параметры GET. У POST мы обращались к json, потому что проверяли отправленное JSON-тело. Названия полей относятся к формату Echo; у другого сервера структура будет иной. Сначала изучайте полученный объект, затем пишите путь к полю.

Не копируйте один и тот же тест на все методы. Например, требование status=200 может быть неверным для endpoint, который по контракту создаёт ресурс с 201 или подтверждает обработку без тела. Проверка должна объяснять ожидаемое поведение выбранного сценария, а не просто возвращать зелёный цвет.

Что сохранять для повторного запуска

Сохраните в коллекции метод, адрес с переменной, параметры, заголовки, тело и сценарии проверок. Запишите в описании: выбранное окружение Training Echo, ожидаемый статус POST 200 и отражение учебного JSON. Коллекция хранит запросы, а само значение окружения проверяйте отдельно: перенос одной коллекции не является проверкой всех связанных настроек.

Авторский контроль воспроизводимости: закройте вкладку, снова откройте сохранённый запрос, выберите окружение и отправьте его. Если поведение изменилось, сравните реальный URL, метод, Body и headers с исходной записью. Не исправляйте тест только ради исчезновения красного результата, пока не выясните причину расхождения.

Частые ошибки на первом наборе запросов

Симптом	С чего начать
Переменная не подставилась	Выбранное окружение, имя и область base_url
Сервер не видит ожидаемое JSON-тело	Метод, raw JSON и фактический Content-Type
Статус проходит, тело не проходит	Ожидаемые поля, типы и значения, а не только код ответа
После переоткрытия сценарий другой	Сохранены ли изменения запроса и какое значение окружения выбрано
Тест проверяет чужую структуру	Не перенесён ли путь args из GET в другой формат ответа

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