Load Runner关联完成的SAP脚本转JMeter的可行性与关联复用问题咨询

无LoadRunner企业版预算时，直接落地JMeter做SAP压测的可行性 #

• 技术路径完全跑通，没有绕不过的硬障碍：
  • 针对SAP本地GUI客户端的交互场景，可搭配开源的SAP专用采样器插件完成操作模拟，不需要购买商业授权
  • 针对SAP Fiori、Web版SAP的访问场景，JMeter本身的HTTP请求模块、会话保持组件可以完整覆盖核心业务流的交互逻辑，同等并发下的资源开销和LoadRunner偏差很小，完全满足常规性能测试的指标采集需求
• 成本完全适配无商业工具预算的现状：所有用到的组件、插件均为开源免费版本，不需要承担License采购、年度技术服务费等支出，对单集群承载千级并发、万级请求的常规测试规模完全够用
• 需要注意的边界：如果测试场景涉及高度定制化的SAP RFC接口调用、需要对接SAP官方原生性能监控埋点，需要用JMeter的Java请求组件做少量二次开发，不存在完全落地不了的问题

LoadRunner已关联脚本转JMX格式过程中的关联逻辑迁移规则 #

• 两类工具没有自动继承关联逻辑的通用能力：LoadRunner和JMeter的脚本存储结构、关联规则的定义逻辑完全不互通，没有跨工具的自动解析适配机制，不存在转换后关联配置自动迁移的效果
• 实际迁移的工作量拆分：
  • 已在LR里梳理清楚的关联点不需要重新排查：前期在LR脚本中定位好的动态参数（比如会话Cookie、临时业务Token、SAP交易生成的临时单据号）的提取规则、传递路径，可以直接平移到JMeter的正则表达式提取器、JSON提取器、边界提取器组件中，能省去80%以上抓包定位动态参数的重复工作
  • 关联配置需要在JMeter环境下重新校验：LR里设置的关联规则作用域、参数引用范围不能直接跨工具复用，需要在JMeter的请求链路中重新调整作用域、匹配规则的边界，避免出现参数提取失败、值传递错位的问题
  • 完全不需要做全量关联重做：只要前期LR脚本的关联逻辑是经过回放验证、能跑通完整业务流的，转换阶段只需要把现有规则做格式迁移，不需要从零开始重新定位所有动态参数

内容的提问来源于stack exchange，提问作者user1969295