SAP性能测试：IT负责人必须了解什么

SAP性能测试要在上线之前证明：关键事务、后台作业和接口，在生产业务量下能够达到商定的响应时间。在设计阶段就启动它；配置稳定之后，在实现阶段运行容量和负载测试；在用户验收测试（UAT）之前完成整个周期；并把结果作为切换的关口。本文写给S/4HANA项目（包括RISE with SAP）的CIO、项目总监和测试负责人。内容包括测什么、谁负责、如何写验收标准，以及上云之后有什么变化。请先看验收标准那张表：如果您填不出来，就说明您还没有准备好测试。

SAP项目里的性能问题，几乎总是在上线之后才被发现。300名用户在交接班时登录，Fiori磁贴就会超时。有人对一张有5,000万条记录的表执行了没有限制条件的会计年度查询，Z报表就卡死了。月末结账期间，后台作业相互重叠，过账运行就中止了。

SAP项目里的性能问题，很少是突然冒出来的。大多数是可以预见的，只是没有被列入计划。常见的模式是：功能测试做得很彻底。容量测试曾经排进了计划，后来时间线被压缩，就推迟了。后果在正式运行的头几周到来。

这些都不是边缘情况。它们是可以预见的。唯一的问题是，项目是自己先测出来，还是让业务在真实订单运行的时候撞上。

贯穿SAP Activate的性能测试

1. 01

   探索

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

2. 02

   实现

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

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（CPI），性能同时取决于好几个层面。一个慢的Fiori磁贴，可能是一次耗时很长的ABAP调用、一个网关超时、一个不是为并发请求设计的OData服务，或者是混合部署中的网络延迟。只测后端，发现不了。测整条路径，才能发现。

1. 01磁贴启动班次开始时的登录风暴
2. 02OData调用网关超时，服务不是为并发而构建的
3. 03ABAP处理耗时很长的ABAP调用
4. 04数据库读取对大表的开放式选择
5. 05渲染远距离站点还有网络延迟

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

集成流程会带来它们自己的风险。在开发和QA环境里，用单条测试消息运行良好的流程，在生产业务量下可能排起长队，或者悄无声息地失败。如果消息队列没有按真实负载来设定容量，延迟就会累积。症状看起来像是别的问题：订单时断时续地失败、发票对不上、数据在一个系统里有、另一个系统里却没有。

1. 负载测试检查预期业务量下的行为。关键词是“预期”。您需要真实的事务量、用户数和并发会话数。很多负载测试失败，是因为用了大家早就知道偏乐观的业务量估算。
2. 压力测试把系统推过设计极限，找出它在哪里崩溃。如果业务量将在十八个月内翻一番，它能告诉您架构能不能扛住，以及容量规划会不会在下一次基础设施复查之前就成为问题。
3. 浸泡测试让稳定的负载持续运行较长时间，暴露随时间积累的问题：内存泄漏、碎片化，以及反复运行中作业链的争用。它是最常被跳过的测试，也是本可以发现下文所述月末故障的测试。
4. 端到端测试跟随用户走过的完整路径：磁贴启动、OData调用、ABAP处理、数据库读取、渲染。只有这样，才能发现逐层单独测试时看不见的问题。

交接班与登录高峰：当200名用户在早上8点打开Fiori启动台时，认证和启动台渲染会陡然飙升。如果从未测试过并发登录，一个在非高峰时段运转良好的系统，在这个时间窗口里可能根本没法用。在制造、零售和金融服务各行业里，登录风暴引来的是上线第一天最显眼的投诉。

月末和年末结账：这是多数项目里风险最高的场景：高业务量的过账、顺序要求严格的作业链，以及一个在固定截止日期前赛跑的财务团队。要按结账期的业务量，而不是日均数量，把结账作业链从头到尾跑一遍。

批处理作业通常是孤立地测试的，这并不反映现实。在月末，后台处理达到峰值，许多程序在同一批资源上并行运行。一个优化不佳的作业可能阻塞另外五个，结账就会超出它的窗口。

从ECC转换到S/4HANA：稳定的ECC代码在HANA上的表现不一样。许多程序会快很多；也有一些在特定的数据模式下出现意料之外的性能特征。针对转换的回归测试不是可选项。我的ECC到S/4HANA迁移指南讲了它在转换计划中的位置。

多区域用户：网络延迟影响每一笔事务。一张销售订单在托管所在国用两秒，如果没有人从3,000英里之外测试过，用户可能觉得它坏了。RISE把托管移交给了SAP，但延迟仍然取决于您选择的区域，以及通往用户的路由。

在准备阶段，也就是任何测试运行之前，与业务商定标准。每一条都要写明事务或作业、负载和阈值。下面这些例子展示的是格式；具体数字请根据运营需要自行设定：

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

“系统应该快到足以满足业务运营”，既无法测试，也无法验收。结果出来之后再改标准，就违背了设立标准的初衷。

逐项点名索要：

期待	应交付什么	为什么重要
性能服务级别	每个事务、接口和作业的阈值，明确通过与否	防止UAT中的意见压过证据
基于风险的范围	按用户量、集成点和数据依赖来排优先级	把测试周期用在真正重要的工作负载上
跨团队参与	Basis、基础设施、业务、安全和集成团队在运行期间都在场	出现缺口时避免互相推卸责任
工具和环境就绪	在周期开始前，负载生成器（OpenText LoadRunner、Tricentis NeoLoad、Apache JMeter）、监控和数据刷新都已就位	让模拟贴近真实
真实的测试数据	生产量级的主数据、真实的接口调用、有代表性的事务组合	让结果能预测上线后的行为
性能报告	负载组合、响应时间、CPU和内存、作业运行时间、错误率	为切换批准提供证据基础
上线后监控计划	头30至60天要观察的关键指标	确认上线后的系统保持在已测试的范围之内

