В прошлом уроке мы разобрали, как тестировать API по документации Swagger — какие запросы и ответы там описаны заранее. Но сама спецификация — это только ожидание. Реальный ответ сервера нужно СВЕРИТЬ с этим ожиданием по нескольким независимым признакам, а не просто взглянуть — «вроде похоже». В этом уроке разберём, по каким именно.
Чему научишься за этот урок:
— проверять ответ API по четырём независимым осям: статус, схема, значения, время;
— находить расхождение именно по ОДНОЙ конкретной оси, а не «в целом что-то не так»;
— понимать, что формально верная схема ответа не гарантирует правильность самих данных.
Четыре независимые оси проверки ответа
Когда тестировщик получил ответ API, его нужно свести с ожиданием (спецификацией) сразу по четырём разным признакам. Они независимы друг от друга: ответ может быть верным по одной оси и ошибочным по другой одновременно.
1. Статус -> код ответа совпадает с ожидаемым по спецификации 2. Схема -> все поля на месте, типы данных верные, нет лишних/пропущенных полей 3. Значения -> сами данные корректны по бизнес-логике, а не только по формату 4. Время -> сервер ответил не дольше, чем допустимо
Статус: код ответа
Первая ось уже частично знакома: в уроке про коды ответа и HTTPS в главе 3 разбирали 200 (успех), 400 (неверные данные), 401 (не авторизован), 404 (не найдено), 500 (ошибка сервера). При проверке ответа API нужно сверить, совпадает ли ПОЛУЧЕННЫЙ код с ОЖИДАЕМЫМ по спецификации для этого конкретного запроса. Например, если ресурс не существует, спецификация обещает код 404 — и если вместо этого пришёл 200 с пустым телом, это уже расхождение по оси «статус», даже если само тело ответа выглядит безобидно.
Схема: структура ответа
Вторая ось — соответствует ли СТРУКТУРА ответа тому, что описано в спецификации (со Swagger-документацией вы уже работали в прошлом уроке): присутствуют ли все ожидаемые поля, верные ли у них типы данных (строка, число, булево значение, массив), нет ли лишних полей, которых не было в спецификации, и нет ли пропущенных обязательных полей. Схема — это ФОРМА ответа, а не его содержание: поле price может формально быть числом, но какое именно число в нём лежит — это уже другая ось.
Значения: сами данные
Третья ось — корректны ли сами ЗНАЧЕНИЯ данных по бизнес-логике продукта. Ответ может быть безупречным по схеме — поле price действительно число, как и требуется, — но конкретное число в нём может быть некорректным: например, отрицательная цена для курса, который по смыслу продукта не может стоить отрицательную сумму. Формальная проверка типа данных здесь ничего не найдёт — нужна проверка именно смысла значения.
Время: время ответа
Четвёртая ось не является функциональной проверкой в привычном смысле: она не про то, ВЕРНЫЙ ли ответ, а про то, насколько БЫСТРО сервер его прислал. Это тот же вид проверки, что уже разбирали в уроке про типы тестирования в главе 2 — тестирование производительности (нефункциональное). Если спецификация обещает ответ за время до 500 мс, а сервер отвечает за 3 секунды, содержимое ответа при этом может быть абсолютно правильным по всем трём другим осям — но по оси «время» это всё равно расхождение.
Пример: разбираем расхождения по осям
По спецификации запрос GET /api/courses/123 должен вернуть код 200 за время до 500 мс, а тело ответа — содержать поля id, title и price:
Ожидание по спецификации: GET /api/courses/123 -> код 200, время до 500 мс Тело: id, title, price (число)
Пример 1. Реальный ответ пришёл с кодом 200 за 300 мс — статус и время в порядке. Но в теле ответа только поля id и title: поле price отсутствует вовсе. Код верный, время верное, а вот структура ответа не совпадает со спецификацией — расхождение по оси «схема».
Пример 2. Реальный ответ пришёл с кодом 200 за 350 мс, тело содержит все три поля, включая price — и это действительно число, как и требуется по типу. Но само число равно -100. Статус верный, время верное, схема верная — а вот отрицательная цена курса смысла не имеет: расхождение по оси «значения».
Пример 3. Тестировщик запрашивает несуществующий курс — GET /api/courses/999. Спецификация обещает в этом случае код 404. Реальный ответ пришёл с кодом 200 и пустым телом. Само тело формально не противоречит ничему, но сам код ответа неверный — расхождение по оси «статус».
Итог:
— проверка ответа API идёт по четырём независимым осям: статус (код ответа), схема (структура и типы полей), значения (корректность данных по бизнес-логике), время (скорость ответа);
— ответ может быть верным по одной оси и ошибочным по другой одновременно;
— формально верная схема (поле нужного типа) не гарантирует, что САМО значение корректно;
— расхождение всегда полезно локализовать до ОДНОЙ конкретной оси, а не просто отметить «что-то не так».
Контрольный вопрос. Что проверяет ось «статус» при анализе ответа API?
Подсказка: Это та же характеристика ответа, которую вы уже разбирали в главе 3 в уроке про коды ответа.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Что проверяет ось «схема» при анализе ответа API?
Подсказка: Это про ФОРМУ ответа — какие поля есть и какого они типа, а не про то, какое конкретно значение в них лежит.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Ответ на GET /api/courses/123 пришёл с кодом 200 и всеми полями по спецификации, но поле price содержит -100 для курса. Расхождение по какой оси?
Подсказка: Формально поле price — число, как и требуется по типу. Дело не в форме, а в том, ЧТО в этом числе.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Какая ось проверки отвечает за то, не слишком ли долго сервер отвечает на запрос?
Подсказка: Это нефункциональная проверка — тот же вид, что уже разбирали в главе 2 в теме про тестирование производительности.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Какие из утверждений про проверку ответа API верны (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Сверь каждое утверждение с итогом урока — одно из четырёх ошибочно приравнивает верный тип данных к верному значению.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Как называется ось проверки ответа API, которая отвечает за наличие всех полей и правильность их типов данных? Ответь одним словом по-русски.
Подсказка: Это слово уже встречалось как заголовок одного из разделов урока — оно про форму, а не про содержание.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. По спецификации GET /api/courses/123 должен вернуть код 200 не дольше чем за 500 мс. Реальный ответ пришёл с кодом 200 за 1200 мс, тело ответа полностью совпадает со спецификацией. По какой оси расхождение? Ответь одним словом.
Подсказка: Код верный, тело верное — сравни только с указанным порогом времени.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Ответ API на GET /api/courses/123 пришёл с полем price, записанным строкой в кавычках, вместо числа. По спецификации поле price должно быть числом. По какой оси проверки это расхождение? Ответь одним словом.
Подсказка: Дело не в самом числе — оно верное по смыслу. Проблема в том, каким типом данных оно записано.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Объясни в 2-3 предложениях: чем отличается расхождение по оси «схема» от расхождения по оси «значения» — на своём примере, отличном от примеров урока.
Критерий приёмки: объяснено, что схема — это про форму (поле есть, у него верный тип данных), а значения — про содержание (само число или строка в поле корректно по смыслу продукта); предложен собственный пример, где формально верный тип поля содержит бессмысленное или неверное по бизнес-логике значение (по аналогии с примером урока про отрицательную цену, но не тот же самый пример).
Подсказка: Вспомни разницу между «поле price — число» (это про тип) и «price равно -100» (это про смысл этого числа).
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Задание. Тестировщик отправил GET /api/courses/123 и получил ответ за 3000 мс (при пороге по спецификации 500 мс), с кодом 200 и телом, полностью совпадающим со спецификацией и по структуре, и по значениям. По какой единственной оси есть расхождение, и почему остальные три оси при этом в порядке? Обоснуй в 2-3 предложениях.
Критерий приёмки: названа ось «время» как единственное расхождение (3000 мс против порога 500 мс); объяснено, что статус в порядке (код 200 совпал с ожидаемым), схема в порядке (все поля на месте, типы верные) и значения в порядке (данные корректны по смыслу продукта) — то есть три из четырёх осей независимо друг от друга прошли проверку, и только время нарушено.
Подсказка: Сверь каждую из четырёх осей по отдельности с условием — три из них совпадают идеально, ищи единственное отличие.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
Онлайн-проверка ответа появится позже
Что дальше
Теперь вы умеете проверять ответ API по всем четырём осям. Но что делать, если для одного и того же запроса нужно проверить доступ РАЗНЫХ пользователей — и убедиться, что без токена доступа не будет вовсе? В следующем уроке разберём авторизацию на учебном API.
