场景四 · 测试覆盖审计

业务背景

项目在测试执行前需要回答两个问题：

「我有没有为每条需求都准备了测试？」—— 保障覆盖率
「我是否存在没挂在任何需求上的孤儿测试？」—— 保障测试集合的有效性

手工方法是用 Excel 维护一张矩阵，由质量人员逐条核对——代价高且容易过时。

演示能力

平台读取项目的需求基线、计划测试用例、自动生成的 CAPL 用例和现有的验证序列：

构建双向覆盖矩阵
按需求类型（功能需求 / 安全需求 / 接口需求等）和业务域（近光灯、远光灯、方向灯、危险灯、角灯、转向控制等）分别计算覆盖率
与场景一的追溯结果交叉验证，识别两个分析视角不一致的条目

🌟 本场景的 Graft 架构

本场景通过 Graft 引用两个上游 Session 的结果：

Rendering diagram…

Graft 在这里的两个作用：

资产复用 — 场景一的追溯数据、场景三的新测试用例不必重读原始文档，直接引用上游结构化结果
交叉验证 — 两个独立 Session 得出的覆盖结论做对比，差异部分自动标为"待复核项"——这是避免"单一视角误判"的系统机制

相关阅读：Graft 跨会话嫁接

实际发给 Agent 的提示词

演示账号 testcasegenerator 在 Session DEMO-D 测试-需求映射审计 里真实发出的指令。这条提示词最关键的是显式列出上游两个 session 的 ID，让 Agent 用 graft skill 去拉前置产物，避免重新读一遍原始文档：

请你扮演 ASPICE SWE.6 验证评审员，审计 ABZ 灯控 v1.17 的测试 ↔ 需求映射完备性。

## 可用 skill
- automotive-process-analyzer（SWE.6 双向矩阵 + 验证评审框架）
- graft（拉前置 session 的 artifact）
- xlsx（生成 .xlsx 矩阵）
- html-report
- 通用文件能力（write_file + python-docx）
怎么用 skill 自己看 SKILL.md。

## 数据（KB = ABZ）
- 02-Software-Requirements-Specification-v1.17.docx
- 07-Verification-and-Validation-Plan-v1.17.docx
- 08-Traceability-Matrix-v1.17.xlsx（GT）
- ValidationSequences_v1.8.xlsx
- 前置 session 产出（用 graft 引用）：
  - DEMO-A 追溯审计 session_id = 51363f993de311f1a60a2930eb8c35dd
  - DEMO-C CAPL 测试用例 session_id = 571333d23de311f1a60a2930eb8c35dd

## 业务步骤
1. 用 graft 拉取 DEMO-C 的产出（C-capl/ABZLightControl_TestModule.can + C-test-cases-overview.docx），
   提取 testcase_<req_id> → req_id 映射。
2. 用 graft 拉取 DEMO-A 的产出（A-aspice-traceability-report.docx），
   拿 SwRS → SwTest 的链路作为旁证。
3. 让 automotive-process-analyzer 给出 SWE.6 双向矩阵的格式与评审准则。
4. 构建双向矩阵：
   - 正向（需求 → 测试）：每条 SwRS 列出覆盖它的 testcase
   - 反向（测试 → 需求）：每条 testcase 列出它声称覆盖的 SwRS
5. 从 07 号文档 + ValidationSequences 把'已规划但未实现'的测试也算进来，
   区分三种状态：planned / implemented_in_capl / executed_in_validation_seq。
6. 与 08 号 GT 矩阵对照，找出：
   - 未覆盖需求（GT 说该测、但 CAPL + Validation 都没有）
   - 孤儿测试（CAPL 里有、上游需求找不到）

## 产出
1. outputs/D-coverage-matrix.xlsx
   Sheet1 正向矩阵  Sheet2 反向矩阵  Sheet3 缺失需求  Sheet4 孤儿测试
2. outputs/D-test-requirement-coverage.docx
   §1 覆盖率 KPI  §2 三状态分布表  §3 缺失需求清单 + 优先级建议  §4 孤儿测试清单
3. outputs/D-coverage-dashboard.html
   仪表盘（覆盖率）+ 堆叠柱（PA 的 planned/implemented/executed）+ 未覆盖需求高亮表

