场景二 · 版本变更影响分析

业务背景

车型平台化和软件迭代速度加快后，版本之间的变更动辄上百条。

当前主流做法：在评审会上由各模块负责人凭经验判断哪些下游产物受影响、需要回归哪些测试。

这种方式的两个问题：

影响范围识别不全 — 漏判会导致集成测试失败甚至外场召回
回归测试范围过大 — 导致测试周期拉长

SUP.10 标准虽然规定了变更管理流程，但缺乏可执行的工具支持。

演示能力

平台对项目两个版本（v1.14 与 v1.17）的全部需求、架构、设计文档做结构化抽取：

自动比对差异生成变更清单
根据 ASPICE 工作产物的层级关系，自上而下追踪每一条变更的下游影响节点
对照测试用例库，给出回归测试推荐清单（必须重跑 / 需要新建 / 当前缺口三类）

🌟 本场景的 Graft 架构（核心亮点）

这是整个案例的核心平台能力展示：

Rendering diagram…

为什么这是 Graft 的标本案例：

两个基线分析是独立工作，独立完成、独立审阅、独立归档
变更分析按需启动，只在需要版本对比时发起
不需要把两个基线的文档再读一次 — Graft 直接引用 A、B 两个 Session 里已经结构化好的结果
节省数倍 token，且结论可溯源（每一个影响节点都能点回两个上游 Session 的具体段落）

相关阅读：Graft 跨会话嫁接

实际发给 Agent 的提示词

演示账号 testcasegenerator 在 Session DEMO-B 版本变更影响 里真实发出的第一句指令（完整不删节）。客户复用时只需替换项目名和版本号：

请你扮演 ASPICE SUP.10 变更管理评审员，对 ABZ 灯控项目从 v1.14 → v1.17 做变更影响分析。

## 可用 skill
- automotive-process-analyzer（找 SUP.10 输出格式 + 影响分析模板）
- html-report
- 通用文件能力（write_file + python-docx）
怎么用 skill 自己看 SKILL.md。

## 数据（KB = ABZ）
v1.14 + v1.17 各 9 份 docx + 两份 casestudy_v1.{14,17}.pdf。重点对比 01-07 号。

## 业务步骤
1. 让 automotive-process-analyzer 给出 SUP.10 变更影响分析的输出框架。
2. 逐份对比同名 v1.14 / v1.17 docx，提取：
   - 新增条目（v1.17 有、v1.14 没有）
   - 删除条目（v1.14 有、v1.17 没了）
   - 修改条目（ID 一致、文本不同；列出 diff 摘要）
3. 对每条变更做影响传播分析：
   一条 SwRS 变了，影响哪些 SwAD / SwDD / SwTest 节点？
   一条 Safety Goal 变了，影响哪些 SafetyMechanism / SwTest？
4. 输出回归测试建议：哪几条 SwTest 必须重跑、哪几条新增。

## 产出
1. outputs/B-change-impact-report.docx
   §1 版本对比总览（KPI：新增 X / 删除 Y / 修改 Z）
   §2 变更明细表（ID / 类型 / 摘要 / 影响节点 / 严重度 H/M/L）
   §3 process area 影响热度
   §4 回归测试建议清单
2. outputs/B-change-impact-dashboard.html
   - 饼图：变更类型分布
   - Mermaid 拓扑图：受影响节点关系
   - 表格：回归测试建议（按严重度排序）

## 通过标准
- 至少识别 1 条新增需求 + 1 条修改需求
- 影响传播至少触达 SwRS / SwAD / SwDD / SwTest 4 层中的 ≥ 3 层
- 回归测试建议数量 = 受影响 SwTest 数（数学一致）
- docx + html 都生成成功

把"ABZ 灯控"换成自家项目名、把"v1.14 → v1.17"换成自家版本区间、把 KB 里 9 份 docx 换成自家基线产物，其余结构可原样套用。

实测数据

维度	数值
识别出的变更条目	178 条
受影响的下游节点	313 个
涉及的 ASPICE 层级	5 层（需求 / 架构 / 设计 / 测试 / 安全分析）
涉及的过程域	10 个（SWE.1–SWE.6、SYS.1、SUP.1、SUP.8、SUP.10）
严重度分布	高 35 / 中 79 / 低 64
回归测试推荐	178 项（其中 22 项需要新建测试用例，156 项为现有测试缺口）
优先级分布	P0 紧急 35，P1 高 142，P2 中 1

Agent 产出的自包含 HTML 看板（B-change-impact-dashboard.html）顶部：版本对比总览（总变更 178 / 新增 86 / 删除 27 / 修改 65）、文档级变更统计、变更类型 × 严重度的双饼图。

变更影响分析看板 - 总览 KPI + 文档级统计 + 类型 / 严重度分布

Process Area 影响热度表：10 个过程域按受影响条目数排序，SUP.1 / SUP.8 / SUP.10 各 178 条均标红，SWE.3~SWE.6 各 22 条标黄——一眼看清本次升级击穿到了 ASPICE 哪几层。

按 Process Area 分组的变更条目数热度

严重度 H 级变更传播路径（Top 35 条）：每个红色节点是一条 High 变更，通过黄色节点串到下游 SwRS / SwAD / SwDD / SwTest。

H 级变更的下游传播路径

回归测试建议清单（178 条，支持按优先级 / 类型 / 严重度筛选）：每条记录含 测试ID / 建议类型 / 关联变更ID / 优先级 / 严重度 / 理由。下表显示按 P0 筛出的头部清单，例如 TEST_GAP_SCS-17 对应"需求 SCS-17 已删除但无 SwTest 节点，需补充回归测试 (H 级)"。

回归测试建议清单 - P0 优先级筛选视图

客户价值

把变更评审从"经验判断"升级为"数据驱动"，三个直接收益：

影响范围量化，避免漏评估
回归测试有明确清单和优先级，测试团队可按 P0 → P2 排期
自动识别"现有测试缺口"，提示哪些变更目前没有任何测试覆盖，是质量风险点

交付物

类别	文件
报告文档	`B-change-impact-report.docx`
可视化看板	`B-change-impact-dashboard.html`
结构化数据	`04-change-manifest.json` / `05-impact-analysis.json` / `06-regression-test-recommendations.json`

下一步

基于推荐清单进入场景三：对"需要新建的 22 项"自动生成测试
场景四验证补齐后的覆盖率提升
深入理解 Graft 机制

场景二 · 版本变更影响分析

On this page