SAP性能测试：负载、并发与工具

SAP性能测试在上线前证明：当大量用户和作业同时运行时，关键事务、后台作业和接口都能达到商定的响应时间。按我的经验，要紧的是并发测试，在达到生产数据量的脱敏数据上运行，对照业务部门在第一次运行之前就商定的通过和不通过标准。

这篇指南写给S/4HANA项目（包括RISE with SAP项目）的CIO、项目总监和测试负责人。它讲测什么、需要什么数据、如何编写验收标准、哪些工具能胜任，以及各方分别负责什么。想了解性能测试在其他测试类型中处于什么位置，请先看我的总览文章SAP测试详解。

SAP项目中的性能问题，很少是意外。

交接班开始时，数百个用户同时登录，Fiori磁贴就超时了。有人对一张非常大的表执行了没有限制条件的整个会计年度选择，一张自定义报表就卡死了。月末后台作业相互重叠，过账运行就中止了。

这些都是可以预见的。唯一的问题是，项目有没有针对它们做过测试，还是要等业务部门在真实订单运行时才发现。

贯穿SAP Activate的性能测试

1. 01

   Explore

   在设计中识别性能风险。代码写出来之前，架构和报表的形态就已经决定了结果。

2. 02

   Realize

   随着配置趋于稳定，运行业务量测试和负载测试。配置不完整会得出误导性的结果。

3. 03

   UAT之前

   在UAT之前完成完整的性能测试周期，而不是把它当作UAT的一部分。

4. 04

   切换

   对照事先商定的验收标准批准切换，而不是凭意见。

5. 05

   Hypercare

   上线后30到60天内盯紧关键指标。大多数性能退化会在第一个结账周期中暴露出来。

在运行于传统数据库上的ECC系统中，性能测试意味着对应用服务器和数据库做负载测试：ABAP运行时、SQL性能和作业调度。前端是SAP GUI，很少让人意外。

在S/4HANA上，有Fiori前端、SAP BTP上的扩展，以及通过SAP Cloud Integration实现的集成，性能同时取决于好几个层次。一个慢的Fiori磁贴，可能是一次耗时很长的ABAP调用、一次网关超时、一个不是为并发请求设计的OData服务，或者混合部署中的网络延迟。只测后端是发现不了的。

1. 01打开磁贴交接班开始时的登录风暴
2. 02OData调用网关超时，服务不是为并发而构建的
3. 03ABAP处理耗时很长的ABAP调用
4. 04数据库读取对大表执行没有限制条件的选择
5. 05页面渲染再加上远程站点的网络延迟

一个端到端测量的响应时间

在转换项目中，SAP HANA性能测试有它自己的特点。稳定的ECC代码在内存数据库上的表现会有所不同。许多程序会快得多，但也有一些在特定的数据模式下出现意料之外的性能特征，所以针对重量级自定义代码做转换专项回归测试，不是可有可无的。

集成流程也有自己的风险。在开发环境中用单条测试消息能正常工作的流程，到了生产数据量下可能会排队积压，或者悄无声息地失败。症状看起来像是别的问题：间歇性的订单失败、发票不匹配、数据在一个系统中存在而在另一个系统中缺失。

性能测试必须在上线前完成。我视为重要的测试是并发测试：大量用户和作业在同一时间作用于同样的事务、表和服务。

一个用户在两秒内录完一张销售订单，几乎证明不了任何东西。同样一张订单，有150人同时在录入订单，后台在跑交货运行，接口在过账入站消息，这样的测试才能预测上线第一天的情况。

下表列出每种测试要证明什么，以及何时运行：

测试	要证明什么	何时运行	通常发现什么
并发测试	大量用户和作业可以同时处理同样的对象	Realize阶段，配置稳定后进行，UAT之前再做一次	锁等待、登录风暴、网关瓶颈
负载测试	系统在预期峰值业务量下达到响应时间要求	Realize阶段，并发测试脚本能运行之后	慢的OData服务、重量级自定义报表
压力测试	超出设计极限时系统在哪里崩溃	UAT之前，如果预期业务会增长	容量规划缺口、队列上限
耐久测试	系统能在数小时的负载下保持稳定	UAT之前，最好覆盖一次模拟结账	内存增长、多次运行中作业链的资源争用
端到端测试	用户等待的整条路径达到目标	与负载测试同时进行	每一层单独测试时看不到的问题

负载测试中的关键词是“预期”。您需要真实的事务量、用户数和会话模式。一个建立在人人都知道过于乐观的业务量估计之上的负载测试，给出的通过毫无意义。

