SAP用户验收测试：谁来负责，如何执行

SAP用户验收测试（UAT）是业务用户在配置好的系统中运行自己的流程，并在上线前正式验收系统的阶段。它归业务部门负责，由IT部门和实施合作伙伴提供支持；在S/4HANA项目中，我会为它规划至少6到8周。

我见得最多的测试失败很简单：UAT和系统集成测试（SIT）做得不够。时间表一延误，这两个阶段就被压缩，缺口则会在上线之后暴露出来。

下面讲的是：谁做什么、准备工作、测试脚本、缺陷分诊，以及一份真正有意义的签字确认。想了解UAT在其他测试类型中处于什么位置，请先看我的总览文章SAP测试详解。

用户验收测试归业务部门负责。这是我的立场，进度再紧也不应该改变。

原因就在名字里。验收是一个业务决定，判断系统能否支撑业务运行，所以只有运营业务的人才能做出这个决定。如果由IT部门或合作伙伴签字确认UAT，那就没有任何人验收过任何东西。

SAP自己的方法论也是这么说的。它的S/4HANA Cloud Private Edition测试策略指导把UAT放在Realize阶段。合作伙伴的配置专家设置手工测试用例，客户的业务线专家执行这些用例并记录结果。

一种可行的分工如下：

角色	在UAT中负责	不负责
业务流程负责人	场景范围、验收标准、对自己流程的最终签字确认	修复配置或代码
关键用户和测试人员	执行脚本、记录结果和证据、提出发现的问题	独自判定一个缺陷“不是缺陷”
UAT负责人（业务方）	每日计划、进度、主持分诊会、向项目发起人报告准备情况	技术修复
实施合作伙伴	起草脚本、准备测试系统、修复缺陷、支持重新测试	验收
内部IT部门	环境、访问权限、与其他系统的接口、传输	验收
数据团队	加载和刷新测试数据、支持对账	业务场景设计

UAT负责人应该来自业务部门，而不是合作伙伴。由合作伙伴主导的UAT，会慢慢变成证明构建能用，而这和业务能否在系统上运行是两个不同的问题。

UAT至少需要6到8周。少于这个时间，业务部门只会把顺利路径测一遍，没有时间重新测试修复，也永远到不了真正问题所在的那些例外情况。

这几周只有在UAT从一个稳定的系统开始时才有用。SAP的指导是，在集成已经搭好、流程所需的数据已经迁移之后，再测试业务流程。这意味着SIT必须先按商定的退出标准完成，我的S/4HANA测试策略指南说明了这些周期如何衔接。

在第一位测试人员登录之前，以下这些应该到位：

1. 已签字确认的流程设计。脚本是根据它们写的，设计没有签字，脚本就定不下来。
2. 已满足并记录准入标准。SIT已完成，没有未关闭的严重缺陷，测试系统除受控修复外已冻结。
3. 一个看起来像生产系统的测试系统。配置、接口、角色和权限都与上线时一致。
4. 接近真实的测试数据。经过脱敏、达到生产水平，在测试开始前加载并完成对账。我的SAP测试数据管理指南讲了具体做法。
5. 从日常工作中抽出来的测试人员。写下他们的名字，与他们的经理商定投入时间，并形成书面记录。
6. 接受过新系统培训的测试人员。在UAT之前而不是期间，简短演示他们将要使用的Fiori应用和事务。
7. 一个测试管理工具。脚本、结果、证据和缺陷放在同一个地方，而不是分散在几个并行的电子表格里。

第5项往往是UAT悄无声息地失败的地方。让测试人员在月结之余挤时间做UAT，他们会把月结放在第一位，而且他们这样做是对的。

UAT脚本是一个业务场景，而不是一张事务清单。“创建一张销售订单”测试的是一个界面。“接一张来自信用冻结中的新客户的订单，放行、交货并开票”测试的才是业务。

根据已签字确认的流程设计来编写脚本，并用业务语言给每个脚本写明清晰的预期结果。测试人员应该不用问顾问，就能说出通过还是不通过。

覆盖四类场景：

1. 核心流程。让业务持续运转的日常流程，例如订单到收款、采购到付款和记录到报告。
2. 例外情况。退货、信用冻结、部分交货、价格变更、冲销，以及被驳回的审批。
3. 期末。财务团队实际执行的月末和年末步骤，按他们执行的顺序。
4. 角色检查。每位测试人员都以上线时将担任的角色来操作，让权限缺口现在就暴露出来。

让合作伙伴起草脚本，再由关键用户用自己的语言改写。如果业务部门离开别人帮忙就看不懂一个脚本，那它是写给构建团队的。

在SAP Cloud ALM中，手工测试用例从一个流程开始，测试计划把它们按周期分组。测试人员把每一步标为通过或不通过，记录实际结果，并从测试执行中直接提出缺陷，这样脚本和缺陷之间的关联就保留下来了。

对于仍在用SAP Solution Manager 7.2做测试管理的项目，请注意它的主流维护于2027年底结束（SAP Support）。新项目请以Cloud ALM来规划。

并不是每一项UAT发现都是缺陷。把它们全当作缺陷，会压垮合作伙伴；把它们全当作变更请求，又会把真正的失败藏起来。

UAT期间每天开一次分诊会。由业务方的UAT负责人主持，合作伙伴的功能负责人和一位IT代表参加，每一项新发现离开会议室时都要有类型、严重程度和负责人。

一个简单的分类就能覆盖大多数发现：

