← назад к разделу

Когда вы нажимаете «Войти», страница не сама решает, верный ли пароль, — она отправляет запрос на сервер и получает ответ. Этот способ общения программы с сервером называется API. Тестировать можно не только кнопки, но и сам обмен — напрямую, без интерфейса, инструментом Postman: запрос в нём собирают по частям, а ответ читают статусом и телом.

запрос ответ POST{{base_url}}/orders окружение staging · base_urlhttps://staging.shop/api уходит:https://staging.shop/api/orders заголовкиContent-Type: application/jsonAuthorization: Bearer eyJhbGc тело{ "customerId": 7,"items": [{"sku": "A-1"}] }Send 201 Created{ "id": 128,"status": "NEW","total": 1500 } ждали 201 и id заказафакт совпал с ожидаемым убрали 401{ "error":"unauthorized" }тот же запрос — 401это негативная проверка проверка = статус и телопротив ожидаемого

Запрос собирают по частям: метод и адрес, в котором {{base_url}} подставляется из окружения, заголовки, тело. Send — и приходит ответ: статус плюс тело, их и сравнивают с ожидаемым. Во второй половине из того же запроса убран заголовок с токеном: адрес и тело прежние, а ответ уже 401 — это негативная проверка, и такой результат для неё ожидаемый.

Что такое API простыми словами

API — это способ, которым одна программа обращается к другой. Для тестировщика важна самая частая его разновидность — обмен по протоколу HTTP, тот же, по которому работают сайты.

Аналогия: API — это официант. Вы (страница) говорите официанту (API) «принеси список моих заказов», он идёт на кухню (сервер) и возвращается с блюдом (данными). Как устроена кухня, знать не нужно: достаточно сделать заказ и проверить, что принесли.

Зачем проверять API отдельно от интерфейса:

  • Быстрее. Перебрать десяток вариантов запроса напрямую быстрее, чем кликать через страницы.
  • Глубже. Баг бывает в API, а интерфейс его маскирует — или наоборот; прямая проверка говорит, где сломано.
  • Раньше. API часто готово раньше интерфейса — можно начинать, пока кнопок ещё нет.

Из чего состоит запрос

Запрос состоит из четырёх частей:

  • Метод — что мы хотим сделать. Основные: GET (получить данные — «покажи мои заказы»), POST (создать — «создай новый заказ»), PUT/PATCH (изменить), DELETE (удалить).
  • URL (адрес) — куда обращаемся, например example.com/api/orders.
  • Заголовки (headers) — служебная информация: формат данных, токен авторизации (кто мы такие).
  • Тело (body) — данные, которые отправляем, обычно для POST. Чаще всего в формате JSON — простом текстовом виде «ключ: значение».

Из чего состоит ответ

В ответе главное — две вещи:

  • Статус-код — короткий итог. Их стоит запомнить по группам:
    • 2xx (200, 201) — успех, всё хорошо.
    • 4xx (400, 401, 403, 404) — ошибка на нашей стороне: неверный запрос, не авторизованы, нет доступа, не найдено.
    • 5xx (500) — ошибка на сервере. Почти всегда баг.
  • Тело ответа — сами данные (обычно JSON): список заказов, сообщение об ошибке, созданный объект.

Проверка API сводится к тому же, что и везде: сравнить фактический ответ — статус и тело — с ожидаемым. Одного статуса мало: 200 говорит лишь, что сервер ответил. Сравнение выглядит так:

живой пример

// статус и тело ответа, скопированные из Postman
const статус = 201;
const тело = JSON.parse('{"id": 128, "status": "NEW", "total": 1500}');
console.log('статус 201:', статус === 201);
console.log('id заказа пришёл:', тело.id !== undefined);
console.log('заказ новый:', тело.status === 'NEW');
Запустить

Запуск примеров доступен в платном доступе. Там этот же код выполняется прямо в статье: редактор, запуск и проверка рядом с абзацем. Три дня бесплатно →

В самом Postman это пишут во вкладке Tests: статус и тело берут из pm.response, а результат виден списком пройденных и упавших проверок.

Первые шаги в Postman

Postman — бесплатная в базовом виде программа, где запрос собирают мышкой: метод, адрес, при необходимости заголовки и тело, кнопка Send.

Адрес стенда в запросы не вписывают руками: его кладут в переменную окружения и пишут {{base_url}}/orders. Переключили окружение — все запросы разом поехали на другой стенд, а не по одному.

Сценарий для тренировки:

  1. Выбрать GET, вписать адрес открытого учебного API (их ищут по запросу «public test API»), нажать Send — увидеть статус 200 и данные.
  2. Повторить с POST: отправить тело с новыми данными — 201 и созданный объект в ответе.
  3. Сделать заведомо неправильный запрос на несуществующий адрес — 404.

Три шага дают связку «запрос → ответ → статус». Дальше проверяют те же позитивные и негативные сценарии: правильные данные, пустые, неверные, без авторизации. Запрос, который шлёт сама страница, видно во вкладке Network — оттуда его копируют в Postman и меняют данные.

Коротко

  • API — обмен программ по HTTP; проверять его можно без интерфейса и раньше, чем интерфейс появится.
  • Запрос — это метод, адрес, заголовки и тело; ответ — статус-код и тело.
  • Проверка API — сравнение фактического ответа с ожидаемым; одного статуса мало, тело сверяют тоже.
  • Группы кодов: 2xx — успех, 4xx — ошибка в нашем запросе, 5xx — на сервере, почти всегда дефект.
  • Адрес стенда держат в переменной окружения: {{base_url}}/orders — переезд на другой стенд стоит одного переключения.
  • Негативные запросы — без токена, с пустым телом, с неверными данными — дают находок не меньше успешных.

Что почитать дальше