耐久测试是最常被省掉的一项。总体而言，业务量测试是时间表被压缩时项目最常走的捷径，也是事后最常后悔的。

先为这些场景编写脚本。它们覆盖了进入生产的大部分故障。

1. 交接班和高峰登录。当几百个用户同时打开Fiori launchpad时，身份验证和launchpad渲染的负载会急剧上升。一个在非高峰时段运行良好的系统，如果从未测试过并发登录，在那个时段可能根本无法使用。
2. 月结和年结。大量过账、顺序要求严格的作业链，以及一个与固定截止时间赛跑的财务团队。按结账期的业务量而不是日均数量，端到端运行结账作业链。
3. 相互重叠的后台作业。批处理作业通常是一次测一个，这并不反映现实。一个优化不佳的作业可能阻塞其他好几个作业，结账就会超出它的时间窗口。
4. 没有限制条件的自定义报表。一张在测试数据上瞬间返回的报表，在一整个会计年度的数据上可能要运行好几分钟。测试典型的和最坏情况的选择条件，并禁止没有限制条件的选择。
5. 多地区用户。网络延迟影响每一笔事务。RISE把托管交给了SAP，但延迟仍然取决于您选择的地区以及到用户的路由，所以要从最远的站点进行测试。

我的ECC到S/4HANA迁移指南讲了转换测试在整体计划中处于什么位置。

生产级的测试数据

数据决定了这一切是否有意义。我坚持使用生产级的脱敏数据：生产数据量和生产真实度，个人字段和敏感字段做脱敏处理。

一个有200,000行未清订单的客户，和一个只有5,000行的客户，表现完全不同。在单薄的测试客户端中瞬间返回的筛选，到了生产中会超时。为高风险领域准备足够的数据量，使用有代表性的事务组合，能做真实接口调用的地方就做真实调用。

如何通过系统复制、选择性测试数据工具和脱敏安全地获得这些数据，我在SAP测试数据管理指南中做了说明。在第一个性能测试周期之前规划好数据刷新，因为它花的时间比大多数测试计划设想的要长。

在Prepare阶段、任何测试运行之前，与业务部门商定标准。每一项标准都要写明事务或作业、负载和阈值。

下面的示例展示了标准的形式。请根据运营需要设定您自己的数字：

项目	负载条件	通过阈值	负责人
创建销售订单（VA01或Fiori应用）	150个并发订单录入用户	95%的事务在3秒以内	订单到收款流程负责人
交接班开始时Fiori launchpad的首次加载	最大班次的峰值并发登录	95%的用户在5秒以内	IT运维负责人
月结作业链	结账期业务量，完整顺序	在商定的结账窗口内完成，没有中止	财务总监
入站订单接口	每小时峰值消息量	没有超过15分钟的队列积压	集成负责人
大数据量的自定义报表	完整的生产数据量，典型选择条件	60秒以内；禁止没有限制条件的选择	报表负责人

“系统应当足够快，能满足业务运营需要”这样的标准，既无法测试，也无法验收。结果出来之后再改标准，就失去了设定标准的意义。

如果系统通过，是因为UAT用户说用起来感觉很快，那您得到的是一个意见，而不是验收标准。按照我的SAP质量关口指南所描述的方式，把结果变成切换前的一道正式关口。包含每个测试阶段准入和退出标准的整体周期计划，应该写进您的S/4HANA测试策略。

SAP性能测试工具

一次性能测试需要三样东西：一个能驱动SAP协议的负载生成器、SAP一侧的监控，以及一个管理测试用例和结果的地方。LoadRunner是我让团队在SAP项目中使用过的负载工具。尽早在测试计划中定下工具，因为许可、负载生成器和脚本编写技能都需要时间来安排。

2026年的主要选择：

工具	作用	需要了解的
OpenText Professional Performance Engineering	负载生成	即原名LoadRunner Professional的产品。它的协议包涵盖SAP、SAP GUI和SAP Web
Tricentis NeoLoad	负载生成	Tricentis列出了对SAP GUI、Fiori、RFC和IDoc的支持，并且可以复用Tricentis Tosca的资产
Apache JMeter	负载生成	开源。驱动Fiori和OData调用这类HTTP流量
SAP Cloud ALM	测试管理	准备并运行手工和自动化测试用例，跟踪缺陷。它本身不生成负载
SAP Solution Manager	测试管理	主流维护于2027年12月31日结束，所以新的工作请在Cloud ALM中规划

