汽车测试自动化

方案定位

面向汽车测试部门 / HIL 实验室 / 集成测试团队，把"需求 → 测试用例 → 台架执行 → 结果回流 → 缺陷归档"这条长链路用 Agent 串起来，让测试工程师从"脚本工"变回"测试设计师"。

行业痛点

痛点	现状
测试用例的"翻译成本"	拿到一份需求文档，人工改写成 CAPL / M-Script / TCL，一个项目几百上千条
台架种类多、脚本不通用	dSPACE / NI / Vector / ETAS 等每家都有自己的脚本语言和 API
结果回流靠人	跑完一轮回归，人工看报告 → 人工登 Jira → 人工关联需求
覆盖率"美化"	测试用例与需求 ID 不关联，评估前靠手工填报，结果普遍虚高

支持的测试生态

厂商	工具链	对接能力
Vector	CANoe / CANalyzer / vTESTstudio	CAPL 脚本生成、仿真节点、测试工程导入导出、结果解析（详见 canoe-test-automation 技能）
dSPACE	ControlDesk / ConfigurationDesk / AutomationDesk	M-Script / Python 脚本、HIL 工程配置、实验自动执行
NI	VeriStand / TestStand / LabVIEW	TestStand Sequence、VeriStand 实时模型对接
ETAS	INCA / LABCAR	标定参数读写、HIL 脚本生成
其他	HIL 专用自研框架	通过 MCP 协议 / Skill 接入

全链路工作流

Rendering diagram…

四大能力

1. 从需求自动生成测试用例

输入：一条结构化需求（例："CAN 报文 0x123 若 100ms 未收到，则触发超时处理并写入 DTC"）

输出（Agent 自动生成）：

CAPL 用例：setTimer 模拟发送端断连、on timer 断言报文超时、checkDiagnostic 断言 DTC 被写入
边界组合：99ms、100ms、101ms、500ms、断电重启等
FMEA 故障注入：信号干扰、报文丢失、时间戳错乱

2. 多台架兼容

同一份需求，一次点击同时产出 CANoe CAPL、dSPACE M-Script、NI TestStand Sequence，根据实验室既有设备分派执行。

3. 结果回流与缺陷归档

日志解析：解析 CANoe .blf、dSPACE .mat、NI .tdms 等台架原生数据
失败分类：按功能 / 通信 / 诊断 / 性能自动分类
缺陷单自动回填：通过 bug-import 技能写入 Jira / Polarion / Redmine，附执行日志 + 失败现场快照
历史对照：失败用例对照 LTM 中的历史 Bug 模式，给出疑似根因提示

4. 双向覆盖率矩阵

正向：需求 → 测试用例 → 执行结果
反向：测试用例 → 关联的需求 ID
多维切片：按 ASIL 等级 / 业务域 / 组件模块分组

客户价值

维度	传统方式	combo agent
用例编写	人工改写，每条 30–90 分钟	自动生成，几秒到几分钟
多台架适配	各写各的，重复劳动	一次建模，多端产出
失败 → 缺陷单	人工搬运	Agent 自动回填，附现场证据
覆盖率统计	手工填报，易美化	系统按 ID 核对，可审计

操作步骤

前置：接入测试台架

接入方式	适用	配置
直接生成脚本	CANoe CAPL / dSPACE M-Script / NI TestStand Sequence	无需台架在线，Agent 直接产出脚本文件
远程下发执行	CI 环境、台架机已联网	通过 MCP 协议或自研 Agent 运行器对接台架

私有化部署下推荐远程下发，台架在内网，Agent 触发后自动跑。

从需求生成测试用例

基于 DOORS 里 Functional_Requirements 模块的所有需求，生成 CANoe CAPL 测试用例。每个功能需求至少 3 个用例（正常 / 边界 / 异常）。

Agent 会：

拉取所有需求
按"可测试性"判断哪些能直接生成、哪些需要人工补充
对每条需求生成 CAPL：
- 正常流：按需求描述走正常路径
- 边界：数值取边界值、时间取阈值前后
- 异常：故障注入（信号丢失、值域越界、时序错乱）
为每个用例标注源需求 ID（// @req: REQ-SWE-102）

多台架并行产出

同一个测试规范，同时产出 CANoe 和 dSPACE 两套用例，根据 CI 配置选一套执行。

Agent 会一次建模多端产出，保证语义等价。

执行结果回流

CANoe 结果（.blf + .xml）、dSPACE 结果（.mat）、NI TestStand 结果（.tdms）都能解析。

这是刚跑完的 CANoe 回归结果，帮我分析。

Agent 会解析结果文件 → 分类失败（功能 / 通信 / 诊断 / 性能）→ 对每个失败查 LTM 找相似历史 Bug → 输出失败根因清单 + 建议的缺陷单模板。

缺陷自动回填

这份失败清单，把需要开缺陷单的帮我提交到 Jira，关联到对应的需求 ID。

Agent 会调用 bug-import 的写入能力（反向）→ 为每条失败创建 Jira issue → 附执行日志 + 失败现场快照 → 关联源需求 ID + 相似历史 Bug 链接。

覆盖率矩阵

输出 SWE.4 单元测试和 SWE.5 集成测试的双向覆盖率，按 ASIL 等级分组。

Agent 会输出正向覆盖（每条需求有几个测试用例覆盖）+ 反向覆盖（每个测试用例对应哪些需求）+ 多维切片（按 ASIL-A/B/C/D / 按业务域 / 按组件模块）+ html-report 看板（可交互筛选）。

典型场景

场景 A：功能验收测试自动化

OEM 对 Tier1 验收：Tier1 交付时带一份功能清单 + 一份需求文档。combo agent 读清单 → 对齐需求 → 生成 CAPL → 台架执行 → 输出验收报告，验收会议从 2 天压缩到半天。

场景 B：回归测试快速收敛

新版本软件 flash → 执行回归套件 → 失败用例自动对照 LTM（bug-import 积累的模式）→ 相似历史 Bug 列表 → 工程师快速定位根因。

场景 C：跨项目用例复用

同一家 Tier1，多个 ECU 项目共享"通信层"、"诊断栈"测试用例。combo agent 识别新项目需求中"与已有用例等价"的部分，直接复用，增量部分再自动生成。

常见问题

Q：CAPL 生成的代码质量如何？ A：结构上完整，可直接编译。但建议测试工程师评审，特别是 FMEA 场景下的故障注入逻辑。Agent 会标注哪些是"确定正确"、哪些是"候选方案"。

Q：台架数据格式是自研的（不是 CANoe/dSPACE/NI），支持吗？ A：通过自定义技能开发解析器即可，一次开发长期复用。

Q：能不能只用 Agent 生成，不做自动执行？ A：完全可以。从"需求 → 脚本"到"脚本 → 执行 → 结果解析"是两个独立环节，按需采用。