同一块板子在两个工位上测出了不同结果，应该先查哪里？如果手里只有一个 PASS 或 FAIL，很难区分是产品差异、测试条件变化，还是仪器读数异常。

测试平台的价值之一，是把“发生了什么”保留下来，让排查有依据。本文结合通用测试平台的公开架构，用一个简化的电压测试说明配置、执行和结果追溯应该怎样配合。示例中的名称与数值仅用于解释设计，不对应实际产品或验收标准。

先把一个测试动作拆开

假设测试内容是：给被测设备上电，等待稳定，再读取电压，并判断是否在规定范围内。至少有五类信息参与其中。

职责 需要回答的问题 示例
产品配置 测什么，使用什么条件？ 等待时间、测量通道、上下限
资源接入 通过什么设备执行？ 电源、万用表、被测设备连接
测试步骤 按什么顺序做哪些动作？ 上电、等待、读取
规则判定 读数是否符合本次要求？ 单位和上下限比较
结果输出 记录到哪里，怎样追查？ 本地结果库、日志或外部系统

这些职责如果混在一个按钮回调中，修改电压阈值也可能碰到通信和写库代码。分开以后，参数调整、设备更换与结果输出可以分别检查，影响范围更容易说清楚。

测试前固定“这一次用的配置”

配置文件名不能完整标识一次运行。一个名为 default 的配置今天和明天可能已经不同；运行过程中打开编辑器看到的内容，也未必是启动时加载的内容。

一种可复现的设计，是在测试开始前保存本次使用的配置快照，并给它分配稳定的标识。测试步骤使用这份已确定的配置，结果记录引用同一个标识。之后编辑配置，不应改变已经开始的这次测试所依据的条件。

需要保留的不只是上下限，还包括会影响结果的等待时间、单位、资源绑定和判定规则。排查时才能区分“同样的产品测出了不同值”和“测试条件本来就不一样”。

同时保留读数、判定依据和执行状态

下面是一份概念性的结果记录，不是平台导入格式或 API 契约：

{
  "run_id": "example-run-001",
  "configuration": "example-config-A",
  "station": "station-A",
  "step": "supply_voltage",
  "measurement": {"value": 5.01, "unit": "V"},
  "limits": {"minimum": 4.75, "maximum": 5.25},
  "execution_status": "completed",
  "verdict": "pass"
}

这里把执行状态和测量判定分开，是为了避免误解：仪器通信超时，说明这一步没有正常拿到读数；拿到读数但超出范围，才是一次可解释的测量不合格。两种情况对应的排查方向不同。

日志可以补充连接过程、重试信息和异常上下文，但不能替代结构化结果。反过来，只有结构化数值而没有必要的日志，也可能无法还原故障过程。

用资源名称表达依赖，用插件实现设备差异

步骤可以依赖一个逻辑资源，例如 voltmeter。至于它连接的是哪台仪器、通过哪种传输方式、如何解析响应，由资源接入层负责。

这种分工并不意味着换设备一定不需要修改代码。设备量程、精度、采样时机和异常行为仍然需要核对。可复用的是职责边界：更换仪器时，重点验证资源实现及其与步骤的契约，而不是在所有产品流程中逐个替换通信细节。

资源释放也应考虑所有权。一次运行结束可以释放它独占的连接；多个工位共享的服务或监听器，则需要由持有它的上层管理，不能由某一步骤随意关闭。

输出失败不能被当作产品测试失败

结果写入本地库或上传外部系统，是另一条需要明确状态的流程。测量已经完成，但外部系统暂时不可用时，应保留原始测量结果，并明确记录上报是否成功。

如果需要重试上传，应复用同一条结果的标识，避免重复入库。涉及烧录、动作机构等有副作用的步骤时，更不能为了补传结果而重新执行整个测试流程。

从三个场景开始检查设计

在接入更多产品之前，可以先用模拟资源检查三件事：

  1. 改变阈值后再运行：新结果能够对应新配置，旧结果仍能还原原来的判定依据。
  2. 制造通信超时：记录能够区分执行异常与测量不合格，不用一个笼统的 FAIL 掩盖原因。
  3. 让结果接收端暂时不可用：已经产生的结果仍可追查，恢复上传不会重复执行测试动作。

这三项只能验证部分软件行为，不能替代真实仪器、治具和产品的现场验证。它们的作用，是先让平台具备清晰的证据链，再带着明确问题进入现场。

后续的开发实践会继续围绕配置管理、插件边界和异常诊断展开。平台整体能力与执行路径可查看测试平台介绍和技术架构。