想更全面地了解功能测试和自动化工具，请看我的SAP测试与验证工具比较。工具没有脚本、数据和标准那么重要。

RISE with SAP把责任分开了

在RISE with SAP下，基础设施归SAP负责：容量规划、超大规模云服务商的地区、网络和平台可用性。客户和合作伙伴负责应用层。

SAP的RISE角色与职责文件对此写得很直白。负载测试的执行和高开销SQL语句的调优，属于需额外收费的SAP Cloud Application Services。如果您不购买，这些工作就由客户来做。

RISE项目中一个常见的失败，是以为SAP运行着基础设施，就会发现性能问题。它会发现基础设施问题。把这种分工写进项目章程和测试计划：

1. SAP：基础设施可用性和平台级响应
2. 合作伙伴：在定义的负载下的应用性能，包括扩展和集成流程
3. 客户：流程层面的结果，例如结账运行时间和订单吞吐量，以及验收决定

公有云缩小了测试范围

在SAP云ERP的公有版上，系统运行在一个由SAP运营的共享平台上。在规划对某个租户进行任何负载测试之前，请以书面形式询问SAP是否允许，以及需要提前多久通知。

这样一来，您的测试就转向属于您自己的部分：自定义集成、扩展、大数据量报表、结账顺序，以及从您的站点出发的网络路径。平台性能问题交给SAP支持处理。

常见错误

1. 把功能测试当作性能测试。功能测试证明一笔事务能给出正确的结果。它对150个人同时运行这笔事务时会怎样只字未提。
2. 把性能交给Basis团队。Basis负责容量规划和作业调度。它不负责报表设计、OData服务架构或集成流程设计，而正是这些决定了应用性能。
3. 只让QA负责。QA运行测试并报告结果，但导致性能问题的决定是在设计阶段做出的。项目级的测试负责人或架构师需要有权尽早质疑这些决定，RACI也应该写明谁可以以性能为由叫停上线。
4. 把缺口当作已知问题接受下来。大多数在生产中出现性能问题的项目，并没有跳过测试。它们是在没有商定标准的情况下做了测试，或者测试了，然后在进度压力下接受了失败。

为您风险最高的事务和作业写下五六条验收标准，每一条都有指定的负责人。如果您填不出上面那张表，说明您还没有准备好测试，而您也已经找到了第一个缺口。

然后检查两件事：计划中有没有一次达到生产数据量的脱敏数据刷新，以及并发测试周期是否在UAT开始之前完成。

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

什么是SAP性能测试？

它检查SAP在真实负载下的表现：用户事务的响应时间、后台作业的运行时间、接口的吞吐量，以及许多人同时工作时的资源使用情况。它必须在上线前完成。

功能正确性和性能是两种不同的属性。一笔事务对一个用户是正确的，换成200个用户就可能超时。

SAP项目中的性能测试应该何时开始？

风险识别从Explore阶段开始，因为架构选择决定了性能结果。实际测试从Realize阶段开始，等配置稳定到结果有意义的时候。

在UAT之前完成最后一个周期，而不是在UAT期间。在UAT中发现的性能缺陷会挤压进度，并带来把它们当作已知问题接受下来的压力。

SAP中的负载测试和并发测试有什么区别？

负载测试检查在预期峰值业务量下的响应时间。并发测试检查当大量用户和作业在同一时刻处理同样的事务、表和服务时会发生什么。锁等待、登录风暴和网关瓶颈就是在这时暴露出来的。

按我的经验，并发测试才是重要的。先运行它们，再在其基础上构建完整的负载测试。

SAP性能测试应该使用什么测试数据？

生产级的脱敏数据。也就是生产数据量和真实度，个人字段和敏感字段做脱敏处理。单薄的测试数据会把上线第一天才出现的慢筛选、重量级报表和超长作业运行时间藏起来。

SAP性能测试用哪些工具？

负载由OpenText Professional Performance Engineering（原名LoadRunner Professional）、Tricentis NeoLoad和Apache JMeter这样的负载生成器来驱动。SAP Cloud ALM或SAP Solution Manager管理测试用例和结果，SAP一侧的监控显示系统在负载下做了什么。

在RISE with SAP下，性能测试由谁负责？

基础设施归SAP负责：容量规划、地区、网络和平台可用性。SAP的RISE角色与职责文件把负载测试的执行和高开销SQL的调优留给客户，除非客户额外付费购买SAP Cloud Application Services。

客户和合作伙伴负责应用性能和验收决定。把这种分工写进验收标准，让每一个阈值都有负责人。