我们组有一套跑了六年多的LoadRunner脚本库，覆盖三条主链路，加起来两百多个事务。去年做信创改造，应用从x86搬到鲲鹏加银河麒麟，中间件换成国产的，数据库也动了。压测环节一开始没人当回事——脚本在、压测机在、流程跑了六年，觉得再跑一遍就是了。

第一轮就卡住了。压测机装不上，Controller起不来；后来借了一台旧机器凑合跑，TPS比改造前掉了一截。会上有人问了一句：这个数字是应用真的变慢了，还是施压端自己先撑不住？

没人答上来。那次会后我们才开始认真看国产替代方案，泽众PR是其中看得比较细的一个。这篇文章是我把这段时间的判断整理出来的结果。结论先放在这里：换工具这件事，难点从来不在"换哪个软件"，而在脚本资产、指标口径、团队习惯这三样东西能不能跟着一起过去。

一、先算三笔账：要不要换，不该由口号决定

很多国产化替代的讨论停在"自主可控"四个字上。真要立项，这三笔账得分开算，因为它们的性质完全不同。

第一笔是许可账。 LoadRunner按虚拟用户数和协议类型做年度授权，据公开信息，一套覆盖常见协议的正式授权通常在每年十几万元这个量级，扩容要另外买。这个数对大型企业不算什么，但对只有几十个测试人员的团队，意味着每次大促前想多压一万并发，都得先走一遍采购流程。

第二笔是环境账。 这一笔在信创项目里往往比许可更硬。压测工具的价值取决于它能不能在被测系统所在的环境里跑起来。LoadRunner的主控端以Windows为主，Load Generator虽然有Linux版本，但在国产CPU加国产操作系统的机器上，整条部署链会变得很别扭——依赖库、图形界面、证书、监控代理，每一项都可能卡一下。

第三笔是协同账。 这笔最少被算，但最影响日常。压测不是测试组一个人的事：开发要看慢事务的调用链，运维要看连接池和GC，DBA要看慢SQL，业务方要确认链路权重配得对不对。工具如果只把图表给测试看，其他人每次都得截图转发，一个问题定位下来能拖掉半天。

三笔账算完，结论通常不是"必须换"，而是"在哪些环节上换是划算的"。这三笔里，环境账和协同账是可验证的硬约束，许可账更像是谈判筹码。

二、把替代拆成三层，别当成一次卸载重装

我见过几次失败的工具替换，原因出奇地一致：第一层就买了，后两层没人管。

层	要回答的问题	判断依据	该交出的东西
工具能力层	压不压得动、看不看得懂	协议覆盖、施压模型、监控粒度	一份能力对照结论
脚本资产层	已有的东西是资产还是负债	脚本语言、可导入格式、重写工时	一张脚本分级表
流程与组织层	换完之后数字还可不可信	指标口径、报告对象、回归机制	一张偏差对照表

三层的顺序不能颠倒。能力层决定"能不能做"，资产层决定"要花多少成本做"，流程层决定"做完之后这个结论有没有人信"。跳过第二层，项目会在第三个月突然发现没人愿意重写那两百个脚本；跳过第三层，新工具跑出来的数字和老工具对不上，评审会上会被质疑到不敢用。

下面按这三层展开，中间穿插泽众PR的具体做法。

三、第一层：泽众PR在工具能力层落的位置

先说清楚"全链路"这三个字在压测里的含义。它指的不是把所有接口都压一遍，而是从入口请求到后端服务的整条业务路径：一个下单动作会依次打到网关、订单、库存、支付，压力要按这条路径上的真实比例铺开。单接口的TPS加起来不等于链路能力，这也是很多团队压测报告好看、真到大促还是出问题的原因。

泽众PR（PerformanceRunner）是国内做测试工具比较早的一支产品线，公开的版本线索能看出它的演进节奏：2009年初版，2012年单机版，2017年推出泽众POne，2021年适配统信UOS与银河麒麟，2023年支持导入JMX与Postman session，2026年6月版本到V4.0.0.8，软件著作权登记号2021SR0658448。这条时间线里有两个节点需要留意：2021年的国产操作系统适配，和2023年的脚本导入——前者对应环境账，后者对应资产账。

它和LoadRunner的相近之处在设计模型上。从脚本到场景，到执行，到监控，到分析，这套五段式是相通的；脚本里有事务、检查点、参数化、集合点这些概念，做压力测试的人换过来，术语不用重学。这个"不用重学"的价值被很多人低估了——工具替换的隐性成本，一大半花在团队重新建立肌肉记忆上。

