自动测试：从项目文档生成可执行、可追溯的用例集
借助 AI 整理项目资料，再由 BMCLI 执行总线操作，可以将测试说明与自动化用例放在同一套规则下管理。本篇介绍如何从客户提供的原始文档出发，生成可执行、可追溯的测试用例集。
设想一款车身控制器进入首轮集成，客户交来了企业标准、通信矩阵和诊断调查表，团队手中还有上一代项目的测试资料。面对这些输入，团队需要检查每条报文、每个信号，以及 DID 和 DTC 的行为。人工逐项编写脚本之前，还要统一字段定义、判断资料冲突、补齐工况和通过条件。AI 可以协助完成资料整理与规则展开，BMCLI 则提供收发、诊断和故障实验所需的接口。
客户只提供通信矩阵时，可以让 AI 先生成候选 DBC，并与矩阵核对；已有 DBC 时，则检查它与规范是否一致。在这份共同定义上，再组织信号边界、允许的组合、丢帧或重复输入，以及诊断读写与故障触发、解除检查。执行哪些主动测试，由项目给定的台架条件与允许操作决定。
测试说明、执行配置和结果报告使用相同的需求编号。用例规模可以随规则扩展，每一项都对应明确的输入、可观察的响应和判定依据。下面从小型通信示例说明这套方法，再把它扩展到项目资料。
图 3-1 同一份要求，贯穿说明、执行与结果。工程关系示意。
给 AI 的输入：描述测试任务
Section titled “给 AI 的输入：描述测试任务”准备通信矩阵、诊断调查表、DBC、台架配置，以及已有的验收条件；放入 input 目录后，可以这样交代任务。
我们正在启动一款控制器项目，请使用 BMCLI，为 input 目录中的客户标准、通信矩阵、诊断调查表和历史项目资料建立可执行、可追溯的测试用例集。先整理需求编号、来源和冲突项：有 DBC 时与矩阵对照，没有时依据定义完整的矩阵生成候选 DBC，并给出核对清单。按我提供的测试规则展开报文与信号边界、允许的组合、丢帧和重复输入检查；诊断部分覆盖资料明确的 DID 读写及 DTC 触发、解除条件。请说明各用例的前置工况、刺激、观察量和判定标准，组合设计按参数约束选择正交或成对覆盖等策略，不把所有排列机械相乘，并在报告中注明实际覆盖准则。测试说明与执行配置使用相同的结构化要求，关联需求、用例和结果。先完成离线检查及允许的被动测试，把写入、故障注入和执行器动作整理为待确认的主动测试计划。交付数据库、测试说明、执行入口和覆盖清单；在获准台架范围内运行并输出报告，缺少判断依据的项列为待补充。
AI 会把资料整理成统一清单，再生成测试和报告。测试说明与执行用例共用需求编号，因此人工评审和自动回归讨论的是同一件事。随文提供的要求与报告样例可作为起点；完整执行器则围绕您项目的资料生成。
成品与效果：一张报告，把要求和结果对应起来
Section titled “成品与效果：一张报告，把要求和结果对应起来”AI 的交付目标是测试说明、可执行用例与结果报告。下面用随文样例展示三者的关联方式。
以第二篇的 VehicleStatus 为例，五帧数据就能整理出下面这份检查摘要：
| 要求 | 检查内容 | 结果摘要 |
|---|---|---|
| COM-VEH-001 | 标准帧 ID 为 0x100 | 收到 5 帧 VehicleStatus |
| COM-VEH-002 | Speed 的比例与单位 | 解码为 0、20、50、88、120 km/h |
| COM-VEH-003 | Gear 枚举 | 0 对应 P，3 对应 D |
| COM-VEH-004 | Counter 递增及回卷 | 0..4 连续；回卷尚待采集 |
| COM-VEH-005 | 接收观察完整性 | gaps=0，dropped=0 |
| COM-VEH-006 | Speed 定义范围 | DBC 声明 0..250 km/h |
这是一份根据示例数据整理的结果表。它把“已观察到的现象”和“还需要补充的测试”放在了一起：Counter 连续递增有了结果，15→0 回卷还需要更长的数据。
报告中保留这样的区分，项目评审就有了明确的下一步。测试的价值也不只是亮起一排绿灯，更在于帮助团队看清还差哪一块。
实现解析：BMCLI 在成品中承担的工作
Section titled “实现解析：BMCLI 在成品中承担的工作”下面结合关键调用说明应用的实现方式。AI 生成的程序将这些调用组织成完整流程，并处理返回结果与任务收尾。
文档与用例，来自同一份要求
Section titled “文档与用例，来自同一份要求”可追溯的关键，不只是报告里有一个编号，而是能够沿着结果找到用例、判断条件和原始要求，也能从一条要求反查它被哪些用例覆盖。测试说明与程序由 AI 基于同一份结构化要求生成，可以减少两者分别维护时的偏差；是否一致，仍通过评审和执行结果确认。
例如，客户修改了 VehicleStatus 的周期要求，AI 应同时更新测试说明、容差配置和执行判定，并列出受影响的用例。每次执行关联所用的需求资料、数据库、用例版本与 ECU 软件版本，形成清楚的配置基线。这样，讨论一个失败项时，团队能够知道“测的是哪版软件、依据的是哪版要求”，而不只是看到某天留下的一份报告。
测试为什么能跟着资料走
Section titled “测试为什么能跟着资料走”关键是给每条要求一个稳定编号。例如：
- id: COM-VEH-001 source: ../02-from-bus-to-signals/network/vehicle-demo.dbc!VehicleStatus statement: VehicleStatus 的标准 CAN ID 为 0x100 expected: can_id: 0x100这里的 YAML 是测试程序的输入。AI 生成的程序读取它，再调用 BMCLI 完成专业操作：
# 检查数据库文件的结构与定义，先发现输入资料中的问题。bmcli database validate --file=input/vehicle.dbc --format=json# 查看指定报文的信号布局、比例与单位。bmcli dbc signal list --message=VehicleStatus ` --database=input/vehicle.dbc --format=json
# 在指定通道采集报文；带 --decode 时同时按数据库输出工程值。bmcli message recv --channel=vehicle-can --duration=30 --decode ` --database=input/vehicle.dbc --format=jsonl
# 读取指定 DID；此处以已配置诊断连接上的 VIN 读取为例。bmcli uds did read 0xF190 --format=jsonBMCLI 负责数据库解析、工程值转换和 ISO-TP/UDS 通信，外层程序负责判断周期是否落在容差内、信号是否符合要求，以及如何呈现结果。这种分工使测试代码更集中，也便于资料变更后逐项调整。
例如，Counter 从 5 跳到 8，报告可以写成“相邻观测值之间缺少 6、7 两个计数”，并附上相关帧。接下来再结合接收完整性和工况判断原因，比一句“CAN 通信异常”更有帮助。
把判断条件写完整
Section titled “把判断条件写完整”周期测试最好同时提供期望周期、容差和运行工况；诊断测试则需要目标地址、会话和响应含义。通信矩阵与 DBC 有差异时，可以先让 AI 做一张对照表，团队确认后再采用统一标准。
范围检查也有两层含义：DBC 是否声明正确，以及 ECU 在采集工况下是否输出了合适的值。将这两项分开记录，报告就能准确反映实际覆盖情况。
进一步探索：让用例集随项目一起成长
Section titled “进一步探索：让用例集随项目一起成长”这个案例还可以继续完善，也可以延伸到更多工作中。您可以从感兴趣的一项出发，与 AI 讨论下一步的实现。
跟随需求变更更新测试
Section titled “跟随需求变更更新测试”收到新版通信矩阵后，可以把新旧资料一起交给 AI，请它先整理变更，再列出受影响的需求编号与用例。实现时以结构化要求为共同输入，同步修改测试说明、BMCLI 调用参数和判定条件，保留原有编号之间的关联。随后只运行受影响的检查，并在报告中说明本次采用的资料和软件版本。评审人员便能沿着一条要求看到修改缘由、执行内容和结果，而不必在几份文件中来回寻找。
让失败报告附带总线现场
Section titled “让失败报告附带总线现场”某项周期或信号检查失败时，可以让执行器同时保存异常附近的报文窗口，并用同一份 DBC 解码关键值。参考做法是在测试期间由 BMCLI 录制，判定程序记录失败时间与用例编号，再从日志中整理相关片段。报告将期望值、实际值和片段入口放在一起，既方便人工追查，也能成为后续回放的输入。这样，本篇的自动测试与第七篇的现场回放就连成了一条问题处理路径。
以下文档介绍本篇涉及的接口；具体参数可通过本机 JSON Help 查询。