我发布过的最丢人的几个 bug 有一个共同点：测试全是绿的。代码完全按规格在跑，只是规格本身和大家真正需要的东西对不上。UAT 就是为这道缝存在的。

为什么我没法测自己做的功能

#

功能做完的时候，主流程我已经走过几百遍了。该点哪个按钮我一清二楚，毕竟按钮是我做的。这种熟悉感让我成了最差劲的测试用户，也让 QA 只能解决一半问题，因为 QA 仍然是照着规格测。只有到了 UAT，问题才会从“是否按设计运行”变成“设计本身对不对”。

UAT、QA 和 Beta 测试不是一回事

#

很多人把这几个词混着用，结果真的会搞不清谁该干什么。

UAT 夹在另外两者中间。如果 QA 还在不断发现崩溃，现在做 UAT 就太早了。用户整轮都会被 bug 绊倒，根本走不到你真正想问的那个问题。

开始之前

#

先做计划：范围、时间表、参与者，以及“通过”是什么意思。成功标准一含糊，UAT 就能拖上好几周。

我还会定准入标准，名字听着挺唬人，其实就是一张短清单。QA 已经通过，没有未解决的严重 bug。预发布环境里的数据看起来像真的，而不是一堆“test test 123”账号。参与的人专门空出了时间，而不是“有空的时候看看”。最后这条最要紧。挤在本职工作缝隙里的 UAT，大概只能分到十分钟真正的注意力。

然后挑和真实用户相像的人。没参与开发的同事就不错；如果能找到几位理解产品是干什么用的、态度友好的外部干系人，更好。大多数功能，五到八个人就够了。再多，收到的基本都是重复的反馈。

写出别人真能照着走的场景

#

场景要围绕日常操作来写，别写边界情况，边界 QA 早就轰炸过了。一个好的 UAT 场景读起来应该像一个平平常常的星期二，而不是压力测试。

每个场景有一个目标和一个起点，并且故意不写步骤。如果你写“点击‘新建发票’，再点击‘添加客户’”，测的就是大家会不会照着指令操作，而不是产品本身讲不讲得通。拿一个开发票的功能来说，场景大概是这样：

场景 4：给新客户开一张部分款项的发票

你刚给一位新客户“港湾咖啡馆”做完店面装修的前一半。按商定总价 $12,000 的 50% 给他们开发票，14 天内付款，发到他们的财务邮箱。

预期结果：客户收到一张 $6,000 的发票，到期日正确，并且在你的仪表盘上显示为未付款。

一个功能，像这样的场景通常写十到十五个就够了。头一两场我会在旁边坐着，尽量少说话，看大家在哪里犹豫。有人在某个按钮前停顿一下，比反馈表上写的任何东西都更能说明问题。

记录 UAT 反馈

#

测试期间，凡是和用户预期不符的都要记下来，包括那些技术上“符合设计”的。有人预期的是一样东西，拿到的却是另一样，不管规格怎么写，这本身就是信息。

记录不需要什么专门的工具。一张共享表格，或者在你们现有的问题跟踪工具里单开一个看板就够了，只要每一条都有同样几个字段：

真正起作用的是“我预期的是”这一栏。没有它，你收到的就是“发票页面看不懂”，谁也没法据此动手。

给反馈分类

#

每天结束时（规模小的话就每轮结束时），我会和产品负责人一起过一遍记录，把每一条归进下面四类之一。

Bug，就是东西坏了，比如总额算错、跳出报错页面。严重的在签字验收前修掉，不严重的排进计划。

变更请求，指的是功能按规格做了，但规格本身错了，比如上面那个缺少的百分比选项。UAT 存在的意义就是找出这类反馈，而它也最难处理，因为修它就意味着范围变大。由产品负责人拍板：现在修，还是先接受、排到以后。

文案或培训问题，指的是功能本身没毛病，只是大家没看懂。往往改个标签、加句提示，或者在帮助文档里补一行就解决了。成本低，值得做。

不修，包括超出范围的想法，以及某一个人的偏好和其他所有人都相反的情况。写下原因，并告诉提出的人。从来收不到回音的测试者，下一轮就不会再给反馈了。

我最想避免的，就是把每一条都当成上线前必须修掉的 bug。两周的一轮 UAT 就是这么拖成两个月的。UAT 反馈的目标不是清零，而是每一条都有一个明确的决定。

签字验收

#

测完之后，该修的修掉；如果改动比较大，就再跑一轮短的，别想当然地以为改好了。然后按开始时商定的标准，拿到真正的签字验收。也就是由一个有名有姓的人说“可以，发吧”，同时把延后处理的事项一并列出来，而不是群聊里一个点赞表情。

我跑 UAT 时犯过的错

#

开始得太晚。如果 UAT 在一个定死的上线日期前两天才开始，每个变更请求都会变成一场要不要延期的争论，而答案永远是不延。要给自己留出空间，能根据测出来的东西采取行动。

找错了人。太熟悉产品的内部员工，表现和开发者差不多。他们知道每样东西在哪。

把沉默当成认可。如果一位测试者什么都没记，多半是没认真测。在把他算作“通过”之前，先去问一问。

还有，让 UAT 沦为 Sprint 末尾的一个勾选框。它更该被当成最后一道关：发布前最后一次，由一个不是你的人来试着用这个东西。

它能换来什么

#

最大的收益是趁问题还便宜的时候抓住它：在发布前，而不是发布后打补丁加道歉。还有些不那么显眼的好处。流程贴合大家实际的工作方式，培训和支持都更省事。参与过测试的干系人签字也更快，因为到那时，产品已经有一部分算是他们的了。我见过的认真跑过一轮 UAT 的版本，上线往往都很平静。

简单来说

#

UAT 就是在软件上线前，让真实用户确认它能满足需求。等 QA 干净了再开始。请五到八个像你的用户的人，把场景写成日常目标而不是操作步骤，把他们预期的和实际发生的之间的每一处差距都记下来。把每条反馈归为 bug、变更请求、文案问题或不修，每一条都做出决定，最后由一个具体的人签字验收。