我发布过的最丢人的几个 bug 有一个共同点：测试全是绿的。代码完全按规格说明在跑，只是规格本身和用户真正要做的事对不上。用户验收测试（UAT）就是为这个缝隙准备的：发布前让真实用户坐下来用一用软件，回答单元测试和 QA 都答不了的那个问题——这东西对真正要用它的人来说，好用吗？
为什么我没法测自己写的功能#
功能做完的时候，主流程我已经走过几百遍了。该点哪个按钮我一清二楚，毕竟按钮是我做的。这种熟悉感让开发者成了最差劲的测试用户。QA 也只能解决一半，因为 QA 仍然是照着规格测。只有 UAT 会把问题从“是否按设计运行”换成“设计本身对不对”。
一轮 UAT 怎么跑#
先做计划：范围、时间表、参与者，以及“通过”的定义。验收标准一含糊，UAT 就能拖上好几周。
然后挑和真实用户相像的人。没参与开发的同事就不错；如果能找到几位理解产品目标、态度友好的外部干系人，更好。场景要围绕日常操作来写，别写边界情况——边界 QA 早就轰炸过了。一个好的 UAT 场景读起来应该像平平常常的星期二，而不是压力测试。
测试过程中，参与者照着场景走，凡是和预期不符的都记成缺陷，哪怕技术上“符合设计”。之后收集反馈、修问题；改动大的话，别想当然，再跑一轮。最后按开头商定的标准拿到正式确认。
它换来什么#
最大的收益是趁问题还便宜的时候抓住它——在发布前，而不是发布后打补丁加道歉。还有些安静的好处：流程贴合大家真实的工作方式，培训和支持都省事；参与过测试的干系人确认得也快，因为到那时产品已经有一半算他们的了。
在公司里我也注意到，认真跑过 UAT 的版本，上线往往最平静。人总想把 UAT 当成冲刺末尾的一个勾选框，但它更该被当成最后一道关：发布前最后一次，由一个不是你的人来试着用这个东西。