差异在部署形态。泽众PR的主控端可以装在Windows上，施压端支持Windows和Linux，压力机可以是物理机、虚拟机，也可以是多台机器组成的集群。厂商公开资料给的规模是单机5000并发、集群10万级虚拟用户。这个数字当量级看就行，实际规模取决于压测机配置、参数化数据量和被测系统本身的响应速度，别拿它去和别的产品的宣传数字直接比。

协议方面，HTTP/HTTPS、Socket、MQ、数据库这几类是常备的，国产中间件方向也有对应适配。这里有个提醒：协议清单不要看它列了多少条，要拿你近一个月的接口清单按协议归类，去对一遍。在用的那几类在不在里面，才是真问题。

监控这块是我个人比较看重的。泽众PR把压测指标和服务端资源指标放在同一条时间轴上：一边是TPS、响应时间、错误率，一边是CPU、内存、磁盘IO、网络，加上数据库侧的连接数、慢查询、缓存命中率。定位问题的路径会短一些——先看性能拐点出现在哪个时刻，再看那个时刻哪条资源曲线先顶到天花板，最后回到事务明细里找是哪个请求在拖。

四、第二层：一份脚本能不能跟着人一起过去

这是替代里最容易被低估的部分，也是最容易在立项时被写成"工作量待评估"然后一直待下去的部分。

LoadRunner的脚本是C语言写的，用VuGen录制之后要处理关联、参数化，很多人在这上面攒了几年经验。泽众PR的脚本是Java/BeanShell。这两者不是一回事，公开资料里也没有"直接读取LoadRunner脚本文件"这种说法，我不建议任何人按这个预期去做计划。

能过去的是思路和数据，不是文件本身。泽众PR支持的导入路径是JMeter的JMX、Postman session、Fiddler抓包和pcap。翻译一下这件事的实际含义：

• 团队里已经有一部分接口在JMeter上跑，那部分资产通常可以直接接过来，这部分是纯收益；

• 有抓包记录或者接口文档的，可以据此重建请求，重写的是编排而不是协议细节；

• 纯LoadRunner的C脚本，常规做法是把业务逻辑、参数化规则、事务边界整理成一份说明，在新工具里重写一遍。

重写的成本取决于脚本复杂度，差别很大。只做表单提交的HTTP脚本，一两个小时左右能落地；带加解密、带动态令牌、带文件上传下载、带状态依赖的脚本，就要按天算。所以我建议第一件事是把脚本库按复杂度分三档——纯HTTP的、带状态依赖的、带自定义协议的——先迁第一档，用跑通的结果去说服团队，而不是先开一场会讨论要不要迁。

已经积累的测试数据、参数化文件、业务链路模型，这些是可以复用的，未必要从零重写。具体能复用到什么程度，和既有脚本的复杂度、所用协议相关，建议先挑两三个脚本做小范围验证，再决定整体节奏。

五、第三层：指标口径，迁移里最容易埋雷的地方

这一段我想多说几句，因为它决定了换完之后你还能不能相信自己的数据。

同一套业务场景，在LoadRunner和泽众PR上各跑一轮，TPS和平均响应时间不会完全相同，这是正常现象。原因至少有四个：

1. 施压模型不同。 虚拟用户是线程模型还是进程模型、一个用户跑几次迭代、思考时间怎么分布，这些参数的默认值本来就不一样。

1. 计时口径不同。 响应时间是从发出请求算到收到第一个字节，还是算到响应体接收完，在下载类接口上差几十毫秒很正常。

1. 施压端自身开销不同。 脚本引擎效率、日志级别、是否开启详细记录，都会吃掉压测机的资源。

1. 采样粒度不同。 采样间隔是1秒还是5秒，峰值会被不同程度地平滑掉。

所以迁移之后的第一件事不是看新工具的数字"好不好看"，而是拿一个已知场景，把两边的数字对齐。

有个可以参考的公开数据：某次对比中，1800并发下两套工具的结果偏差在±5%以内，HTTP响应时间相差48毫秒，TPS相差18笔/秒。这个量级的偏差在性能测试里属于可接受范围，但前提是两边的事务边界、思考时间、加压曲线设置一致。数据来自公开对比资料，实际偏差与场景设计和施压机配置相关，仅供参考。

具体怎么对齐？我的做法是固定一个基准场景（比如登录加查询，不带复杂业务），同一套被测环境、同一批参数化数据、同一条加压曲线，两边各跑三轮取稳定段均值，把偏差记成一张对照表。这张表以后每次换版本、换施压机、换环境，都能拿来校准。它是整个迁移项目里最不起眼、也最值钱的一份文档。

