Диагностика, повторы и честный результат

Три разных источника падения

Падающий API-тест может указывать на дефект сервиса, неверные данные/предусловия или ошибку самого теста. Сохраните фактический метод, полный целевой адрес без реальных секретов, заголовки в очищенном виде, тело, статус, ответ и время/версию. Затем сопоставьте ожидание с контрактом и проверьте исходное состояние. Отдельно отмечайте, был ли HTTP-ответ вообще получен. DNS, connection refused и разрыв соединения не являются статусом 500.

Например, ожидание 409 для Бориса на published-задаче ошибочно в API-CORE-1:403 приходит раньше проверки состояния. Такой провал надо исправить в тесте, а не заводить дефект сервиса. Если же отказ 422 сопровождается новой записью, наблюдение противоречит A6 и требует дефектного отчёта. Одинаковый красный индикатор в инструменте скрывает разные причины, поэтому решение должно опираться на трассу и оракул.

Таймаут не сообщает, состоялась ли операция

GET считается безопасным в смысле отсутствия запрошенного изменения состояния ресурса; это не обещание отсутствия логов или иных служебных эффектов. Идемпотентность означает одинаковый целевой эффект нескольких одинаковых запросов, а не равенство всех ответов или времени. POST сам по себе не даёт такой гарантии. Наш A7 явно допускает две записи при двух одинаковых успешных созданиях.

Если клиент отправил POST и потерял ответ, операция могла уже завершиться. Слепой повтор способен создать дубль. В локальной модели это легко увидеть двумя последовательными Create с одним title: получите разные ID. Это не дефект модели, а заданное отсутствие устранения дублей. Для реального продукта механизм ключа идемпотентности, проверка результата или политика повторов должны быть согласованы в контракте. Нельзя просто добавить заголовок Idempotency-Key и считать, что сервер обязан его поддержать.

Свидетельства должны позволять повторить вывод

Репорт по API содержит начальный снимок, актор, запрос, ожидаемые статус/данные/эффект и фактический ответ со снимком после. При авторизационных проблемах не раскрывайте реальные токены в публичном отчёте: обозначьте роль и безопасный идентификатор тестового субъекта. В нашей лаборатории demo-токены публичны, но привычка очищать реальные материалы остаётся важной. Гипотезу о причине записывайте отдельно от наблюдения.

Итог прогона перечисляет исполненные сценарии и ограничения: локальная модель без базы/сети между сервисами, последовательный запуск, фиксированные синтетические данные, отсутствие нагрузочного теста. Все успешные проверки стенда не доказывают безопасность произвольного API. Если вы только прочитали скачиваемый check-lab.mjs, он не считается запущенным. Сначала выполните, сохраните фактический вывод, затем заявляйте результат. Точная формулировка статуса — часть профессиональной надёжности тестировщика.

Как классифицировать