测试操作执行：从准备到复盘

台架前的二十分钟，往往决定了一整天测试的可信度。

很多人以为测试执行是从点下“开始”按钮开始的。我的经验恰好相反：真正决定结果的，是上电之前那张检查表。电源、地线、通信、针脚、模型版本、被测件软件版本，这几件事只要有一项没对齐，后面跑出来的所有曲线都值得怀疑。

一、执行前：先把不确定性关进流程里

先对齐版本。被测件的软件版本、标定数据、仿真模型、测试脚本，四者必须能互相追认。我习惯在测试记录的第一行写下这四个版本号，后来任何一个异常，都可以从这一行开始排除。

再做电气检查。断电状态下测阻值，确认没有短路；检查保险和互锁；确认供电极性和量程。上电之后先看静态电流，再看电源纹波。不要急着让被测件工作，先确认它“安静的时候”是正常的。

通信检查同样重要。CAN 的波特率和终端电阻、LIN 的调度表、报文周期是否与规范一致，这些在 CANoe 的 Trace 窗口里一眼就能看出来。比起后面花几个小时排查“为什么响应不对”，这十分钟非常划算。

最后是信号映射表。被测件针脚、台架通道、模型信号，三列必须一一对应。我见过太多问题出在“线接对了，但映射表里差了一列”。

二、上电与状态建立

上电顺序不是形式。一般先台架、后被测件，先低压逻辑、后功率输出。KL30 常电与 KL15 唤醒的时序要按整车逻辑走，尤其是网络管理相关的测试项，唤醒和休眠的边界往往比功能本身更容易出问题。

判断状态是否建立，不要只看界面上的绿灯。用示波器看电平，用总线日志看报文，用模型里的观测点看信号。三个视角互相印证，才算真的“起来了”。

三、执行中的三段式

我把一次正式执行拆成三段：冒烟、正式、异常。

冒烟只跑关键路径，十分钟内确认台架、被测件、脚本三者都活着。正式执行按用例走，每一条都保留原始数据，而不是只保留结论。异常发生时先冻结现场，再谈排查。

记录要足够让另一个人复现：时间戳、环境温度、供电电压、软件版本、脚本版本、操作人。这些字段看起来琐碎，但它们是数据能不能变成证据的分水岭。

四、异常处理：先保现场

出问题时，人的第一反应往往是重启。我尽量克制这个冲动。先保存 Trace、截图、模型日志和台架报警记录，再决定要不要复位。因为很多问题只出现一次，重启之后线索就断了。

定位时一次只改一个变量。换线、改模型、改脚本，分开做。否则即使问题消失了，也不知道是哪一步让它消失的。

还要判断问题属于哪一层：被测件、台架、模型，还是脚本。四层的排查方法完全不同。把台架问题当成零件缺陷，是最容易浪费时间的一种误判。

五、复盘：测试产出的是可信度

一份报告写完，不代表这次测试结束。失败项要分类：真实缺陷、环境问题、用例问题、预期写错。四类的处理方式完全不一样，混在一起就会让下一次重复踩坑。

我会把这次遇到的检查点补回清单，把新发现的边界补回用例库。重复的动作交给脚本，判断留给人。

台架不会因为跑得多就变得可靠，它只会因为每一次都被认真对待而变得可靠。