机器人一出问题，团队很容易听到一句话：

“这个功能测过，当时没问题。”

接着往下问：测的是哪台机器？当时是什么版本？用了什么负载？跑了多久？中间有没有报警、重启或人工介入？

回答却开始变得模糊。

“当时测试没问题”可能完全真实，也不是在否定测试人员。但当测试对象、条件和证据已经说不清时，这句话几乎无法支持下一步判断。

没有坐标的“正常”，只是一段记忆，不是一条证据。

“当时没问题”，为什么接不住下一问？

因为机器人测试的结论从来不是独立成立的。

同一个功能，换一台机器、换一套参数、换一个负载、换一种操作顺序，工程含义都可能不同。测试记录只剩“正常”，后续至少有几条判断路径很难分开：

• 现场进入了当时没有覆盖的新条件；
• 相似征兆当时已经出现，只是没有留下；
• 机器版本或状态变化以后，原来的结论已经不再适用。

团队明明测过，出了问题却还得从头猜。断掉的不是测试动作，而是测试和后续判断之间的关系。

测试结束时，结果至少要留下三个坐标

这里说的坐标，不是要求每次测试都生成一套复杂资料，而是测试结束以后，结果至少还能对应到三个问题：

测的是谁

是哪一台机器，当时加载了什么版本、参数和配置，处于什么初始状态。

在什么条件下测

使用了什么任务、负载、环境和操作方式，测试实际覆盖到了什么边界。

凭什么这样判断

现场实际发生了什么，有没有异常和人工介入，结论由哪些日志、数据或记录支撑。

对象说不清，结果就找不到对应的机器；条件说不清，结论就没有适用边界；证据说不清，后面的人就无法重新核对。

三句很常见的话，最容易让证据断在现场

这些话本身不一定错。问题是，一旦它们成为测试留下的全部信息，工程判断也会跟着停在这里。

测试不是给过去打勾，而是给未来留下起点

机器人测试当然要回答当前能不能通过。

但它还承担另一个任务：几天后、几周后或者进入新场景以后，如果机器人出现不同表现，团队能否沿着当时留下的对象、条件和证据继续判断。

这也是为什么测试价值不能只看跑了多少轮、填了多少张表。真正有用的测试，会让后续的人知道：原来的结论适用于哪里，新的问题又是从哪一处开始偏离。

测试的终点不是“机器人当时没问题”，而是以后出现问题时，团队不用重新从猜测开始。