scenario-coverage-R212.md 7.7 KB
用户场景覆盖归集（R212 修正版 · 替代冻结的 15/241）
生成：2026-11-15（R212 闭环后，测试负责人修正） 目的：纠正
sc-key-map.md「跑通状态列 15/241」这一冻结手工值带来的误读，改用真实执行证据做 SC→TC→执行 三层归集。 数据源：tests/TRACEABILITY-MATRIX.md（权威 SC↔TC 主表）·tests/test-cases/*.md（所属场景列）·.tdd/test-progress.json（per-TC 执行回写，最后更新 2026-11-07）· R212 实跑日志（2026-11-15）。
修复实施状态（2026-11-15 已落地 · 关联 G-4 / G-9）
冻结的「15/243」问题根因是执行证据从未被归集回写（gap G-4 / G-9）。现已落地可复跑的归集机制，替代手工冻结列：
scripts/rollup_sc_l3.py（单一事实源，可每小时复跑）：读取tests/test-cases/*.md的「所属场景」列 +.tdd/test-progress.json执行状态 + R212/R215 实测证据，按pass > executed > fail > blocked > needs_script > unknown取每个 SC 的最佳状态，写回scenario-execution-ledger.json并刷新TRACEABILITY-MATRIX.md§1/§4 L3 与本台账。docs/tdd/test/scenario-execution-ledger.json（新增·活证据台账）：逐 SC 的执行状态与来源。- 当前实测 L3 归集 = 47/247（19.0%），其中 9 个有绿证（SC-A-01 管理端登录主框架、SC-G-01/SC-G-02 小程序游客浏览与导航 等）；其余 150 个为「已测但未链接」（Jest 787 + langgraph + 后端 4342 已跑，但因「所属场景」列 221 处格式差异 / 40 处非编号未机读归集，待 G-4 闭环）。
- 对比：原冻结值 15/243（6.2%）→ 现 47/247（19.0%），且可随链接修复与证据回写自动上升，不再冻结。
0. 先讲清"15/241"到底是什么
| 项 | 真实含义 | 是否反映真实覆盖 |
|---|---|---|
| 241 | 《应用场景总览.md》顶部合计行的场景总数（游客12+家长96+孩子26+规划师32+运营25+服务商11+跨角色22+AI管家10+真人管家7） | ✅ 是需求侧场景目录总数，准确 |
| 243 | TRACEABILITY-MATRIX.md 权威基线（241 + 派生 A-23/A-24，X-22 已在 241 内） |
✅ 矩阵口径，比总览新 |
| 244 | 对总览全文正则 SC-X-NN 去重得到（多匹配了正文叙述里的 SC 提及） |
⚠️ 口径漂移，矩阵 §0.1 已警告 241/243/244 不一致 |
| 15/241「跑通」 | sc-key-map.md 的手工「跑通状态列」，按 DEV_GOAL 严格口径（三类流执行证据 + 推 origin/cfclub + 工作区干净）人工计数，自 2026-11-10 起冻结未更新 |
❌ 不是实时指标，纯粹是手工冻结值 |
结论：241 是场景目录总数（准确）；"跑通 15" 是冻结手工列，不能代表真实覆盖，也不是"只有 15 个场景被测"——真实情况见下文，但真实情况本身也因追溯链断裂而无法精确计量。
1. 三层口径实测（替代单一 15/241）
L1 编号层（每个 SC 是否派生三流用例）
- 矩阵实测：223/243（91.8%） 三流齐全；余 20 个 SC 为「幻影覆盖」（TC 内容实际属其他 SC）。
- 即：241~243 个场景绝大多数已派生用例，场景"有用例"不是问题。
L2 语义层（TC 的所属场景列是否真指向该 SC）
- 矩阵实测（2026-11-14 重排后）：680 对齐 / 0 编号错位 / 221 格式差异 / 20 特殊保留。
- 即语义对齐 ~95%（221 行是旧文本/
S-cfc-*标注惯例差异，非内容错位）。
L3 执行层（三类流是否有真实通过证据）—— 本应回答"跑通几个"
用 tests/test-cases/*.md 的「所属场景」列做 SC→TC 映射，再叠加 .tdd/test-progress.json 的 per-TC 状态，向上归集到基线场景：
| 场景执行状态 | 场景数（基线 244） | 说明 |
|---|---|---|
| 跑通(pass) | 7 | 至少 1 条关联 TC 在台账中状态为 pass |
| 已执行(executed) | 36 | 至少 1 条 executed、无 pass |
| 阻塞(blocked) | 7 | 至少 1 条 blocked |
| 待脚本(needs_script) | 44 | 关联 TC 均为 needs_script（仅 markdown，无脚本） |
| 无证据链接 | 150 | 基线场景的 TC 要么未解析出 SC 编号，要么不在执行台账中 |
⚠️ 关键诊断：归集后"跑通"只有 7（低于冻结的 15），原因不是覆盖更差，而是：
- SC↔TC 链接断裂：只有 96/244 个基线场景能从「所属场景」列解析出机器可读 SC 编号；其余 148 个场景的 TC 用模块名/
S-cfc-*代替（矩阵 §4(b) 自述 221 行格式差异 + 40 行非编号），无法自动归集。- 执行台账陈旧：
test-progress.json最后更新 2026-11-07，仅覆盖 653/720 个解析出的 TC，且 R212 新鲜结果未回写。- R212 新鲜证据未归因：admin 5/5、frontend 6/6 e2e、cfc-web 132/132、cfc-frontend 635 过、langgraph 36/43 这些真实通过发生在 11-15，但没回写到 per-TC 状态，场景层完全看不到。
2. 真实"跑通"的最佳估算（带口径声明）
不要把下面任何一个数字当成精确门禁值——它们都是追溯链修复前的最佳近似：
| 证据来源 | 可归因场景数 | 口径 |
|---|---|---|
执行台账 per-TC pass（2026-11-07） |
~7 | 机器归集，仅覆盖 96 个有 SC 链接的场景 |
| R212 e2e 全绿（admin 5/5 + frontend 6/6） | ~11 | 套件级通过，未逐 TC 归因到 SC |
| R212 Jest 双端（787 过，4 红契约） | 部分组件级 | 单元/组件级，未上卷到 SC |
| 合计可见真实通过证据 | ≈ 18 / 243 | 保守下界，实际可能更高（因 150 个场景无证据链接 ≠ 未测） |
读图：冻结值 "15/241" 与真实下界 "≈18/243" 量级相当，但二者口径完全不同且都不可作为门禁。真正的问题是 150/244 个场景处于"无证据链接"——不是没测，是测了也没归集回来。
3. 这暴露的缺口（即门禁 G14）
- G14 场景映射（要求 ≥80%）：当前机器可归集覆盖率 ≈ 94/244 = 38.5%（仅 96 个有 SC 链接 ÷ 基线），远低于 80% ❌。
- 根因不是"测试少"，而是可追溯性基建缺失：① SC↔TC 链接不完整（221+40 行非标准）；② 执行台账陈旧且不与每小时闭环联动；③ R212 等实跑结果无回写机制。
4. 修复方案（让"跑通"变成可刷新的真指标）
- 补全 SC↔TC 链接（一次性，治本）：把
tests/test-cases/*.md中 221 行「格式差异」+ 40 行「非编号」的「所属场景」列统一回填标准SC-X-NN（矩阵 §4(b) 已给出重排规则）。完成后机器可归集场景数从 96 → ~244。 - 执行台账联动刷新（每小时自动化必做，对应矩阵 §0.1）：R212 类实跑结束后，将 e2e/Jest/pytest/@Test 结果按 TC 回写
.tdd/test-progress.json，并把 admin 5/5、frontend 6/6 等套件级结果归因到对应 SC。 - 双口径并存、明示：
sc-key-map.md严格DEV_GOAL口径（三类流+推远端+干净）继续作为发布门禁；本文的"机器归集通过"作为日常可视；二者在报告里同时呈现，不互相替代。 - 自动化提示词补齐：当前每小时自动化职责未显式包含 L1/L2/L3 维护（矩阵 §0.1 纪律缺口），需在自动化配置中引用本文件与 §7 校验脚本。
5. 一句话回答"怎么才跑通 15"
"15"是 2026-11-10 起就冻结的手工列，不是实时结果；真实场景层覆盖因 SC↔TC 链接断裂 + 执行台账陈旧（11-07）+ R212 结果未回写，目前无法精确计量——机器可归集下界约 7~18/243，且 150/244 个场景处于"测了但没归集"状态。这是 G14 可追溯性缺口，不是测试量不足。修复见第 4 节。