Как вы тестируете REST API? Что проверяете и как используете Postman?
Короткий ответ
- Проверяю статус-коды, тело, заголовки, время ответа
- Валидирую схему ответа, а не только отдельные поля
- Негативные кейсы: невалидные данные, авторизация, чужие ресурсы
- Проверяю побочный эффект: запись реально создана в системе
- В Postman: коллекции, окружения, переменные, тесты на JavaScript
- Прогон коллекций в CI через Newman или Postman CLI
- Граничные случаи: пагинация, пустые списки, идемпотентность
Тестирование API — это проверка контракта, данных, ошибок и безопасности напрямую, минуя UI, с автоматизацией через коллекции.
Как сказать вслух
пример ответаЯ иду от контракта: смотрю документацию, обычно OpenAPI, и проверяю каждый эндпоинт. Позитивные сценарии — правильный статус-код, структура и значения полей ответа. Негативные — невалидное тело, отсутствующий токен, доступ к чужим данным, несуществующие идентификаторы. Обязательно проверяю эффект: если POST создал заказ, он должен реально появиться при последующем GET. В Postman собираю коллекции с переменными окружения и пишу проверки на JavaScript, чтобы прогонять их автоматически.
Подробный ответ
Основной ответ
Тестирование API — проверка бизнес-логики через программный интерфейс, без браузера. Базовый чек-лист на эндпоинт: корректный статус-код (200/201/204 для успеха, 400 на невалидный ввод, 401/403 на проблемы аутентификации и прав, 404 на отсутствующий ресурс); соответствие тела ответа контракту — типы, обязательные поля, формат дат, лучше валидацией JSON-схемы; заголовки и время ответа; побочные эффекты — данные реально создались, изменились, удалились; идемпотентность PUT и DELETE; пагинация, сортировка, фильтры, пустые результаты. Негативные сценарии: лишние и отсутствующие поля, неверные типы, SQL-инъекции и XSS в строках, чужие ресурсы под своим токеном (IDOR). В Postman это оформляется в коллекции: окружения для стендов, переменные, цепочки запросов с передачей данных, скрипты проверок, запуск через Collection Runner и в CI через Newman или Postman CLI.
Ключевые моменты
- Контракт прежде всего. Валидация по JSON-схеме ловит сломанные поля, которые не проверяются точечными assert-ами.
- Проверка эффекта. Ответ 201 ещё не значит, что сущность создана правильно — проверяется последующим GET или запросом в БД.
- Безопасность на уровне API. Доступ к чужим ресурсам, просроченный токен, эскалация прав — обязательная часть набора.
- Автоматизация коллекций. Newman / Postman CLI позволяет гонять коллекции в пайплайне; для крупных проектов чаще переходят на pytest + requests.
Практический контекст
На собеседовании часто дают живой эндпоинт или описание и просят перечислить проверки, либо спрашивают, чем POST отличается от PUT и что вернёт сервер в конкретной ситуации. Интервьюер смотрит, тестирует ли кандидат «через ответ 200 — ок» или понимает контракт, негативные сценарии и побочные эффекты. Упоминание прогона коллекций в CI и ограничений Postman — заметный плюс.
Пример кода
// Postman: вкладка Tests у запроса POST /orders
pm.test("Статус 201", () => pm.response.to.have.status(201));
pm.test("Схема ответа", () => {
const schema = {
type: "object",
required: ["id", "status", "total"],
properties: {
id: { type: "integer" },
status: { type: "string" },
total: { type: "number" }
}
};
pm.response.to.have.jsonSchema(schema);
});
// Сохранить id для следующего запроса в цепочке
pm.environment.set("orderId", pm.response.json().id);Частые ошибки
- Проверяют только статус-код 200, игнорируя тело, схему и побочные эффекты
- Не называют ни одного негативного сценария, пока не спросят отдельно
- Знают Postman как «кнопку Send», но не умеют в переменные, тесты и прогон в CI