Шесть проверок контракта: где API держит слово, а где отвечает не тем

Коды 200, 404, JSON и XML, негативный случай и время ответа — вживую, без моков.

Что это

Агент проверяет не «отвечает ли сервер», а держит ли он контракт

«Вернулось 200» — не проверка. Проверка — это код, тип содержимого, обязательные поля и поведение на ошибке, сверенные с описанием метода. Агент делает шесть таких проверок, включая негативную: несуществующий ресурс обязан ответить 404 с телом ошибки, а не 200 с пустотой.

Вход и выход

Что вызвано в этой сессии, а что подключим

Вход

Три адреса: карта сайта, публичный REST-сервис и сервис подсказок. Моков нет — только живые ответы.

  • Шесть проверок — работают

    Коды 200 и 404, типы XML и JSON, обязательные поля, негативный случай: 6 из 6 прошли.

  • Время — измерено

    От 26 мс до 6,3 с: самый долгий ответ — переход по старому адресу, а не данные.

  • JSON — разобран

    Для JSON проверяется наличие ключа и типа, а не «похоже на JSON».

  • Коллекция и авторизация — подключим

    Postman-коллекция и ключ к внутреннему API: доступ и токен, два дня.

Что открывается: проверки, время ответа и схемы

Все шесть ответов сняты 09.11.2026; коды и тела приведены как есть

  1. 1

    Шесть проверок

    Адрес, метод, код, тип, что ожидали, что получили — по каждой.

  2. 2

    Время ответа

    Сколько миллисекунд отвечал каждый адрес: где данные, а где инфраструктура.

  3. 3

    Схемы и негатив

    Проверка обязательных полей и поведение на несуществующем ресурсе.

Что агент делает и что остаётся человеку

Строит проверкуАгент: метод, адрес, ожидаемый код, обязательные поля. Человек: даёт описание контракта.
Гоняет негативАгент: несуществующий ресурс, битый параметр, пустое тело. Человек: решает, что критично.
Разбирает JSONАгент: ключи, типы, вложенность, отсутствие лишнего. Человек: решает, что менять в контракте.
Мерит времяАгент: миллисекунды по каждому вызову, сравнение с прошлым прогоном. Человек: ставит порог.
Оформляет дефектАгент: запрос, ожидание, ответ, тело. Человек: приоритет и срок.

Сценарий: от контракта до результата

  1. 1

    Контракт

    Описание метода: адрес, параметры, коды, схема ответа.

  2. 2

    Позитив

    Вызов с верными данными: код, тип, обязательные поля.

  3. 3

    Негатив

    Несуществующий ресурс и битый параметр: 404 и 400, тело ошибки.

  4. 4

    Время

    Замер каждого вызова: данные против инфраструктуры.

  5. 5

    Сверка

    Схема ответа против описания: чего не хватает, что лишнее.

  6. 6

    Выход

    Протокол проверок; расхождения — дефектами, время — историей.

Откуда данные

Что нужно на входе

  • Описание API

    Документация или коллекция: что метод обещает и какие поля обязательны.

  • Доступ

    Тестовый ключ или токен: без него проверяется только публичная часть.

  • Стенд

    Адрес окружения: боевой API, staging или локальный запуск.

  • Прокси

    Перехват запросов, когда нужен точный заголовок или тело — по доступу к среде.

Норма, на которую опирается работа

Краевые случаи

Где решает человек, а не агент

  • API требует ключ с правами записи

    Агент не пишет в боевую систему: сначала тестовый контур, потом решение человека.

  • Контракт не описан

    Агент фиксирует фактическое поведение как «наблюдаемое» — это не норма, а факт.

  • Ошибка 500

    Агент приносит тело и время; причина — к разработке, не к тестировщику.

  • Ответ зависит от времени

    Агент повторяет вызов и отмечает нестабильность, а не «плавает, значит норма».

Что обычно возражают

  • «У нас есть коллекция в Postman»

    Коллекция — это запросы; проверки контракта и негатив всё равно кто-то должен написать.

  • «API внутренний, контракт не нужен»

    Внутренний API ломается так же: 404 и тело ошибки нужны и там.

  • «Кто даст ключ?»

    Ключ к тестовому контуру даёт владелец системы; до этого проверяется публичная часть.

  • «Время ответа — это к DevOps»

    Порог ставит человек, но мерить должен тот, кто гоняет проверки — иначе некому.

  • «Зачем негативные проверки?»

    Без них 200 на несуществующий ресурс выглядит как успех — и живёт в проде.

Границы

Чего агент не делает

Не пишет в боевые системы без отдельного разрешения и тестового контура. Не выдаёт фактическое поведение за описанный контракт. Не обходит авторизацию и не подбирает ключи. Не делает вывод о нагрузке по одному вызову. Числа — только измеренные. Гарантий нет — ст. 5 ФЗ-38.

Вопросы, которые задают первыми

С чего начать?

Пришлите описание метода и адрес — вернём протокол шести проверок с кодами и временем.

Что нужно от нас?

Описание контракта и тестовый ключ. Без ключа проверим публичную часть.

Сколько идёт прогон?

Все шесть проверок — секунды; время каждого ответа в протоколе.

Это заменит Postman?

Нет: коллекция остаётся. Агент добавляет проверки, негатив и историю прогонов.

Где смотреть расхождения?

В протоколе: ожидание против факта, с телом ответа и временем.

Роль целиком

Что ещё берёт на себя агент

Роли

Прогнать контракт вашего API

Пришлите описание метода и адрес — вернём протокол проверок с кодами, схемами и временем.