测试用例表里，功能项、操作步骤、预期结果一个不少。

可真正执行时，问题还是会冒出来：现场条件和用例不一样，还要不要继续？中间人工复位了一次，结果还算不算？机器人停在等待状态，是正常流程还是测试失败？

用例并不是没有。

真正没有写清的，是不同的人应该怎样执行，又凭什么得到同一个判断。

好用例不是让机器人“跑一遍”，而是让不同的人按同一套依据跑完，仍然能得到同一个工程判断。

测试用例评审时，至少要追问下面 7 件事。

第一问：这条用例到底要证明什么？

用例不能只有一个功能名称。

它要对应一个明确目标：验证哪项需求、哪个接口、哪种风险或哪条使用边界。否则流程即使跑通，也很难判断它究竟证明了什么。

第二问：机器人从什么状态开始？

同一个任务，从正常待机、异常恢复、重新上电或任务中断状态开始，结果可能完全不同。

用例要说清测试对象、版本配置和前置状态。起点不一致，后面的结果就很难比较。

第三问：哪些条件必须相同，哪些条件要主动变化？

环境、负载、网络、电源、工装、人员和任务输入，都会影响机器人表现。

评审不只是确认“有没有测试条件”，还要区分：哪些条件必须固定，哪些条件要主动推向边界，哪些条件本次明确不覆盖。

第四问：谁操作，系统应该怎样回应？

“执行任务”不是完整步骤。

要说清谁操作、按什么顺序操作、每一步等待什么反馈，以及机器人状态发生变化时下一步做什么。否则熟悉系统的人和第一次接手的人，可能执行成两条不同路径。

第五问：什么结果算通过？

“正常”“稳定”“满足要求”都很难在现场直接判断。

通过标准至少要让执行人员知道：观察什么结果、允许多大偏差、人工介入是否允许，以及哪些现象属于否决条件。

第六问：异常、暂停和人工介入以后怎么算？

机器人测试很少只有一条完全顺利的成功路径。

中途报警、任务暂停、重新尝试或人工复位以后，是继续原用例、从头重测，还是直接判定无效？如果不提前约定，最容易出现的不是技术争议，而是结果到底算不算的争议。

第七问：测试结束后，结论靠什么留下来？

不需要每条用例都保存庞大的数据包，但必须提前定义哪些日志、数据、状态或记录能够支撑结论。

如果测试中发现问题，这些证据还应支持后续回到原触发条件复测，并判断修改是否真正覆盖了原问题。

一张可以拿走的七问表

测试用例评审是把原本会在测试现场发生的解释、追问和争议，提前变成共同依据。

如果一条用例在执行前回答不了这 7 问，测试现场迟早会用争议把空白补上。