企业官网建设流程全解析

做了这么多年SAP性能测试，我最大的感受是：SAP系统不是不能压，而是很多人一上来就选错了工具和协议。项目标题里写的“使用LoadRunner工具对SAP进行压测”，看着简单，实际上从脚本录制、关联、参数化到后端监控，每一步都有坑。这篇文章我把我实际踩过的路、趟过的雷都写出来，从协议选型到场景设计，从脚本开发到问题排查，一条线讲清楚，希望能帮到正在做SAP压测或者准备做SAP压测的朋友。

1. 为什么SAP压测这么折磨人，又为什么选LoadRunner

1.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压测上依然是非常能打的组合。我每次压测结束还会做一件事，就是把所有脚本、参数、监控快照按日期和版本压缩归档，附上一份简短的环境配置说明，塞到项目文档库里。别看这一步不起眼，等系统上线后出了性能问题，别人拿着当时的测试报告来问你“这个数是怎么压出来的”，你能五分钟内翻出全套记录，那时候你就知道这习惯有多值钱了。