## 通过标准
- graft 成功拿到 DEMO-A 和 DEMO-C 的产出（明确说明引用的 artifact 路径）
- 双向矩阵两个方向行数自洽
- 至少 1 条未覆盖需求被识别（若全覆盖则给出反例论证）
- xlsx + docx + html 都生成成功

这条提示词就是 Graft 在真实项目里的标准用法——先有 DEMO-A / DEMO-C 两个独立 session 各自完成追溯和测试生成，等到要做覆盖审计时，把两个 session_id 贴进来，Agent 直接读取上游 artifact 做交叉比对，不需要把 docx/xlsx 重新读一遍。Token 节省一倍以上，且结论可溯源。

实测数据

总体覆盖情况：

维度	数值
需求总数	105 条
已被覆盖	46 条
未被覆盖	59 条
整体覆盖率	43.8%
孤儿测试	0 个

按需求类型分组：

需求类型	总数	已覆盖	覆盖率
功能需求 (ELS)	49	40	81.6%
安全控制需求 (SCS)	43	0	0.0% ⚠️
功能安全需求 (FSR)	13	6	46.2%

按业务域分组（计划用例 / 已有 CAPL 用例 / 已有 ValSeq 序列）：

业务域	计划	CAPL	ValSeq
近光灯	9	7	5
远光灯	6	0	2
方向灯	12	0	3
危险灯	2	0	0
角灯	3	0	0
转向控制 (SCS)	0	0	0
其他	13	0	0

与场景一的交叉验证结果：

34 条需求两个视角一致 ✅
14 条仅在场景一识别到（可能是漏了测试）
79 条仅在场景四识别到（可能是场景一追溯不全）
差异部分自动标记为"待复核项"，避免单一视角带来的误判

Agent 产出的自包含 HTML 看板（D-coverage-dashboard.html）顶部：105 / 46 / 59 / 43.8% 四张 KPI 卡，下方是"按功能域 — 三级测试覆盖分布"堆叠柱图（已规划 / 已实现 CAPL / 已执行验证序列）和"按需求类型覆盖率"环形图。

双向覆盖审计看板 - 总览 KPI + 双图表

按需求类型覆盖率环形图：ELS 功能需求 81.6%、FSR 功能安全需求 46.2%、SCS 安全控制需求 0%——SCS 的 0% 覆盖率是一眼可见的重大风险项（图中的橙色 / 红色区块）。

按需求类型的覆盖率对比（突出 SCS 0%）

按功能域 — 三级测试覆盖分布堆叠柱图：蓝色 = 已规划 / 绿色 = 已实现 CAPL / 橙色 = 已执行验证序列。近光灯（21 条需求，三色齐全）是当前测试最完整的域；其他域如远光灯 / 方向灯几乎只有"已规划"，一眼看出"计划了多少、真正落地多少"的差距。

按业务域的三级覆盖分布

全部需求覆盖状态表（105 条，支持按功能域 / 状态 / 关键词筛选）：已覆盖 显示绿色、未覆盖 显示红色。表格同步列出每条需求的覆盖测试名（例如 ELS-14 被 TC_LowBeam_On / TC_LowBeam_Off 等多条 testcase 覆盖）。可以直接作为评审会议里"逐条核对"的替代物。

全部需求 × 测试覆盖状态（105 条清单）

客户价值

一份矩阵同时回答三个问题：

覆盖率
缺口分布
孤儿测试

并按需求类型和业务域两个维度切分，让管理层可以快速定位"哪个域风险最大"（本例中 SCS 域 0% 覆盖率是首要风险）。

多视角交叉验证机制确保结论可信，避免把覆盖率指标"包装得好看但失真"。

交付物

类别	文件
报告文档	`D-test-requirement-coverage.docx`
可视化看板	`D-coverage-dashboard.html`
结构化数据	`D-coverage-matrix.xlsx` / `coverage_analysis.json` / `dashboard_data.json`

下一步

把差异项（14 + 79 共 93 条待复核）分配给责任人处理
针对 SCS 域 0% 覆盖率回到场景三批量生成测试用例
进入新基线后，触发场景二的常态化变更管理
深入理解本场景依赖的 Graft 机制

场景四 · 测试覆盖审计

On this page