发现类型	含义	谁来处理	对签字确认的影响
缺陷	系统没有做到已签字确认的设计所说的	合作伙伴修复，测试人员重新测试	严重和高级别缺陷阻止签字确认
变更请求	设计已经实现，但业务部门现在想要不同的东西	设计委员会决定，并说明成本和时间	不阻止，除非业务部门表示没有它流程就无法运行
数据问题	主数据或业务数据错误或缺失	数据团队更正，测试人员重新测试	如果同样的数据要上线，则阻止
培训或使用问题	系统没问题，但测试人员不知道怎么用	培训负责人更新材料	不阻止，但会纳入培训计划
权限问题	角色缺少访问权限，或权限过多	安全团队调整角色	对受影响的角色阻止

在UAT开始之前，用业务语言商定严重程度的定义。严重缺陷会让一个流程停下来，而且没有变通办法。高级别缺陷有变通办法，但在业务量大时业务部门无法长期维持。

留意变更请求那一栏。UAT中出现一长串变更请求，通常意味着业务部门在设计阶段没有充分参与，这是一个要在下一批次之前解决的问题。

SAP的Activate培训说明，用户验收测试完成并签字确认后，Realize阶段才算完成。把这份签字确认做成一份文件，而不是一串邮件往来。

每位业务流程负责人为自己的流程签字。签字确认应记录：

1. 测试了什么。执行、通过和失败的场景，证据保存在测试工具中。
2. 还有什么未关闭。每一个未关闭的缺陷，以及它的严重程度、负责人和目标日期。
3. 哪些是带着变通办法验收的。逐一列出，并写明业务部门同意采用的变通办法。
4. 谁签的字、何时签的。每个流程一位具体的人，而不是一个委员会。

在UAT开始之前写好退出标准，结果出来时不要改动。如果业务部门仍想带着缺口上线，就把它记录为一项签字的决定。我的SAP质量关口指南讲了这个关口如何与阶段转换相衔接。

UAT签字确认不是上线决定，而是上线决定的输入。

我坚持的上线标准，是一份事先商定的详尽切换检查清单。UAT签字确认只是其中的一行，旁边还有数据对账、培训和切换演练。

签字确认之后，要保护好已经验收的东西。从这时起到上线，每一次修复和传输都需要重新测试，我的SAP回归测试指南讲了如何把它控制住。

您不需要一份长文件。您需要的是一份计划，每次都回答同样的问题，在UAT开始之前写好，并由业务部门签字。

一份简单的提纲就够了：

部分	包含什么	负责人
范围	范围内的流程、组织单元和角色，以及明确排除在外的内容	业务流程负责人
进度	开始和结束日期、测试周期、重新测试窗口、期末运行	UAT负责人
团队	按流程划分的测试人员、他们从日常工作中抽出的安排、合作伙伴和IT的支持联系人	UAT负责人和直线经理
准入标准	已满足SIT退出标准，测试系统已冻结，数据已加载并对账，测试人员已培训	UAT负责人与项目经理
环境和数据	测试系统、范围内的接口、脱敏的生产级数据、刷新计划	IT部门和数据团队
脚本	每个流程的场景清单、预期结果、与流程设计的关联	合作伙伴起草，关键用户批准
缺陷流程	发现类型、严重程度定义、每日分诊、重新测试规则	UAT负责人主持分诊
报告	每日进度、按严重程度统计的未关闭缺陷、提交给项目发起人的阻碍事项	UAT负责人
退出标准	各严重程度未关闭缺陷的阈值、通过的场景、已商定的变通办法	业务流程负责人
签字确认	每位流程负责人的签字栏、已接受的变通办法清单	业务流程负责人和项目发起人

各个批次之间保持模板不变。第二次推广应复用第一批次的脚本和经验，而不是从头再来。

这个月就从业务部门中指定您的UAT负责人，并请每位流程负责人提名能抽出时间的测试人员。然后在计划中SIT之后为UAT安排6到8周，时间表吃紧时守住它。

如果您的UAT正由合作伙伴来执行，或者总是被压缩，我可以帮助项目把它正确地搭建起来。您可以在这里联系我。

SAP中的用户验收测试是什么？

它是业务用户对照自己的真实流程测试配置好的SAP系统，并在上线前正式验收系统的阶段。在SAP Activate中，它发生在Realize阶段，在集成测试之后。关键用户执行场景脚本、记录结果、提出发现的问题，流程负责人签字确认。

SAP项目中的UAT由谁负责？

业务部门：流程负责人决定范围并签字确认，关键用户执行测试。实施合作伙伴起草脚本、修复缺陷，内部IT部门提供环境、访问权限和接口。IT部门和合作伙伴都不应代替业务部门验收系统。

SAP UAT应该持续多长时间？

在S/4HANA项目中规划至少6到8周。这样才有时间运行核心流程、例外情况和期末步骤，然后重新测试修复。比这更短的UAT，通常只把顺利路径测一遍，其余问题要到上线后才发现。

SAP中的SIT和UAT有什么区别？

系统集成测试（SIT）检查流程和接口能否跨模块、跨系统协同工作，主要由项目团队执行。UAT检查业务部门能否在系统上运行自己的流程，由业务用户执行。SIT应在UAT开始之前完成。

UAT签字确认应该包含什么？

测试过的场景及其结果，每一个未关闭的缺陷及其负责人和日期，业务部门接受的所有变通办法，以及每位流程负责人的署名签字。在UAT开始之前商定退出标准。带着缺口的签字确认，应该是一项有记录的业务决定。

SAP Cloud ALM能用于UAT吗？

能。SAP Cloud ALM支持基于流程构建的手工测试用例、每个周期的测试计划、逐步记录通过或不通过，以及从测试执行中直接提出缺陷。按SAP的指导，由合作伙伴专家设置测试用例，由客户业务专家执行并在其中记录结果。