09. Test Cases (TC)
Часть RENAR Standard v1.0-draft · ← Оглавление
9.1 Назначение главы
Глава нормирует TC (Test Case) как first-class артефакт стандарта. TC верифицирует требования (глава 06: BR / SR / TR) и спецификации (глава 08: SPEC-ARCH / API / DATA / INT / PROC / UI / AI / SEC / OPS), замыкая trace chain: ТЗ → ADAPT → BR / SR / SPEC → TR → TC (см. §5.3).
TC по жизненному циклу, версионированию и правилам approval равен требованию. Глава фиксирует:
- закрытый список нормативных принципов TC (§9.2);
- common schema TC (§9.3) и type-specific extensions (§9.6);
- нормативное требование pos/neg pairing (§9.7);
- закрытую таблицу «тип SPEC → обязательные виды TC» (§9.8);
- защиту от подгонки тестов через тег
[test-spec-change](§9.13); - спот-чек инженера (§9.14) — единственная регулярная точка ручного контроля качества TC.
Глава опирается на ISO/IEC/IEEE 29119 «Software testing» в части концепций test design, test execution, test result reporting и pos/neg coverage, но фиксирует closed list типов TC, mandatory pos/neg pairing и judge ≠ production isolation как нормативные требования v1.0, не присутствующие в ISO 29119 в формализованном виде.
Положения главы являются нормативными. Закрытые списки (принципы, типы TC, обязательные виды TC по типу SPEC) — mandatory clauses RENAR conformance (глава 14); расширение — только через formal change procedure стандарта.
9.2 Закрытый список нормативных принципов TC
| # | Принцип | Нормативная формулировка |
|---|---|---|
| P1 | First-class артефакт | TC — самостоятельный артефакт стандарта, по жизненному циклу и версионированию равный требованию. Хранится отдельным файлом в подпапке tests/ requirements substrate (§9.17). |
| P2 | Документ ≠ реализация | TC описывает что и как проверяется (decoupled от implementation). Реализация (код) адресуется полем automation.location и хранится в code substrate. Один TC — одна реализация. |
| P3 | AI-generated | TC создаются и редактируются AI-агентом по заданию инженера; инженер не пишет TC вручную (см. глава 12 §12.N). |
| P4 | AI-executed | Все TC в статусе ready и выше — автоматизированы. Прогон производится автоматическим runner’ом (CI / AI-runner / specialized executor). Результаты записываются в last-run только bot-managed actor’ом по факту прогона. |
| P5 | Pos/neg pairing | На каждое утверждение требования (BR / SR / SPEC) создаётся минимум одна пара positive + negative TC (§9.7). |
| P6 | last-run — bot-managed | Поле last-run (date / result / runner-id / requirement-version / judge-report) заполняется только автоматическим runner’ом. Ручное редактирование last-run любым актором запрещено стандартом (§9.12). |
| P7 | Judge ≠ production isolation | Для типов TC, использующих LLM-as-judge (ux, eval), judge-модель не должна совпадать с production-моделью, генерирующей оцениваемый артефакт. Совпадение блокируется substrate-нативным hook’ом (§9.6.2). |
Список закрыт. Новые принципы добавляются только через formal change procedure (глава 14).
9.3 Common schema TC (frontmatter)
Все типы TC делят общий набор frontmatter-полей. Type-specific поля добавляются как extensions поверх (§9.6). Полная machine-readable schema — в reference/02-schemas.md.
---
# === Identity (mandatory) ===
id: TC-NN # immutable; NN sequential в рамках scope
title: "<short, descriptive>"
type: TC
slug: "<kebab-case>" # auto-derived
# === Classification (mandatory) ===
tc-type: acceptance | ux | system | contract | eval | security
negative: boolean # true для парного негативного TC
# === Scope (mandatory) ===
level: system | subsystem | module
scope:
system: "<system-id>"
subsystem: "<subsystem-id>" # null если level=system
module: "<module-id>" # null если level ≠ module
# === Lifecycle (mandatory) ===
status: draft | ready | passing | failing | obsolete
# === Verification target (mandatory; хотя бы один из) ===
verifies:
- id: SR-NN | BR-NN | SPEC-<TYPE>-NN
version: "<substrate-native version-ref>" # V5 pinning (см. глава 11)
- id: ...
# === Pair link (mandatory если negative=false и существует парный) ===
paired-with: # ID парного TC (positive ↔ negative)
- TC-NN
# === Automation (mandatory) ===
automation:
status: automated | manual-pending
location: "<substrate-native pointer to implementation>" # mandatory если automated
manual-pending-until: "<ISO date>" # mandatory если manual-pending
manual-pending-reason: "<text>" # mandatory если manual-pending
# === Execution (mandatory если type=ux | eval) ===
judge:
vendor: "<provider>" # mandatory; см. P7 isolation
model: "<model-id>"
prompt-template: "<template-path>@<version>"
baseline: # mandatory для ux | eval
artifact: "<substrate-native pointer>"
perceptual-diff-threshold: float # для ux
metric-thresholds: {} # для eval
# === Last run (auto-managed; bot-only) ===
last-run:
date: "<ISO-datetime>"
result: pass | fail | skipped | n/a
runner-id: "<runner-name@version>"
run-ref: "<substrate-native reference>"
requirement-version: "<version-ref of verified artifact>"
judge-report: "<inline or pointer>"
# === AI provenance (mandatory на RENAR-4+) ===
ai-provenance:
generated-by: "<vendor>-<model>@<date>"
prompt-template: "<template-path>@<version>"
context-tokens: integer
output-tokens: integer
human-edits: boolean
# === Замена / obsolescence ===
obsolete-pending: boolean # true при detected delta-ТЗ инвалидации
replaces: "<old-id>"
replaced-by: "<new-id>"
obsoleted-date: "<ISO date>"
---verifies[] — закрытый список ссылок на верифицируемые артефакты (BR / SR / SPEC). TR прямо не указывается в verifies — TR верифицируется через свой parent SR (см. §6.7). verifies[].version — substrate-native pinning артефакта (V5 capability, см. глава 11 §11.3.5); QG-2 (§9.10) требует совпадения verifies[].version с текущей версией артефакта.
9.4 Body разделы TC
Body любого TC обязательно содержит следующие разделы (substrate-agnostic):
| Раздел | Обязательность | Содержание |
|---|---|---|
| Контекст | mandatory | На какой пункт верифицируемого артефакта ссылается TC; цитата или paraphrase утверждения. |
| Предусловия | mandatory | Состояние системы и данных, требуемое для прогона; обеспечивается seed-механизмом. |
| Шаги | mandatory | Действия runner’а; для tc-type: ux — намерения, не селекторы (см. §9.6.1). |
| Pass-критерий | mandatory | Бинарный, наблюдаемый, воспроизводимый (см. §9.11). |
| Fail-критерий | mandatory | Перечень наблюдаемых признаков нарушения (не отрицание Pass); включает утечки, side-effects, race conditions. |
| Постусловия | mandatory | Какое состояние ожидается после прогона; cleanup-механизм. |
| Out of scope | mandatory | Что намеренно не проверяется, с указанием парного TC, где это покрыто. |
| Связанные TC | optional | Ссылки на семантически связанные TC. |
Раздел «Out of scope» — нормативно обязательный: защищает от ложного ощущения покрытия. Отсутствие раздела блокирует переход TC в ready.
9.5 Закрытый список типов TC
tc-type ∈ { acceptance, ux, system, contract, eval, security }| Тип | Что проверяет | Применяется к | Runner-семейство |
|---|---|---|---|
acceptance | Достигнута ли бизнес-цель? | BR | E2E + AI-валидатор |
ux | Соответствует ли UX заявленному опыту? | SPEC-UI | AI-driver + VLM-judge |
system | Ведёт ли система себя как описано? | SR, SPEC-PROC, SPEC-ARCH | xUnit-семейство |
contract | Соблюдён ли контракт? | SPEC-API, SPEC-INT, SPEC-DATA | Contract-testing framework |
eval | Достигнуто ли качество AI-компонент? | SPEC-AI | Eval-runner с baseline dataset |
security | Соблюдены ли security-инварианты? | SPEC-SEC | Authz/threat-test framework |
Список закрыт. Новые типы добавляются только через formal change procedure стандарта (глава 14). Конкретные технологии runner’ов — substrate-specific и фиксируются в conformance manifest реализации.
9.6 Type-specific extensions
9.6.1 tc-type: ux — UX тесты на основе SPEC-UI
UX-тест нормативно построен как двухслойная структура:
| Слой | Содержание | Исполнитель |
|---|---|---|
| Сценарий (намерение) | «<актор> хочет <результат> после <условие>» | AI-driver: переводит намерение в действия, находит элементы по семантике (без жёстких селекторов) |
| Перцептивная проверка | «На отрисованном состоянии видно <критерий>» | Perceptual judge (VLM): принимает рендер + критерий, возвращает pass/fail с обоснованием |
Mandatory frontmatter extension: judge.vendor, judge.model, baseline.artifact, baseline.perceptual-diff-threshold.
Mandatory body sections дополнительно к §9.4: Сценарий (намерение, не селекторы); Perceptual критерий (что должен увидеть judge); Парный негативный (пустое состояние / ошибка / отсутствие прав).
Регрессия по визуалу. Дополнительно к VLM-judge — perceptual diff против baseline.artifact с порогом perceptual-diff-threshold. Превышение порога блокирует переход TC в passing.
Обновление baseline. Изменение baseline.artifact требует substrate-нативного approval-механизма с тегом [baseline-update] (см. §9.13); автоматическое обновление запрещено.
9.6.2 tc-type: eval — Eval-тесты на основе SPEC-AI
Eval-тест нормативно проверяет качество AI-компонент через dataset с метриками и порогами.
Mandatory frontmatter extension: judge.vendor, judge.model, baseline.artifact (versionable dataset), baseline.metric-thresholds.
Mandatory body sections: dataset provenance (как собран, какая разметка); метрика-кластер (одна eval-TC = одна семантически связная группа метрик; разные семейства — разные TC); regression rule (что считается провалом — выход за threshold или регрессия ≥ N% против baseline).
Judge ≠ production isolation (нормативно). Поле judge.vendor + judge.model обязано отличаться от production-model спецификации SPEC-AI, нормирующей оцениваемое поведение. Substrate-нативный hook (глава 11 §11.3.3) обязан блокировать merge change unit при совпадении.
Dataset versioning. Eval-dataset — substrate-managed versionable artifact: каждое изменение фиксируется как atomic change unit с описанием (что добавлено / убрано / переразмечено) и authorship (генератор-агент / критик-агент / human spot-check).
Cost gating. Eval не запускается на каждое изменение реализации (cost): runner запускается при изменении SPEC-AI, production-model, или dataset, либо по расписанию. Триггеры фиксируются в substrate-native runner-configuration.
Двухступенчатая разметка dataset. Generator-agent создаёт кандидатов; critic-agent проверяет по чек-листу; engineer spot-check ≥ 10% случайных примеров до merge dataset.
9.6.3 tc-type: contract — Контрактные тесты на основе SPEC-API / SPEC-INT / SPEC-DATA
Mandatory body sections: machine-readable контракт (ссылка на OpenAPI / GraphQL SDL / Protobuf / JSON Schema из SPEC); сторона генератор / сторона потребитель; мок counterparty (для SPEC-INT — sandbox / реальная среда отдельным TC).
Mandatory extension для SPEC-INT. Контрактные TC обязательно сочетаются с интеграционным TC (tc-type: contract, level: subsystem | system) против реальной или sandbox-counterparty — мокированного контракта недостаточно для verify SPEC-INT.
9.6.4 tc-type: security — Security-тесты на основе SPEC-SEC
Mandatory body sections: атрибуты модели угроз (STRIDE-категория или эквивалент); subject под тестом (authn / authz / data classification / secrets / audit / encryption); negative scenarios (попытка обхода, неавторизованный доступ, leakage); ожидаемое поведение системы при нарушении.
Security-TC нормативно содержит только negative scenarios (попытка обхода защиты). Positive «дать корректный доступ корректному актору» покрывается tc-type: system со scope SPEC-SEC.
9.7 Pos/neg pairing — нормативное требование
На каждое утверждение требования (BR / SR / SPEC), описывающее наблюдаемое поведение, создаётся минимум одна пара positive + negative TC.
| Положительный TC | Парный отрицательный TC |
|---|---|
negative: false | negative: true |
| Описывает happy path / success behavior | Описывает граничные условия, нарушения, обходы |
paired-with: [TC-<neg-id>] | paired-with: [TC-<pos-id>] |
Negative TC нормативно описывает наблюдаемые признаки нарушения (что не должно произойти), а не отрицание Pass-критерия позитивного TC. Примеры:
| Утверждение | Pos TC | Neg TC |
|---|---|---|
| «Аутентификация по email + password» | Корректные credentials → 200 + JWT | Неверный пароль → 401 без раскрытия, какое поле неверно; отсутствие записи в session-store; rate-limit после N попыток |
| «Создание заказа» | Валидный payload → 201 + order-id | Невалидный price < 0 → 422 с явной ошибкой; отсутствие записи в БД; отсутствие side-effect (уведомление, начисление) |
QG-2 (§9.10) обязан блокировать promote артефакта в verified, если хотя бы одно нормативное утверждение покрыто только положительным TC.
Single-TC-coverage допускается только в одном случае: артефакт описывает запрет / negative invariant сам по себе (например, security-TC по STRIDE-категории — он негативный по природе).
9.8 Spec-specific TC — обязательные виды по типу SPEC
Закрытая нормативная таблица: каждый тип SPEC обязан иметь минимум по одному TC каждого «обязательного вида» перед переходом в verified (глава 08 §8.8).
| Тип SPEC | Обязательные виды TC | Дополнительные виды TC |
|---|---|---|
| SPEC-ARCH | Conformance (zoning / dependency rules) | Quality attribute baseline (latency / throughput / availability) |
| SPEC-API | Contract (по контракту из contract-file) | Auth negative; rate-limit; versioning compatibility |
| SPEC-DATA | Constraint (FK / NOT NULL / unique); Migration (forward + rollback) | PII handling; retention; index regression |
| SPEC-INT | Contract (mocked counterparty); INT-TC (real / sandbox counterparty) | Failure injection; idempotency; observability (correlation IDs) |
| SPEC-PROC | Happy path E2E; Alternative paths E2E | Compensation (для saga); SLA end-to-end |
| SPEC-UI | VLM-judge с baseline (judge ≠ production); Accessibility (WCAG-AA минимум) | i18n (string overflow / RTL); Journey E2E |
| SPEC-AI | Eval против baseline dataset (judge isolated) | Adversarial (prompt injection как negative TC); Cost regression; Hallucination tests |
| SPEC-SEC | Authz / RBAC matrix; Threat-test per STRIDE-категории | Audit log; Secrets leakage; Encryption invariants |
| SPEC-OPS | Smoke after deploy; SLO regression (load test) | Failover / DR drill; Observability (alert firing correctness) |
Substrate-нативный hook promote SPEC → verified (глава 11 §11.3.3) обязан проверять наличие минимум по одному TC каждого обязательного вида и блокировать переход при отсутствии.
Таблица закрыта на v1.0. Расширение — только через formal change procedure (глава 14).
9.9 Lifecycle TC
9.9.1 State machine
draft ──[QG-0 approval]──▶ ready ──[runner pass]──▶ passing
│ │
│ [runner fail] │
└─────────────────────▶ failing
│
[delta-ТЗ invalidation; │
see §9.16] │
┌────────────────────────────────────────┘
▼
obsolete| Статус | Смысл | Триггер перехода |
|---|---|---|
draft | Создан, реализация в работе | Создание AI-агентом |
ready | Реализация валидна; dry-run runner прошёл; pos/neg парность подтверждена | QG-0 (§9.10): one-click approval |
passing | Последний прогон last-run.result = pass на текущей requirement-version | Bot-managed по факту прогона |
failing | Последний прогон last-run.result = fail | Bot-managed по факту прогона |
obsolete | Терминальный; покрываемое поведение больше не существует | Delta-ТЗ инвалидация (§9.16) или deprecation родительского артефакта |
obsolete — терминальный статус: TC в obsolete не удаляется, остаётся как исторический след (immutable IDs, V1; см. глава 11 §11.3.1).
9.9.2 Связь со статусом верифицируемого артефакта
Перевод BR / SR / SPEC в verified нормативно требует: все TC из verified-by верифицируемого артефакта имеют last-run.result = pass и last-run.requirement-version совпадает с текущей версией артефакта (см. §9.10 QG-2).
9.10 Quality Gates для TC
Канонические определения Quality Gates — в главе 10 §10.3. Эта секция — TC-локальная сводка gates, применимых к TC напрямую (QG-0, QG-1) или использующих TC как evidence (QG-2). Нумерация и семантика обязаны совпадать с канонической §10.3; project-local переопределение запрещено (§10.10.2).
| Gate (canonical) | Роль TC | Pre-condition (краткая; полная — в ch10) | Post-condition |
|---|---|---|---|
| QG-0 — Approval (§10.3.1) | TC (draft → ready) — approval-часть | Citation на verifies[] — артефакт существует в substrate в состоянии не ниже approved; общие pre-conditions §10.3.1; actor approval зафиксирован substrate-нативно (V3 + V6) | TC разрешается к проверке QG-1 |
| QG-1 — Implementation (§10.3.2) | TC (draft → ready) — implementation-часть | automation.status = automated (или manual-pending с дедлайном + reason); pos/neg парность (§9.7); dry-run runner прошёл; обязательные секции body TC (§9.4) заполнены | TC переходит в ready; runner допускается к production-прогону |
| QG-2 — Verification (§10.3.3) | Артефакт (BR / SR / SPEC / TR) → verified / → done; TC участвует как evidence | Все TC из verified-by верифицируемого артефакта в статусе passing; pos/neg парность для каждого нормативного утверждения; spec-specific обязательные виды TC (§9.8) присутствуют; last-run.requirement-version совпадает с текущей version артефакта | Верифицируемый артефакт переходит в verified (TR — в done); TC остаётся passing |
Substrate-native one-click promote draft → ready атомарно проверяет pre-conditions обоих QG-0 и QG-1 как единый bundle (см. §10.3.2 «Триггер») — диаграмма §9.9.1 показывает агрегированный gate-passage как «QG-0 approval».
Проверка совпадения last-run.requirement-version с текущей version верифицируемого артефакта при каждом последующем прогоне TC — runner-managed consistency check (§10.9.3), не отдельный Quality Gate в смысле §10.2.1. При mismatch substrate автоматически переводит TC в failing до повторного прогона на актуальной версии артефакта; record в audit-trail (§10.13) фиксируется типом runner-fail, не gate-passage.
Substrate-нативные hooks (глава 11 §11.3) обязаны блокировать gate-переходы, нарушающие pre-condition.
9.11 Pass / Fail / Out of scope — нормативные критерии
9.11.1 Pass-критерий
Pass-критерий обязан быть:
- Бинарным — да или нет, без интерпретации.
- Наблюдаемым — фиксируется без доступа к внутренним структурам системы.
- Воспроизводимым — повторный прогон в тех же условиях даёт тот же результат.
| Плохо | Хорошо |
|---|---|
| «Логин работает корректно» | «POST /auth/login с верными credentials возвращает 200 и JWT с exp = now + 24h ± 1м» |
| «Производительность приемлемая» | «p95 latency < 200 мс при 100 RPS на /search в течение 5 минут» |
| «Ошибка обрабатывается» | «При невалидном email возвращается 422 с телом {"field":"email","code":"invalid_format"}» |
9.11.2 Fail-критерий
Fail-критерий — не отрицание Pass. Перечисляет наблюдаемые признаки нарушения, в том числе те, которые Pass-критерий явно не покрывает:
- Какой ответ / состояние / событие признаётся отказом.
- Утечки информации (например, в 401 не должно быть указано, какое именно поле credentials неверно).
- Side-effects, которых не должно быть — запись в лог, отправка письма, мутация других записей.
- Race conditions: одновременные запросы не приводят к нарушению инвариантов.
9.11.3 Out of scope
Каждый TC обязательно содержит секцию «Out of scope» с явным перечислением:
- Что намеренно не проверяется этим TC;
- Где это покрыто (ссылка на парный TC или другой TC).
Раздел защищает от ложного ощущения покрытия (см. также глава 12 — coverage matrix). Отсутствие явного «Out of scope» нормативно блокирует QG-0 (§9.10).
9.12 last-run — bot-managed only
Поле last-run (date / result / runner-id / run-ref / requirement-version / judge-report) заполняется только автоматическим runner’ом (CI-bot / AI-runner / specialized executor). Ручное редактирование last-run любым человеком — нарушение стандарта; substrate-нативный hook (глава 11 §11.3.6) обязан блокировать change unit, изменяющий last-run от non-bot author.
Состав last-run:
| Поле | Mandatory | Содержание |
|---|---|---|
date | да | ISO-datetime прогона |
result | да | pass | fail | skipped | n/a |
runner-id | да | Идентификатор runner’а + версия |
run-ref | да | Substrate-native pointer на полный лог прогона |
requirement-version | да | Версия верифицируемого артефакта на момент прогона (V5 pinning) |
judge-report | да для ux | eval | Inline или pointer на отчёт VLM/eval-judge |
9.13 Защита от подгонки тестов
9.13.1 Нормативное правило
AI-агент не может одновременно изменить implementation-код и Pass / Fail-критерии существующего TC в одном change unit так, чтобы failing TC становился passing, без явного approval инженером на изменение TC.
Без этого правила AI-агент имеет тривиальный путь к зелёному прогону — ослабить критерий вместо исправления кода.
9.13.2 Механизм [test-spec-change]
| Класс изменения | Тег | Approval |
|---|---|---|
| Изменение Pass / Fail-критериев существующего TC | [test-spec-change] | Mandatory: явный approval инженером change unit отдельно от любого изменения implementation-кода |
Изменение automation.location (перенос реализации без изменения проверяемого поведения) | — | Без отдельного approval |
| Изменение implementation-кода без правок TC | — | Standard workflow |
Обновление baseline.artifact / dataset / mockup-baseline | [baseline-update] | Mandatory: явный approval инженером |
| Создание нового TC | — | QG-0 (§9.10) |
Substrate-нативная реализация тегов — substrate-specific (см. guide/03, guide/04); нормативное требование — атомарность change unit, явное обозначение класса изменения, и опциональная (но рекомендуемая) изоляция таких изменений в отдельный change unit от изменений implementation-кода.
9.13.3 Аудит
Все change units с тегом [test-spec-change] агрегируются в substrate-нативный audit-feed для архитектора. Цель — отследить паттерн: если AI-агент часто запрашивает изменение критериев, это сигнал о проблеме формулировок исходного требования (глава 07 ADAPT backward finding категории terminology или gap).
9.13.4 Judge isolation (P7) — частный случай защиты
judge.vendor + judge.model обязательно отличается от production-модели верифицируемого SPEC-AI (§9.6.2). Совпадение блокируется substrate-нативным hook’ом.
9.14 Спот-чек инженера
9.14.1 Нормативная процедура
Раз в спринт (или эквивалентный регулярный интервал, фиксируемый в conformance manifest проекта) инженер выполняет спот-чек 5 случайных TC в статусе passing. Цель — поймать ситуацию, когда AI-агент сгенерировал «зелёный» TC, который ничего значимого не проверяет (assert True-эквивалент; VLM-prompt, проходящий на пустом экране; eval-критерий, всегда возвращающий pass на baseline).
9.14.2 Sampling
| Параметр | Нормативное требование |
|---|---|
| Размер выборки | 5 TC (по умолчанию); может быть увеличено в conformance manifest проекта |
| Распределение по типам | Равномерное по tc-type (acceptance / ux / system / contract / eval / security) — каждый тип имеет шанс быть выбранным |
| Статус | Только passing |
| Кто выбирает | AI-агент случайным образом (substrate-native randomness; seed фиксируется в audit-feed) |
9.14.3 Что инженер проверяет
- Соответствует ли Pass / Fail-критерий заявленному поведению в верифицируемом артефакте?
- Не слишком ли мягкий критерий VLM-judge или eval-judge?
- Реальны ли предусловия (не подменены ли seed’ом, маскирующим bug)?
- Покрывает ли Out-of-scope именно то, что должен покрывать парный TC?
9.14.4 Фиксация результата
Результат спот-чека фиксируется substrate-native:
last-spot-check:
date: "<ISO-date>"
by: "<engineer-id>"
sampled-tests: [TC-NN, TC-NN, ...]
issues-found: integer
issues:
- test: "TC-NN"
issue: "<краткое описание>"9.14.5 Реакция на находки
При issues-found > 0:
- Архитектор регистрирует change unit на исправление найденных TC.
- AI-агент обязан учесть выявленный паттерн в следующих генерациях TC; паттерн добавляется в system prompt агента или в meta-style guide.
- При повторном обнаружении того же паттерна — эскалация на пересмотр шаблона генерации TC.
9.15 Coverage matrix (auto-generated)
9.15.1 COVERAGE-artifact
COVERAGE.md (substrate-native имя artifact) — auto-generated сводный отчёт покрытия требований и спецификаций тест-кейсами на уровне requirements substrate. Помечается substrate-native флагом auto-generated.
9.15.2 Mandatory метрики
| Метрика | Цель | Действие при нарушении |
|---|---|---|
coverage-percent (verified / total artifacts) | Целевой порог фиксируется в conformance manifest | Substrate-нативный gate блокирует промоушн |
approved без verified | 0 перед промоушн | Бэклог AI-агента на следующую итерацию |
| Покрытие парным negative TC | 100% утверждений | AI-агент создаёт change unit с парным негативом |
passing-tests / total-tests | 100% перед промоушн change unit | Блокирует QG-2 (§9.10) |
manual-pending overdue | 0 | Уведомление архитектору; блокировка затронутых артефактов |
Stale (last-run.requirement-version < текущей) | 0 | AI-агент перезапускает прогон |
9.15.3 Триггеры перегенерации
COVERAGE.md перегенерируется автоматически при:
- Завершении change unit с изменением артефактов требований / SPEC / TC;
- Промоушн change unit в основную линию substrate;
- Каждом успешном прогоне runner’а (обновление
last-run); - По расписанию (substrate-native scheduler).
9.16 Delta-ТЗ и TC
9.16.1 Impact analysis по тестам
При delta-ТЗ (глава 07 §7.6) AI-агент выполняет impact analysis по TC одновременно с impact analysis по требованиям:
-
Находит все TC, у которых
verifies[].versionниже новой версии верифицируемого артефакта. -
Помечает их
obsolete-pending: true. -
Формирует таблицу затронутых TC в frontmatter delta-ADAPT или связанном change unit:
TC Verifies Старая версия Новая версия Действие TC-NN SR-NN v1.1 v1.2 Update (новый шаг) TC-NN SR-NN v1.1 v1.2 Без изменений (актуален) TC-NN BR-NN v1.0 deprecated Перевести в obsolete -
Генерирует обновлённые версии TC в том же change unit, что delta-ADAPT.
-
После прогона обновлённых TC и их перехода в
passing— снимаетobsolete-pendingи обновляетverifies[].versionна новую версию артефакта.
9.16.2 Переход TC в obsolete
TC переходит в obsolete (терминально), если:
- Родительский артефакт (BR / SR / SPEC) переведён в
deprecatedбез замены; - Родительский артефакт заменён новым (
replaced-by), для которого создан новый набор TC, и старый набор не покрывает поведения нового артефакта; - Поведение, покрываемое TC, в новой версии артефакта больше не существует.
obsolete TC immutable и не удаляется (V1; см. глава 11 §11.3.1).
9.17 Storage layout
Тест-кейсы хранятся в подпапке tests/ requirements substrate. Substrate-нативная реализация storage — substrate-specific (см. guide/03 для distributed VCS; guide/04 для document-oriented store).
9.17.1 На уровне системы / подсистемы
[system|subsystem].req/
br/ sr/ tr/ # глава 06
specs/ # глава 08
adapt/ # глава 07
tests/
acceptance/ TC-NN-*.md
system/ TC-NN-*.md
ux/ TC-NN-*.md
contract/ TC-NN-*.md
eval/ TC-NN-*.md
security/ TC-NN-*.md
baselines/ # для ux / eval
<baseline-artifact>.png
<eval-dataset>.jsonl
COVERAGE.md # auto-generated (см. §9.15)9.17.2 Implementation в code substrate
Реализация TC (код) живёт в code substrate отдельно от requirements substrate; адресуется полем automation.location (substrate-native pointer). Связь TC↔implementation: 1:1.
9.18 Связь с другими главами
| Глава | Связь |
|---|---|
| 05 Положение в типологии методологий | TC — нижний слой trace chain (Утверждение 1 SoT inversion); pinning требования через verifies[].version (Утверждение 3 substrate versioning) |
| 06 Иерархия требований | TC верифицирует BR / SR; verified-by[] — auto-derived inverse edge на стороне требования |
| 07 ADAPT | TC → SR → ADAPT → ТЗ — полная trace chain; backward findings (terminology, gap) питаются паттернами из [test-spec-change] audit (§9.13.3) |
| 08 Specifications | Spec-specific TC по таблице §9.8; SPEC → verified-by[] auto-derived; type-specific extensions §9.6 |
| 10 Lifecycle и QG | TC state machine; QG-0 + QG-1 bundle для TC (draft → ready); QG-2 для верифицируемого артефакта требует pos/neg парность и spec-specific виды TC |
| 11 Substrate versioning | Immutable IDs (V1); atomic change unit и hooks (V2 + V3); diff & review для [test-spec-change] (V3); версионирование TC без потери истории (V4); pinning verifies[].version (V5); author + timestamp для last-run (V6) |
| 12 Maturity model | RENAR-1: TC обязательно; RENAR-3+: pos/neg pairing 100%, spec-specific TC table обязательно; RENAR-4+: AI-generated + AI-executed |
| 14 Conformance | Closed list типов TC (§9.5) — mandatory clause v1.0; spec-specific TC table (§9.8) — mandatory clause v1.0; pos/neg pairing — mandatory clause v1.0; judge ≠ production isolation — mandatory clause v1.0 |
| reference/02 — schemas | Полная machine-readable schema TC frontmatter + type-specific extensions |