Как тестировать API: от запроса к проверке бизнес-правил

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

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

Что проверять кроме кода ответа

Код ответа показывает, как сервер классифицировал результат на уровне HTTP-ответа, но не доказывает бизнес-успех. Допустим, создание заявки вернуло 201. Этого мало, если в теле нет идентификатора, часть полей потерялась, история действий не создалась или запись появилась дважды. Поэтому после каждого важного запроса стоит проверить не только статус, но и смысл результата.

Обычно полезно разложить проверку API на четыре слоя. Первый — контракт ответа: структура тела, обязательные поля, типы данных, сообщения об ошибке. Второй — состояние данных: можно ли потом прочитать созданную сущность и совпадают ли сохраненные значения с отправленными. Третий — границы доступа: не получает ли данные тот, кому они не положены. Четвертый — последствия операции: появился ли ожидаемый побочный эффект и не случилось ли лишнего.

• Контракт ответа: есть ли поле id, статус заявки, описание ошибки по конкретному полю.
• Состояние: можно ли прочитать созданную заявку и увидеть те же значения.
• Права: не видит ли чужой пользователь чужую заявку.
• Повторяемость: что будет, если клиент отправит тот же запрос еще раз.
• Побочный эффект: появилась ли запись в истории заявки после создания.

Такой разбор помогает не пропустить типичную ловушку: API формально «отвечает правильно», но процесс для пользователя работает неправильно. Именно здесь тестирование API становится проверкой поведения системы, а не только чтением HTTP-статусов.

Учебный набор запросов

Возьмем учебный API заявок с таким контрактом. Запрос POST /applications создает заявку. Обязательные поля: request_id, customer, product, amount. Запрос GET /applications/{id} возвращает созданную заявку. Запрос GET /applications/{id}/history показывает историю действий. Если тот же request_id приходит повторно, система должна распознать повтор и не создавать дубликат.

Ожидания в этом примере такие: успешное создание возвращает 201, неверные данные — 400, обращение без прав — 403, повтор того же запроса с тем же request_id — 200 с уже существующей заявкой. Еще раз: это не общая норма для любого API, а договоренность внутри учебного примера, чтобы было на чем отработать логику проверок.

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

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

Позитивный сценарий для API — это не просто «получили 201». Он заканчивается тогда, когда можно доказать бизнес-результат. В нашем примере после успешного POST /applications нужно сохранить id из ответа, затем прочитать заявку по этому id и сверить поля customer, product и amount. После этого отдельно проверить историю и убедиться, что там есть событие CREATED. Тогда вы подтвердите и создание, и побочный эффект.

Негативные сценарии полезно строить не абстрактно, а от конкретного риска. Если убрать обязательное поле customer, важно проверить не только 400, но и понятность ошибки: по какому полю отклонен запрос. Если открыть заявку от имени другого пользователя, важно проверить не только 403, но и отсутствие утечки данных в теле ответа. Если повторить тот же запрос, важно проверить не только код 200, но и то, что в истории не появилось второе событие создания.

Учебный пример

Учебный пример. Тестировщик отправляет запрос на создание заявки:

POST /applications
{
  "request_id": "req-1001",
  "customer": "Ирина",
  "product": "standard",
  "amount": 1200
}

Дальше он проверяет по шагам: ответ 201; в теле есть непустой id; статус равен new; запрос GET /applications/{id} возвращает те же значения полей; запрос GET /applications/{id}/history показывает ровно одну запись CREATED. Затем тестировщик повторяет исходный POST с тем же request_id. По нашему учебному контракту API отвечает 200 и возвращает тот же id. После этого история по-прежнему содержит одну запись CREATED, а не две. Практический результат такого примера — вы проверяете не только создание, но и защиту от дублей.

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

pm.test("Есть id заявки", function () {
  const body = pm.response.json();
  pm.expect(body.id).to.be.a("string").and.not.empty;
});

Оформление дефекта

Когда проверка падает, баг-репорт должен показывать не только техническую ошибку, но и нарушенное правило. Формулировка «POST вернул не тот код» слишком слабая, если проблема на самом деле в том, что система создает дубликат заявки при повторной отправке. Разработчику важнее сразу увидеть сценарий, входные данные и бизнес-следствие.

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

Пример формулировки дефекта: «При повторном POST /applications с тем же request_id система создает вторую заявку. Ожидалось: возврат существующей заявки по учебному контракту и отсутствие нового события CREATED. Фактически: создан новый id, в истории две записи CREATED».

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

Как понять, что набор проверок уже полезен

Минимально полезный набор проверок для учебного API заявок отвечает на пять вопросов. Создается ли сущность корректно? Отвергаются ли плохие данные предсказуемо и понятно? Защищены ли данные от чужого доступа? Что происходит при повторном запросе? Появляется ли нужный побочный эффект и не появляется ли лишний? Если на каждый вопрос у вас есть отдельная проверка, набор уже помогает ловить реальные ошибки, а не только демонстрирует умение нажимать кнопку Send.

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

Если хотите отрабатывать такой подход на программе обучения, посмотрите курс «Ручное тестирование (Manual QA)». В подтвержденной программе указаны REST и основные методы, коды ошибок HTTP, спецификация API, тестирование API с помощью Postman, SQL, тестирование баз данных и создание баг-репорта. Для себя полезно проверить три вещи: есть ли самостоятельные задания именно по API, как проверяют результат работы, и дают ли обратную связь по тест-кейсам и баг-репортам, а не только по теории.