Тестирование REST API и работа в Postman

Вопрос «как вы тестируете API?» — проверка на самостоятельность: работали ли вы с бэкендом напрямую или только кликали интерфейс.

Тестирование API — проверка контракта между системами: что сервис принимает, что возвращает, как ведёт себя при неверных данных и без прав.

Вопрос 1: «Что вы проверяете, тестируя REST-эндпоинт?»

Что на самом деле проверяет интервьюер

Есть ли у вас чек-лист в голове. Ответ «отправляю запрос и смотрю, что вернулось» — уровень «никогда этим не занимался».

Развёрнутый ответ

Рабочий чек-лист по любому эндпоинту:

Код ответа и его соответствие спецификации (201 на создание, а не 200).
Схема тела: состав полей, типы, обязательность, отсутствие лишних полей — особенно персональных данных, которые не должны утекать наружу.
Значения: соответствуют ли данные тому, что реально записалось в базу.
Заголовки: Content-Type, кэширование, CORS, Location при создании.
Авторизация: без токена, с протухшим токеном, с токеном чужой роли, с токеном другого пользователя (проверка на IDOR — доступ к чужому объекту по подстановке id).
Негативные сценарии: обязательное поле отсутствует, тип неверный, значение за границей, очень длинная строка, лишние поля, невалидный JSON.
Идемпотентность и повторы, гонки (два одновременных запроса), пагинация и сортировка, время ответа.

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

curl -i -X POST https://api.example.com/v1/orders \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"product_id": 42, "qty": 2}'

Проверка схемы ответа «руками»

В любом инструменте проверка схемы сводится к одной и той же логике — сверке фактических полей и типов с ожидаемыми:

const response = { id: 42, email: "qa@example.com", age: "31", roles: [] };

const schema = {
  id: "number",
  email: "string",
  age: "number",
  createdAt: "string",
};

const errors = [];
for (const [field, type] of Object.entries(schema)) {
  if (!(field in response)) {
    errors.push("нет поля " + field);
  } else if (typeof response[field] !== type) {
    errors.push(field + ": ожидали " + type + ", пришло " + typeof response[field]);
  }
}

console.log(errors.length === 0 ? "PASS" : "FAIL");
errors.forEach(e => console.log("  " + e));

Вывод:

FAIL
  age: ожидали number, пришло string
  нет поля createdAt

Оба найденных дефекта — реальные и очень частые: число, приехавшее строкой, и поле, которое молча исчезло после рефакторинга. Именно поэтому проверка схемы стоит в чек-листе выше проверки конкретных значений.

Вопрос 2: «Что вы делали в Postman?»

Что на самом деле проверяет интервьюер

Отличаете ли вы «нажимал Send» от системной работы: коллекции, окружения, переменные, автотесты, запуск в CI.

Развёрнутый ответ

Уровни владения инструментом, от базового к сильному:

Отправка запросов, подстановка заголовков и авторизации, чтение ответа.
Коллекции — набор запросов, отражающий сценарий; окружения (environments) — переменные {{base_url}}, {{token}}, чтобы одна коллекция гонялась на dev, stage и prod.
Тесты на вкладке Tests: проверка кода, полей, времени ответа. Скрипты пишутся на JavaScript.
Pre-request script — получить токен перед запросом; передача данных между запросами через переменные коллекции (создали заказ → сохранили id → запросили его).
Newman — консольный запуск коллекции, встраивание в CI, отчёт по прогонам.

// вкладка Tests в Postman
pm.test("Статус 201", function () {
  pm.response.to.have.status(201);
});

pm.test("Ответ быстрее 800 мс", function () {
  pm.expect(pm.response.responseTime).to.be.below(800);
});

pm.test("В ответе есть id заказа", function () {
  const body = pm.response.json();
  pm.expect(body).to.have.property("id");
  pm.collectionVariables.set("order_id", body.id);
});

Объект pm существует только внутри Postman, поэтому такой код не запускается в браузере — но именно его показывают на собеседовании как пример «умею писать тесты в Postman». Стоит добавить, что коллекция с окружениями и Newman в CI — уже маленькая автоматизация API-тестов без единого фреймворка.

Типичные ошибки кандидатов

Проверяют только код ответа и забывают про тело: приходит 200 с пустым или сломанным JSON.
Не тестируют права доступа. Подстановка чужого id — самый частый и самый дорогой дефект REST-сервисов.
Хранят токен и URL прямо в запросах вместо переменных окружения — коллекция не переносится между стендами.
Считают Postman «инструментом для GET-запросов» и не знают про коллекции, переменные и Newman.
Не сверяют результат с базой: API ответил 201, а записи в БД нет.

Как ответить кратко

По каждому эндпоинту проверяю: код ответа по спецификации, схему тела — состав полей, типы, обязательность и отсутствие лишних данных, сами значения и их соответствие базе, заголовки, а затем права доступа: без токена, с протухшим, с чужой ролью и с чужим id. Дальше идут негативные сценарии — отсутствующее обязательное поле, неверный тип, границы, невалидный JSON — и повторные запросы на идемпотентность. В Postman работаю коллекциями с окружениями и переменными вместо захардкоженных URL и токенов, пишу тесты на вкладке Tests, получаю токен в pre-request script, передаю id между запросами через переменные коллекции и запускаю всё через Newman в CI.