Чек-лист тестирования REST API: проверки, примеры и ответы для собеседования

1. Преврати документацию в тестовую модель

Начинай с ресурса, а не инструмента. Для POST /orders определи, кто имеет право вызвать метод, обязательные headers, поля и ограничения request, успешный response, формат ошибок и состояние заказа после создания. Неясные правила фиксируй вопросами, а не подставляй текущее поведение как expected result.

Собери decision table: пользователь авторизован или нет, корзина пустая или нет, товара хватает или нет, нужна оплата или нет. Так находятся комбинации, которые пропускает плоский список endpoints. Зафиксируй environment и версию API.

• Назови бизнес-инвариант endpoint.
• Отдели документированное правило от предположения.
• Зафиксируй версию, среду и владельца тестовых данных.
• Свяжи response с обещанным переходом состояния.

2. Методы, статус-коды, headers и content negotiation

HTTP semantics — часть контракта. GET безопасен; PUT и DELETE определены как идемпотентные; POST не становится идемпотентным автоматически. Проверяй смысл повтора именно в продукте. Ответ 200 с объектом error всё равно может нарушать контракт.

Проверяй Content-Type, Location после создания, cache headers там, где они нужны, и correlation id для расследования. Различай 400 для сломанного синтаксиса, 401 для отсутствующей/невалидной аутентификации, 403 для нехватки прав, 404 для отсутствующего ресурса, 409 для конфликта состояния и 422 для семантически невалидного ввода согласно договорённости API.

POST /orders HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json
Idempotency-Key: order-77-cart-19

{"delivery_address_id": 55}

3. Валидация входа и тест-дизайн

Для каждого поля с правилом применяй классы эквивалентности и границы. Для quantity 1–10 нужны 0, 1, 10, 11, неверный тип, missing, NULL и дробь. Для строк — empty, whitespace, длина, encoding и normalization. Не создавай десятки случайных значений из одного класса.

Проверяй межполевые и зависящие от состояния правила. Валидный coupon может истечь, адрес — принадлежать другому пользователю, product id — вести на товар без остатка. Ошибка должна назвать правило без stack trace и внутреннего SQL.

valid:   {"quantity": 1}, {"quantity": 10}
invalid: {"quantity": 0}, {"quantity": 11}
type:    {"quantity": "2"}, {"quantity": 2.5}
missing: {}, {"quantity": null}

4. Проверяй schema, значения и сохранённое состояние

Schema validation подтверждает required fields, types и formats, но не правильность total и не факт сохранения. Бизнес-значения сравнивай с независимо рассчитанным oracle. Для двух товаров по 690 со скидкой 10% вычисли expected total по согласованному правилу округления.

После write выполни read через поддерживаемый интерфейс. Если POST сообщает 1242, а GET — 1380, подозрительны persistence или read model. Если оба показывают 1242, но провайдер списал 1380, дефект ниже по цепочке. Это разные отчёты.

pm.test('created', () => pm.response.to.have.status(201));
pm.test('json response', () => pm.expect(pm.response.headers.get('Content-Type')).to.include('application/json'));
const order = pm.response.json();
pm.test('expected total', () => pm.expect(order.total).to.eql(1242));
pm.environment.set('order_id', order.id);

5. Authentication, authorization и ownership

Authentication отвечает «кто вызывает», authorization — «что ему разрешено». Проверь отсутствие token, malformed/expired token, неверную роль и доступ к чужому объекту. Скрытая UI-кнопка не защищает API.

Создай двух синтетических пользователей. A создаёт order, B пробует GET, PATCH и DELETE по id A. Проверь также list, search, export и nested resources: закрытый detail может соседствовать с утечкой в поиске.

Actor A + order A: GET allow, PATCH allow
Actor B + order A: GET deny,  PATCH deny
Admin   + order A: по документированной роли
Anonymous          : deny без утечки данных

6. Идемпотентность, повторы, конкуренция и пагинация

Клиент повторяет запрос после timeout, proxy может переотправить вызов, пользователь — нажать дважды. Повтори request с тем же и другим idempotency key и проверь конечный бизнес-эффект. Запусти параллельные запросы для одного coupon, lead conversion или последней единицы товара.

Для pagination проверь стабильный порядок, отсутствие overlap/gaps, metadata и границы page size. Rate limit проверяй на limit−1, limit и limit+1 вместе с headers и reset, а не только до первого 429.

• Один key и одинаковый body.
• Один key и другой body.
• Timeout до получения ответа клиентом.
• Два запроса стартуют одновременно.
• Граница лимита с обеих сторон.

7. Сбои зависимостей и асинхронная обработка

API может ответить до завершения queue consumer, payment provider или email service. Разделяй принятие работы и её завершение. Определи polling/status endpoint, событие завершения, допустимое окно eventual consistency и поведение после deadline.

Смоделируй timeout и 5xx зависимости, malformed response, duplicate/out-of-order event и недоступную очередь. Проверь retry, dead-letter handling, idempotent consumer и reconciliation. Публикация сообщения ещё не доказывает доставку уведомления.

POST /exports -> 202 + export_id
GET /exports/{id} -> queued | processing | ready | failed
ready -> download URL работает и принадлежит автору
failed -> причина безопасна, retry наблюдаем

8. Производительность, автоматизация и полезный отчёт

Performance-проверке нужны workload и threshold: concurrency или RPS, объём данных, warm-up, percentile и error budget. «API быстрое» неизмеримо. Смотри p95/p99 вместе с error rate и saturation; один request benchmark не равен load test.

Автоматизируй стабильные ценные проверки: contract, критичные бизнес-правила, authorization matrix и регрессионные пути. Изолируй data, не строй длинные цепочки, скрывающие первую причину, и сохраняй request id, очищенные request/response, среду, expected state и side effects.

• Быстрые contract tests на каждое изменение.
• Integration tests хранения и зависимостей.
• Небольшой critical smoke после deployment.
• Regression по затронутому риску.
• Наблюдение latency, errors и queues.