UAT（用户验收测试）让业务代表在可运行版本中完成真实工作，判断系统是否达到约定的业务目标。有效的UAT要同时准备场景、角色、数据、预期结果和验收责任人；发现问题后区分缺陷、需求变化与使用说明问题，复测后再作出接受、附条件接受或不接受的决定。
它可以从需求阶段就开始准备验收条件，而不必等研发结束才临时召集业务同事“随便点点”。最重要的产物，是一份能说明谁在什么版本上验收了哪些业务场景、还存在哪些风险的记录。
UAT、功能测试和原型评审，分别确认什么
| 活动 | 主要回答 | 参与与材料 |
|---|---|---|
| 原型评审 | 拟定方案是否把任务、规则和交互说明白 | 产品、设计、研发；PRD与可演示原型 |
| 功能与系统测试 | 实现是否符合规格，功能及系统行为是否正确 | 测试与研发；可运行版本、用例与数据 |
| UAT用户验收 | 目标用户能否用它完成约定的业务工作 | 业务代表、产品、测试支持；业务场景与验收标准 |
例如报销系统中，“提交接口返回正确”是重要测试结果；财务能否找到待处理单据、核对附件、完成退回与再次提交，则是完整业务任务。两者互相支持。UAT通过也不能替代性能、安全或回归测试的结论。
ISTQB的验收测试说明强调业务角色与测试角色协作，使验收活动对齐业务需求。具体项目应在开始时约定验收范围和责任，避免测试完成后才争论什么算交付。
开始验收前，确认这五件事
- 范围有边界：本次涉及哪些流程与用户，不包含哪些功能，哪些变化需要单独确认。
- 版本可识别：写清构建或版本号、部署时间和环境地址，验收中途变更需记录。
- 角色和数据可用：准备业务角色账号及对应权限，覆盖正常、异常和边界数据。
- 基础测试已达到准入条件：关键流程能够运行，阻塞问题有明确说明，必要接口可用。
- 验收人有代表性：实际处理业务的人参加操作，由获得授权的人作出接受决定。
如果测试环境用固定模拟结果替代了某个外部系统，要明确本轮能验证到哪里。例如报销审批能完成，但银行付款并未真实联通，就不能把端到端付款也勾选为通过。未覆盖部分要进入后续计划。
把验收范围写成业务场景
以报销审批为任务，先描述人要完成什么，再列页面和按钮。下面是场景设计参考，金额规则、审批权限及流程分支应替换成实际业务约定。
| 场景 | 前置条件 | 完成后应能确认 |
|---|---|---|
| 正常提交并审批 | 申请人、审批人与财务角色齐备，材料有效 | 单据状态、待办与流转记录一致 |
| 退回后修改再提交 | 审批人退回并注明原因 | 申请人能定位原因；修订后进入约定流程 |
| 越权访问或操作 | 普通员工尝试访问他人单据 | 不能读取或操作无权限内容，给出合适反馈 |
| 规则边界 | 准备边界值两侧的数据 | 审批路径与已确认规则一致 |
| 重复提交与网络重试 | 提交后结果暂未返回 | 不产生重复业务单据，能确认最终状态 |
| 历史记录与查询 | 存在已完成、退回和处理中单据 | 按角色和条件找到正确记录，并解释当前状态 |
场景不是越多越好。优先覆盖高频、关键业务结果和高风险分支，再补必要的边界。一个跨角色流程通常比多个孤立页面更能暴露交接问题。
把“正常可用”改成可判断的验收标准
“报销流程顺畅”无法直接验收。可以改成：“申请人提交有效单据后，指定审批人的待办中出现该单据；审批人退回时填写的原因，申请人在单据详情中可见；再次提交后保留前次退回记录。”每条都可以被观察和复查。
与需求对应时，为场景保留需求编号和规则出处。标准本身有歧义，先回到用户故事与验收标准澄清，再安排操作，避免不同人按不同理解打勾。
一张可以直接复制的验收记录表
| 记录字段 | 填写说明 |
|---|---|
| 场景编号与需求编号 | 例如UAT-03，对应需求REQ-12 |
| 角色、环境、版本 | 谁执行、在哪个环境和版本操作 |
| 前置数据 | 单据状态、账号权限、必要配置 |
| 操作与预期 | 操作步骤及每个关键节点的可观察结果 |
| 实际结果与证据 | 实际状态、截图或日志位置；不能只写“有问题” |
| 判定与问题单 | 通过/未通过/阻塞；关联缺陷或待确认记录 |
| 复测与确认 | 修复版本、复测人、结果和确认时间 |
执行时尽量让业务代表自己操作。研发站在旁边一步一步提示，可能掩盖真实工作中的理解问题；测试同事可以协助准备环境、记录证据和定位故障。遇到阻塞时先记录停在何处，不要凭口头承诺提前写通过。
同一个场景有多个检查点时，逐项记录差异。“整体通过但备注有问题”的写法容易让残留问题在交付时消失。缺少数据、外部依赖不可用和实现缺陷，也应分别标识。
验收出现问题，先分流再处理
| 问题类型 | 怎么判断 | 后续动作 |
|---|---|---|
| 实现缺陷 | 与已确认标准或规则不符 | 建立问题单、评估影响、修复并复测 |
| 需求变化 | 提出了原范围未包含的新规则或行为 | 评估价值、成本与影响，进入变更决定 |
| 说明或培训问题 | 功能行为符合约定，但用户理解或操作存在困难 | 判断是否需改文案、交互或培训，不能自动归咎用户 |
| 环境与数据问题 | 账号、配置、接口或数据不具备执行条件 | 修复条件后重跑，不计为业务验收通过 |
严重程度按业务后果判断，而不按修复代码的多少判断。一个文字错误若改变业务含义，可能影响决策；一个视觉偏差若不影响关键任务，未必需要阻塞整次发布。由团队事先约定阻塞标准，并记录最终决定者。
什么时候可以签收，什么时候不能
先核对约定的验收范围是否执行完、阻塞问题是否关闭、残留问题是否有负责人，再做决定。不是所有项目都要求同一种签字形式，但结论需要可追溯。
| 决定 | 应记录的内容 |
|---|---|
| 接受 | 本次版本、已验收范围、结果、确认人和日期 |
| 附条件接受 | 不影响关键目标的残留项、影响范围、处理期限、负责人及已获授权的接受条件 |
| 不接受 | 未达到的标准、阻塞任务、必要补救及再次验收条件 |
关键业务不能完成、权限错误或核心数据结果不正确时，不能用“附条件接受”掩盖问题。商业交付有合同验收条款的，还应按已约定的范围和流程执行；产品团队不能自行替其他责任方签收。
一份验收结论的简洁写法
本次验收对象：［版本/环境］。范围：［业务场景编号］。执行结果：［通过、未通过、阻塞项及证据链接］。残留问题：［编号/影响/负责人/期限］。决定：［接受/附条件接受/不接受］。复验条件：［需补齐的事项］。确认人及日期：［填写］。
把设计依据、实现版本和验收结果接起来
前期在墨刀原型上评审角色、状态和异常路径，能提前暴露规则歧义。验收时依据的是实际运行版本；原型链接作为方案依据，不能代替实际结果。把需求编号、原型位置、测试场景和问题单放在同一份索引里，变更后就知道哪些场景需要重验。
若需要AI辅助整理验收场景，可以提供已确认的PRD、角色和规则，让它列出主路径、边界和异常，并标出材料缺口。已有的AI生成测试用例方法适合帮助起草；执行证据、结果判定与接受决定仍来自真实验收。
从一个跨角色任务开始，先填完整场景和记录表，再扩大范围。UAT的价值会体现在交付后少了哪些无法完成的任务、漏掉的角色和反复解释的规则。
