团队一旦交付了通过所有技术测试的费用系统。第一天，财务团队发现无法处理多币种索赔，而这占据了他们工作的很大一部分。没有什么东西“坏了”，但它无法使用。 用户验收测试的存在就是为了在发布之前准确地捕捉到这种差距。

本指南介绍了 UAT 与其他测试的不同之处、如何逐步运行它以及如何决定何时准备发布。上面的场景和下面的示例是说明性的，应该调整该过程以适合您的项目。

什么是UAT？

UAT 通常是发布前的最后测试阶段，目标用户确认软件可以在现实条件下完成其工作。它也称为最终用户测试或验收测试。它是在开发和系统测试之后发布的，此时产品预计会稳定。

其目的不是找到每一个错误。到这个阶段，其中大部分应该已经消失了。目的是验证：我们构建了正确的东西吗？测试人员验证产品是否符合规格。 UAT 验证规范和产品确实满足需求。

UAT 与 QA 测试

UAT 不会取代其他测试。如果用户不断遇到基本错误，则构建尚未准备好，并且您正在浪费他们有限的时间。这些问题属于早期测试级别和回归测试。

谁运行 UAT？

选择真正从事当前工作的测试人员。经验丰富的索赔处理人员会发现经理或代理人永远不会发现的问题。包括一系列的经验，因为新员工经常会透露一些令人困惑的步骤，而专家却没有注意到这些步骤。并确保他们的经理为此腾出时间，因为 UAT 无法在满负荷工作的情况下取得成功。

UAT 的类型

UAT 七步流程

1. 定义范围和目标

决定什么是被接受的，什么是超出范围的，以及什么是重要的业务成果。例如：“财务人员可以以任何支持的货币提交、批准和支付费用报销。”

2. 同意验收标准

用通俗易懂的语言写下成功的样子，最好是在项目开始时而不是启动前一周。模糊的标准会导致后来的争论。

3. 选择并介绍测试人员

选择真实的用户，解释目的，向他们展示如何记录反馈，并明确他们正在测试软件而不是自己被测试。许多人担心会出现问题。

4.准备环境和数据

UAT 环境应尽可能接近生产环境。使用真实的数据，设置正确的用户角色，并检查电子邮件等集成。如果复制生产数据，请先屏蔽个人信息。运行快速冒烟测试，这样测试人员就不会发现损坏的构建。

5. 编写场景

这些基于真实的工作流程而不是单个按钮。他们应该像工作一样阅读，而不是像软件一样阅读。我们的测试用例与测试场景指南解释了您需要多少详细信息。

6. 运行测试并收集反馈

与可以提供帮助的人进行会议。将问题收集到一处，并附上屏幕截图。也留出一些时间进行自由探索，因为人们会尝试脚本从未预料到的事情。 探索性测试为此提供了有用的技术。

7. 修复、重新测试并签核

对反馈进行分类，修复重要问题，并让相同的用户确认修复。然后记录正式决定。

UAT测试用例

UAT 测试用例对于非技术人员来说应该很容易遵循。以下是费用系统的示例：

ID:        UAT-012
Scenario:  Submit a foreign currency expense claim
User role: Sales employee
Before:    Logged in, with a USD receipt ready

Steps:
  1. Create a new expense claim
  2. Enter a client dinner of 80 USD and attach the receipt
  3. Submit the claim for approval

Expected:  The amount is converted to INR at the current rate
           The manager receives an approval request
           The claim shows as "Awaiting approval"

Result:    Pass / Fail
Comments:
Tester / Date:

请注意，它描述的是真实任务，而不是技术细节，并且它留有评论的空间。这些评论常常被证明是最有价值的部分，例如“这有效，但我永远找不到那个按钮”。

进入和退出标准

这些适合更广泛的软件测试生命周期。提前与利益相关者设定数字。 “我们会在感觉合适的时候做出决定”往往会导致在最后期限的推动下匆忙答应。

处理反馈

UAT 反馈是多种因素的混合体，并非全部都是错误。将其分类：

使用明确的规则来确定阻止发布的内容，如严重性与优先级中所述。并对每个项目做出回应，包括您拒绝的项目。如果反馈似乎消失了，人们就会停止提供反馈。我们关于如何编写错误报告的指南可以帮助测试人员清楚地描述问题。

UAT清单

UAT之前

• 范围和验收标准以书面形式商定
• 系统和回归测试完成
• 选择测试人员，向他们介绍情况并给予时间
• 环境、账目、真实数据都准备好了
• 副本中的个人数据已被屏蔽
• 场景由业务部门审核
• 设置一个记录问题的地方
• 签署所有者已被命名

在UAT期间

• 有可用的支持联系人
• 每天都会对问题进行分类
• 与利益相关者分享进展
• 以受控方式部署和重新测试修复

UAT之后

• 退出标准已检查
• 已知问题已记录在案，并与所有者一起记录
• 记录正式签核
• 更新了培训和发行说明
• 举行了简短的回顾展

敏捷团队中的 UAT

传统的 UAT 是在最后的一个大阶段，出现意外的代价是昂贵的。敏捷团队缩短了这个循环。产品负责人在冲刺期间根据验收标准审查每个故事，用户在冲刺审查中看到工作软件。许多团队仍在主要版本发布之前运行集中的 UAT，特别是在多个功能合并到一个工作流程中的情况下。

随着频繁的发布，功能标志和金丝雀部署等技术让真正的用户逐渐尝试新的工作。请注意，这些补充了验收测试，但它们不会自动取代它，特别是在需要正式记录的受监管行业中。

常见错误

• 将其视为形式。 没有实际用途的签核不能保护任何人。
• 使用了错误的测试人员。 开发人员和 QA 对系统的了解太多，无法代表用户。
• 从不稳定的构建开始。测试人员很快失去信任和兴趣。
• 把它留到最后一刻。这样就没有时间来修复你所学到的东西。
• 使用不切实际的数据。测试数据很少有实际工作中出现的混乱情况。
• 让范围扩大。 将新想法视为变更请求，除非它们是真正的阻碍者。

最后的话

UAT 是您在发布之前了解该软件是否真正对使用它的人有帮助的最后机会。从项目一开始就进行规划，招募真正的用户，并就成功的样子达成一致。对于您的下一个版本，请尝试一个简单的更改：在真实场景中与一名用户坐在一起，在他们工作时什么也不说。

常见问题

继续学习