简介LoadRunner 11.00中文版是一款经典的企业级性能测试工具主要面向软件测试工程师、性能测试初学者以及需要开展并发压测的项目团队。它通过模拟真实用户行为结合负载控制、并发调度与实时监控帮助定位系统瓶颈是性能测试领域常用的解决方案之一。压缩包内共43个文件以bmp界面图片、xml报告模板、exe安装与汉化程序为主另附install.pdf安装说明、Readme.txt使用说明等整体大小121.6MB。其中4个exe对应Analysis、Virtual User Generator及汉化包等组件xml模板可自定义测试报告格式bmp图片用于安装界面与授权引导。资源已获得299人关注适合希望快速搭建中文版LoadRunner环境、熟悉性能测试流程的读者尤其是需要规避英文界面门槛的入门用户。1. 为什么性能测试圈到现在还有人坚持 LoadRunner 11.00先交代个背景。我在性能测试这块摸爬滚打了十年出头从 LoadRunner 8.0 一路用到 2023中间接触过 JMeter、Gatling、k6甚至自己写过压测脚本。但每次有同事问“有没有顺手的老工具推荐”我第一反应还是 LoadRunner 11.00 中文版。有人会说2024 年了还提 11.00这不古董吗我不否认它是老版本但性能测试圈对“老版本”的容忍度远高于开发圈。原因很现实很多企业的性能测试资产——脚本、场景、基线数据——都是基于 LoadRunner 11.00 积累的。尤其是银行、保险、政务这类行业系统迭代慢验收标准还挂在 LR 11 的压测报告模板上。你拿新版本跑出来的报告客户审计那边可能不认。另外LoadRunner 11.00 对 Windows Server 2008、IE8 这种旧环境兼容性极好而这些旧环境恰恰是不少核心系统的真实运行环境。说到“中文版”这里有个很实际的痛点LoadRunner 的官方文档和界面默认是英文的对于刚入行的测试工程师来说英文界面带来的门槛比工具本身还高。中文版缓解了这个问题尤其是录制选项、运行时设置、Analysis 报告这些高频模块中文界面上手要快得多。这篇文章不是教你背诵菜单而是想讲清楚一件事拿到 LoadRunner_11.00 中文版压缩包之后怎么把它变成一套能真正跑起来、能出报告、能在线上排障时用上的性能测试工具。我会结合自己这些年的实际项目把安装、脚本、场景、分析这条链路走一遍并且把那些“文档上不会写、踩了才知道”的坑一并倒出来。如果你是刚转岗做性能测试的 QA或者被领导点名“搞一下系统压测”的开发这篇文章应该能帮你少走至少两周弯路。2. 从压缩包到可用环境中文版安装的完整脉络2.1 解压前的三个检查项标题里的文件是LoadRunner_11.00中文版.zip拿到压缩包后别急着解压双击 setup。我先说三个检查项都是当年踩过的坑。第一确认压缩包完整性。LR 11 完整安装包大约 1.5~2GB压缩包如果不到 1GB大概率是残缺版本安装到一半会报“无法找到文件”或者直接闪退。在 Windows 下可以用右键属性查看大小也可以用压缩软件自带的“测试压缩文件”功能检查 CRC。第二杀毒软件隔离名单。LoadRunner 11.00 安装包里包含多个进程注入工具和 agent 服务部分杀毒软件会把bin目录下的thpcoin.dll、drv相关驱动误报为风险文件。安装前建议把整个安装目录加入白名单或者临时退出杀毒软件。否则安装到中间突然被隔离后面清理起来非常麻烦。第三安装路径不要带中文字符和空格。这一点老生常谈但我真的见过同事把 LR 装在D:\性能测试工具\LoadRunner下结果 VuGen 的脚本编译一开就报cannot open include file web_api.h折腾半天才发现是路径编码问题。LoadRunner 11 对 Unicode 路径的支持非常差老老实实装在C:\LoadRunner或者D:\LR11这类纯英文路径下。2.2 安装顺序与许可证配置解压完成后进入安装目录按顺序装三个组件LoadRunner 完整安装程序→LoadRunner 中文补丁包→LoadRunner 分析工具。这里有一个细节先装英文原版再打中文补丁最后再装 Analysis。很多人图省事直接装中文版结果 Analysis 图表模块是英文界面VTSVirtual Table Server组件缺失后续做参数化数据文件时少了一个入口。安装过程中会提示输入许可证。LR 11.00 的许可证分两种一个是global类型支持基础协议另一个是web类型支持 Web - HTTP/HTML、Web Services 等 Web 协议。日常压测 Web 系统的话用 Web 类型就够了golb-xxxxxxx这类密钥网上很多但注意不要用那种“破解版”的注册机容易引入风险程序。正版授权可以联系厂商申请试用我记得官方会提供一个 30 天全功能试用码足够跑完一个完整项目了。装完以后打开 Controller确认左下角显示许可证剩余天数并且协议列表里有Web - HTTP/HTML就说明基本环境可用了。2.3 中文版特有的目录结构与关键文件安装完成后LoadRunner 11 的根目录结构里有几个关键位置需要熟悉bin可执行文件目录wlrun.exe是 Controller 主程序vugen.exe是 VuGen 脚本编辑器。templates场景模板目录里面存着系统预置的场景模型新建场景时可以选。analysisAnalysis 模板目录出报告之前可以在这里自定义图表模板。dat协议定义和配置信息目录protocols.dat文件记录了当前可用的协议列表。中文版和英文版最大的不同不只是界面语言而是dat目录下的语言包文件。如果你在录制脚本时发现录制选项里没有“URL Based Script”或者中文界面下部分下拉框是空白的多半是语言包文件没有正确加载。我建议把dat目录下的language.txt文件打开确认一下里面应该包含chinese_simplified 1的配置项。如果没有手动加上再重启 VuGen。3. 录制脚本到业务线程的完整链路VuGen 的每一步都别跳3.1 用 HTML 还是 URL 录制模式这个选择影响后续维护成本很多新手第一次打开 VuGen录制一个登录流程回放能过就觉得万事大吉。但脚本上线跑两天就会发现并发一上来登录接口频繁报 500业务数据校验失败。这时候回头排查往往是录制模式选错了。LoadRunner 11 的 VuGen 提供两种录制模式HTML - Advanced基于 HTML 的高级模式录制的是用户操作层面的业务动作比如“点击登录按钮”、“填写用户名密码”。回放时 Vugen 会自己生成完整的 HTTP 请求。缺点是对 Ajax、iframe 这类动态页面兼容性差生成的脚本里会夹杂大量web_reg_find之类的注册函数。URL - Based基于 URL 的模式录制的是浏览器发出的每一个 HTTP 请求回放时严格按 URL、请求头、请求体逐条发送。这种模式更接近真实报文适合接口级压测也更容易排查问题。我的建议是如果你的被测系统是简单同步请求比如老式的 JSP、ASP.NET Web Forms用 HTML 模式可以快速出脚本如果系统是前后端分离、接口有大量异步调用或者要进行精细化的请求级监控直接选 URL 模式别犹豫。工具里切换到 URL 模式的位置菜单栏工具→录制选项→Recording Mode改成URL Based Script。3.2 录制时要不要记录 think time我的答案是“别一次录满”热词里有“loadrunner 录制时记录thinktime”这个点值得说道说道。think time 是用户操作之间的思考停顿时间LoadRunner 默认会在回放时“模拟”这段停顿。但压测场景里思考时间的设置直接影响 TPS每秒事务数。如果你要测的是系统最大吞吐量建议录制时不勾选记录 think time或者在运行时设置里把 think time 设置为“忽略”。如果你要测的是真实用户并发体验比如电商大促时的真实链路那可以按比例保留一部分 think time比如 50%。具体设置路径录制选项 →Recording→Think Time取消勾选“记录思考时间”。运行时设置里回放→Think Time选择“忽略”。我在某个电商项目里压测下单接口时第一次用了完整思考时间TPS 只有 1200去掉思考时间后TPS 直接冲到 4800。两种场景各有意义但很多人把思考时间当成“录完就完事”的默认参数导致压测结果和真实容量评估偏差巨大。3.3 关联是门手艺活自动关联和手动关联的取舍录制完脚本后VuGen 会提示有几个动态值需要关联。大多数人会直接点“自动关联”确实省事但 LR 11 的自动关联经常给你关联错地方尤其遇到 sessionid、token 这种同名字段多处出现的情况。比较可靠的做法是先回放一遍脚本打开“回放日志”搜索“Error - 27791”或者“Error - 27795”这类错误通常是某个动态值没有正确关联导致服务器返回错误。找服务端返回报文里的动态值常见的是Set-Cookie头里的 sessionid或者 JSON 响应里的token:xxxxx。在 VuGen 左侧的“关联”窗口里手动添加规则用web_reg_save_param_regexp把动态值捕获到参数里再替换掉脚本中的硬编码。举个例子某系统登录后返回一个 sessionId在登录命令之前加一行web_reg_save_param_regexp( ParamNameSessionId, LBsessionId\:\, RB\,, LAST);然后在后续请求里把所有sessionidxxx替换成sessionid{SessionId}。这样就算 session 每次变化回放也能稳定通过。这里有个小技巧录制完脚本以后先用回放的“诊断”模式跑一遍观察哪些请求的响应码是非 200 的再从这些请求入手做关联分析效率高得多。3.4 参数化别只替换数据要考虑数据分布登录脚本通常要把用户名密码参数化避免几十个并发用户都用一个账号。但参数化不是简单地“把固定值换成常量文件”就完了还要考虑数据分布方式。LR 11 的参数化支持 Sequential顺序、Random随机、Unique唯一三种取数方式。场景里 50 个并发用户跑 30 分钟如果参数表里有 100 条用户数据用 Random 模式容易出现“一个用户被多个虚拟用户使用”的情况这在有状态业务系统里可能会触发踢下线逻辑。建议用 Unique 模式并按“每次迭代取一条”来配置确保每个虚拟用户拿到的账号是唯一的。参数类型除了从文件读取还可以用“DateTime”动态生成时间戳、“Random Number”生成随机数这些在构造测试数据时很常用。我一般会把每个参数单独放在一个.dat文件里放在脚本目录的data子目录下方便管理。4. 场景搭建Controller 里的负载模型与指标观察4.1 手动场景和面向目标场景什么时候用哪个LoadRunner 11 的 Controller 里新建场景有两种方式手动场景和面向目标场景。手动场景适合你已经明确知道并发数的场景比如“我要模拟 100 个用户同时登录”。你可以自己控制加载策略——每 15 秒加 10 个用户持续 30 分钟结束后每 10 秒释放 5 个用户。面向目标场景适合你还不确定系统容量想通过自动加压来找拐点的场景。设置目标为“每分钟事务数达到 3000”LR 会自动逐步增加虚拟用户数直到达到目标或者系统崩溃。这种方式做容量评估很直观。我常用的策略是先用面向目标场景做一轮摸底找到系统的拐点大概在哪个并发范围再用手动场景细化验证拐点附近的行为。4.2 负载生成器的资源监控场景跑起来以后除了看被测系统的指标还要关注负载生成器自身的状态。LR 11 的 Controller 可以实时查看每个 Load Generator 的 CPU、内存、网络情况。我见过不止一次虚拟用户加到 500 个负载机 CPU 直接 100%瓶颈根本不在被测系统而在施压端。如果遇到这种情况解法很简单给负载机装 LR Agent 进程通过多台负载机分流。Controller 的Scenario→Load Generators里添加多台机器把虚拟用户分摊到不同负载机上。注意负载机之间的系统时间要尽量同步不然测试结果的时间戳会出现混乱。4.3 场景运行时设置里的几个硬指标在 Controller 里启动场景前建议先改几个运行时设置右键场景里的脚本 →运行时设置Log 级别日常压测设置为“仅发送出错消息”不要选“扩展日志”否则百万级请求会把日志缓冲区撑爆直接影响施压性能。Keep-Alive如果被测系统支持 HTTP Keep-Alive保持默认开启连接复用能显著降低负载机端口占用。超时时间HTTP 请求超时默认 120 秒。如果你的业务接口响应较慢比如报表类接口可以调大到 180 秒否则会出现大量“超时”误报。代理设置如果压测环境走代理出口要在运行时设置里把代理服务器地址写上否则脚本回放会直接连接被测地址场景一启动就大量 Failed。这些设置看起来琐碎但直接影响压测结果的可信度。拿“日志级别”来说我见过团队直接把 LR 默认的全日志开上去跑 500 并发跑着跑着 Controller 直接卡死最后查出来是日志阻塞了 IO纯属自找的。4.4 场景运行时的实时曲线怎么看场景跑起来以后Controller 下方会实时刷新监控曲线。别等 30 分钟跑完才去看结果实时曲线能帮你提前判断问题。重点看三条曲线Running Vusers、Transaction Response Time、Hits per Second。正常情况下用户加载阶段 Running Vusers 曲线呈阶梯上升事务响应时间应该相对平稳如果响应时间曲线在某个并发点突然抬升而且抬升后再也没有回落那基本可以确定这个并发点就是瓶颈点。我通常在运行过程中按快捷键CtrlE打开“在线监控”把 Web 服务器资源、数据库服务器资源一起挂进来这样可以快速定位瓶颈到底在 Web 端还是 DB 端。还有个小提示曲线刷新频率默认是 5 秒如果觉得反应太慢可以在“运行设置”里把刷新间隔改为 1 秒但注意这会稍微增加 Controller 的负载。5. 报告分析Analysis 里别只盯着平均响应时间5.1 核心报告页签怎么看场景跑完LR 会自动弹出 Analysis。很多人看了一眼“平均事务响应时间”觉得可以就把报告导出了。但要我说平均响应时间是最误导人的指标——1 个请求 1 毫秒 999 个请求 900 毫秒平均下来 899 毫秒看起来“一般”但真实体验已经崩了。Analysis 里要看的核心报告页签事务响应时间百分比看 90th、95th 百分位响应时间这才是真实用户体验的参考。每秒事务数看 TPS 是否平稳有没有锯齿状波动。波动大说明系统在某个时间窗口内出现资源争抢。每秒 HTTP 连接数可以观察连接复用是否正常。如果连接数远大于并发用户数说明 Keep-Alive 没生效。错误统计如果出现大量HTTP Status 500或者Connection reset by peer要优先排查服务端日志而不是继续调负载参数。我在一次压测中某页面的平均响应时间只有 600ms但 95th 百分位是 4.8 秒。最终查出来是数据库连接池在并发超过 200 时开始排队连接获取时间随线程数线性增长。光看平均值这个问题根本发现不了。5.2 关联曲线判断瓶颈层级Analysis 的左下角有一个“相关性图”区域可以把不同指标拖到 X 轴和 Y 轴做关联分析。比较常用的组合X 轴Y 轴判断逻辑并发用户数平均响应时间如果曲线接近线性上升可能是应用逻辑处理不过来如果前期平缓、后期陡升可能需要查资源耗尽型问题。每秒事务数CPU 使用率CPU 先到 100%说明计算密集如果 CPU 没饱和但 TPS 上不去可能瓶颈在锁、队列或 IO。接收字节数服务器内存内存持续攀升不回落基本可以确定有内存泄漏风险。这个关联分析手法是我在定位性能瓶颈时最依赖的工具。它能帮你从“不知道查什么”快速收敛到“查应用层还是查基础设施”。5.3 报告导出与附件整理LoadRunner 11 的 Analysis 报告可以导出为 HTML、Word、Excel 格式。导出 HTML 时默认会把图表以 PNG 图片内嵌方便直接贴到邮件里。但有一种情况要注意如果你用中文版导出的 HTML 报告里中文标题可能会出现乱码尤其是在英文操作系统的环境下。我建议导出前把系统区域语言设置为“简体中文”或者直接在 Analysis 的图表设置里把标题改成英文。如果要把报告提交给客户或者审计最好把“测试执行信息”也一起存档包括场景名称、执行时间、虚拟用户数、总请求数、失败事务数。这些信息可以在报告的“摘要”部分看到。别只发一张响应时间曲线图完整的报告才能说明压测的可信度。6. 中文版日常使用中的几个典型坑与排查思路6.1 录制 https 时证书不可信问题热词里有“loadrunner https”确实LR 11 录制 HTTPS 协议是有坑的。录制的浏览器弹出“证书不可信”会导致无法正常访问页面。排查思路是这样LR 11 自带了一个代理证书生成工具路径在bin目录下叫CertGen.exe。它会在用户文档目录下生成一个LR_Microsoft.cer证书。你要做的是关闭所有 IE 窗口。运行CertGen.exe会弹出生成成功提示。双击LR_Microsoft.cer选择“安装证书”把它装到“受信任的根证书颁发机构”。装完以后重启 VuGen再去录制 HTTPS 站点就不会弹证书错误了。注意LR 11 对 TLS 1.2 的支持有限如果被测系统强制要求 TLS 1.2 以上录制时会直接握手失败。这时候可以建议开发在测试环境临时降级 SSL 版本或者用 Wireshark 抓包和web_custom_request手工写脚本绕过录制难题。6.2 中文脚本文件乱码用中文版 VuGen 写脚本时如果脚本文件编码不是 UTF-8注释里的中文会在下次打开时变成乱码甚至导致编译报错。我习惯的做法是每次写完脚本后用文本编辑器将脚本文件另存为 UTF-8 with BOM 格式。LR 11 对 UTF-8 支持并不好加 BOM 后才能被正确识别。如果你已经因为乱码打不开脚本可以在 VuGen 的文件→打开脚本时手动选择“打开并修复”大部分情况下能挽回脚本主体逻辑但注释里的中文基本救不回来了。6.3 场景运行中途出现“Failed to copy spatial iop zip”这个报错其实不是 LoadRunner 本身的问题而是 Controller 与负载生成器通信时临时目录文件被占用导致的。热词里出现“Failed to copy spatial iop zip 与技术支持部联系”应该是某个环境在部署 LR 时遇到的兼容性问题。我遇到过一次最后排查是负载生成器安装目录下的bin\wbspat.zip文件被杀毒软件锁住了。解决方法是找到该文件右键属性 → 安全 → 确认当前用户有完全控制权限。检查杀毒软件隔离区把该文件恢复并加入白名单。重启 Controller 与 Load Generator 的 Agent 服务。如果还不行检查一下负载生成器的磁盘空间。LR 运行时会生成大量临时文件磁盘满了也会出现各种诡异的复制失败错误。6.4 脚本里用到了国密算法怎么办热词里有个“loadrunner国密”这与国产化趋势有关。如果被测系统要求使用国密 SM2/SM3/SM4 加密通信LoadRunner 11.00 自带的加密组件并不支持录制时只能看到密文报文无法直接做参数化。我的经验是分两层解决如果只是登录流程有国密加密你可以在vuser_init里调用外部 DLL例如 C 语言写的国密算法库通过lr_load_dll加载再调用加密函数生成动态密文拼接进请求。如果整个通信协议都做国密改造那就别硬用 LR 11 录制了建议用 Wireshark 抓包拿到明文请求模板结合web_custom_request手工构造脚本把加密部分交给外部算法模块处理。这种方式写出来的脚本可控性反而更高。6.5 Controller 在大量虚拟用户下卡死LR 11 是 32 位程序Controller 在管理超过 1000 个虚拟用户时内存占用会逼近 4GB 上限界面卡顿几乎是必然的。替代方案有两个一是把虚拟用户拆到多台负载机上每台不超过 300 个二是用“控制台模式”减少界面渲染压力。Controller 顶部菜单有View→Consolidated View只显示关键指标能缓解一部分卡顿。如果你压测的场景需要上万并发说实话 LR 11 这个版本已经力不从心了可以换 2023 版本或者 JMeter 分布式方案没必要在旧版本上死磕。7. 关于一些还没展开说的细节最后补两句做性能测试这些年我最大的感受是工具永远只是工具决定压测质量的是思路。LoadRunner 11.00 中文版虽然老但它把“脚本录制 - 场景设计 - 压力执行 - 报告分析”这条链路做得非常完整对新手建立性能测试方法论依然是个好选择。而且它在国内存量项目里的占有率决定了你在职场上大概率会遇到它。与其嫌弃它旧不如把它吃透。最后分享一个小习惯每次压测完我会把场景文件和 Analysis 报告以“项目名_日期_目标场景”的格式归档下次同类项目直接复用场景配置能省掉大量重复设计时间。这个习惯从 LR 11 用到现在从来没有后悔过。本文还有配套的精品资源点击获取 LoadRunner 11中文版实用指南：从脚本录制到场景压测与报告分析
简介LoadRunner 11.00中文版是一款经典的企业级性能测试工具主要面向软件测试工程师、性能测试初学者以及需要开展并发压测的项目团队。它通过模拟真实用户行为结合负载控制、并发调度与实时监控帮助定位系统瓶颈是性能测试领域常用的解决方案之一。压缩包内共43个文件以bmp界面图片、xml报告模板、exe安装与汉化程序为主另附install.pdf安装说明、Readme.txt使用说明等整体大小121.6MB。其中4个exe对应Analysis、Virtual User Generator及汉化包等组件xml模板可自定义测试报告格式bmp图片用于安装界面与授权引导。资源已获得299人关注适合希望快速搭建中文版LoadRunner环境、熟悉性能测试流程的读者尤其是需要规避英文界面门槛的入门用户。1. 为什么性能测试圈到现在还有人坚持 LoadRunner 11.00先交代个背景。我在性能测试这块摸爬滚打了十年出头从 LoadRunner 8.0 一路用到 2023中间接触过 JMeter、Gatling、k6甚至自己写过压测脚本。但每次有同事问“有没有顺手的老工具推荐”我第一反应还是 LoadRunner 11.00 中文版。有人会说2024 年了还提 11.00这不古董吗我不否认它是老版本但性能测试圈对“老版本”的容忍度远高于开发圈。原因很现实很多企业的性能测试资产——脚本、场景、基线数据——都是基于 LoadRunner 11.00 积累的。尤其是银行、保险、政务这类行业系统迭代慢验收标准还挂在 LR 11 的压测报告模板上。你拿新版本跑出来的报告客户审计那边可能不认。另外LoadRunner 11.00 对 Windows Server 2008、IE8 这种旧环境兼容性极好而这些旧环境恰恰是不少核心系统的真实运行环境。说到“中文版”这里有个很实际的痛点LoadRunner 的官方文档和界面默认是英文的对于刚入行的测试工程师来说英文界面带来的门槛比工具本身还高。中文版缓解了这个问题尤其是录制选项、运行时设置、Analysis 报告这些高频模块中文界面上手要快得多。这篇文章不是教你背诵菜单而是想讲清楚一件事拿到 LoadRunner_11.00 中文版压缩包之后怎么把它变成一套能真正跑起来、能出报告、能在线上排障时用上的性能测试工具。我会结合自己这些年的实际项目把安装、脚本、场景、分析这条链路走一遍并且把那些“文档上不会写、踩了才知道”的坑一并倒出来。如果你是刚转岗做性能测试的 QA或者被领导点名“搞一下系统压测”的开发这篇文章应该能帮你少走至少两周弯路。2. 从压缩包到可用环境中文版安装的完整脉络2.1 解压前的三个检查项标题里的文件是LoadRunner_11.00中文版.zip拿到压缩包后别急着解压双击 setup。我先说三个检查项都是当年踩过的坑。第一确认压缩包完整性。LR 11 完整安装包大约 1.5~2GB压缩包如果不到 1GB大概率是残缺版本安装到一半会报“无法找到文件”或者直接闪退。在 Windows 下可以用右键属性查看大小也可以用压缩软件自带的“测试压缩文件”功能检查 CRC。第二杀毒软件隔离名单。LoadRunner 11.00 安装包里包含多个进程注入工具和 agent 服务部分杀毒软件会把bin目录下的thpcoin.dll、drv相关驱动误报为风险文件。安装前建议把整个安装目录加入白名单或者临时退出杀毒软件。否则安装到中间突然被隔离后面清理起来非常麻烦。第三安装路径不要带中文字符和空格。这一点老生常谈但我真的见过同事把 LR 装在D:\性能测试工具\LoadRunner下结果 VuGen 的脚本编译一开就报cannot open include file web_api.h折腾半天才发现是路径编码问题。LoadRunner 11 对 Unicode 路径的支持非常差老老实实装在C:\LoadRunner或者D:\LR11这类纯英文路径下。2.2 安装顺序与许可证配置解压完成后进入安装目录按顺序装三个组件LoadRunner 完整安装程序→LoadRunner 中文补丁包→LoadRunner 分析工具。这里有一个细节先装英文原版再打中文补丁最后再装 Analysis。很多人图省事直接装中文版结果 Analysis 图表模块是英文界面VTSVirtual Table Server组件缺失后续做参数化数据文件时少了一个入口。安装过程中会提示输入许可证。LR 11.00 的许可证分两种一个是global类型支持基础协议另一个是web类型支持 Web - HTTP/HTML、Web Services 等 Web 协议。日常压测 Web 系统的话用 Web 类型就够了golb-xxxxxxx这类密钥网上很多但注意不要用那种“破解版”的注册机容易引入风险程序。正版授权可以联系厂商申请试用我记得官方会提供一个 30 天全功能试用码足够跑完一个完整项目了。装完以后打开 Controller确认左下角显示许可证剩余天数并且协议列表里有Web - HTTP/HTML就说明基本环境可用了。2.3 中文版特有的目录结构与关键文件安装完成后LoadRunner 11 的根目录结构里有几个关键位置需要熟悉bin可执行文件目录wlrun.exe是 Controller 主程序vugen.exe是 VuGen 脚本编辑器。templates场景模板目录里面存着系统预置的场景模型新建场景时可以选。analysisAnalysis 模板目录出报告之前可以在这里自定义图表模板。dat协议定义和配置信息目录protocols.dat文件记录了当前可用的协议列表。中文版和英文版最大的不同不只是界面语言而是dat目录下的语言包文件。如果你在录制脚本时发现录制选项里没有“URL Based Script”或者中文界面下部分下拉框是空白的多半是语言包文件没有正确加载。我建议把dat目录下的language.txt文件打开确认一下里面应该包含chinese_simplified 1的配置项。如果没有手动加上再重启 VuGen。3. 录制脚本到业务线程的完整链路VuGen 的每一步都别跳3.1 用 HTML 还是 URL 录制模式这个选择影响后续维护成本很多新手第一次打开 VuGen录制一个登录流程回放能过就觉得万事大吉。但脚本上线跑两天就会发现并发一上来登录接口频繁报 500业务数据校验失败。这时候回头排查往往是录制模式选错了。LoadRunner 11 的 VuGen 提供两种录制模式HTML - Advanced基于 HTML 的高级模式录制的是用户操作层面的业务动作比如“点击登录按钮”、“填写用户名密码”。回放时 Vugen 会自己生成完整的 HTTP 请求。缺点是对 Ajax、iframe 这类动态页面兼容性差生成的脚本里会夹杂大量web_reg_find之类的注册函数。URL - Based基于 URL 的模式录制的是浏览器发出的每一个 HTTP 请求回放时严格按 URL、请求头、请求体逐条发送。这种模式更接近真实报文适合接口级压测也更容易排查问题。我的建议是如果你的被测系统是简单同步请求比如老式的 JSP、ASP.NET Web Forms用 HTML 模式可以快速出脚本如果系统是前后端分离、接口有大量异步调用或者要进行精细化的请求级监控直接选 URL 模式别犹豫。工具里切换到 URL 模式的位置菜单栏工具→录制选项→Recording Mode改成URL Based Script。3.2 录制时要不要记录 think time我的答案是“别一次录满”热词里有“loadrunner 录制时记录thinktime”这个点值得说道说道。think time 是用户操作之间的思考停顿时间LoadRunner 默认会在回放时“模拟”这段停顿。但压测场景里思考时间的设置直接影响 TPS每秒事务数。如果你要测的是系统最大吞吐量建议录制时不勾选记录 think time或者在运行时设置里把 think time 设置为“忽略”。如果你要测的是真实用户并发体验比如电商大促时的真实链路那可以按比例保留一部分 think time比如 50%。具体设置路径录制选项 →Recording→Think Time取消勾选“记录思考时间”。运行时设置里回放→Think Time选择“忽略”。我在某个电商项目里压测下单接口时第一次用了完整思考时间TPS 只有 1200去掉思考时间后TPS 直接冲到 4800。两种场景各有意义但很多人把思考时间当成“录完就完事”的默认参数导致压测结果和真实容量评估偏差巨大。3.3 关联是门手艺活自动关联和手动关联的取舍录制完脚本后VuGen 会提示有几个动态值需要关联。大多数人会直接点“自动关联”确实省事但 LR 11 的自动关联经常给你关联错地方尤其遇到 sessionid、token 这种同名字段多处出现的情况。比较可靠的做法是先回放一遍脚本打开“回放日志”搜索“Error - 27791”或者“Error - 27795”这类错误通常是某个动态值没有正确关联导致服务器返回错误。找服务端返回报文里的动态值常见的是Set-Cookie头里的 sessionid或者 JSON 响应里的token:xxxxx。在 VuGen 左侧的“关联”窗口里手动添加规则用web_reg_save_param_regexp把动态值捕获到参数里再替换掉脚本中的硬编码。举个例子某系统登录后返回一个 sessionId在登录命令之前加一行web_reg_save_param_regexp( ParamNameSessionId, LBsessionId\:\, RB\,, LAST);然后在后续请求里把所有sessionidxxx替换成sessionid{SessionId}。这样就算 session 每次变化回放也能稳定通过。这里有个小技巧录制完脚本以后先用回放的“诊断”模式跑一遍观察哪些请求的响应码是非 200 的再从这些请求入手做关联分析效率高得多。3.4 参数化别只替换数据要考虑数据分布登录脚本通常要把用户名密码参数化避免几十个并发用户都用一个账号。但参数化不是简单地“把固定值换成常量文件”就完了还要考虑数据分布方式。LR 11 的参数化支持 Sequential顺序、Random随机、Unique唯一三种取数方式。场景里 50 个并发用户跑 30 分钟如果参数表里有 100 条用户数据用 Random 模式容易出现“一个用户被多个虚拟用户使用”的情况这在有状态业务系统里可能会触发踢下线逻辑。建议用 Unique 模式并按“每次迭代取一条”来配置确保每个虚拟用户拿到的账号是唯一的。参数类型除了从文件读取还可以用“DateTime”动态生成时间戳、“Random Number”生成随机数这些在构造测试数据时很常用。我一般会把每个参数单独放在一个.dat文件里放在脚本目录的data子目录下方便管理。4. 场景搭建Controller 里的负载模型与指标观察4.1 手动场景和面向目标场景什么时候用哪个LoadRunner 11 的 Controller 里新建场景有两种方式手动场景和面向目标场景。手动场景适合你已经明确知道并发数的场景比如“我要模拟 100 个用户同时登录”。你可以自己控制加载策略——每 15 秒加 10 个用户持续 30 分钟结束后每 10 秒释放 5 个用户。面向目标场景适合你还不确定系统容量想通过自动加压来找拐点的场景。设置目标为“每分钟事务数达到 3000”LR 会自动逐步增加虚拟用户数直到达到目标或者系统崩溃。这种方式做容量评估很直观。我常用的策略是先用面向目标场景做一轮摸底找到系统的拐点大概在哪个并发范围再用手动场景细化验证拐点附近的行为。4.2 负载生成器的资源监控场景跑起来以后除了看被测系统的指标还要关注负载生成器自身的状态。LR 11 的 Controller 可以实时查看每个 Load Generator 的 CPU、内存、网络情况。我见过不止一次虚拟用户加到 500 个负载机 CPU 直接 100%瓶颈根本不在被测系统而在施压端。如果遇到这种情况解法很简单给负载机装 LR Agent 进程通过多台负载机分流。Controller 的Scenario→Load Generators里添加多台机器把虚拟用户分摊到不同负载机上。注意负载机之间的系统时间要尽量同步不然测试结果的时间戳会出现混乱。4.3 场景运行时设置里的几个硬指标在 Controller 里启动场景前建议先改几个运行时设置右键场景里的脚本 →运行时设置Log 级别日常压测设置为“仅发送出错消息”不要选“扩展日志”否则百万级请求会把日志缓冲区撑爆直接影响施压性能。Keep-Alive如果被测系统支持 HTTP Keep-Alive保持默认开启连接复用能显著降低负载机端口占用。超时时间HTTP 请求超时默认 120 秒。如果你的业务接口响应较慢比如报表类接口可以调大到 180 秒否则会出现大量“超时”误报。代理设置如果压测环境走代理出口要在运行时设置里把代理服务器地址写上否则脚本回放会直接连接被测地址场景一启动就大量 Failed。这些设置看起来琐碎但直接影响压测结果的可信度。拿“日志级别”来说我见过团队直接把 LR 默认的全日志开上去跑 500 并发跑着跑着 Controller 直接卡死最后查出来是日志阻塞了 IO纯属自找的。4.4 场景运行时的实时曲线怎么看场景跑起来以后Controller 下方会实时刷新监控曲线。别等 30 分钟跑完才去看结果实时曲线能帮你提前判断问题。重点看三条曲线Running Vusers、Transaction Response Time、Hits per Second。正常情况下用户加载阶段 Running Vusers 曲线呈阶梯上升事务响应时间应该相对平稳如果响应时间曲线在某个并发点突然抬升而且抬升后再也没有回落那基本可以确定这个并发点就是瓶颈点。我通常在运行过程中按快捷键CtrlE打开“在线监控”把 Web 服务器资源、数据库服务器资源一起挂进来这样可以快速定位瓶颈到底在 Web 端还是 DB 端。还有个小提示曲线刷新频率默认是 5 秒如果觉得反应太慢可以在“运行设置”里把刷新间隔改为 1 秒但注意这会稍微增加 Controller 的负载。5. 报告分析Analysis 里别只盯着平均响应时间5.1 核心报告页签怎么看场景跑完LR 会自动弹出 Analysis。很多人看了一眼“平均事务响应时间”觉得可以就把报告导出了。但要我说平均响应时间是最误导人的指标——1 个请求 1 毫秒 999 个请求 900 毫秒平均下来 899 毫秒看起来“一般”但真实体验已经崩了。Analysis 里要看的核心报告页签事务响应时间百分比看 90th、95th 百分位响应时间这才是真实用户体验的参考。每秒事务数看 TPS 是否平稳有没有锯齿状波动。波动大说明系统在某个时间窗口内出现资源争抢。每秒 HTTP 连接数可以观察连接复用是否正常。如果连接数远大于并发用户数说明 Keep-Alive 没生效。错误统计如果出现大量HTTP Status 500或者Connection reset by peer要优先排查服务端日志而不是继续调负载参数。我在一次压测中某页面的平均响应时间只有 600ms但 95th 百分位是 4.8 秒。最终查出来是数据库连接池在并发超过 200 时开始排队连接获取时间随线程数线性增长。光看平均值这个问题根本发现不了。5.2 关联曲线判断瓶颈层级Analysis 的左下角有一个“相关性图”区域可以把不同指标拖到 X 轴和 Y 轴做关联分析。比较常用的组合X 轴Y 轴判断逻辑并发用户数平均响应时间如果曲线接近线性上升可能是应用逻辑处理不过来如果前期平缓、后期陡升可能需要查资源耗尽型问题。每秒事务数CPU 使用率CPU 先到 100%说明计算密集如果 CPU 没饱和但 TPS 上不去可能瓶颈在锁、队列或 IO。接收字节数服务器内存内存持续攀升不回落基本可以确定有内存泄漏风险。这个关联分析手法是我在定位性能瓶颈时最依赖的工具。它能帮你从“不知道查什么”快速收敛到“查应用层还是查基础设施”。5.3 报告导出与附件整理LoadRunner 11 的 Analysis 报告可以导出为 HTML、Word、Excel 格式。导出 HTML 时默认会把图表以 PNG 图片内嵌方便直接贴到邮件里。但有一种情况要注意如果你用中文版导出的 HTML 报告里中文标题可能会出现乱码尤其是在英文操作系统的环境下。我建议导出前把系统区域语言设置为“简体中文”或者直接在 Analysis 的图表设置里把标题改成英文。如果要把报告提交给客户或者审计最好把“测试执行信息”也一起存档包括场景名称、执行时间、虚拟用户数、总请求数、失败事务数。这些信息可以在报告的“摘要”部分看到。别只发一张响应时间曲线图完整的报告才能说明压测的可信度。6. 中文版日常使用中的几个典型坑与排查思路6.1 录制 https 时证书不可信问题热词里有“loadrunner https”确实LR 11 录制 HTTPS 协议是有坑的。录制的浏览器弹出“证书不可信”会导致无法正常访问页面。排查思路是这样LR 11 自带了一个代理证书生成工具路径在bin目录下叫CertGen.exe。它会在用户文档目录下生成一个LR_Microsoft.cer证书。你要做的是关闭所有 IE 窗口。运行CertGen.exe会弹出生成成功提示。双击LR_Microsoft.cer选择“安装证书”把它装到“受信任的根证书颁发机构”。装完以后重启 VuGen再去录制 HTTPS 站点就不会弹证书错误了。注意LR 11 对 TLS 1.2 的支持有限如果被测系统强制要求 TLS 1.2 以上录制时会直接握手失败。这时候可以建议开发在测试环境临时降级 SSL 版本或者用 Wireshark 抓包和web_custom_request手工写脚本绕过录制难题。6.2 中文脚本文件乱码用中文版 VuGen 写脚本时如果脚本文件编码不是 UTF-8注释里的中文会在下次打开时变成乱码甚至导致编译报错。我习惯的做法是每次写完脚本后用文本编辑器将脚本文件另存为 UTF-8 with BOM 格式。LR 11 对 UTF-8 支持并不好加 BOM 后才能被正确识别。如果你已经因为乱码打不开脚本可以在 VuGen 的文件→打开脚本时手动选择“打开并修复”大部分情况下能挽回脚本主体逻辑但注释里的中文基本救不回来了。6.3 场景运行中途出现“Failed to copy spatial iop zip”这个报错其实不是 LoadRunner 本身的问题而是 Controller 与负载生成器通信时临时目录文件被占用导致的。热词里出现“Failed to copy spatial iop zip 与技术支持部联系”应该是某个环境在部署 LR 时遇到的兼容性问题。我遇到过一次最后排查是负载生成器安装目录下的bin\wbspat.zip文件被杀毒软件锁住了。解决方法是找到该文件右键属性 → 安全 → 确认当前用户有完全控制权限。检查杀毒软件隔离区把该文件恢复并加入白名单。重启 Controller 与 Load Generator 的 Agent 服务。如果还不行检查一下负载生成器的磁盘空间。LR 运行时会生成大量临时文件磁盘满了也会出现各种诡异的复制失败错误。6.4 脚本里用到了国密算法怎么办热词里有个“loadrunner国密”这与国产化趋势有关。如果被测系统要求使用国密 SM2/SM3/SM4 加密通信LoadRunner 11.00 自带的加密组件并不支持录制时只能看到密文报文无法直接做参数化。我的经验是分两层解决如果只是登录流程有国密加密你可以在vuser_init里调用外部 DLL例如 C 语言写的国密算法库通过lr_load_dll加载再调用加密函数生成动态密文拼接进请求。如果整个通信协议都做国密改造那就别硬用 LR 11 录制了建议用 Wireshark 抓包拿到明文请求模板结合web_custom_request手工构造脚本把加密部分交给外部算法模块处理。这种方式写出来的脚本可控性反而更高。6.5 Controller 在大量虚拟用户下卡死LR 11 是 32 位程序Controller 在管理超过 1000 个虚拟用户时内存占用会逼近 4GB 上限界面卡顿几乎是必然的。替代方案有两个一是把虚拟用户拆到多台负载机上每台不超过 300 个二是用“控制台模式”减少界面渲染压力。Controller 顶部菜单有View→Consolidated View只显示关键指标能缓解一部分卡顿。如果你压测的场景需要上万并发说实话 LR 11 这个版本已经力不从心了可以换 2023 版本或者 JMeter 分布式方案没必要在旧版本上死磕。7. 关于一些还没展开说的细节最后补两句做性能测试这些年我最大的感受是工具永远只是工具决定压测质量的是思路。LoadRunner 11.00 中文版虽然老但它把“脚本录制 - 场景设计 - 压力执行 - 报告分析”这条链路做得非常完整对新手建立性能测试方法论依然是个好选择。而且它在国内存量项目里的占有率决定了你在职场上大概率会遇到它。与其嫌弃它旧不如把它吃透。最后分享一个小习惯每次压测完我会把场景文件和 Analysis 报告以“项目名_日期_目标场景”的格式归档下次同类项目直接复用场景配置能省掉大量重复设计时间。这个习惯从 LR 11 用到现在从来没有后悔过。本文还有配套的精品资源点击获取