SAP测试详解：类型、阶段与负责人

SAP测试要做的，是证明一套配置好的SAP系统能用您的数据、按您的业务量正确运行您的业务流程，上线前如此，此后每次变更也如此。在S/4HANA项目中，它涵盖六种测试：单元测试、系统集成测试（SIT）、用户验收测试（UAT）、回归测试、性能测试和切换演练。

每种测试回答的问题不同，彼此不能替代。按我的经验，测试约占项目工作量的35%，所以它理应有自己的计划、预算和负责人，而不是在构建结束时挤出几周了事。

这一页是总览。每种测试都有单独的指南，链接在下面各节中。

一套SAP系统，是配置、主数据、自定义代码和接口在一起协同工作。一处的改动可能让别处的流程出问题，而且往往出在一个谁都没碰过的模块里。

所以SAP测试围绕业务流程来组织，而不是围绕界面。订单到收款、采购到付款、记录到报告都横跨多个模块，一个只测到单笔事务就停下的测试，证明不了多少东西。

测试也不会在上线时结束。支持变更、SAP版本发布和新的推广都会改变系统，所以同样的纪律要一直延续到运行阶段。

下面是我在S/4HANA项目中会规划的六种测试。表格列出了每种测试要证明什么、何时进行、应由谁负责。

测试类型	要证明什么	在SAP Activate中的位置	负责人
单元测试	每个配置项、程序或增强单独都能正常工作	Realize阶段，在每个构建冲刺之内	功能顾问和技术顾问
系统集成测试（SIT）	完整流程能用接近真实的数据跨模块、跨接口运行	Realize阶段，构建稳定后分轮进行	项目测试负责人，与流程负责人一起
用户验收测试（UAT）	业务部门能在系统上跑通真实场景	Realize阶段后期，Deploy之前	业务部门
回归测试	变更之后，原来正常的功能依然正常	从Realize开始，之后Run阶段的每次发布	测试负责人，业务量足够时辅以自动化
性能测试	系统在大量用户和生产级业务量同时作用下依然稳定	Realize阶段，上线前完成	项目级性能负责人，与Basis团队一起
切换演练	上线顺序、数据加载和时间安排全程可行	Deploy	切换经理

贯穿SAP Activate的SAP测试

1. 01

   Prepare

   搭建测试工具、测试团队和测试环境。

2. 02

   Explore

   在做Fit-to-Standard决策的同时编写测试策略，让需求可以被测试。

3. 03

   Realize

   冲刺中做单元测试，构建稳定后进行多轮SIT、性能测试和UAT。

4. 04

   Deploy

   按照商定的检查清单进行切换演练，然后做出上线决策。

5. 05

   Run

   每一次支持变更、升级和发布都做回归测试。

单元测试

单元测试由构建该项内容的人来做。功能顾问检查一个定价条件，开发人员检查一个增强或一个接口映射。

它是必要的，但不充分。单元测试通过，并不能告诉您这一项和流程的其他部分碰到一起时会怎样。

系统集成测试

SIT是项目发现设计是否可行的地方。一张销售订单要流转到交货、开票、会计和报表，沿途每个接口都必须正确过账。

我把SIT分成多轮来规划，而不是只跑一遍。第一轮发现的缺陷得到修复，下一轮再证明这些修复没有弄坏其他东西。各轮测试、准入标准和退出标准如何衔接，请看我的S/4HANA测试策略指南。

用户验收测试

UAT是业务部门确认系统能支持上线后的工作方式。它属于业务部门，而不属于系统集成商，因为只有业务部门才能验收系统。

UAT至少需要6到8周。为了迁就延误的构建而压缩它，您得到的是纸面上的签字和生产中的问题。我的SAP用户验收测试指南讲了测试脚本、角色和签字确认。

回归测试

回归测试是在变更之后重新运行已经验证过的测试，找出被变更弄坏的地方。在周期较长的项目中，线上支持修复和项目变更会同时在系统中流转。

我的做法是运行两套独立的环境，一套给项目，一套给日常运营（BAU）。这样线上支持变更和项目变更就分开测试，谁也不会掩盖另一方的缺陷。我的SAP回归测试指南讲了双环境做法、升级和影响分析。

性能测试

性能测试必须在上线前完成。最要紧的是并发测试，也就是大量用户在同一时刻执行事务。

一笔事务对一个用户是正确的，换成两百个用户就可能超时。功能测试永远不会让您看到这一点。我写给IT负责人的SAP性能测试指南讲了负载测试、压力测试和耐久测试，以及如何编写验收标准。

切换演练

切换演练测试的是上线本身：技术步骤的顺序、数据加载、对账和签字确认，以及各自的耗时。在棕地转换项目中，我会在切换前安排三次模拟转换。

我坚持的上线标准，是一份事先商定、内容详尽的切换检查清单。如果检查清单是在切换周末才写出来的，那之前的演练就算不上真正的演练。

按我的经验，测试约占项目工作量的35%。把测试看作构建和上线之间短暂空档的发起人，往往会对这个数字感到意外。

这些工作量分摊在很多人身上。顾问做单元测试，测试团队准备并执行SIT，业务用户执行UAT，Basis和集成团队支持性能测试和切换演练。

数据迁移与之并行，单是它就要占30%到40%的工作量。两者高度重叠，因为每一轮测试都需要看起来像生产数据的迁移数据。

我见得最多的测试失败，就是SIT和UAT测试做得不够。构建一延误，测试轮次就被砍掉，上线日期却纹丝不动。在我主导或挽救过的21个SAP项目中，最大的错误仍然是一开始没有好好规划，而测试通常是这个问题最先暴露的地方。

