用户验收测试（user acceptance testing，简称 UAT），是新系统上线前，由实际使用者确认系统能否支撑日常工作的环节。开发团队的测试验证软件是否按设计运行；UAT 则确认系统是否满足业务需求、符合员工和客户的实际使用方式。对委托开发软件的企业来说，UAT 通常是交付或上线前确认成果的主要机会。
UAT 和其他测试有什么区别
软件项目一般包含几轮测试，负责人和目的各不相同：
- 开发及 QA 测试：验证功能是否符合规格、代码是否运行正确，通常由开发团队完成。
- 回归测试：确认系统改动后，原有功能依然正常。
- 用户验收测试：用真实的任务、数据和用户角色，确认系统符合业务流程，由业务用户负责或参与。
开发测试通过，不等于验收一定通过。一个表单可以完全正常提交，但字段顺序未必符合前台员工接受预约时的实际操作。
应该由谁参与
参与 UAT 的，最好是以后真正依赖系统的人，而不只是项目发起人。视项目情况，可以包括：
- 处理预约、订单或咨询的一线员工；
- 负责审批、修改记录或查看报表的主管或管理员；
- 核对金额、导出数据和对账的财务或运营人员；
- 在合适时，邀请少量客户或会员测试对外流程。
开发团队一般负责准备测试环境、说明问题反馈方式并修复缺陷；系统能否接受，由企业决定。
开始前需要准备什么
- 验收标准：书面约定每个功能或流程怎样才算“通过”，最好在确定项目范围时就写好，不要等到项目收尾。
- 测试场景：简短、贴近实际的任务，例如“为会员创建预约、修改时间，然后取消”，并写明每一步的预期结果。
- 测试环境：UAT 一般在与正式数据隔离的测试或 staging 版本上进行，操作出错也不会影响实际业务。
- 测试账户和数据：为每个用户角色准备账户，以及接近真实的样本数据。除非已经妥善约定，否则不要使用真实的个人信息或支付信息。
- 问题记录方式：用共享清单或跟踪工具记录操作步骤、预期结果、实际结果和截图。
- 时间安排：测试人员还有本职工作，需要为 UAT 和第二轮复查预留时间。
以下示例仅用于说明：一家公司用 Web 应用替代原来基于电子表格的预约流程，请两名前台员工和一名经理参与 UAT。开发团队的测试全部通过，但员工发现，如果客户没有电子邮箱地址，系统就无法保存电话预约。问题记录后，双方确认它属于缺陷还是范围变更，修复后在上线前复查。
给发现的问题分类
UAT 发现的问题不一定都是缺陷，可以先分类：
- 缺陷：系统没有按约定的内容运行。
- 变更需求：系统按约定运行，但业务现在希望换一种做法。这类需求可能影响工期或费用，应另行约定。
- 疑问和培训需求：功能已经存在，只是用户不知道怎么用。
每个缺陷都应约定严重程度，例如是否阻碍上线，还是可以留到后续版本修复，让签收有清晰的优先级，而不是只看问题数量。
签收与上线之后
UAT 通常以签收结束，也就是记录系统可以上线的决定，有时会附上已知的小问题和修复计划。请确认协议中签收意味着什么，例如是否代表质保期或支持服务开始。
UAT 只反映系统在某个时间点的状态。上线后的改动和更新，可能影响已经验收的功能，这时就需要回归测试和持续的网站监测。签收后的支持条款，通常写在软件支持 SLA 中。如果你正在开发第一个版本来验证想法，可以阅读 MVP 说明。
如需了解服务范围，可以查看 technine.io 的网站与 Web 应用开发服务，其中包括 UAT 及上线验证。
常见问题
UAT 是客户的事，还是开发方的事？
通常双方都要参与。开发方准备测试环境、支持测试人员并修复缺陷；企业负责或参与测试，并做出验收决定。这些分工最好在项目启动前约定。
UAT 需要多长时间？
取决于系统规模、用户角色数量，以及测试人员能投入多少时间。至少要安排一轮测试和一轮修复后的复查，并尽早确定时间安排。
UAT 可以自动化吗？
验收决定必须由人做出，因为它是在判断系统是否符合业务需要。约定流程的重复检查可以自动化，以后也能用于回归测试，详情可以查看 technine.io 的自动化 UI 及用户流程测试。