六、四步走：一条能落地的路线

常见的迁移方案写成"评估—试点—推广"三段，方向没错，做起来容易变成"评估完了没下文"。我把它拆成四个有明确交付物的动作：

第一步，资产盘点，交出脚本分级表。 按协议、复杂度、业务重要性三个维度给现有脚本打标，分成"必须迁""可以缓""直接废弃"三类。这一步交出的是一张表，不是一份结论。

第二步，影子运行，交出双跑记录。 挑一条非核心但完整的链路，两套工具在同一个时间窗口、同一批数据下各压一轮。目的不是比谁的数字漂亮，是验证新工具能不能复现旧工具发现过的问题。

第三步，口径校准，交出偏差对照表。 就是上一节说的那张表。它是后面所有结论的地基，也是评审会上少数能挡住"你们是不是换了个工具把数字做漂亮了"这类质疑的东西。

第四步，纳入回归，交出流水线配置。 把压测场景做成可重复执行的任务，接进发布流程。到这一步，工具才算真的换完了；停在第三步，它只是一个新玩具。

这四步里，第三步最常被跳过，也最常在半年后返工。

七、上手前需要先确认的几件事

1. 协议在不在清单里。 国产中间件、行内自研协议，先拿最小用例验证，别等压测前一周才发现不支持。

1. 重写工时怎么估。 按脚本分级表算，不要按"一天能迁几个"拍脑袋。带状态的脚本，一个可能要花掉两天。

1. 施压机从哪来。 集群压测要机器，虚拟化环境和物理机的表现不一样，压测机的网络带宽要单独核，别让施压端先成为瓶颈。

1. 授权怎么算。 泽众PR的标准协议包在50虚拟并发以下为免费使用档，超出部分或其他协议包按商业授权计，具体以官方最新说明为准。这句话的实际含义是：小规模验证可以先跑起来，正式压测前要把授权额度谈清楚。

1. 装上不等于会用。 工具解决的是"能压"，场景怎么设计、瓶颈怎么判断、结论怎么写给业务看，还是人的事。

八、落回具体工具：泽众PR减少的是哪几项工作

前面几节讲的是方法，这一节把它落回具体工具上。沿着这条路走一遍，泽众PR实际减少的是下面这几项工作量：

• 多类协议共用一套场景模型。 HTTP/HTTPS、Socket、MQ、数据库这几类脚本，用的是同一套事务、检查点、参数化定义。协议不同不影响场景怎么编排，压测方案不用按协议重写多份。

• 施压端能落在国产环境里。 2021年就做了统信UOS与银河麒麟的适配，信创改造时压测环境可以跟着被测系统一起搬，不必在国产化之外再单独维护一套Windows压测机。

• 脚本资产有四个现成的入口。 JMX、Postman session、Fiddler抓包、pcap，团队里已有的这部分接口资产通常可以接过来，需要重写的范围被压缩到"纯C脚本"这一类。

• 指标和资源挂在同一条时间轴上。 定位问题时不用在压测报告、监控平台、数据库报表之间对时间戳，开发、运维、DBA看的是同一个画面。

这几项收益的大小随项目复杂度、脚本存量和环境差异变化，不是一个固定值。把它当成"能省掉多少工作量"的清单看，比当成功能表看更接近实际。

九、哪些团队可以先拿它跑一轮

• 正在做信创改造，压测环境要跟着搬到国产CPU和国产操作系统上的团队——环境账这一项收益最直接。

• 脚本资产以HTTP/HTTPS为主，或者已经在用JMeter、Postman，迁移成本相对可控的团队。

• 压测结果需要开发、运维、DBA坐在一起看的团队，指标落在同一条时间轴上的价值会很快显现。

• 想把压测从"大促前的一次运动"变成"每次发布的一个环节"的团队，回归机制这一块越早搭越省事。

反过来说，如果脚本库全是C写的复杂协议脚本，短期内也没有信创要求，那把现有工具用透，比换一套新的更划算。

至于怎么开始，我的建议是别一上来做全量评估。挑一条链路，把脚本迁过去，两套工具各跑一轮，拿到那张偏差表。这张表出来之后，换不换就不再是一个需要开会争论的问题了。

---

注：文中产品参数与版本信息来自厂商公开资料及公开对比数据，实际表现与压测机配置、脚本复杂度、被测系统响应相关，仅供参考，以官方最新说明为准。文中提及的LoadRunner、JMeter等第三方名称与商标归其权利人所有。