Тестирование API на практике

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 13, остальные разбираются в тренажёре.

1. #api_test_practice1 / 5
   Как в запросе передают Bearer-токен и зачем?

   A)Токен передают в query-параметре URL, чтобы он попадал в логи и был виден в адресе

   B)Bearer-токен вписывают в тело каждого запроса рядом с основными данными полезной нагрузки

   C)Токен сохраняют в cookie, и браузер сам решает, к каким запросам его прикладывать

   D)В заголовке Authorization: Bearer <токен>; по нему сервер опознаёт и авторизует запрос

   показать ответ и разбор

   +D)В заголовке Authorization: Bearer <токен>; по нему сервер опознаёт и авторизует запрос

   // разбор: Bearer-токен — распространённый способ авторизации API. Клиент получает токен при логине и в каждом защищённом запросе кладёт его в заголовок Authorization со схемой Bearer: Authorization: Bearer eyJ.... Сервер извлекает токен, проверяет подпись и срок, определяет пользователя и его права и решает, пропускать ли запрос. «Bearer» значит «предъявитель»: кто владеет токеном, тот и авторизован — поэтому его берегут (HTTPS, короткий срок). Тестировщик проверяет: без токена — 401, с истёкшим/подделанным — 401/403, с валидным — доступ по правам.

2. #api_test_practice2 / 5
   Зачем валидировать ответ API по схеме (например, JSON Schema)?

   A)Автоматически проверить структуру и типы всех полей

   B)Чтобы измерить размер ответа в байтах и убедиться, что он не превышает лимит канала

   C)Чтобы ускорить парсинг ответа на клиенте за счёт заранее известной его структуры

   D)Чтобы зашифровать поля ответа согласно описанной в схеме модели данных сервиса

   показать ответ и разбор

   +A)Автоматически проверить структуру и типы всех полей

   // разбор: Точечные ассерты проверяют отдельные значения (id == 42), но не заметят, что поле переименовали, сменили тип (число стало строкой), убрали или добавили лишнее — а это ломает клиентов. Валидация по схеме (JSON Schema, Pydantic, OpenAPI) сверяет весь ответ с описанием контракта: набор полей, их типы, обязательность, форматы. Одной проверкой она ловит структурные регрессии на всём объекте, а не там, где тестировщик догадался поставить ассерт. Это делает контракт исполняемым: изменил ответ несовместимо — тест сразу красный. Особенно ценно при версионировании и на границе команд.

3. #api_test_practice3 / 5
   Зачем в тесте подменять внешний сервис моком или стабом?

   A)Чтобы убрать сетевой код из функции на время прогона набора тестов

   B)Задать заранее известный ответ вместо реального сервиса

   C)Чтобы прогнать тест на боевом внешнем сервисе и получить самые реалистичные данные

   D)Чтобы ускорить сам внешний сервис, кэшируя его ответы между разными тестами

   показать ответ и разбор

   +B)Задать заранее известный ответ вместо реального сервиса

   // разбор: Реальный вызов внешнего API делает тест зависимым от чужой системы: она может быть недоступна, медленна, отдавать меняющиеся данные или стоить денег/квоты за вызов — тест становится флаки и хрупким. Мок/стаб подменяет внешний сервис заданным ответом (нужный успех или ошибка), так что тест проверяет логику своего кода детерминированно и быстро, не выходя в сеть. Отдельно моки позволяют смоделировать труднодостижимые случаи: таймаут, 500, кривой ответ. Реальную интеграцию проверяют отдельными, более редкими интеграционными/e2e-тестами.

4. #api_test_practice4 / 5
   Почему API-тесты держат в CI, а не гоняют вручную?

   A)Потому что вручную API-тесты технически не получится выполнить без специального сервера

   B)Потому что в CI тесты проверяют скорость ответа, а вручную — его корректность

   C)Автопрогон на каждый коммит ловит регресс контракта до прода

   D)Потому что CI шифрует запросы, а при ручном прогоне данные идут открытым текстом

   показать ответ и разбор

   +C)Автопрогон на каждый коммит ловит регресс контракта до прода

   // разбор: API — контракт между командами и клиентами, и он ломается тихо: кто-то переименовал поле, сменил код ответа, добавил обязательный параметр — и интеграции падают. Если проверять это руками, проверка случается редко и нерегулярно, а между релизами регресс копится незамеченным. В CI набор API-тестов гоняется на каждый коммит/пулл-реквест автоматически: сломал контракт — сборка красная сразу, до слияния и до прода. Так дефект ловится там, где он дёшев, а не у потребителя по кривым данным. Ручные проверки остаются для разведочных и разовых сценариев.

5. #api_test_practice5 / 5
   Зачем в Postman/автотестах API выносят значения в переменные окружения?

   A)Чтобы каждый запрос выполнялся быстрее за счёт кэширования значений переменных

   B)Чтобы скрыть тело запроса от других членов команды, работающих с той же коллекцией

   C)Чтобы Postman сам генерировал тестовые данные вместо тестировщика при прогоне

   D)Один набор тестов гоняют против dev/stage/prod, меняя лишь baseUrl и токен, без правки самих запросов

   показать ответ и разбор

   +D)Один набор тестов гоняют против dev/stage/prod, меняя лишь baseUrl и токен, без правки самих запросов

   // разбор: Адрес API, токены, идентификаторы различаются между средами (dev, stage, prod). Если вписать их прямо в каждый запрос, для смены среды пришлось бы править все тесты — долго и с ошибками. Переменные окружения выносят эти значения в отдельный набор: запрос ссылается на {{baseUrl}}/users, а конкретный baseUrl подставляется из выбранного окружения. Так один и тот же набор тестов запускают против любой среды переключением окружения, а секреты не хардкодятся в тела запросов. Это делает тесты переносимыми и безопаснее в части хранения токенов.