Methods
HTTP-метод задаёт тип операции: GET читает представление, POST создаёт ресурс, PATCH изменяет часть состояния. Проверки не должны смешивать их смысл.
REST-контракт как evidence
Тест-кейсы из OpenAPI-контракта
QAForge разбирает OpenAPI как технический источник: методы, пути, параметры, request body, статусы и response schemas. Контракт дополняет контекст задачи, но сам по себе не подтверждает полноту бизнес-требований.
- REST
- OpenAPI
- Methods
- Statuses
- Schemas
Рабочий процесс
Как использовать QAForge
Шаг 1
Соедините задачу и контракт
Передайте задачу и OpenAPI/Swagger evidence, чтобы техническая форма операции не потерялась в общем описании.
Шаг 2
Сверьте найденные операции
Проверьте распознанные methods, paths, параметры, bodies, statuses и schemas до генерации.
Шаг 3
Проверьте результат
После генерации разберите Quality Guard, уточните бизнес-ожидания и только затем используйте или экспортируйте cases.
По существу
Что учитывает этот сценарий
Paths
Path определяет ресурс и его адресацию. Path-параметры, отсутствующий ресурс и неверный формат идентификатора требуют отдельных сценариев.
Parameters
Path, query и header parameters различаются обязательностью, типом, допустимыми значениями и местом передачи.
Request body
Request body проверяется по обязательным полям, типам, enum, ограничениям и комбинациям данных, которые описаны контрактом и задачей.
Response statuses
Успешные и ошибочные response statuses превращаются в наблюдаемые ожидаемые результаты, без выдумывания неописанных кодов.
Response schemas
Response schemas дают форму ответа: поля, типы, вложенность и обязательность. Бизнес-смысл дополнительно сверяется с задачей.
Компактный пример
REST: создание заказа
Исходный контекст
Фрагмент OpenAPI описывает создание заказа. Контракт уточняет транспортные поля, но задача должна объяснить права доступа, повторный запрос и бизнес-ограничения суммы.
POST /orders
header: X-Idempotency-Key (required)
body: { customerId: string, items: OrderItem[] }
responses: 201 Order, 400 ValidationError, 409 Conflict201: заказ создан
Валидное тело создаёт заказ, возвращает 201 и ответ с id, status и total по schema.
400: обязательное поле
Отсутствующий customerId отклоняется как ошибка тела запроса; ресурс не создаётся.
Контекст идемпотентности
Неизвестный X-Idempotency-Key не подменяет бизнес-правило повторов; ожидаемое поведение нужно взять из задачи.
Ревью контракта
QA-инженер проверяет, совпадают ли contract statuses с реальной политикой авторизации, ошибок и повторных запросов.
Границы и ответственность
Результат требует QA-ревью
- OpenAPI evidence дополняет задачу, а не восстанавливает отсутствующие роли, бизнес-инварианты и пользовательские ожидания.
- Наличие status code в контракте не доказывает, что сервис реализует его корректно; это проверяется на тестовом окружении.
- QAForge не выполняет запросы к production API и не утверждает, что контракт полностью соответствует реализации.
- Сгенерированные проверки нужно сверить с актуальной версией спецификации и проверить перед использованием или импортом.
Связанные сценарии
Продолжить по вашей задаче
Посмотрите подход на готовом примере
Готовый пример открывает существующее рабочее пространство без регистрации и без внешнего провайдерного вызова.