В прошлом уроке мы проверяли, кто получает доступ к API и с каким токеном. Теперь разберём, что происходит, когда в API пытаются отправить заведомо НЕКОРРЕКТНЫЕ данные — и как по ответу API понять, где именно находится дефект: в интерфейсе или на сервере.
Чему научишься за этот урок:
— отправлять негативные API-проверки напрямую в запрос;
— понимать связку «дефект виден в UI, причина в запросе»;
— локализовать дефект — на стороне клиента он или на стороне сервера — глядя напрямую в ответ API.
Негативные API-проверки
Принцип негативных проверок уже знаком по уроку 5.1 главы 5, посвящённой тест-дизайну: там мы намеренно отправляли некорректные данные в форму интерфейса. Теперь тот же принцип применяется напрямую к API — минуя интерфейс вовсе. Тестировщик отправляет заведомо некорректный запрос: пустые обязательные поля, неверные типы данных (текст вместо числа), значения за пределами допустимого диапазона — и проверяет, что сервер их корректно ОТКЛОНЯЕТ, а не молча принимает как валидные.
Связка «дефект виден в UI, причина в запросе»
Когда баг проявляется в интерфейсе — например, «форма не показывает скидку» или «на экране неверные данные», — причина может быть в ДВУХ разных местах. Первое: сам интерфейс неправильно ОБРАБАТЫВАЕТ уже корректные данные, присланные сервером, — это дефект клиента. Второе: сервер СРАЗУ вернул некорректные данные, а интерфейс лишь честно их отобразил — это дефект сервера (API). Тот же принцип «чья это ошибка, клиента или сервера» уже применялся в уроке 3.4 (коды ответа) и в уроке 7.3 (клиентская и серверная валидация форм) — здесь он применяется к содержимому ответа API напрямую.
Как локализовать дефект
Способ прост: тестировщик открывает Postman (или вкладку Network в DevTools, знакомую по уроку 3.7) и смотрит НАПРЯМУЮ, что реально вернул API, — в обход интерфейса. Если API уже вернул неверные данные — дефект на сервере. Если API вернул верные данные, а на экране всё равно показано неправильно — дефект в клиенте.
Пример
На экране оплаты курса скидка по промокоду не отображается. Тестировщик открывает Postman и отправляет тот же запрос напрямую к API. Если ответ API содержит поле скидки, равное 0, — сервер сам не посчитал скидку, дефект на сервере. Если ответ API содержит поле скидки, равное 500, — сервер посчитал скидку верно, а на экране её всё равно нет — значит, дефект в клиенте: интерфейс не отобразил то, что честно прислал сервер.
Сценарий A: API вернул discount = 0 -> сервер не посчитал скидку -> дефект НА СЕРВЕРЕ Сценарий B: API вернул discount = 500 -> сервер посчитал верно, но на экране скидки нет -> дефект В КЛИЕНТЕ
Итог:
— негативные API-проверки — отправка заведомо некорректных данных напрямую в запрос и проверка, что сервер их отклоняет, а не принимает молча;
— связка «дефект виден в UI, причина в запросе» — баг на экране может быть дефектом клиента (неверно обработал верные данные) или дефектом сервера (сразу вернул неверные данные);
— локализация — открыть Postman или вкладку Network и посмотреть напрямую, что вернул API, в обход интерфейса.
Контрольный вопрос. Что проверяют негативные API-проверки?
Подсказка: Тот же принцип негативных проверок, что уже разбирали в главе 5 — только теперь применительно к API.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Если сервер сразу вернул некорректные данные, а интерфейс лишь честно их отобразил на экране — на чьей стороне дефект?
Подсказка: Интерфейс здесь ни при чём — он просто показал то, что получил.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Если API вернул верные данные, а интерфейс всё равно показал их неправильно — на чьей стороне дефект?
Подсказка: Сервер здесь сработал верно — проблема в том, как эти данные ОБРАБОТАЛ интерфейс.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Каким инструментом тестировщик смотрит напрямую, что реально вернул API, в обход интерфейса?
Подсказка: Это два инструмента, которые уже разбирались в этой и в третьей главе курса.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Какие из утверждений про негативные API-проверки и локализацию дефектов верны (выбери все подходящие)?
Выберите все верные варианты.
Подсказка: Одно из утверждений противоречит самой идее связки «дефект виден в UI, причина в запросе» — там причина бывает по обе стороны.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Контрольный вопрос. Ответ API содержит поле скидки, равное 500, но на экране оплаты скидка не отображается. На чьей стороне дефект? Ответь одним словом по-русски.
Подсказка: Сервер посчитал скидку верно — сравни это с тем, что показано на экране.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Тестировщик отправляет в API пустое обязательное поле price при создании курса. Как называется такая проверка — когда специально отправляют некорректные данные, чтобы убедиться, что сервер их отклонит? Ответь одним словом по-русски.
Подсказка: Термин уже встречался в уроке 5.1 главы 5 — противоположность позитивной проверке.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. На экране корзины не отображается итоговая сумма заказа. Тестировщик отправляет тот же запрос напрямую в Postman и видит в ответе API поле итоговой суммы, равное null, вместо ожидаемого числа. На чьей стороне находится дефект? Ответь одним словом.
Подсказка: API уже вернул некорректное значение — интерфейс здесь просто показал то, что получил.
✅ Готово, если: ты ввёл(а) верный ответ, и онлайн-проверка его приняла.
Проверить ответ →
Реальная проверка — на нашей платформе, бесплатно и без регистрации. Открыть задачу и ввести ответ →
Задание. Объясни в 2-3 предложениях: почему открытие Postman или вкладки Network в DevTools помогает точно определить, на чьей стороне дефект, а простой взгляд на экран приложения — нет?
Критерий приёмки: объяснено, что взгляд на экран показывает только конечный результат совместной работы и клиента, и сервера, не различая их вклад; открытие Postman или Network показывает ответ API НАПРЯМУЮ, в обход интерфейса, поэтому позволяет увидеть, что именно прислал сервер, до того как это обработал клиент — и таким образом отделить одну сторону от другой.
Подсказка: Подумай, что именно скрывает от тестировщика обычный экран интерфейса, в отличие от прямого ответа API.
✅ Готово, если: ответ раскрывает то, что просит критерий приёмки в задании выше.
Онлайн-проверка ответа появится позже
Задание. На странице профиля пользователя вместо возраста показано «NaN лет». Тестировщик отправляет GET /api/user/profile напрямую в Postman и получает в ответе поле age в виде текстовой строки со словом «тридцать» вместо числа. Локализуй дефект: на чьей стороне он находится, и по какой из двух тем этого урока — негативная проверка или связка UI/запрос — это можно объяснить? Обоснуй в 2-3 предложениях.
Критерий приёмки: названо, что дефект на стороне сервера — API вернул поле age в неверном формате (строка вместо числа), и интерфейс, попытавшись математически обработать текст как число, получил «NaN» (not a number); связано с обеими темами урока: это одновременно пример того, что сервер должен был отклонить или не допустить некорректное значение age при сохранении (тема негативных проверок, только со стороны входных данных), и пример связки «дефект виден в UI (NaN лет), причина в запросе (сервер вернул строку вместо числа)».
Подсказка: Посмотри, в каком формате пришло поле age от сервера, и подумай, что должен был сделать интерфейс с текстом вместо числа.
✅ Готово, если: ответ раскрывает то, что просит критерий приёмки в задании выше.
Онлайн-проверка ответа появится позже
Что дальше
Это был последний урок главы «API и Postman». Глава дала полный набор навыков для тестирования API напрямую: что такое API и чем REST отличается от легаси-протокола SOAP; как собирать в Postman коллекции запросов, окружения и переменные; как тестировать по документации Swagger, ещё не имея готового интерфейса; как проверять ответ по четырём независимым осям — статус, схема, значения, время; как проверять авторизацию — доступ конкретного пользователя по токену и отказ без него; и как по негативным API-проверкам и связке «дефект виден в UI, причина в запросе» точно локализовать дефект — на стороне клиента он или сервера. Дальше в курсе — глава «SQL и данные для тестировщика»: она откроет доступ к данным на ещё один уровень глубже, чем API, — прямо в базу данных.
