Итоговый проект: проверка API-контракта
Подготовьте коллекцию, матрицу, доказательства инвариантов и понятный отчёт по локальному стенду.
- Собрать воспроизводимый набор API-проверок.
- Покрыть доступ, данные, состояние и побочные эффекты.
- Передать фактические результаты с границами применимости.
Что вы передаёте коллеге
Итоговый проект должен позволять запустить проверку и понять её смысл без вашего присутствия. Приложите API-CORE-1, команду запуска лаборатории, адрес/порт, способ reset, версию ваших файлов и набор сценариев. В каждом сценарии назовите актор, начальные данные, запрос, ожидаемый ответ и наблюдение состояния. Не заставляйте коллегу восстанавливать эти условия из скриншотов зелёных значков.
Минимальный набор связывает позитивное создание с чтением полученного ID, отдельные уровни валидации, объектный доступ, публикацию, повтор и отсутствие побочных эффектов. Добавьте один осмысленный дополнительный класс, которого нет в стартовой коллекции: например, description:null или 80 эмодзи. Так вы покажете, что умеете расширять модель, а не просто нажимать Runner. Укажите, какое правило и риск добавляет этот пример.
Два допустимых режима сдачи
Динамический режим использует настоящий локальный HTTP-стенд: скачайте исходники в отдельную папку, запустите процесс, проверьте коллекцию или check-lab.mjs, затем выполните собственное расширение. Сохраните фактический stdout, итоговые статусы и краткие очищенные трассы. После работы остановите процесс Ctrl+C. Не запускайте учебный сервер на публичном интерфейсе и не добавляйте туда настоящие данные: его назначение — изолированная синтетическая практика.
Офлайн-режим доступен без установки: спроектируйте набор по контракту и разберите трассы S1–S4/D1–D4 из материалов. Все собственные новые запросы останутся Not run. Честный офлайн-пакет лучше вымышленного динамического успеха. В обоих режимах критерии включают точность ожиданий, полноту выбранной модели и аккуратность ограничений. Автоматическая проверка quiz на сайте подтверждает знание ответов, а не выполняет ваш Postman или экспертную оценку проекта.
Как проверить качество и устойчивость набора
Пройдитесь по независимости: не использует ли Read устаревший taskId; не запускается ли негатив состояния без нужного права; не сбрасывается ли state между первым и повторным publish. Сравните snapshot до и после отказов; по одному статусу инварианты не доказаны. В успешной публикации ожидайте изменение только state существующего ID. Небольшой строгий набор с понятными причинами ценнее множества одинаковых запросов.
Отчёт завершает цепочку: что проверено, что упало, где причина в тесте, что заблокировано и что осталось неизвестным. Успешная лаборатория не является аудитом реального API. Запишите отсутствие проверки распределённых сбоев, производительности, реальной аутентификации и хранения между перезапусками. Если локальная проверка выявила ошибку ваших assertions, исправьте их и сохраните причину исправления, затем повторите затронутую часть набора. Не скрывайте первоначальную проблему заменой статуса без объяснения.
Источники и проверка фактов
RFC 9110 — HTTP SemanticsСемантика методов и статусов. Порядок проверок и поля OrbitDesk заданы отдельным учебным контрактом, не самим HTTP.Postman — post-response scriptsИменованные тесты и assertions после получения ответа; официальный синтаксис pm.test / pm.expect.Авторский учебный материал · Редакция QA Orbit · версия 2026-10-28.1