有四个错误出现得最多，即使在交付模式成熟的大型企业里也是如此。

把功能测试当作性能测试：功能测试证明一笔事务给出了正确的结果。至于150个人同时运行它会怎样，它什么也说明不了。

用很小的数据量做测试：一个有200,000个未结订单行的客户，与一个只有5,000个的客户，表现并不一样。在测试中瞬间返回的过滤条件，到了生产环境会超时。要为高风险的区域填充足够的数据量。

把性能交给Basis：Basis负责容量规划和作业调度。报表设计、OData服务架构和集成流程设计不归它管，而这些恰恰决定着应用的性能。

把责任只交给QA：QA运行测试并报告结果。造成性能问题的那些决策，是业务、技术和Basis团队在设计阶段做出的。项目级的测试负责人或架构师，需要有权及早质疑这些决策，RACI里也应当写明，谁可以基于性能理由阻止上线。

RISE划分了责任

在RISE with SAP下，SAP负责基础设施：容量规划、超大规模云区域、网络和平台可用性。客户和合作伙伴负责应用层。SAP的RISE职责分工文档把这一点说得很直白：查找和调优耗资源的SQL语句，仍由客户负责，除非您购买SAP额外的应用服务。

RISE项目里一个常见的失误，是以为SAP既然运营着基础设施，就会发现性能问题。它会发现基础设施的问题。它不会发现设计糟糕的OData服务、低效的ABAP作业，或者无法扩展的集成流程。要把这个划分写进章程和测试计划：

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

公有版和GROW缩小了范围

在S/4HANA Cloud公有版上（通常通过GROW with SAP购买），SAP在其多租户平台上运行性能测试，作为自身产品标准的一部分，并不期待客户对共享系统做负载测试。您的测试转向属于您的部分：自定义集成、扩展、高业务量的报表和分析、结账与合并的顺序，以及从您各站点出发的网络路径。平台本身的性能问题，交给SAP支持处理。

AI能帮脚本，帮不了架构

负载测试厂商正在加入AI，用于脚本维护和结果分析，这对应用在各周期之间不断变化的项目有帮助。在为这些说法付费之前，先在您自己的系统架构上验证。SAP Cloud ALM可以帮助生成测试用例和需求，AI助手也可以根据流程描述起草场景提纲。

这些都解决不了架构问题。AI不会告诉您，OData服务本该用另一种方式设计，或者某个报表对它的数据量来说太重了。这些判断仍然由人来做，在设计阶段，在任何测试运行之前。

在生产中出现性能问题的项目，多数并没有完全跳过测试。它们是在没有商定标准的情况下测试，或者测试之后，在进度压力下把缺口当作已知问题接受了。关键在于标准，以及执行标准的纪律，而不在于工具。至于性能在各类测试中处于什么位置，请看我写的SAP测试和验证工具对比和SAP质量关口指南。

什么是SAP性能测试，为什么重要？

它检查SAP在真实负载下的表现：用户事务的响应时间、后台作业的运行时间、接口的吞吐量，以及并发工作下的资源使用。

功能正确和性能是两种不同的属性。对一个用户正确的事务，对200个用户可能会超时。在测试数据上十分钟跑完的作业，在生产业务量下可能要跑几个小时。上线之后才发现这些，会扰乱运营，迫使紧急变更，并在用户接受度最脆弱的时候损害他们的信任。

SAP项目中，性能测试应该什么时候开始？

风险识别从探索阶段开始，因为架构的选择决定性能结果。正式测试从实现阶段开始，此时配置已稳定到足以让结果有意义。配置不完整，给出的数字会有误导性。

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

SAP性能测试应该由谁负责？

应该是项目，而不只是QA。QA负责执行和报告，但决定性能的那些决策，是业务、技术和Basis团队在设计阶段做出的。中心架构师或项目测试负责人，需要有权及早质疑这些决策。

要在RACI里写明：谁批准验收标准，标准不达标时谁负责整改，以及谁可以基于性能理由阻止上线。

RISE with SAP如何改变性能测试的责任？

SAP负责基础设施：容量规划、区域、网络和平台可用性。客户和合作伙伴负责应用性能：配置、扩展、OData和Fiori的设计、集成流程以及流程关键指标。SAP的RISE职责分工文档把SQL调优留给客户，除非购买了SAP额外的服务。

要把这个划分写进验收标准，让每个阈值都有负责人。

SAP Fiori最常见的性能问题有哪些？

有四种模式涵盖了其中大部分。班次开始时的登录风暴，此时认证和启动台渲染陡然飙升。返回大结果集，或者每次交互都要多次调用后端的OData服务。网关层本身变成瓶颈，所以测试期间必须监控它。还有自定义的或被大量修改的应用，标准的性能假设对它们不适用。

如何为SAP定义性能验收标准？

写明事务、负载和阈值。例如：“在订单录入角色下，150个并发用户，95%的事务在3秒内完成订单创建。”这是可以测试的。

“系统应该足够快”则不是。要在准备阶段，根据真实的运营需要与业务商定标准，并且在结果出来之后不要改动。

如果跳过或压缩性能测试，会发生什么？

问题会在生产中浮现：作业超出窗口并阻塞其他作业，Fiori应用在高峰时超时，月末结账用了两倍的时间、错过报告截止日期，接口队列堆积。

在最初几周就遇到性能问题的用户，会对系统形成负面印象，很难扭转。而且在正式运营中做紧急整改，成本比当初做测试还要高，因为在实现阶段本来只是一个设计决策的事情，变成了紧急的架构变更。