场景三 · 测试用例自动生成

业务背景

ASPICE SWE.4 要求：每条软件需求都有对应的测试用例，且测试方法（等价类划分、边界值分析、错误猜测、故障注入等）需符合标准。

实际项目中的问题：

从需求到 CAPL 测试脚本的转化高度依赖资深测试工程师的经验
每条需求平均耗费 0.5–1 人天
不同工程师的写法风格不一致，给后续维护带来困难

演示能力

Rendering diagram…

平台从软件需求规格中抽取需求条目，再从 CAN 通信矩阵（DBC 文件）和架构文档中抽取信号定义：

自动建立"需求 ↔ 信号"映射，匹配不上的需求显式标记为 NO_SIGNAL（暴露上游接口缺口）
按照 ASPICE SWE.4 规范，用 automotive-process-analyzer skill 挑选合适的派生技术（等价类 EP / 边界值 BVA / 状态转换 / 结构性覆盖）
输出可在 Vector CANoe 仿真环境中直接运行的 CAPL 脚本：
- 测试模块（Test Module） — 组织 testcase，人工手写 + skill 模板
- 仿真节点（Simulation Node） — canoe-test-automation 自动产出，模拟物理 ECU 的信号响应

实际发给 Agent 的提示词

演示账号 testcasegenerator 在 Session DEMO-C CAPL 测试用例 里真实发出的指令。这条提示词最关键的是：明确区分"仿真节点 CAPL（工具自动产出）"和"Test Module CAPL（Agent 按模板手写）"，避免 Agent 误用 skill：

请你扮演 ASPICE SWE.4 测试工程师，从 ABZ 灯控 v1.17 软件需求出发，直接生成可在 CANoe 里跑的 CAPL 测试用例。

## 可用 skill
- automotive-process-analyzer（SWE.4 测试用例 + 信号接口规范）
- canoe-test-automation（DBC 解析 + 仿真节点 CAPL 工具自动生成 + Test Module CAPL 测试用例由你按 skill 自带模板手写）
- html-report
- 通用文件能力（write_file + python-docx）

⚠️ 关于 canoe-test-automation 的关键认知（必读 SKILL.md 确认）：
- 工具会自动产出'仿真节点 CAPL'（搭建虚拟 ECU 环境，不是测试用例本身）
- 'Test Module CAPL'（真正的测试用例 .can）是 你自己写——
  skill 在 templates/ 下提供测试模块模板、references/ 下提供 Test Module CAPL API 速查，
  你按需求逐条写 testcase_ 函数填进模板。

## 数据（KB = ABZ）
- 02-Software-Requirements-Specification-v1.17.docx（需求来源）
- 03-Software-Architecture-Design-v1.17.docx（信号 / 接口定义）
- vector-lightcontrol-CAN.dbc（信号定义；已上传到 KB）

## 业务步骤
1. 让 automotive-process-analyzer 给出 SWE.4 测试用例写法规范（覆盖方法 / 派生技术 / 通过准则）
2. 从 02 号 docx 提取灯控相关功能需求（ELS 档位、远近光、自适应、故障降级）
3. 用 canoe-test-automation 解析 DBC、生成仿真节点 CAPL；再把每条需求映射到 1+ DBC 信号，匹配不上的需求标记 NO_SIGNAL
4. 按 skill 提供的 Test Module 模板和 API 速查，为每条需求手写 1+ testcase 函数
   （命名 testcase_<req_id>_<场景>；注释含源需求 ID / 信号 / 预期值 / 超时；函数体 setup / 激励 / 等待 / 校验 / 日志）
5. 同步给出测试用例总览 docx + 信号覆盖率 html

## 通过标准
- ≥ 5 条 testcase（每条 ≥ 10 行实质代码）
- 每个 testcase_ 头注释里能找到源需求 ID
- DBC 中真实存在的信号名才能写进 CAPL（不准虚构信号名）
- 仿真节点 .can 与 Test Module .can 两类文件都落盘