测试的质量取决于所用的数据。我的原则是数据要脱敏，但要达到生产水平：生产规模的数据量和接近真实的记录，个人字段和敏感字段做脱敏处理。

少量、干净的测试数据会把要紧的问题藏起来。一张报表在几千条记录上几秒就能跑完，换成一整年的过账可能要跑好几个小时。

环境和数据同样重要。在Prepare阶段规划好测试环境，决定各轮之间如何刷新，并把项目变更和BAU变更分开。我的SAP测试数据管理指南讲了系统复制、数据脱敏和选择性测试数据。

我对自动化的原则很简单。测试用例数量大、需要大量反复测试时，就做自动化。达不到这个程度，手工测试就可以。

自动化通常最先在回归测试上见到回报，因为每次变更后都要跑同样的测试。UAT基本上仍然靠手工，因为它的目的是业务用户的判断，而不是脚本的判断。

尽早做决定有一个很实际的理由。自动化测试的构建和维护都要花时间，只有运行很多次才能收回成本。我的SAP测试自动化指南讲了从哪里入手、什么时候能见到回报。

这些工具分为三类：测试管理、功能自动化和性能测试。我主导或合作过的团队用过Tricentis Tosca、Worksoft、Panaya、SAP Cloud ALM、SAP Solution Manager、UiPath和LoadRunner。

下表列出每类工具做什么，以及其中的产品：

工具类别	做什么	团队常用的产品
测试管理	测试计划、测试用例、执行记录、缺陷，以及到需求的可追溯性	SAP Cloud ALM、SAP Solution Manager、Panaya
功能测试自动化	在SAP和非SAP应用中运行基于脚本或基于模型的测试	Tricentis Tosca、SAP Test Automation by Tricentis、Worksoft、UiPath
性能测试	模拟大量并发用户和生产级业务量	OpenText LoadRunner，现以OpenText Professional Performance Engineering之名销售

在做选择之前，有几个产品事实值得了解。

1. SAP Cloud ALM包含在SAP Enterprise Support中，也包含在含有Enterprise Support, cloud editions的云订阅中（SAP Support）。它的测试管理涵盖测试准备、测试计划和执行，包括用于UAT的手工测试用例（SAP Learning）。
2. SAP Solution Manager 7.2的主流维护于2027年底结束，部分功能（包括测试套件）可选择延长维护至2030年底（SAP Support）。
3. SAP Test Automation by Tricentis是SAP转售的自动化产品，与SAP Cloud ALM集成，面向SAP和第三方系统（SAP）。
4. LoadRunner是OpenText的产品。LoadRunner Professional现在叫OpenText Professional Performance Engineering，支持SAP GUI和SAP Web协议（OpenText）。

如果您正在启动一个新项目，请在Cloud ALM而不是Solution Manager中规划测试管理。想看更深入的比较，请阅读我的SAP测试工具指南。

在SAP Cloud ERP公有版（S/4HANA Cloud Public Edition）上，SAP按自己的时间表为每个客户升级。SAP Learning的说法是每六个月升级一次，目前在2月和8月，其间每月交付新功能（SAP Learning）。

升级日期不由您选择，所以回归测试变成了日程上的固定事项，而不是一个项目。这是在公有云系统上尽早实现回归测试自动化最有力的理由。

在私有云和本地部署中，升级时间由您掌控。但每次升级仍然需要一轮回归测试，规模要与变更涉及的流程相匹配。

首先，把测试作为一条工作流写进计划，给它配上自己的负责人和预算，规模约为工作量的三分之一。然后指定UAT的业务负责人，现在就在日程中为它留出6到8周，赶在构建把它挤掉之前。

用可衡量的退出标准，把测试结果和上线/不上线的决策挂钩。我的SAP质量关口指南讲了具体做法。如果您的项目已经陷入困境，我关于SAP项目挽救的笔记讲了先修什么。

如果您想就测试策略或上线决策听取独立意见，我可以为您的组织提供这方面的帮助。您可以在这里联系我。

什么是SAP测试？

SAP测试证明一套配置好的SAP系统能用您的数据、按您的业务量正确运行您的业务流程。在S/4HANA项目中，它包括单元测试、系统集成测试、用户验收测试、回归测试、性能测试和切换演练。上线之后，每一次支持变更和版本发布都还要继续测试。

SAP测试有哪些类型？

六种主要类型是单元测试、系统集成测试（SIT）、用户验收测试（UAT）、回归测试、性能测试和切换演练。单元测试检查单个项目，SIT检查跨模块、跨接口的完整流程，UAT是业务部门对系统的验收。回归测试、性能测试和切换演练分别防范变更、负载和上线本身带来的风险。

SAP用户验收测试需要多长时间？

请为UAT规划至少6到8周。它应由业务部门负责，跑真实场景并签字确认。UAT和SIT测试做得不够，是我见得最多的测试失败。

测试占SAP项目的多大比例？

按我的经验，测试约占项目工作量的35%。这包括准备和执行单元测试、多轮SIT、UAT、回归测试、性能测试和切换演练。数据迁移与之并行，而且每一轮测试都需要接近生产的数据。

SAP测试应该自动化吗？

当测试用例数量大、需要大量反复测试时就做自动化，这通常指回归测试。达不到这个程度，手工测试就可以。UAT基本上仍然靠手工，因为它的目的是业务部门的判断。

SAP测试用什么工具？

大多数项目会把一个测试管理工具、一个自动化工具和一个性能测试工具组合起来用。常见的选择是：测试管理用SAP Cloud ALM或Solution Manager，自动化用Tricentis Tosca、SAP Test Automation by Tricentis、Worksoft或UiPath，性能测试用OpenText LoadRunner。新项目应以Cloud ALM为准来规划，因为Solution Manager的主流维护将于2027年结束。