做性能测试这些年听得最多的抱怨就是LoadRunner装起来麻烦用起来更麻烦。作为商业性能测试工具LoadRunner在大型系统压测、协议模拟、结果报告这些方面依然能打但它的安装环境、录制回放逻辑和运行机制劝退了一大批刚入门的同学。不管是搜索loadrunner 12.63下载还是从公司资料盘里翻出老版本很多人遇到的问题根本不是你脚本写错了而是踩进了同一个坑环境不对、录制方式不对、参数处理不对。这篇文章我就把这些年自己踩过的、也在社群里反复看到别人踩的典型问题按使用阶段拆开讲一遍。真不是夸张这些问题一半以上的人都遇到过而且大部分时候锅不在技术水平。1. 装好LoadRunner的第一步环境兼容与安装激活那些坑我在给团队配置LoadRunner环境的时候发现绝大多数问题都发生在“还没开始录制”之前。比如安装包下载不完整、安装到一半回滚、装完打不开、打开了录不了。这些问题看起来千奇百怪根子其实都集中在环境兼容性这一处。1.1 安装环境兼容性先查兼容矩阵再动手很多人拿到loadrunner 12.63安装包就直接一路下一步没一会就卡在某个报错弹窗上。LR对Windows版本、浏览器内核、VC运行库、.NET Framework版本都有依赖不是说你机器能正常上网办公它就一定能装得上。以Windows系统为例12.63对Windows Server 2012/2016/2019、Windows 10的支持相对明确但如果你想在Win11上跑老版本就要有折腾的准备。我见过不止一台Win11机器装完Controller直接起不来最后用“兼容模式”设置为Windows 8才勉强能用。安装前做这几件事能让后面少掉一半麻烦以管理员身份运行安装程序别双击普通用户权限就直接装。安装前暂时关闭杀毒软件和系统防火墙。很多安全软件会把LR的临时代理进程当风险程序处理导致装完某些组件缺失。安装路径不要出现中文和空格。项目组一堆人脚本目录叫“E:\性能测试\登录脚本”后面编译失败、参数文件找不到全是这个原因。安装组件不一定要全选。单机调试只需要VuGen、Controller、Analysis、Load Generator。SiteScope、TruClient浏览器组件这些如果没明确要用建议不装省空间也少冲突。关于loadrunner 12.63下载我多啰嗦一句尽量从官方页面拿安装包别用第三方站的“高速下载”。老版本安装包在Win10/11上的兼容性问题已经够多了第三方打包还可能夹带额外组件。下载完先校验一下文件大小和哈希值装到一半报错的情况相当一部分就是安装包损坏导致的。1.2 License报错的另一种可能先看系统时间新手装上LR最常遇到的弹窗除了“License security violation”就是“试用License已过期”。这里有一个很多人想不到的原因系统时间被改过。LR客户端每次启动都会比对时间戳如果系统当前时间比上次运行时间还早哪怕只是几分钟它也会判定License异常。很多公司电脑装了时间同步工具或安全管控软件偶尔会把系统时间往前拨于是第二天一开机LR就报错了。遇到这种情况先别急着找破解补丁按这个顺序处理把系统时间恢复为当前正确时间重新同步重启LR。如果虚拟机是快照回滚过头了直接重新设定时间为最新。企业内网如果屏蔽了License验证域名需要找IT在hosts里放行或关闭网络验证。试用License到期时去官网申请试用授权或联系商务。网上流传的注册机、破解补丁我不建议碰既不稳定也可能带来安全问题。还有个小细节如果你在Help About里看到Vuser数量上限是1000而场景里填了5000那么跑到100个左右就会开始报“No more licenses available”。这不是软件坏了是容量不够。1.3 打不开、闪退、白屏的排查顺序安装成功之后VuGen白屏或闪退也是高频问题。我习惯按这个顺序查远程桌面会话里跑VuGen偶发白屏或UI异常。这个和显卡驱动有关系断开重连或切到本机控制台会话往往就好。右键vugen.exe属性 兼容性 兼容模式选Windows 8或Windows 7。很多12.53/12.60/12.63在Win10/11上的闪退都能这样解决。始终以管理员身份运行。LR安装后默认进程权限可能不够Agent写不了临时目录录制按钮就是点不动。杀毒软件隔离。把LR整个安装目录加入白名单否则录制时创建的临时代理经常被拦。C:\Users\用户名\AppData\Local\Temp目录不可写时编译脚本也会报错。给当前用户加写入权限一般就好了。我还习惯在装完LR后用自带示例跑一遍最简单的Web脚本确认录制和回放链路都通再开始真实项目。省得环境问题混进业务脚本里排查起来两头为难。2. 录制不上的时候先别怀疑脚本查这四件事终于装好环境打开VuGen准备录制结果点Record按钮后网站完全没有反应或者录出来的Action里只有一个空空的vuser_init。这种情况我见过太多。洛一下基本都是下面四类原因。2.1 浏览器版本和代理端口LR录制原理是启动一个本地代理服务器让浏览器通过这个代理转发请求。所以任何浏览器层面绕过代理的设置都会让录制结果为空。高版本Chrome默认启用了安全DNS、QUIC等特性HTTP请求经常不走代理导致VuGen什么都抓不到。实用的解决办法是用Edge的IE模式。LR对老的Trident内核兼容性最好IE模式下录制成功率很高。在Edge设置 默认浏览器里允许IE模式重新加载然后把被测地址加进“Internet Explorer模式页面”列表。Firefox ESR版本手动设置代理为localhost:7777。检查本机7777端口是不是被Fiddler或Charles占用了。如果占用就去LR录制选项里换一个端口。录HTTPS站点时第一次会弹证书安装提示一定要装到“受信任的根证书颁发机构”。没弹窗的话检查Internet选项 高级取消勾选“检查服务器证书吊销”。2.2 协议选错一半的人栽在这里很多新人录制Web系统时习惯性选择Web Services或TruClient。Web Services协议会把HTTP请求包装成SOAP风格脚本里一堆XML回放还老容易出错TruClient是行为级模拟录制慢、脚本量大对负载机资源要求也高不适合大型并发压测。对绝大多数Web页面和APP接口直接选Web - HTTP/HTML就够了。按F12打开浏览器开发者工具看请求头里有“Content-Type: application/json”或普通HTML这就是标准HTTP请求用Web - HTTP/HTML协议没问题。只有确定后端是基于SOAP的WebService才需要选Web Services协议。TruClient则更适合前端交互极复杂的场景比如拖拽、Canvas绘图这种必须模拟用户行为的但它占资源多压大规模用户要谨慎。2.3 录制模式HTML-based还是URL-based录制选项里有个经典选择Use HTML-based script还是Use URL-based script。默认的HTML-based模式会把请求按页面对象拆分脚本可读性好适合传统同步页面。但遇到大量AJAX异步请求时浏览器内部的行为可能被合并部分XHR请求会被漏掉回放时接口链路就不完整。接口级压测我建议直接用URL-based模式。每个请求都会以web_url或web_custom_request出现回放更贴近客户端真实行为。缺点是脚本很啰嗦。页面级压测HTML-based够用但回放后要检查日志里是不是完整发出了所有XHR请求。2.4 中文乱码和参数文件编码录制完的脚本里中文参数显示成一堆“锟斤拷”或\uXXXX转义看着头大。处理方式在Tools Recording Options Advanced里找到Support Charset勾选UTF-8。如果脚本里存在混合编码用lr_convert_string_encoding函数转换比如从gb2312转到utf-8。参数化数据文件如果是CSV不要直接用Excel另存为CSV那个默认是ANSI编码。正确做法是用记事本另存为UTF-8 with BOM或者用VS Code另存为UTF-8。这些不是大问题但堆在一起足够让你在录制阶段耗上一整天。3. 回放能跑通不等于脚本没问题关联、参数化、超时是三大拦路虎脚本回放成功很多人就放心了但这只是开始。回放成功不意味着压测结果有意义。真正的问题藏在动态参数、数据分配和超时设置里。3.1 为什么自动关联经常救不了你回放时最常见的报错就是登录失败或者某个接口返回404/500。这通常是服务端返回了动态参数比如session id、csrf token、带时间戳的签名。录制时脚本里写死的是旧值回放时服务器一看就拒绝。LoadRunner有自动关联功能但它的前提是录制和回放都成功。换句话说如果录制时本身就有部分请求失败自动关联根本扫不出变化值。更麻烦的是很多服务端token做了加密比如时间戳用户ID拼起来再做MD5自动关联识别不了这种“不直观”的变化。我的固定做法是手写web_reg_save_param步骤很机械用两个不同账号录制两份相同流程的脚本。对比两份脚本里的请求URL、Cookie和响应体找出变化的位置。可以用Beyond Compare也可以用LR自带的Tools Compare with。确认动态值出现在请求的哪一层URL、请求体、请求头还是响应里的Set-Cookie。在该动态值出现之前插入web_reg_save_param并设置左右边界。比如token出现在响应头里 web_reg_save_param(token,LBtoken,RB;,SearchAll,LAST);回放日志里查看“Save Parameter token xxx”确认捕获成功。这个函数有三个常见的坑。第一左右边界必须逐字符确认引号、空格、换行符都不能马虎。第二动态值如果出现多次要用SearchAll抓成数组再按下标使用。第三捕获成功了但回放还是失败多半是请求里有两处需要替换的参数你只换了一个。这时候把请求做一次完整参数化会更稳。3.2 参数化数据够不够分配方式选错会压出假结果参数化看起来不难但分配方式选错压测结果基本没参考价值。LoadRunner有三种典型分配方式Sequential所有Vuser按顺序读取文件一轮读完从头再来。适合公共账号池、全局配置数据。Random随机取值。适合商品ID、活动ID这类不需要唯一性的数据。Unique保证每个Vuser取到的值都不重复。适合手机号、身份证、订单号这类必须唯一的业务数据。Unique方式最坑。当参数文件里的行数少于总迭代数时会报“Not enough records in the parameter file”。解决办法有两个一是准备足够多的数据二是在文件属性里选“Continue in a cyclic manner”让它一轮用完从头取。但如果业务要求数据必须真正唯一循环复用就会造成脏数据。还有路径问题。脚本在VuGen里调得好好的Controller一跑就报文件找不到通常是参数文件用了绝对路径。本机D盘路径在压力机上当然不存在。建议在参数属性里用相对路径并把数据文件放在脚本目录下。Controller加载脚本时参数文件默认会跟着脚本走。3.3 超时错误先分清是脚本问题还是系统瓶颈LoadRunner压测中的超时错误早就不该再当玄学处理。常见的几个如下表错误码含义常见原因Error -27796连接服务器失败服务器连接数打满、防火墙拦截、端口错误Error -27727等待响应超时接口处理太慢、接收超时参数设置过小Error -27257待处理连接过多大量请求堆积网络或服务器处理不过来Error -27798生成请求失败参数变量未定义、字符串拼接错误我的排查顺序是先用单个Vuser回放一遍。如果单用户也报错说明脚本本身超时设置不合理或者接口本身就有基础问题。这时候去Runtime Settings Preferences里调大HTTP请求连接超时和接收超时比如连接10秒、接收30秒。如果单用户正常、多用户才出现首选怀疑服务器连接数、数据库连接池或网络带宽不要急着调超时。另外要提醒一句为了压测不停顿把接收超时调到300秒甚至600秒很多时候会把“接口慢”掩盖成“压测通过”。报告发出去出了性能事故是要追责的。超时设置要贴近真实用户可以接受的响应时间而不是迁就接口实际速度。3.4 Runtime Settings这几个选项直接影响结果走向同样的脚本在VuGen里跑得好到Controller里跑出完全不同的结果八成是Runtime Settings没检查。重点看四个Number of Iterations默认只跑一遍就退出很多新人忘了改压测图里TPS只持续几秒就归零。Think TimeIgnore表示完全忽略用户思考时间请求一个接一个Replay as recorded才更像真实用户。压极限吞吐可以Ignore但报告里要注明。Simulate a new user on each iteration勾选后每次迭代都重连TCP更贴近真实用户反复访问不勾选则连接复用TPS数据会好看些。选择依据是被测系统的会话管理方式别一律照抄。Log设置调试时用Extended log没问题压测时一定要改回Standard或Disable否则每个Vuser写大量日志内存和磁盘会先爆掉。4. 压测执行阶段Vuser起不来、TPS上不去、指标看不懂场景开始后Vuser一直卡在Initializing然后变成Error这种状态最让人抓狂。但按顺序查绝大多数都能在十分钟内定位。4.1 Vuser初始化失败的排查链路Controller和Load Generator不在同一台机器时先确认压力机右下角有没有“LoadRunner Agent Process”图标。没有就手动启动这个Agent进程没起来所有Vuser都会初始化失败。接下来依次查网络端口Controller与Agent默认通信端口54345很多防火墙只放行80/443。两个机器要能互相ping通并且telnet通这个端口。名称解析压力机解析不了Controller主机名常见于跨网段。在压力机的hosts文件里写上Controller的IP和机器名。权限Agent进程要以管理员身份运行否则Vuser创建不了子进程、写不了临时目录。License容量试用License一般限制并发数填了5000跑到额度上限就全部报错。系统资源压力机内存不足会直接报“Memory allocation error”。这时候减少日志输出关闭不必要的浏览器进程。还有一个关键设置Vuser运行模式分为Process和Thread。Process模式下每个Vuser一个独立进程占资源大Thread模式下多个Vuser共用一个进程的多个线程同样配置能撑更多用户数。预算有限的公司压力机往往不宽裕用Thread模式能省不少开销。但Thread模式下脚本要线程安全尽量别用全局变量和共享文件句柄。4.2 集合点不是越多越好负载模型要贴合业务LoadRunner的集合点可以让所有Vuser在同一时刻发起请求非常适合秒杀、抢票、整点签到这类瞬间并发场景。但在常规业务压测里把每个事务都加集合点等于人为制造一个巨大的尖峰。500个用户同时释放集合点服务器瞬间收到500个请求大量超时和500错误就出来了。这种结果能说明系统在极端浪涌下扛不住但没有办法反映日常运行水平。我的经验是集合点只加到真正需要模拟“瞬间爆发”的事务上其他事务用阶梯式Ramp Up。Ramp Up设置为0也不是好习惯一开始就是满负载容易出现假性失败。压测时间至少要跑10到15分钟看稳定性和资源趋势而不是只跑1分钟就下结论。4.3 报告别只盯平均值90%响应时间才有参考价值Analysis报告打开后大家习惯先看“Average Response Time”这是最大的误区。平均值最容易掩盖长尾问题100个事务里99个0.5秒1个20秒平均值只有0.695秒看起来很好看但真实用户可能遇到的就是20秒的卡顿。LoadRunner默认报告里就有90th Percentile和Standard Deviation一定要以90%响应时间、最大响应时间、错误率作为核心参考。TPS和吞吐量也要一起看。如果TPS没涨吞吐量却翻倍了很大概率是某个请求返回了大体积数据比如图片、报表文件而不是业务能力提升。压测结束后把事务响应时间图、运行Vuser数图、CPU利用率图放到同一张时间轴上对比。CPU到80%后响应时间开始明显上涨那个拐点就是系统的软极限。4.4 资源监控别只装一个计数器很多人在Controller里只加一个Windows Resources监控然后发现压力机CPU 100%被测服务器CPU只有30%就以为被测系统没问题。这个结论不成立因为默认计数器监控的是本机不是你的应用服务器。建议每个项目提前确认应用服务器、数据库服务器、中间件、缓存组件分别开启对应的性能监控或者在脚本里通过lr_user_data_point采集关键指标。监控项至少覆盖CPU总占用、CPU队列长度、可用内存、磁盘队列、网络吞吐、数据库连接数。5. 除了排雷也聊聊什么时候可以不硬扛LoadRunner写到这里总有人问这些坑这么多能不能不用LoadRunner我的回答是可以但要分场景。LoadRunner最厉害的地方在于企业级方案、大量协议支持、自动化报告以及和ALM这些平台的联动这也是很多企业指定性能测试工具必须用LR的原因。但如果是敏捷团队接口经常变每次都用LR录制脚本成本确实高。尤其是WebSocket长连接、gRPC、Dubbo这些较新的协议LR版本支持并不及时。我自己带团队就定了三条规矩接口级快速验证用轻量工具写脚本不启动LR这么重的环境。正式验收、全链路压测、要出报告的场合用LoadRunner它的图表自动生成能力能让汇报轻松很多。遇到特殊协议先查LR版本支持矩阵不支持就选别的工具不要硬录。这个思路同样适用于搜索loadrunner 12.63下载的新手。如果你只是自己学习压测用社区的试用版在新虚拟机里跑就行不要为了“永久版”去折腾注册机。版本选新不选旧优先用当前官方版录制和回放的成功率会高很多。5.1 脚本从A机器搬到B机器之前先写一份环境说明这是我觉得最值得分享的经验。LR脚本迁移的问题比想象中多参数文件路径、证书、hosts配置、录制的协议版本、浏览器版本全都要记录。我之前帮别的团队排查过一个脚本本机回放通过压测机一跑就报错查了两个小时最后发现关联函数的边界值用的是录制机返回值里的换行符本机日志能匹配压测机因为字符集不同没匹配上。这就是环境差异导致的典型问题。现在我会在脚本目录放一个“环境说明.txt”模板大致是这样脚本名称、录制环境IP/浏览器版本、协议版本、依赖证书、参数文件及编码、预置数据要求、超时设置、是否模拟新用户、特殊关联说明。半年后再捡起这个脚本或者换一个人接手都不会懵。5.2 为什么这些问题“一半的人都遇到过”说到底LoadRunner的难点不在功能操作而在于“环境态”和“运行态”的变量太多。操作步骤是固定的但每个人电脑里的浏览器版本、中文路径、系统时间、防火墙策略都不一样。同一版本在不同机器上表现出两种行为一点都不奇怪。所以遇到问题先不要怀疑自己水平按“环境-协议-脚本-场景-数据”的顺序排查比自己闷头改脚本高效得多。最后再分享一个小技巧调试脚本时把Runtime Settings里的Log选成Extended log并勾选Parameter substitution和Data returned by server回放一次就能在日志里看到每个参数被替换成了什么值、服务器返回了什么内容。定位问题能快一倍。等脚本稳定后记得把日志切回Standard否则场景一跑起来成百上千个Vuser同时写日志磁盘会先于被测系统崩溃。这一条帮我少加过好几次班。