Введение в API-тестирование: первый запрос в Postman и базовая проверка JSON-ответа
Проверка API начинается не с большого набора автотестов, а с понятного вопроса к одному запросу: что отправили, какой ответ ожидали и что получили? Postman позволяет выполнить такой запрос напрямую, без нажатия кнопок в интерфейсе приложения. Это помогает отделить поведение серверного метода от отображения страницы.
Разберём авторское упражнение на публичном Postman Echo. Оно показывает передачу параметров и чтение JSON, но не имитирует полноценный магазин: Echo возвращает сведения о запросе, а не проверяет выдуманные правила покупки курса. Затем на отдельном условном контракте рассмотрим негативные сценарии и описание дефекта.
Что именно проверяется без интерфейса
В пользовательском интерфейсе выбор курса может сопровождаться формой, подсказками и кнопкой. API-проверка обращается к серверному адресу напрямую и рассматривает его контракт: допустимый метод, параметры, права, структуру ответа и правила ошибок. Красиво отрисованная страница не доказывает, что сервер отклоняет неверные данные, а успешный API-ответ не подтверждает корректное отображение страницы.
Перед запросом полезно сформулировать ожидаемый результат. Для Echo наш критерий скромный: GET выполнен, сервер вернул JSON, а переданные course=python и level=basic доступны в объекте args. Проверять оплату или существование учебного курса по этому ответу нельзя.
Адрес, метод, заголовки и тело
GET https://postman-echo.com/get?course=python&level=basic| Элемент | Роль в примере |
|---|---|
| Схема и сервер | https://postman-echo.com — куда отправляется запрос |
| Путь | /get — выбранная точка обращения |
| Метод | GET — действие запроса; его выбирают отдельно от адреса |
| Query-параметры | course и level после ?; пары разделены & |
| Headers | Служебные сведения запроса, например предпочтительный формат ответа |
| Body | Для этого GET-упражнения оставляем пустым |
Метод и путь нужно читать вместе. Одинаковый адрес с другим методом может обозначать другую операцию или не поддерживаться сервером. Не переносите данные в произвольное место только потому, что Postman позволяет заполнить поле: расположение параметра определяется контрактом API.
Accept и Content-Type отвечают на разные вопросы. Первый может сообщать, какой формат ответа клиент предпочитает; второй описывает формат передаваемого содержимого. В ответе Content-Type помогает понять, что именно прислал сервер. Заголовок с названием JSON ещё не заменяет проверку самого тела.
Первый запрос и сохранение результата работы
- Откройте Postman и создайте HTTP-запрос в новой вкладке.
- Выберите GET и вставьте адрес из примера.
- На вкладке Params проверьте две пары: course — python, level — basic. Если вставили URL целиком, не добавляйте эти параметры вторым экземпляром.
- Для этого открытого учебного endpoint не задавайте собственную авторизацию и не добавляйте рабочие токены других проектов.
- Нажмите Send и дождитесь ответа. Посмотрите статус, заголовки и тело.
- Сохраните запрос в отдельную учебную коллекцию с именем, отражающим сценарий, например Echo — параметры курса.
На этом этапе удобно изменить только level с basic на advanced, повторить отправку и сравнить соответствующее значение в args. Восстановите basic после опыта, если сохранённый сценарий должен оставаться исходной проверкой. Так вы контролируете изменение одной переменной, а не пытаетесь объяснить сразу несколько отличий.
Если ответа вообще нет, не путайте транспортную ошибку со статусом API. Сообщение Postman о невозможности соединения отличается от полученного HTTP 404. Сначала установите, дошёл ли запрос до сервера и вернулся ли HTTP-ответ; затем разбирайте его содержание.
Как читать JSON вручную
В ответе Echo найдите следующий фрагмент. Остальные поля ответа здесь опущены, чтобы сосредоточиться на переданных параметрах:
{
"args": {
"course": "python",
"level": "basic"
}
}Фигурные скобки обозначают объект; имена его полей записываются строками в двойных кавычках. Значение args — вложенный объект. Значения course и level в нашем примере — строки. Массив, объект, число, строка, логические значения и null — разные виды JSON-значений; похожее отображение не делает их взаимозаменяемыми.
Для каждого важного поля проверьте четыре вещи: существует ли ключ, имеет ли значение ожидаемый тип, подходит ли само значение и согласуется ли оно с другими полями. Например, "101" — строка, а 101 — число. В показанном ответе от 4 ноября 2026 года значения python и basic получены как строки. Это наблюдение одного запроса, а не правило о типах всех параметров любого API. Ожидаемые типы на своём стенде сверяйте с его контрактом.
Отдельно различайте отсутствующее поле, null и пустую строку. Если контракт разрешает неизвестное отчество как null, отсутствие ключа может иметь другой смысл. Не придумывайте правило по одному увиденному ответу: ожидаемая структура берётся из документации или явно согласованного учебного контракта.
Минимальные позитивные и негативные сценарии
Позитивная проверка использует допустимые данные и ожидает описанный результат. Негативная намеренно нарушает конкретное условие, чтобы проверить предусмотренную реакцию. Для учебного API каталога представим отдельный контракт: GET /courses/101 возвращает существующий курс, закрытый метод требует авторизации, а недопустимый фильтр имеет описанную ошибку.
| Сценарий на своём стенде | Что изменить | Что сверить |
|---|---|---|
| Допустимый запрос | Использовать известный идентификатор и разрешённые параметры | Статус, типы, идентификатор и обязательные поля по контракту |
| Неверный параметр | Передать недопустимое значение одного фильтра | Документированную ошибку, её код и объяснение |
| Нет авторизации | Убрать credentials у метода, которому они нужны | Предусмотренный отказ; 401 относится к отсутствующим действительным данным аутентификации |
| Нет ресурса | Выбрать заведомо отсутствующий объект | Ожидаемую реакцию, например документированный 404, и тело ошибки |
Это не набор обещаний поведения Echo. Если добавить course=несуществующий в Echo, он может просто отразить текст: у него нет нашего каталога курсов. Аналогично открытый endpoint не обязан вернуть 401 после удаления заголовка авторизации, который ему изначально не требовался.
Не делайте вывод «любой неправильный запрос должен дать 400». Конкретный статус и формат ошибки зависят от смысла запроса и контракта. Даже при ожидаемом 200 нужно проверить данные: сервер способен вернуть успешный транспортный статус и неверное бизнес-содержимое.
Как описать найденное расхождение
Представим условный дефект учебного каталога: спецификация требует числовой id, а сервер вернул строку. В описании результата зафиксируйте:
- стенд и версию API или документации;
- метод, путь, параметры и необходимые условия доступа без самих секретов;
- точные шаги воспроизведения и использованные учебные данные;
- ожидаемое: поле id имеет числовой тип и значение 101;
- фактическое: поле id содержит строку "101", с минимальным фрагментом JSON;
- статус ответа, время проверки и идентификатор запроса, если сервер его предоставляет.
Такое описание объясняет расхождение, а не просто сообщает «API не работает». Приложенный запрос должен позволять коллеге повторить ситуацию на разрешённом стенде. Перед передачей удалите пароли, cookies и токены: они не нужны для понимания типа поля.
После первого упражнения у вас должен остаться сохранённый запрос и понятный ожидаемый ответ. Затем добавляйте новые сценарии по одному. Полезный результат API-проверки — не количество нажатий Send, а установленное соответствие конкретного запроса его контракту.
