大家都说“完成了”，为什么验收还是对不上？

先问：用户打开这个页面，要做什么？

我们用一个简化的设备状态页作例子。用户打开它，是为了知道设备现在能不能继续工作；发现异常后，还需要知道下一步找谁处理。

如果需求只写“展示设备状态”，开发可能先做几个标签。但读者真正需要的，还包括状态来自哪里、多久更新，以及暂时没有数据时会看见什么。

先把这条用户过程写下来：进入页面，看见状态，识别异常，找到下一步操作。它比一串功能名更容易暴露双方没有讨论过的问题。

把“完成”拆成几种能检查的情况

接着，围绕这个页面列几个情况。正常有数据、正在等待数据、更新失败，不应该被同一句“支持状态展示”包住。

每一行都写清楚前提、用户动作和应看到的结果。还没确认的条件先留出来，例如更新频率和错误提示，不要让实现团队替业务作决定。

下面是一张讨论用的小表。它不是现成的验收标准：括号里的内容，需要项目相关人给出具体答案。

让开发结果和测试记录对应到同一行

表格有了以后，为每行保留同一个编号。开发说明实现了哪一行，测试把环境、版本、操作和结果记录到这一行。讨论“完成了吗”时，就能找到具体差异。

例如，正常状态已经显示，但更新失败的提示还没定义，那就分别记录，不必把整个功能统称为完成或没完成。接下来要补的是提示规则，而不是把整个页面推倒重来。

工具文档能帮助完成测试，却不能代替项目结果。Unity 的目标平台性能文档介绍了采集数据的方法；某个页面在指定设备上是否达到项目要求，仍需要对应的测量和测试记录。[1]

• 实现记录：这一行已经做到什么？还依赖什么？
• 测试记录：在哪个设备、哪个版本上，实际发生了什么？
• 未决问题：缺什么信息，由谁确认，确认后影响哪些行？

需求变了，先找被影响的那几行

假设业务方后来要求显示“上次在线时间”。先检查这项数据由哪个接口提供、加载失败时怎样显示，以及原来的更新规则是否还适用。

把受影响的行更新，并请对应的人确认，再安排实现和复测。这样变更的范围可以解释，已有测试结果也知道哪些能保留。

下一次开需求会时，试着只带一页：用户过程、几个关键情况、预期结果和负责人。复杂细节可以链接到其他文档，这一页负责让大家讨论的是同一件事。