我第一次听说Test Module，是在一个被手动测试折磨到崩溃的下午。
当时我们在做一个车身域控制器的回归，DBC升了个小版本，信号加了两个、周期改了一个。按流程，回归用例要全跑一遍------六十多条，我和另一个同事分头在CANoe里手动发报文、盯Trace、一条条对结果，整整折腾了两天半。第二天中午，组长路过看了一眼，说了句让我记到现在的话："这种机械活，你还打算手动干几年？"
回去我就翻CANoe的帮助文档，找到了Test Module。说白了，它就是一个"带断言的CAPL工程"：你把测试步骤写成代码，报文收发、条件判断、超时等待都让程序自己干，跑完自动出一份带结论的报告。PASS还是FAIL，一目了然。
今天这篇，就带你从零跑起第一个Test Module。我用的是CANoe 17 SP1 + VN1630，工程基于我们一个真实的BCM（车身控制器）测试项目简化而来，代码里的注释都是我当时给自己留的原话。
一、建工程：三步，别一上来就写代码
很多人第一次用Test Module，打开CANoe就直奔CAPL写代码，结果环境配得一团糟。顺序反了。先搭好架子，再写用例。
第一步，新建一个Test Configuration。 菜单File→New→Test Configuration，或者直接在Simulation Setup里右键添加Test Module节点。Test Module本质上是一个特殊的仿真节点，挂在总线拓扑上，它既能收发报文，又能执行测试逻辑。
第二步，把DBC挂上。 双击Test Module节点，在Databases页签里关联你测试用的DBC文件。注意版本------我吃过一次亏：测试环境里挂的是v2.2的DBC，开发给的信号定义已经是v2.3，信号名对不上，跑出来的FAIL全是假失败，查了半天才发现是DBC没同步。从那以后，我每次建工程第一件事就是核对DBC版本号，写在测试说明里。
第三步，确认通道和硬件。 Hardware页签里选好你的VN接口和通道号，波特率跟DBC里定义的一致（我们项目是500k）。这三步做完，架子就搭好了，一个报文都还没写，但环境已经是"可测试"状态。
二、写第一个TestCase：代码比你想的简单
在Test Module节点上右键→Insert CAPL Program，会生成一个带测试框架的CAPL文件。框架长这样，我逐段拆：
capl
/* BCM休眠唤醒回归 - TestModule 01
环境: CANoe 17 SP1 + VN1630, DBC v2.3.1
作者: 我自己, 2026-10 整理 */
variables
{
msTimer tWait; // 超时计时器, 每个testcase用完记得重新set, 别复用旧的
int nmReceived; // 有没有收到NM报文, 0/1当标志位用
}
on start
{
nmReceived = 0;
testReportWrite("=== 回归开始: 锁车休眠 ===");
// on start只做初始化, 别在这里写断言, 跑起来会乱
}
on message NM_BCM
{
nmReceived = 1;
// NM_BCM是DBC里定义的网络管理报文, ID 0x540
}重点来了，testcase块。CAPL的测试框架里，测试用例用testcase关键字定义，每个testcase跑完会自动给一个结论。第一个用例，我写的是"锁车后NM报文停止发送"------这是休眠测试里最经典的一个检查点：
capl
testcase TC_NM_StopAfterLock()
{
// 步骤1: 模拟锁车动作, 发一帧车身状态报文, 把"已锁车"位置1
testStep("发送锁车信号");
message BodyState msg;
msg.DoorLockState = 1; // 1=已锁车, 这个值在DBC里, 别手写错
output(msg);
testStepPass(); // 这一步只是发报文, 能发出去就算过
// 步骤2: 等待, 给ECU留出进入休眠准备的时间
testStep("等待5秒, 观察NM报文");
nmReceived = 0;
tWait.set(5000); // 这里容易写反, 注意: 是set(5000)不是setTimer之类的
testWaitForTimeout(tWait);
// 步骤3: 断言. 5秒内没再收到NM报文, 说明ECU乖乖睡了
testStep("检查NM报文是否停止");
if (nmReceived == 0)
testStepPass();
else
testStepFail("锁车5秒后仍收到NM报文, 休眠异常");
}看懂了吗？整个逻辑就是：发锁车信号→等5秒→看NM报文停没停。testStep标记一个步骤，testStepPass/testStepFail给这个步骤下结论。所有步骤都PASS，这个testcase就是PASS；有一个FAIL，整个用例就是FAIL。
再补一个带报文值断言的用例，检查"解锁后NM报文恢复"，顺带演示怎么断言信号值：
capl
testcase TC_NM_ResumeAfterUnlock()
{
testStep("发送解锁信号");
message BodyState msg;
msg.DoorLockState = 0; // 0=未锁车
output(msg);
testStepPass();
testStep("等待3秒, 检查NM报文恢复");
nmReceived = 0;
tWait.set(3000);
testWaitForTimeout(tWait);
if (nmReceived == 1)
testStepPass();
else
testStepFail("解锁3秒后仍未收到NM报文, 唤醒异常");
}两个用例，一个管"睡得下去"，一个管"叫得醒来"。休眠唤醒测试的核心，差不多就是这两句话。
三、跑起来，看报告：三栏就够了
写完代码，点工具栏的"Start Test"（绿色三角）。CANoe会按顺序执行所有testcase，Trace窗口照常滚动，但你不用再一条条看了------跑完弹出的Test Report才是主角。
报告分三块看。第一块是Verdict总览：几个PASS、几个FAIL，一眼看到底。第二块是每个testcase的步骤明细：哪个步骤FAIL了，testStepFail里你写的中文原因原样显示------这就是为什么我坚持在testStepFail里写清楚"锁车5秒后仍收到NM报文"而不是只写个"失败"，三个月后回看报告，你能立刻知道当年在测什么。第三块是Trace关联：每个步骤的时间戳都能点回去看当时的报文，定位问题不用重新跑。
我第一次跑通的时候，两个用例全绿，那种"机器替我干完了两天半的活"的感觉，至今记得。后来这个Test Module被我们复用到每次DBC版本变更的回归里，六十多条用例，跑一遍二十分钟，人只需要在最后看报告。
四、我踩过的3个坑，你直接避开
坑一：msTimer复用不重置。 有一次我在两个testcase里用了同一个tWait，第二个用例的testWaitForTimeout几乎瞬间返回------因为计时器还停在上一个用例的超时状态。教训：每个testcase开头重新set，或者干脆每个用例用自己的计时器变量。
坑二：DBC版本没同步，假FAIL满天飞。 前面建工程时说过，测试环境的DBC必须和被测件版本一致。我的习惯是把DBC版本号写进on start的testReportWrite里，报告第一行就是版本信息，对不上立刻能发现。
坑三：报告里写中文注释要当心编码。 CAPL文件用UTF-8保存，testStepFail里的中文在报告里显示正常；但如果你从别的编辑器复制代码进来，编码一乱，报告里的中文就变成问号。统一用CANoe自带的CAPL Browser写代码，别在记事本里折腾。
五、写在最后
总结一下：Test Module=仿真节点+CAPL测试框架+自动报告。建工程三步（Test Configuration→挂DBC→配硬件通道），写用例抓住testStep/testStepPass/testStepFail/testWaitForTimeout这四个函数，跑完看报告三栏。第一次不用贪多，跑通一个testcase，你就跨过了自动化测试的门槛。