用户验收测试(UAT):确保应用在上线前已准备就绪

凡是等待过软件项目完工的人,都熟悉这样一个时刻:开发团队宣布应用已经完成,演示顺利,所有人都准备上线。然而真正使用一周之后,投诉清单开始陆续出现。报表不符合财务团队的习惯,审批流程与现场的工作方式不合,一些罕见但重要的情况竟然没有处理。

"符合规格"与"满足需求"之间的差距,往往比预期的更大。开发人员测试的是应用是否按设计工作。只有用户才能回答,这个设计是否真正适合他们的工作方式。这就是用户验收测试,即 UAT,发挥作用的地方:它是上线前的最后阶段,真实用户用真实场景试用应用,并宣布它是否合格。

本文面向企业主和项目经理,而不是专业测试人员,来解释 UAT。我们讨论它与其他测试有何不同、如何规划、编写场景、选择测试人员、记录并为发现排优先级,以及判定应用何时可以上线。我们不使用凭空编造的缺陷数量或理想时长;每个项目都不同。我们提供的是你可以调整使用的实用框架。

摘要

• UAT 是由真实用户针对真实工作场景进行的测试,用来确认应用满足业务需求,而不仅仅是技术规格
• 从项目一开始就规划 UAT:在开发完成之前就确定时间、测试人员、测试环境和通过标准
• 基于日常工作编写场景,包括不寻常的情况和错误,而不只是完美路径
• 以结构化方式记录每一项发现,按业务影响排序,并决定哪些必须在上线前修复
• 制定共同认可的上线标准,并为上线后可能出现的问题准备预案

什么是 UAT,它与其他测试有何不同

软件开发包含多个目的不同的测试层次。单元测试单独检查小段代码。集成测试检查这些部分能否协同工作。测试团队进行的系统测试确认整个应用符合规格。这一切通常由技术团队完成,回答的是:"我们构建的是否符合计划?"

UAT 回答的是另一个问题:"我们构建的东西真的能把工作做成吗?"测试人员不是技术人员,而是业务用户:收银员、仓库人员、财务文员、销售经理。他们用类似日常工作的数据和场景运行应用,然后判断流程是否合理、结果是否正确、应用是否适合使用。

这种区别很重要,因为规格可能有误或不完整。一个完全按照需求文档构建的功能,如果文档遗漏了一个重要的工作步骤,仍然可能毫无用处。只有每天亲身经历这项工作的用户,才会察觉:"哦,这里我们通常还需要记录这个。"

因此,UAT 不是项目结束时签字的形式。它是误解与真实运营之间最后的安全网。为了赶进度而压缩它,几乎总会导致上线后更大的代价,因为那时修复必须在业务运转的同时进行。

从项目一开始就规划 UAT

好的 UAT 不是在应用完成时才开始,而是在规划项目时就开始。如果到最后才想到它,通常时间所剩无几、测试人员没空,而急于上线的压力会导致发现被忽视。

首先要商定的是时间。在进度中分配足够的 UAT 周期,包括修复发现和重新测试的时间。许多项目进度失败,是因为以为 UAT 只需要一两天,而实际上"测试、修复、重测"的循环通常会重复好几次。一开始就为此留出余地。

其次,确定谁参与,并确保他们真正有时间。测试人员是有日常工作的员工。如果让他们在做完所有任务的同时还要测试,UAT 的质量会很差。争取上级的支持,让测试人员有专门的时间。第三,确定测试环境:与正式系统分开的应用副本,里面有真实的测试数据,这样实验就不会破坏业务数据。

第四,尽早确定通过标准。应用要满足什么条件才能被宣布为就绪?例如所有核心场景运行时没有严重缺陷,没有缺陷阻碍主要工作,并且主要利益相关方批准。开头的共识可以避免在压力很大的结尾发生争执。

角色与职责

确定由谁来协调 UAT,通常是业务方的项目经理。同时确定开发方由谁接收发现报告、谁决定优先级,以及谁有权宣布通过。有一个明确的负责人,就能避免发现落在两方之间,各自以为对方会处理。

