Шесть проверок контракта: где API держит слово, а где отвечает не тем
Коды 200, 404, JSON и XML, негативный случай и время ответа — вживую, без моков.
- Открыть чат14 дней бесплатно, токены в подарок
Что это
Агент проверяет не «отвечает ли сервер», а держит ли он контракт
«Вернулось 200» — не проверка. Проверка — это код, тип содержимого, обязательные поля и поведение на ошибке, сверенные с описанием метода. Агент делает шесть таких проверок, включая негативную: несуществующий ресурс обязан ответить 404 с телом ошибки, а не 200 с пустотой.
Вход и выход
Что вызвано в этой сессии, а что подключим
Вход
Три адреса: карта сайта, публичный REST-сервис и сервис подсказок. Моков нет — только живые ответы.
Шесть проверок — работают
Коды 200 и 404, типы XML и JSON, обязательные поля, негативный случай: 6 из 6 прошли.
Время — измерено
От 26 мс до 6,3 с: самый долгий ответ — переход по старому адресу, а не данные.
JSON — разобран
Для JSON проверяется наличие ключа и типа, а не «похоже на JSON».
Коллекция и авторизация — подключим
Postman-коллекция и ключ к внутреннему API: доступ и токен, два дня.
Что открывается: проверки, время ответа и схемы
Все шесть ответов сняты 09.11.2026; коды и тела приведены как есть
- 1
Шесть проверок
Адрес, метод, код, тип, что ожидали, что получили — по каждой.
- 2
Время ответа
Сколько миллисекунд отвечал каждый адрес: где данные, а где инфраструктура.
- 3
Схемы и негатив
Проверка обязательных полей и поведение на несуществующем ресурсе.
Что агент делает и что остаётся человеку
| Строит проверку | Агент: метод, адрес, ожидаемый код, обязательные поля. Человек: даёт описание контракта. |
|---|---|
| Гоняет негатив | Агент: несуществующий ресурс, битый параметр, пустое тело. Человек: решает, что критично. |
| Разбирает JSON | Агент: ключи, типы, вложенность, отсутствие лишнего. Человек: решает, что менять в контракте. |
| Мерит время | Агент: миллисекунды по каждому вызову, сравнение с прошлым прогоном. Человек: ставит порог. |
| Оформляет дефект | Агент: запрос, ожидание, ответ, тело. Человек: приоритет и срок. |
Сценарий: от контракта до результата
- 1
Контракт
Описание метода: адрес, параметры, коды, схема ответа.
- 2
Позитив
Вызов с верными данными: код, тип, обязательные поля.
- 3
Негатив
Несуществующий ресурс и битый параметр: 404 и 400, тело ошибки.
- 4
Время
Замер каждого вызова: данные против инфраструктуры.
- 5
Сверка
Схема ответа против описания: чего не хватает, что лишнее.
- 6
Выход
Протокол проверок; расхождения — дефектами, время — историей.
Откуда данные
Что нужно на входе
Описание API
Документация или коллекция: что метод обещает и какие поля обязательны.
Доступ
Тестовый ключ или токен: без него проверяется только публичная часть.
Стенд
Адрес окружения: боевой API, staging или локальный запуск.
Прокси
Перехват запросов, когда нужен точный заголовок или тело — по доступу к среде.
Что читаем, что пишем и что нужно от вас
Что подключим
1С — своя база
Читаем: OData-сервис, справочники, документы. Пишем: ничего на первом шаге. Нужно: адрес OData и право чтения. Срок: 1 день.
Яндекс Трекер
Читаем: задачи и дефекты. Пишем: дефект по API. Нужно: токен с правом задач. Срок: 1 день.
Timeweb Cloud
Читаем: сборки и стенды по API. Пишем: запуск прогона. Нужно: токен с правом сборок. Срок: 1 день.
DaData
Читаем: реквизиты и адреса для тестовых запросов. Пишем: ничего. Нужно: ключ API. Срок: 1 день.
Yandex Cloud
Читаем: ресурсы стенда и метрики по API. Пишем: ничего. Нужно: сервисный аккаунт на чтение. Срок: 2 дня.
Норма, на которую опирается работа
- ГОСТ Р 56921-2016, часть 2Процессы тестирования: проверка интерфейсов — отдельный уровень со своими критериями.
- RFC 9110 (HTTP Semantics)Коды ответов и их смысл: 200, 400, 404 — обещание сервера, а не пожелание.
- 152-ФЗ, ст. 5В тестовых запросах нет настоящих персональных данных: только синтетика или обезличивание.
Краевые случаи
Где решает человек, а не агент
API требует ключ с правами записи
Агент не пишет в боевую систему: сначала тестовый контур, потом решение человека.
Контракт не описан
Агент фиксирует фактическое поведение как «наблюдаемое» — это не норма, а факт.
Ошибка 500
Агент приносит тело и время; причина — к разработке, не к тестировщику.
Ответ зависит от времени
Агент повторяет вызов и отмечает нестабильность, а не «плавает, значит норма».
Что обычно возражают
«У нас есть коллекция в Postman»
Коллекция — это запросы; проверки контракта и негатив всё равно кто-то должен написать.
«API внутренний, контракт не нужен»
Внутренний API ломается так же: 404 и тело ошибки нужны и там.
«Кто даст ключ?»
Ключ к тестовому контуру даёт владелец системы; до этого проверяется публичная часть.
«Время ответа — это к DevOps»
Порог ставит человек, но мерить должен тот, кто гоняет проверки — иначе некому.
«Зачем негативные проверки?»
Без них 200 на несуществующий ресурс выглядит как успех — и живёт в проде.
Границы
Чего агент не делает
Не пишет в боевые системы без отдельного разрешения и тестового контура. Не выдаёт фактическое поведение за описанный контракт. Не обходит авторизацию и не подбирает ключи. Не делает вывод о нагрузке по одному вызову. Числа — только измеренные. Гарантий нет — ст. 5 ФЗ-38.
Вопросы, которые задают первыми
С чего начать?
Пришлите описание метода и адрес — вернём протокол шести проверок с кодами и временем.
Что нужно от нас?
Описание контракта и тестовый ключ. Без ключа проверим публичную часть.
Сколько идёт прогон?
Все шесть проверок — секунды; время каждого ответа в протоколе.
Это заменит Postman?
Нет: коллекция остаётся. Агент добавляет проверки, негатив и историю прогонов.
Где смотреть расхождения?
В протоколе: ожидание против факта, с телом ответа и временем.
Роль целиком
Что ещё берёт на себя агент
Тест-план и матрица трассируемости
Восемь ворот приёмки → восемнадцать проверок → метод и результат: что закрыто, а что нет.
Регресс к релизу: набор и прогон
Восемь автотестов, прогон 23 секунды, один красный: регресс ловит реальный дефект.
Баг-репорт с шагами и артефактами
Два дефекта с живого сайта: шаги, ожидаемо и фактически, фрагмент журнала, severity.
Функциональный прогон веб-приложения
Сто сорок четыре адреса: карта, страница, ссылки, ответ сервера — протокол по семьям.
Разбор требований и вопросы к ТЗ
Пять противоречий в требованиях и вопросы, которые нужно закрыть до первого прогона.
Отчёт о тестировании и готовности
Двадцать шесть находок по severity и вердикт: что блокирует релиз, а что нет.
SQL-сверка данных при разборе дефекта
Девять запросов к пяти таблицам: где данные расходятся и что это значит для дефекта.
Разбор журнала в Linux
Сто сорок четыре строки: коды, среднее, p95, самые медленные — командой и проверкой на Python.
Роли
Прогнать контракт вашего API
Пришлите описание метода и адрес — вернём протокол проверок с кодами, схемами и временем.