这条提示词里最关键的约束是"DBC 中真实存在的信号名才能写进 CAPL"——这是防止大模型对着需求虚构信号名（典型幻觉）。演示 session 最终只产出了 6 条 testcase（而不是 8 条），就是因为 DBC 里真实存在的灯控信号只有 HeadLight / LightSwitch 两个。

实测数据

维度	数值
灯控域软件需求	49 条（ELS-1 ~ ELS-49）
DBC 真实灯控信号	2 个（`HeadLight` LightCtrl 0x268 / `LightSwitch` LightSwitch 0x210）
完成"需求 → 信号"映射	3 条 MAPPED（ELS-14 / ELS-16 / ELS-18）+ 46 条 NO_SIGNAL（暴露上游接口缺口）
生成的 CAPL 文件	2 份（`ABZLightControl_TestModule.can` 13.5 KB / `simulation_node.can` 8.3 KB）
派生的测试用例	6 个 testcase（TC-1 ~ TC-6，全部有源需求 ID 可追溯）
覆盖的派生技术	4 种：等价类划分 (EP) · 边界值分析 (BVA) · 状态转换 · 结构性覆盖

Agent 产出的自包含 HTML 看板（C-test-coverage.html）：信号匹配率、每需求平均 testcase 数、DBC 信号使用率三个 KPI，下面是"需求 × 信号覆盖率热力图"——深蓝表示有 testcase 覆盖，灰色表示 NO_SIGNAL。

测试覆盖看板 - KPI + 需求 × 信号热力图

需求 × 信号覆盖率热力图（放大视图）：ELS-14/16/18 三条需求完美映射到 DBC 里真实存在的 HeadLight / LightSwitch 两个信号；其余 17 条代表性需求（ELS-29 灯光亮度 100%、ELS-42 欠压调光、ELS-39 刹车灯…）因为 DBC 里没有对应信号全部标成 NO_SIGNAL。

需求 ↔ 信号映射热力图

自动生成的 CAPL 测试脚本（ABZLightControl_TestModule.can 首 110 行）：包含注释头、6 条 testcase 清单、全局变量定义、MainTest 入口、TC-1 完整实现（Setup / Stimulus / Check / Assert / Log 五段式）。

自动生成的 CAPL 测试脚本样例（含完整 TC-1）

6 条 testcase ↔ SWE.4 派生技术映射表：每条 testcase 都能溯源到 ELS 需求 ID、DBC 信号名和对应的 ASPICE SWE.4 派生技术。一张表就把"为什么写了这 6 条、每条覆盖什么场景"说清楚。

测试用例派生方法映射（SWE.4 4 种技术全覆盖）

客户价值

对测试团队的直接收益：

每条 testcase 从 0.5–1 人天压缩到 10 分钟级
输出格式统一、命名规范一致（testcase_<req_id>_<场景>），工程师只需 review 而无需从零编写
把"哪些需求当前没有信号可测试"这种隐藏的接口缺口显式呈现（46 条 NO_SIGNAL），反向驱动需求和架构补全
强约束：DBC 里不存在的信号名不会被虚构，避免了大模型写 CAPL 的典型幻觉

交付物

类别	文件
报告文档	`C-test-cases-overview.docx`（40 KB）
可视化看板	`C-test-coverage.html`（20 KB）
过程工件	`swe4-test-specification.md` / `requirement-signal-mapping.md` / `architecture-signal-definitions.md` / `dbc-signal-list.md` / `abz-requirements-extraction.md`
CAPL 脚本	2 份（`ABZLightControl_TestModule.can` 测试模块 + `simulation_node.can` 仿真节点）

下一步

在场景四中，生成的 CAPL 用例会通过 Graft 被引用，参与双向覆盖矩阵计算
回到场景二：对"需要新建的 22 项"回归测试自动补齐