编写有用的测试场景

测试场景是模仿真实工作的一系列步骤,以及预期结果。场景的质量决定 UAT 的质量。好的场景源自业务流程,而不是功能清单。

先列出用户将用这个应用做的主要工作,例如创建订单、收货、日结现金、申请休假或审批采购。对每项工作,写出从开始到结束的步骤、使用的数据,以及预期结果,比如库存减少多少,或报表显示某个数字。

不要只测试完美路径。真实的工作充满不顺畅的事件:客户中途取消、部分付款、退货、数据输错或审批被拒。为不寻常的情况和错误添加场景,因为许多隐藏的问题正是出现在那里。

1. 01使用用户日常使用的语言和术语,而不是开发团队的技术术语
2. 02步骤要写得足够详细,让第一次尝试的人也能照着做
3. 03包含真实的测试数据,包括长名字、大数字和特殊字符等困难示例
4. 04说明可以清楚检验的预期结果,而不只是"运行良好"
5. 05包含跨角色的场景,例如由收银员创建订单,经理审批,然后汇报给财务
6. 06包含报表的场景,因为报表往往是构建应用的主要原因

用接近真实的数据和情境测试

用五行样本数据看起来很流畅的应用,面对成千上万条真实数据时,可能变慢或令人困惑。如果可能,加载在数量和多样性上接近真实数据的测试数据,例如经过匿名化的部分旧数据迁移结果。还要在用户实际使用的设备和网络上测试,包括最简单的那种。在开发人员快速的笔记本上测试,并不能代表使用旧平板和弱信号的门店。

选择并准备测试人员

最好的测试人员是每天都会使用应用的人,因为他们最了解这项工作。从每个主要角色中选出代表,包括挑剔和持怀疑态度的人。热情的测试者有帮助,但细心且敢于说"这不合适"的测试者,对应用质量的价值要大得多。

人数不必很多。每个角色几个人,通常就足以发现大部分工作流程问题。更重要的是多样性:有经验的用户和新手、动作快的人和慢的人,因为每种人暴露的问题都不同。

开始前先为测试人员做好准备。说明 UAT 的目的、对他们的期望,以及如何记录发现。提供简短的培训,让他们了解应用的基础,但不要引导过多,以免掩盖本应看得见的易用性问题。如果测试人员卡住了、需要频繁提问,这本身就是关于应用清晰度的宝贵发现。

执行 UAT 并记录发现

UAT 进行期间,要养成一致的记录习惯。每项发现都应以相同的格式记录,以便跟进。内容包括问题的简短描述、重现步骤、预期结果和实际发生的情况、有帮助时附上截图,以及发现者是谁。

避免含糊的记录,例如"报表不对"。好的记录应该像这样:"在每日销售报表上,某个日期的总计与列表中交易之和不一致;用某组测试数据时,总计显示的是这个数,而应该是那个数。"这些细节能为开发人员节省大量时间,减少来回提问。

把所有发现集中在一个地方,而不是散落在私信和群聊里。一份共享清单,哪怕只是电子表格,也便于跟踪每项发现的状态:新建、修复中、待重测或已完成。这也能避免同一发现被重复报告,并让所有人对进展一目了然。

定期共同回顾发现,例如在 UAT 进行期间每天或每两天一次。业务代表与开发人员之间的简短会议,可以澄清含糊的发现、商定优先级,并保持修复的节奏。

为发现排优先级

并非所有发现都同样重要,也并非都必须在上线前修复。按业务影响分组,有助于在时间压力下做出理性的决定。

• 严重:阻碍主要工作,或导致数据错误、资金损失或安全风险;必须在上线前修复
• 重要:工作仍可完成,但方式麻烦或结果不够准确;应在上线前修复,或有商定的临时解决办法
• 次要:不影响工作结果的舒适度或外观问题;可以安排在上线之后
• 建议:其实超出原范围的改进想法;记录下来留待下一阶段,而不是在最后一刻添加

