Введение в тестирование API в Postman: первый чек-лист ручного тестировщика

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

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

Зачем тестировщику понимать API до знакомства с автотестами

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

• быстрее локализовать дефект;
• проверять функциональность ещё до готовности интерфейса;
• отделять проблемы фронтенда от проблем бэкенда;
• строить сценарии осмысленно, а не проверять поведение наугад.

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

Как устроен API-запрос

В Postman новичок чаще всего работает с четырьмя базовыми частями запроса.

На практике чаще всего встречаются методы GET, POST, PUT, PATCH и DELETE. Их удобно запомнить не как набор терминов, а как смысл действий:

• GET обычно получает данные;
• POST обычно создаёт запись или запускает операцию;
• PUT заменяет представление ресурса целиком;
• PATCH меняет часть данных;
• DELETE удаляет ресурс.

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

С чего начать в Postman

Для первого проекта достаточно освоить три вещи: запрос, коллекцию и environment.

Коллекция

Коллекция — это группа сохранённых запросов. В ней удобно раскладывать ручки по модулям: авторизация, каталог, профиль, заказы. Смысл простой: не собирать один и тот же запрос заново и не терять рабочие сценарии. Коллекция также помогает показать коллеге, что именно вы проверяли.

Environment

Environment хранит набор переменных для разных контекстов работы. Например, у проекта может быть тестовый сервер и другой стенд. Вместо ручной замены адресов и служебных значений удобнее переключать окружение.

Переменные

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

Для старта обычно хватает такого набора:

• base_url — базовый адрес сервера;
• auth_token — токен, если запрос требует авторизации;
• user_id или order_id — идентификатор сущности для повторных проверок.

После отправки запроса Postman показывает ответ в нижней части окна. Там полезно смотреть как минимум на три вкладки: код ответа, тело ответа и заголовки ответа. Если запрос не сработал ожидаемым образом, для дополнительной диагностики помогает Postman Console.

Какие проверки выполнить на первом запросе

Типичная ошибка новичка — считать проверкой сам факт того, что «что-то вернулось». На самом деле первый ручной чек-лист состоит из нескольких уровней.

Код ответа

Сначала смотрят статус ответа. Он должен соответствовать сценарию. Успех не всегда означает только код 200: для разных операций возможны разные корректные ответы. Для ручного тестировщика важнее не запомнить все варианты, а сравнить поведение с ожидаемым смыслом операции. Если при заведомо неверных данных сервер отвечает как при успехе, это подозрительный результат.

Структура тела ответа

Следующий шаг — проверить, что именно пришло в теле ответа:

• ответ не пустой, если по смыслу в нём должны быть данные;
• структура выглядит ожидаемо: объект, массив, вложенные поля;
• названия полей стабильны и понятны;
• тип данных выглядит корректно: число не превращено в строку без причины, дата не похожа на произвольный текст;
• значения относятся к отправленному запросу.

Учебный пример. Если вы запрашиваете профиль пользователя с идентификатором 15, полезно проверить не только наличие поля id, но и то, что в ответе действительно возвращается 15, а не данные другого пользователя.

Обязательные поля

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

• все ли обязательные поля присутствуют;
• не равны ли они null без понятной причины;
• не пусты ли строки там, где значение ожидается всегда;
• не исчезли ли поля, на которые рассчитывает клиентская часть.

Заголовки ответа

На старте не нужно анализировать каждый header, но полезно проверить хотя бы базовые признаки ответа. Например, если вы ожидаете JSON, логично убедиться, что сервер действительно возвращает ответ подходящего типа. Это часто помогает быстро объяснить, почему клиент не может обработать данные.

Повторяемость поведения

Полезно отправить тот же запрос ещё раз. Если вы ожидаете стабильный результат, а ответ заметно меняется без видимой причины, это важное наблюдение. Для GET-запросов особенно значимо, что они предназначены для получения данных, а не для скрытых изменений состояния.

Позитивные и негативные сценарии без написания кода

Негативное тестирование API на первом этапе не требует скриптов. Во многих случаях достаточно вручную изменить запрос в Postman и посмотреть, как система отреагирует.

Позитивный сценарий

Позитивный сценарий — это корректный запрос с ожидаемыми данными. Его задача не просто «получить успешный ответ», а подтвердить, что сервер делает именно то, что должен. Если запрос создаёт сущность, стоит проверить не только код ответа, но и содержимое возвращённых данных: например, появился ли идентификатор, сохранились ли отправленные поля, не изменились ли значения неожиданным образом.

Негативные сценарии

Для первого проекта обычно достаточно нескольких простых вариантов:

1. убрать обязательное поле из тела запроса;
2. передать пустое значение вместо заполненного;
3. подставить неверный тип данных, например строку вместо числа;
4. использовать несуществующий идентификатор ресурса;
5. отправить запрос без обязательных служебных данных, если сценарий это предполагает;
6. поменять HTTP-метод и посмотреть, как система реагирует.

Учебный пример. Если ручка создания заказа требует поле productId, негативными сценариями могут быть: удалить это поле, передать пустую строку, отправить текст вместо числа или указать идентификатор товара, которого не существует. Важно ожидать не просто «какую-нибудь ошибку», а осмысленную реакцию: подходящий статус, понятный ответ и отсутствие ложного создания заказа.

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

Как зафиксировать результат проверки

Когда проблема найдена, важно оставить такую запись, чтобы другой человек мог воспроизвести ситуацию. Ниже — не обязательный отраслевой стандарт, а удобный рабочий пример для ручной фиксации результата при проверке API.

Обычно полезно сохранить:

• какой endpoint и какой HTTP-метод использовались;
• на каком окружении выполнялась проверка;
• какие данные отправлялись в запросе, если они влияют на результат;
• какой статус и какое тело ответа вернул сервер;
• какой результат ожидался;
• какие шаги позволяют повторить сценарий.

Пример такой записи может выглядеть так:

Сценарий: проверка создания заказа без обязательного productId
Запрос: POST /orders
Шаги:
1. Отправить запрос на создание заказа
2. Не передавать productId в body
3. Нажать Send
Фактический результат:
Сервер возвращает успешный статус и создаёт заказ
Ожидаемый результат:
Запрос отклоняется, создаваемой записи нет

Такой формат полезен не потому, что он «единственно правильный», а потому, что из него понятно, что именно проверялось и какой результат оказался неожиданным. Если запрос сохранён в коллекции, его ещё проще показать разработчику или коллеге по команде.

Типичные затруднения новичка

• «Я не понимаю, что должно быть в ответе». Тогда сначала нужно выяснить ожидаемый контракт: какие поля нужны, какие статусы допустимы, что считается успешным результатом.
• «Я получил ошибку и не знаю, это баг или неверно собранный запрос». Сначала стоит перепроверить метод, URL, заголовки, формат тела запроса и выбранное окружение.
• «Я всё время вручную меняю адрес и путаюсь». Это признак того, что пора вынести повторяющиеся значения в переменные.
• «Не понимаю, какие негативные сценарии придумать». Начинайте с простых изменений в данных: убрать поле, оставить пустым, исказить тип, подставить несуществующее значение.
• «Ответ пришёл, но я не вижу причину странного поведения». Сравните код ответа, тело и заголовки, а при необходимости загляните в Postman Console, чтобы увидеть дополнительные детали выполнения запроса.

Что можно считать хорошим первым результатом

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