用户验收测试流程图
用户验收测试流程模板，涵盖范围、业务场景、受保护测试数据、环境准备、执行证据、缺陷分级、重测和签署。
什么是用户验收测试流程
UAT 是业务方检验发布能否支持约定工作和成果的过程，不是技术测试的最后一次重跑。本流程先定义范围、退出标准、测试人员和有权签署的人。业务测试人员编写可追溯到需求和风险的端到端场景，环境和数据支持人员准备有代表性且受保护的数据，交付团队证明已部署版本可测试。执行时记录预期与实际结果及证据，产品负责人按业务影响划分缺陷，而不是把所有差异视为同等严重。
本图有意比 /zh/templates/企业软件实施流程 的完整实施生命周期更窄。系统、集成、性能和安全测试应在 UAT 前建立技术信心；本流程只关注业务场景、阻断级别、有针对性的修复、回归重测和责任明确的签署决策。非阻断缺陷只有通过组织规定的剩余风险路径，并指定负责人和后续行动，才可接受。应使用本次发布获批的需求、数据处理规则和决策权限替换示例标准，不要假定一种严重程度模型适合所有系统。
本流程图涵盖的内容
本模板包含
- 从范围和场景设计，到测试数据、环境准备、执行、缺陷分诊、重测和签署的八个阶段
- 由业务负责且可追溯到需求和风险的场景，使覆盖范围反映真实工作而不只是系统功能
- 使用有代表性的测试数据，并在授权、脱敏或重新生成后才授予测试人员访问
- 记录执行证据并按严重程度分诊，区分阻断缺陷与需要明确处理的非阻断问题
- 修复、部署和回归重测回路，最后由发起人签署或退回补充证据
何时使用本模板
- 发布在生产部署或合同里程碑前需要正式业务验收
- 测试人员收到脚本时没有代表性数据、稳定访问或与获批需求的可追溯关系
- 缺陷讨论因严重程度、业务影响和剩余风险接受权限未定义而停滞
- 当前仅用非正式消息签署，没有证据包、未关闭缺陷记录或具名审批人
运作方式
定义范围和签署权限
列出 UAT 包含的流程、用户群体、需求和风险，以及明确排除项。指定审批人及该角色接受或拒绝发布所需的证据。
编写业务场景
围绕真实任务、决策、例外和交接建立端到端用例，而不是逐个界面测试。让每个场景可追溯到需求和优先风险，以便覆盖评审发现有意义的缺口。
准备安全且有代表性的数据
规定覆盖正常和例外路径所需的数据组合、谁有权批准使用，以及敏感值如何脱敏或合成。确认保护处理后引用关系和边界情况仍然真实。
设定严重程度和重测规则
用业务语言定义阻断和非阻断影响、由谁定级、哪些修复需重测受影响用例，以及新版本需要多少回归覆盖。执行前写明对分级有异议时的处理路径。
建立签署记录
汇总已执行用例、实际结果、证据、环境和版本标识、缺陷、重测结果及已接受的剩余行动。让批准、拒绝和补充证据请求成为带日期和负责角色的清晰决策。
常见问题
用户验收测试的目的是什么？
UAT 为负责的业务所有者提供证据，说明发布支持约定的真实场景并适合投入运营。它验证业务适用性，而不是证明所有技术属性。结果应是有记录的验收决策，包括已知缺陷和剩余行动的处理，而不只是通过的用例数量。
谁应执行和批准 UAT？
代表性业务用户应执行场景，因为他们理解实际工作、例外和后果。UAT 负责人协调范围、数据、环境和证据，产品负责人支持分诊，交付团队修复缺陷。最终批准应由有权接受运营影响和剩余风险的业务发起人或授权审批人作出，而不是仅由构建团队批准。
应如何确定 UAT 缺陷优先级？
按书面定义评估业务影响，包括关键任务是否无法完成、数据或控制是否受损、是否有安全变通方案，以及影响多少用户或交易。技术复杂度可影响修复计划，但不应降低业务严重程度。非阻断问题也需记录为签署前修复，或由负责人接受并安排后续行动。
UAT 签署应包含哪些证据？
记录应包含测试版本和环境、获批范围与退出标准、已执行场景、预期和实际结果、支持证据、缺陷严重程度与状态、重测结果、剩余问题及负责人，以及审批人的签署日期和决策。应保留足够背景，使团队无需依赖个人邮箱或记忆即可还原业务接受了什么。
此流程所处的位置
在大多数组织中，此流程紧随数据迁移流程图：从评估到切换之后，并交接给放行与否决策流程：上线就绪决策树。
它是数字化转型中的一个步骤。
第 1 步: 数字化转型流程图
第 2 步: 数字化项目优先级流程
第 3 步: 项目治理流程图
第 4 步: 企业软件实施流程
第 5 步: 数据迁移流程图：从评估到切换
数据迁移流程模板，涵盖范围评估、字段映射、清理、模拟装载、数据核对、业务验证、切换检查和受控回滚。
第 6 步: 用户验收测试流程图 当前位置
用户验收测试流程模板，涵盖范围、业务场景、受保护测试数据、环境准备、执行证据、缺陷分级、重测和签署。