注意缺陷与需求变更的区别。缺陷意味着应用没有按约定工作。需求变更意味着用户意识到他们想要的与约定的不同。两者都合理且有价值,但处理方式不同:缺陷在项目范围内修复,而需求变更则评估对时间和成本的影响,再共同决定。把两者混在一起,是项目膨胀的主要来源之一。

避免"算了,以后再说"的陷阱

临近截止日期时,最大的诱惑是把所有发现都推迟,理由是上线后再修。有些确实可以,但修复的欠债太多,会让用户从第一天起就失去信任。用户对新应用的第一印象,会强烈影响他们的接受度。如果第一天充满了本已发现的问题,就很难再赢回他们。

判断应用何时适合上线

上线的决定应基于商定的标准,而不是感觉或压力。回顾一开始制定的通过标准,逐条检查。所有核心场景都通过了吗?是否没有遗留的严重发现?遗留的重要发现是否有获批的临时解决办法?每个主要角色的代表是否都表示已准备好?

把这个决定记录下来。主要利益相关方的书面批准不只是官僚形式;它确保所有人都了解应用上线时的状态,包括作为风险接受的发现。它也避免日后对哪些已经达成一致、哪些没有而产生误解。

如果标准没有满足,有勇气推迟上线,往往比发布一个尚未就绪的应用更便宜。仓促上线,然后不得不在混乱中撤回或修复,代价要大得多,无论是金钱还是信任。也可以考虑分阶段上线,例如先从一家分店或一个团队开始,以便在出现问题时限制影响。

上线之后:保持学习循环

UAT 并不意味着测试就此结束。上线后,安排一段密集的支持期,开发团队和业务代表随时待命处理出现的问题。为用户提供便捷的报告渠道并迅速响应,因为早期几天的快速响应对用户接受度影响很大。

准备一个回退方案,即在发生严重问题时回到旧的工作方式或上一版本的办法。这个方案很少用到,但它的存在让上线的决定从容得多。还要确保如果需要回退,早期录入的数据不会丢失。

为下一个项目总结 UAT 过程的经验:哪些场景暴露的问题最多、哪些问题直到上线后才被发现,以及业务与开发之间的合作如何改进。一个项目接一个项目,这个过程会变得更轻松、更有效。

UAT 中的常见错误

有几个错误在许多项目中反复出现。把 UAT 安排得太短、太靠近上线截止日期,是最常见的。让开发人员或不了解该工作的人代替真实用户充当测试人员,是另一个。只测试完美路径、测试数据太少太整齐,以及没有以结构化方式记录发现,也非常普遍。

另一个错误是直到最后才让决策者参与,导致批准来得很晚,还伴随着大量需求变更。从一开始就让主要利益相关方参与,包括参与 UAT 进展的评审,这样就不会有最后一刻的意外。

运行 UAT 的实用步骤

1. 01从一开始就把 UAT 放进项目进度,包括修复和重测的时间
2. 02指定协调人、各角色的测试人员、测试环境和通过标准
3. 03依据真实工作编写场景,包括不寻常的情况、错误和报表
4. 04准备真实的测试数据,并给测试人员专门的时间和简短的说明
5. 05把所有发现记录在一份格式统一的共享清单中,并定期回顾
6. 06按影响排优先级,依据标准决定是否上线,并准备回退方案

结语

UAT 是一项保护大投资的小投资。耗资巨大构建的应用,可能仅仅因为几处与真实工作方式不符的地方而未被接受,而只要给真实用户试用的机会,这些问题几乎总能在上线前发现。有了良好的规划、真实的场景和基于标准的决策,UAT 把上线从一场赌博变成了一个可衡量的步骤。

如果你正在做软件或新系统项目,不要等到应用完成才想到 UAT。从一开始就规划,让合适的人参与,并留出足够的时间。第一天就被良好接受的应用,是很久之前所做准备的成果。