做了这么多年SAP性能测试我最大的感受是SAP系统不是不能压而是很多人一上来就选错了工具和协议。项目标题里写的“使用LoadRunner工具对SAP进行压测”看着简单实际上从脚本录制、关联、参数化到后端监控每一步都有坑。这篇文章我把我实际踩过的路、趟过的雷都写出来从协议选型到场景设计从脚本开发到问题排查一条线讲清楚希望能帮到正在做SAP压测或者准备做SAP压测的朋友。1. 为什么SAP压测这么折磨人又为什么选LoadRunner1.1 SAP系统压测的难点到底在哪很多人觉得SAP压测就是“录制个GUI操作然后并发跑一跑”这是最常见的误区。SAP是一个重型企业套件它的客户端交互是“长会话、多屏跳转、动态数据密集”的跟普通Web系统完全不是一个量级。你在SAP GUI里点一个回车背后可能触发一连串ABAP程序、数据库查询、RFC调用和锁操作任何一个环节性能掉了用户体感就是“卡”。SAP压测的难点主要有四个第一事务链很长。用户从登录、菜单进入到创建订单、保存凭证中间十几个屏幕每个屏幕都有大量的动态数据。录制下来的脚本如果不去做参数化和关联回放的时候基本活不过第一个界面。第二动态数据太密集。SAP的会话ID、文档号、批次号、凭证号全都是运行时才生成的脚本必须实时截取再回填。这个工作在Web系统里有类似逻辑但SAP GUI里更隐蔽字段不在URL中而是藏在控件属性和表格行里新手很难找。第三后端指标权重极高。压测SAP不能只看LoadRunner的响应时间图你必须同时盯住SAP端的dialog process、RFC队列、ABAP缓存、数据库时间、锁等待否则客户端响应慢了你根本不知道是网络慢、应用层挂死还是数据库堵了。第四环境要求严格。SAP压测最好在独立测试Client做账号要专门准备生产数据不能污染压测窗口要跟Basis团队提前对齐。有人直接在开发机上乱压结果把系统配置改乱最后还得花几天恢复得不偿失。1.2 协议选型GUI、RFC、HTTP/Fiori各有各的玩法LoadRunner压SAP第一个决定就是选协议。这步错了后面全白干。SAP GUI协议SAPGUI是压经典GUI客户端场景的首选。它直接录SAP GUI for Windows操作脚本里出现的是sapgui_open_connection、sapgui_login、sapgui_press_button这类函数。它的优势是还原度最高毕竟录制的是什么回放就是什么比较贴近真实用户操作。代价是每个虚拟用户需要加载一个GUI环境资源占用比较大。RFC协议是压后台接口、批处理、第三方集成的套路。LoadRunner通过SAP RFC SDK跟系统通信录制的是RFC函数调用适合不经过GUI的后台压力测试。脚本里通常是lr_rfc_call这类动作本质上是在模拟程序调用BAPI或RFC函数而不是模拟人点屏幕。如果压的是SAP Fiori、SAP Gateway的OData服务或者Web Dynpro那就走HTTP/HTTPS协议。脚本会记录HTTP请求需要处理Cookie、Session、XSRF Token本质上是标准的Web压测逻辑但SAP特有的Token和CSRF防护机制会给你埋不少雷。这三种路径我看很多团队都用过我的建议是业务入口是GUI就优先SAPGUI协议压接口或中间件用RFC压Portal/Fiori/移动端用HTTP。不要图省事一锅端用HTTP去模拟GUI登录那样压出来的结果没有参考价值业务部门不认。1.3 为什么选LoadRunner而不是其他压测工具这几年开源工具很热JMeter、k6、Gatling都有人用但SAP压测场景下LoadRunner的价值依然突出。最核心的一点是LoadRunner对SAP GUI的脚本化支持是独一份的。JMeter本质是做协议层的模拟你没法像SAPGUI协议那样直接录制和回放一个带树形导航、表格控件和状态栏反馈的GUI会话。SAP的Screen Painter元素、表格行选择、菜单路径都是SAPGUI协议内部做了专门处理的开源工具想做到这个程度得花大量时间做二次开发。其次LoadRunner的场景设计能力成熟。Controller里可以精确控制分阶段加压、思考时间、集合点、Vuser策略分析器还能自动汇总事务响应时间、吞吐量、每秒事务数这些标准指标。做大型压测项目时稳定性和可追溯性比什么都重要。我不是说JMeter不行。如果你压的是SAP对外发布的REST API、OData服务JMeter完全够用方案也轻。但如果是业务部门指着SAP GUI说“我们用户就是在这个界面上慢”那老老实实用LoadRunner的SAPGUI协议省下来的调试时间远超你的License成本。2. 压测前的准备工作环境、录制与脚本改造2.1 环境准备别在压测当天才想起Basis的事做SAP压测环境准备的花的时间往往比写脚本还多。我的经验是提前一周把这些事列清楚逐个确认。SAP端要确认四件事。第一测试Client是否存在且数据干净。最好用专门的测试Client不要碰生产和开发机的原始数据。纯压测性能时哪怕数据不全是典型业务分布也要保证关键主数据存在比如要压MIGO过账物料、供应商、库存地点都得齐全。第二SAP进程参数是否允许压测。Dialog process数量、后台作业队列、RFC通道数这些直接决定了系统能承受多少并发。用RZ12看分配情况用SM50看当前进程。第三License问题。SAP的在线用户数和并发会话数是受License约束的压测时如果模拟了大量登录用户可能触发License告警或被强制踢出得提前跟Basis确认测试账号是否走独立扩展。第四压测窗口。SAP晚上一般有Batch任务白天有业务高峰尽量选一个Batch链路少、其他用户干扰小的窗口。LoadRunner端也要匹配好版本。SAPGUI协议跟SAP GUI补丁版本有兼容性要求LR的补丁包要更新到对应版本。如果你压S/4HANA建议确认是否支持当前GUI版本比如SAP GUI 7.70。我吃过一次亏SAP GUI升级到新版本后录制的脚本回放时会话立刻断开最后发现是LoadRunner补丁太旧升级后就好了。另外压测账号池要提前准备。SAP的密码策略复杂密码有效期、登录失败锁定都可能让你中途尴尬。我会准备30到50个测试用户密码统一设置为已知的固定值并临时延长有效期压测完再恢复。这一步不提前做场景跑到一半所有人被锁画面非常难看。2.2 录制脚本录像谁都会关键是录之前想清楚业务场景脚本录制用VuGen协议选SAPGUI。录制前最重要的一件事是先把业务流程走一遍记录下来确定要做哪些事务。我建议不要录“所有步骤一锅端”。比如你要压财务月结场景你就专门录一个“创建会计凭证”的脚本把登录、点击路径、输入字段、保存凭证这些步骤完整走一次。不要在里面混入查报表、改权限等无关操作脚本越纯粹后期越容易参数化和分析。录制时的操作节奏要刻意放慢。SAP GUI的每个回车、每次Tab跳转、每点一次工具栏按钮都会生成事件操作太快会导致脚本堆满无意义动作维护成本飞涨。我一般控制在每个屏幕停顿两三秒确保界面刷新和控件加载完成这样录制出来的脚本结构比较干净。录制完成后的第一件事是删除无关事件。SAP GUI录制脚本里会有大量“select_item”、“set_text”之类的动作有些是界面自动触发的不是真实业务操作。对比一下你录屏时的操作记录凡是你没有主动做的都删掉。还要特别处理搜索帮助界面F4搜索帮助会打开新的弹出窗口脚本里会产生额外的事务和事件如果业务上是直接填主数据的话这类辅助界面事件可以清理掉。还有一点录制时用经典登录窗口别用SSO或受信任登录。SPNego、单点登录这类机制会让脚本回放极不稳定因为它的认证过程依赖大量动态票据和上下文LoadRunner很难完全模拟。压测资格预审时会要求SAP Basis关闭目标测试Client的SPNego或者在用户参数中固定认证方式。2.3 参数化和关联脚本能不能稳定回放就看这一步SAP GUI脚本里有两类动态数据一类是输入数据的多样化需要参数化另一类是系统动态生成的数据需要关联。这两个概念容易搞混我分开说。参数化解决的是“每次跑都要输入不同的值”。典型例子是登录账号。录制脚本时你用的是脚本001登录的回放时如果所有人都用脚本001真实度极差而且可能互相挤占会话。解决方式是建立一个用户池把登录用户script_user参数化通过lr_save_string或参数文件按Vuser分配。同样地物料号、工厂、库存地点、会计科目这类业务输入值都建议参数化才能模拟不同用户处理不同单据。关联解决的是“系统每次返回的值都不一样脚本必须在运行时获取”。最典型的是SAP的会话ID和凭证号。例如你做MIGO收货过账保存成功后系统会返回物料凭证号这个号码是数据库自动生成的下一次运行保证不同。脚本里如果把这个值写死回放时必然找不到对应凭证后续动作全部失败。SAPGUI协议下的关联我不会用Web_reg_save_param那种Web专用函数。SAPGUI脚本主要通过lr_save_string、sapgui_find_text、sapgui_get_text来抓取动态值。实操中我会做这样几步回放一次脚本看Log里哪些步骤的返回值是变化的重点观察保存凭证后界面上的“Document Number”字段。用快照功能找到这个字段的控件位置和文本属性写一个sapgui_get_text把它读出来再用lr_save_string保存到参数。后续步骤中的凭证号引用处替换为该参数。最后必须全量回放至少三次确认三个关键点登录是否每次都成功、动态值是否每次都能正确抓取、业务操作是否每次都走到最后。三次回放全部通过脚本才算能进场景。3. 场景设计、负载模型与压测执行3.1 负载模型并发多少、干什么事、节奏怎么控制压测不是简单地把脚本扔进Controller然后设成100个Vuser无限跑。真正要做的是设计一个跟真实业务匹配的负载模型。先确定业务占比。拿SAP ECC常见场景举例可能30%用户在创建销售订单25%在做MIGO收货20%在跑MD04/MD07查库存15%在做FB50录入会计凭证10%在登出登录。不同事务的占比由业务量历史数据算出来不能拍脑袋。压测时配置不同脚本的Vuser数量比例才能真实反映系统负载结构。然后处理思考时间和Pacing。思考时间模拟用户“看屏、输入、思考”的间隔LoadRunner脚本里对应lr_think_time。压GUI场景时思考时间不能设成0否则相当于所有用户同时疯狂敲屏幕产生不真实的峰值。一般我会按操作复杂度设3到10秒不等。 Pacing是迭代间隔决定一个Vuser完成一次完整事务后等多久再跑下一次。Pacing的计算可以这么推假设目标是一小时内系统要处理120笔订单过账每个过账脚本执行时间约30秒那一个Vuser每小时能跑60次需要2个Vuser才能撑起120笔。反过来目标TPS为每秒10笔而每个脚本平均耗时2秒那么理论上需要同时并发约20个Vuser。实际值还要加上Pacing的等待时间公式大概是并发用户数 目标TPS × 事务时长 Pacing。这个计算过程我建议记到测试方案里写报告时业务方问起你可以一眼说清楚。最后是集合点。SAP压测里月度关账、物料集中过账这类场景可以用集合点让大量Vuser在某个动作前同时等待制造并发高峰。但使用集合点要谨慎它容易制造瞬时尖峰而不符合真实用户分布建议只在测试具体并发风险时使用日常压测别乱开。3.2 场景配置与监控Controller一侧要盯哪些数据Controller的Group配置按脚本和Vuser比例把资源分好然后设置阶梯加压策略。我习惯用20%梯度比如200个Vuser分成5批每批间隔2到3分钟逐步加到目标值而不是一次性灌满。SAP系统比较脆弱瞬时涌入过多登录可能导致dialog process队列瞬间打满这种失败不是你性能问题的真实反映而是加压方式的问题。场景运行期间LoadRunner一侧要重点监控这些指标事务响应时间曲线尤其是90%响应时间和平均时间看有没有明显拐点。每秒事务数TPS判断系统处理能力有没有达到天花板。虚拟用户状态有没有大量Error/Stopped错误类型分布如何。网络吞吐量如果吞吐量在Vuser增长时不再上升大概率是应用端问题而不是网络。同时联合Basis在SAP端开ST03N工作负载分析、SM50进程列表、SM66全局进程概览、ST02缓冲命中率和缓存管理和SM12锁表做监控。前后端日志同步记录压测结束后对时间轴你就能精准定位是应用层慢还是数据库慢。3.3 压测执行从冒烟测试到持续负载的完整流程压测执行阶段我会遵循一套固定流程避免“一上来就跑满”。第一步单Vuser冒烟。目标不是测性能而是确认脚本在场景模式下能稳定跑通包括登录、业务操作、动态数据关联、日志记录。一个Vuser跑20次迭代如果全通过说明脚本质量过关。第二步小并发验证。比如按10%、20%的负载跑15分钟观察内存、响应时间、错误率是否有异常。很多时候脚本本身没问题但一加压就暴露关联遗漏比如某个动态值在低并发时不太变高并发时才随机生成导致脚本崩溃。这一步能把这类问题先滤一遍。第三步目标负载持续压测。按设定的负载模型把Vuser加到目标值稳定运行至少1小时。SAP性能测试中半小时以下的持续负载难以暴露内存泄漏、锁累积等长期问题至少跑1小时。我一般会跑2小时看更稳定的趋势。第四步阶梯加压测试可选。逐步增加负载直到系统出现明显性能拐点或错误率飙升这个数据可以用来推算系统的容量上限。阶梯压力测试结束后要记录从多少并发开始响应时间明显上扬这个“拐点值”在扩容决策中很有价值。压测过程中的数据采集必须跟脚本版本绑定。每个脚本、参数文件、Controller场景文件、SAP端ST03N快照、监控截图都要按时打标签存档。我见过不少团队压测完了结果指标在报告里能对上号但三个月后想复现当时的场景脚本版本都分不清等于白测。3.4 结果分析找到那一层最慢的墙压测结束后第一轮分析先看LoadRunner Analysis里的整体趋势。重点画三张图事务响应时间随并发变化图、TPS随并发变化图、错误率随并发变化图。如果响应时间在某个并发值突然陡增说明系统在该位置达到瓶颈。然后对比SAP端的时间切面。ST03N里能看到“Frontend Response Time”和“Backend Response Time”的细分。如果前端响应时间高而后端处理时间低问题出在网络或GUI渲染如果后端响应时间也高再看是ABAP处理时间长、数据库执行时间长还是锁等待时间长用ST05做SQL Trace能找到具体的数据库语句瓶颈。ST02的缓冲命中率如果大幅下降说明SAP缓冲配置不足扩容或调参时优先考虑。最后要分清“系统瓶颈”和“脚本瓶颈”。如果大量Vuser报错集中在某条动态参数上那是脚本问题不是系统问题。所以我的习惯是压测报告里单独列一个“脚本质量验证”小节把所有错误先按脚本原因归类剩下的才纳入系统性能问题列表。这一步能帮你少背很多锅。4. 常见问题与排查技巧实录4.1 脚本回放失败先怀疑关联和会话上下文SAPGUI脚本最常见的问题是回放时登录成功但进入某个事务后就报“Item not found”或者“Session expired”。这类问题90%是关联遗漏或者会话上下文丢失。排查思路是先看Log找到失败步骤前最后一次成功的操作判断丢失的数据是在哪个界面产生的。打开快照对比脚本中此处的参数值与运行时实际值。如果运行时值跟录制值不同就需要在这里加关联。还有一种隐蔽情况SAP GUI脚本回放时前一个事务的窗口没有正常关闭导致后续步骤用的还是旧窗口上下文。解决办法是在事务结束时增加关闭窗口或提交确认的逻辑让脚本流程严格按“打开事务—操作—保存退出”的顺序行进。还有一个小经验录制脚本时不要打开多个SAP GUI窗口同时操作。多窗口会生成非常复杂的窗口ID切换逻辑回放时经常找不到目标窗口。业务上非要模拟多窗口的话建议录成多个独立脚本在各脚本内部处理单窗口流程。4.2 Vuser资源占用过高SAPGUI协议的通病SAPGUI协议每个Vuser都要启动一个GUI客户端实例内存和CPU占用远高于Web协议。200个Vuser跑在一台负载机上经常会发现本机CPU先打满还没压到SAP就先把压测机压死了。处置方式有几个。第一把SAP GUI的视觉效果关掉脚本里尽量避免触发桌面主题动画、高DPI缩放等操作把SAP GUI调整到“性能模式”能明显降低Vuser资源占用。第二在Controller里配置多台Load Generator把Vuser分散到多台机器。我压大规模SAP系统时一般按每台负载机不超过50个Vuser的标准分配宁可多准备几台机器也不要让负载机成为瓶颈。第三如果压测场景偏后台事务就改用RFC或HTTP协议资源占用会小很多当然前提是业务上不需要真实GUI交互。4.3 SAP端“Dialog process not available”与License告警压测跑到一半大量Vuser登录失败报“Dialog process not available”这是SAP可用的对话进程耗尽。先别急着加并发先看RZ12里分配的dialog process数量结合系统内存和CPU余量判断是否能扩容。很多SAP系统默认只有几十个dialog process真实用户在线量不大的环境里压测并发一大立刻触顶。另一种情况是License消息SAP的在线用户License有限测试账号池超过License限制后后续用户无法登录。解决方法是申请测试专用的License或在压测环境简化登录认证。我在做外部项目压测时都会提前把测试用户数、License扩展、dialog process扩容三项做成一个“压测前置检查表”Basis确认签字后才会开始压测。这个表在项目汇报时非常有用能把环境制约从你的测试能力问题中摘出来。还有一类问题涉及锁等待。压测大量更新型事务如MIGO过账、发票校验时某些物料或科目会被多个会话并发操作SM12里能看到锁请求排队。这种情况下加大Vuser并不会提升吞吐量反而会把系统拖得更慢。调整负载模型减少对同类数据的并发操作或者让业务数据更分散比单纯加资源更有效。4.4 HTTP/Fiori脚本的典型坑CSRF、Token与编码如果压测的是SAP Fiori或OData服务常见问题略有不同。OData服务对CSRF防护非常严格很多请求必须先发一个GET获取XSRF Token再在后续请求的Header中带上。脚本里必须把这个Token从响应中关联出来并且处理Token失效后的刷新逻辑否则压测中大量请求会返回401或403。Cookie管理也更敏感。SAP Gateway的会话Cookie有时效压测场景持续时间长时需要设计Cookie刷新逻辑或者让每个迭代重新认证。我用LoadRunner的Web协议跑Fiori时会把认证方式和Cookie作用域单独做一遍验证确认长时间压测不会因为Cookie过期而大面积报错。还有一个非常容易忽略的细节中文和特殊字符的URL编码。SAP的OData服务经常需要传中文搜索条件或带特殊字符的物料描述直接用录制时的值回放可能因为编码不一致导致查不到数据。压测前要把这些输入值统一做URL编码处理并在低并发下验证搜索能返回正确结果。另一个提示压Fiori时建议先确认Gateway的负载能力。很多SAP系统瓶颈不在后端ECC而在SAP Gateway/PI层。如果压测结果出来发现Gateway CPU先打满别急着扩容后端先把Gateway的线程池、内存、连接池调优再重新压一轮做对比。这类分层排查的思路能帮你在汇报时更有条理地说明瓶颈所在。说了这么多归根到底就一句经验LoadRunner压SAP功夫在脚本之外。先把业务场景想透把协议选对把关联参数化做扎实压测过程中盯住SAP后端的进程、锁、缓冲和数据库时间结果分析时按层拆解。做好了这些LoadRunner这套老牌工具在SAP压测上依然是非常能打的组合。我每次压测结束还会做一件事就是把所有脚本、参数、监控快照按日期和版本压缩归档附上一份简短的环境配置说明塞到项目文档库里。别看这一步不起眼等系统上线后出了性能问题别人拿着当时的测试报告来问你“这个数是怎么压出来的”你能五分钟内翻出全套记录那时候你就知道这习惯有多值钱了。