1. 项目概述性能测试的“老将”与新手的“敲门砖”LoadRunner这个名字在性能测试领域几乎等同于一个时代的代名词。即便在云原生和微服务架构大行其道的今天LoadRunner 12.02 作为一款经典的商业性能测试工具依然是许多企业特别是金融、电信、大型制造业等传统核心业务系统进行性能压测的“标配”。它就像一位经验丰富的老将虽然界面可能不如一些新兴的开源工具那么“酷炫”但其强大的协议支持、精准的资源监控和成熟的测试分析体系依然是构建可靠性能基准的利器。对于刚入行的测试工程师或者需要接手维护既有性能测试脚本的团队来说掌握 LoadRunner 12.02 的基本使用不仅是完成工作的必备技能更是理解性能测试完整生命周期——从脚本录制、场景设计到结果分析——的绝佳路径。很多人一听到 LoadRunner可能会被其庞大的功能和略显复杂的界面吓退。但事实上它的核心使用流程是高度结构化和清晰的。本次分享我将以一个从业者的视角带你拆解 LoadRunner 12.02 从安装配置到完成一次基础性能测试的全过程。我们会聚焦于最常用的 WebHTTP/HTML协议因为这是互联网应用最普遍的交互方式。通过这个具体的例子你将不仅学会“点哪里”更能理解每个操作背后的意图比如为什么参数化是必须的集合点该如何设置才有效以及如何从纷繁的测试结果图表中一眼揪出系统的性能瓶颈。无论你是需要快速上手完成一个紧急的压测任务还是想系统性地打好性能测试的基础这篇内容都将提供可直接“抄作业”的步骤和避坑指南。2. 环境准备与工具核心组件解析在真正开始录制脚本之前我们必须先理解 LoadRunner 12.02 的“五脏六腑”。它不是一个单一的程序而是一个由多个组件协同工作的套件。盲目地点击安装包很可能导致后续使用中各种组件连接失败。因此我们先来理清它的核心架构。2.1 核心三大组件VuGen、Controller、AnalysisLoadRunner 的核心工作流由三个主要组件驱动理解它们的分工是高效使用的前提。Virtual User Generator (VuGen)这是我们的“脚本工厂”。它的唯一任务就是录制和开发虚拟用户VUser脚本。你可以把它想象成一个高度专业化的浏览器或其他客户端模拟器它能记录下你与服务器应用的所有交互请求与响应并生成对应协议的脚本代码默认是C语言。VuGen 工作的产出物就是一个.usr文件项目文件和其关联的脚本文件。Controller这是性能测试的“指挥中心”和“压力发生器”。在 Controller 中我们设计测试场景Scenario决定用多少个 VUser虚拟用户来跑脚本、以什么样的节奏如每隔15秒启动5个用户加压、这些 VUser 运行在哪些负载生成器Load Generator上。Controller 负责将 VuGen 生成的脚本分发给各个负载生成器指挥它们同时执行并在这个过程中收集全局的性能数据。Analysis这是我们的“数据分析中心”。压测结束后Controller 会生成一个结果文件。Analysis 组件则负责打开这个结果文件将海量的原始数据事务响应时间、吞吐量、点击数、系统资源计数器等进行汇总、关联和可视化生成各种图表和报告。我们性能瓶颈定位、出具测试报告主要就依赖这个工具。注意很多新手容易混淆 VuGen 和 Controller。简单记VuGen 管“单个用户怎么操作”Controller 管“成千上万个用户怎么一起操作”。你绝不会在 Controller 里编辑脚本细节也绝不会在 VuGen 里设置500个用户并发。2.2 安装部署要点与避坑指南LoadRunner 12.02 的安装过程本身并不复杂但有几个关键点一旦忽略就会导致后续步骤失败。以下是基于大量实战安装经验总结的清单操作系统兼容性LoadRunner 12.02 对 Windows 7 SP1 和 Windows 8.1 的支持相对较好。在 Windows 10 或 Windows 11 上安装可能会遇到一些兼容性问题尤其是 Controller 和 Analysis 组件。强烈建议如果条件允许为性能测试专门准备一台 Windows 7 SP1 或 Windows Server 2008 R2 的纯净虚拟机作为负载机。这能避开绝大多数莫名的错误。安装包获取与完整性确保你拥有完整的安装包。通常它包含一个主安装程序和一个巨大的“安装包”文件夹。安装时主安装程序会从这个文件夹中提取所需文件。如果文件夹缺失或路径不对安装会卡住。安装路径绝对不要安装在包含中文或空格的路径下。使用默认的C:\HP\LoadRunner或类似D:\LoadRunner的纯英文路径是最安全的选择。这是很多脚本回放失败和组件启动异常的根源。防火墙与杀毒软件在安装和后续使用过程中暂时关闭 Windows 防火墙和第三方杀毒软件特别是那些带有“主动防御”功能的。它们可能会拦截 LoadRunner 的某个进程通信导致负载生成器Load Generator无法连接。以管理员身份运行无论是安装程序还是后续启动 VuGen、Controller都请右键选择“以管理员身份运行”。这能避免因权限不足导致的文件写入或注册表修改失败。安装后重启安装完成后按照提示重启计算机。这不仅仅是形式而是为了让一些底层驱动如网络数据包捕获驱动和系统环境变量生效。实操心得我个人的习惯是在安装完成后首先单独打开 VuGen尝试创建一个空白 Web 脚本并编译F7确保脚本引擎工作正常。然后再打开 Controller创建一个指向本地负载生成器的简单场景。这两步自查能提前发现80%的环境问题。3. 脚本录制与开发从用户操作到可执行代码一切就绪后我们进入核心环节——脚本开发。录制脚本看似简单点一下“录制”按钮但录出一个“健壮”、“可复用”、“能真实模拟用户”的脚本需要很多技巧。3.1 协议选择与录制配置启动 VuGen首先面临的是协议选择。LoadRunner 支持上百种协议选错协议会导致根本录不到任何内容。对于绝大多数基于浏览器的 Web 应用选择“Web - HTTP/HTML”协议即可。除非你的应用大量使用 WebSocket、Ajax 长轮询等才需要考虑多协议或更底层的选择。创建脚本后进入录制配置界面。这里有几个关键参数Application type选择“Internet Applications”即浏览器应用。URL Address填入你要测试的网站起始地址如http://www.example.com。Working directory脚本工作目录保持默认或指定一个英文路径。Record into action选择将录制的操作放到哪个部分。通常我们把登录等初始化操作放到vuser_init核心业务操作放到Action退出清理操作放到vuser_end。首次录制可以全放到Action。点击“Start Recording”VuGen 会启动一个内置浏览器。之后你在该浏览器中的所有操作点击、输入、提交都会被捕获并生成对应的脚本函数。3.2 脚本增强让脚本“活”起来直接录制的脚本是“死”的它只是忠实地记录了你的一次操作。要用于模拟大量用户必须进行“增强”主要涉及三个方面3.2.1 事务Transaction事务用来衡量一个或多个操作的响应时间。比如我们将“用户登录”这个操作定义为一个事务。 在脚本中在登录操作开始前插入lr_start_transaction(Login);在登录操作结束后插入lr_end_transaction(Login, LR_AUTO);。这样Analysis 报告中就会单独统计“Login”事务的平均响应时间、通过率等关键指标。关键点事务的命名要有业务意义如“Login”、“SearchProduct”、“SubmitOrder”。3.2.2 参数化Parameterization这是性能测试脚本的灵魂。如果100个用户都用同一个账号“test”登录系统可能会因为缓存、锁等原因导致测试结果失真更可能触发业务逻辑错误如“用户已登录”。参数化就是将脚本中的常量如用户名、密码、搜索关键词替换为从数据源读取的变量。 操作步骤选中脚本中的常量值如“test”右键选择“Replace with a Parameter”。创建一个新的参数文件如username.dat编辑该文件每一行就是一个参数值如 user1, user2, ... user100。在参数属性中设置“Select next row”为“Unique”“Update value on”为“Each iteration”。这样每个虚拟用户每次迭代都会取一个唯一的用户名。避坑技巧参数文件务必保存为 ANSI 编码放在脚本目录下。UTF-8 编码可能导致中文参数乱码。对于需要关联使用的参数如登录后产生的 Session ID要确保其获取和更新的逻辑正确。3.2.3 集合点Rendezvous集合点用于制造“瞬间并发”的压力。比如你想测试100个用户同时点击“提交订单”按钮时系统的表现。你需要在提交订单的脚本前插入集合点lr_rendezvous(SubmitOrder);。在 Controller 中设置集合点策略后虚拟用户运行到这里时会暂停直到所有用户都到达这个点再一起释放从而形成真正的并发压力。注意事项集合点不是越多越好。滥用集合点会使得测试场景变得不真实现实中用户操作不可能完全同步并且会极大增加测试的复杂度和耗时。通常只在最核心、最可能产生瓶颈的业务点如秒杀、抢购的提交瞬间设置集合点。3.2.4 检查点Checkpoint检查点用于验证服务器返回的内容是否正确是判断业务是否成功执行的关键。通过web_reg_find或web_find函数在请求之前注册一个文本检查点比如检查返回页面中是否包含“登录成功”字样。如果检查失败该次迭代可以被标记为失败。这能确保我们压测的是正确的业务流而不是一堆错误的请求。3.3 脚本调试与回放验证脚本增强后绝不能直接拿到 Controller 去压测。必须在 VuGen 中先进行单用户回放调试。语法检查F7确保脚本没有语法错误。单次回放F5观察回放日志Replay Log。务必切换到“Extended log”模式并勾选“Data returned by server”。这样你能看到服务器返回的所有数据对于调试参数化和关联至关重要。验证业务逻辑通过检查点日志和肉眼观察回放摘要确认脚本完整地走通了业务流并且关键检查点都通过了。迭代回放在“Run-time Settings”中设置迭代次数为3-5次模拟一个用户重复操作进一步验证参数化数据在多次迭代中是否正确轮询。只有单用户回放完全成功且符合业务预期这个脚本才算初步合格可以交付给 Controller 用于场景设计。4. 场景设计与执行构建真实的压力模型脚本准备好后我们来到 Controller这里是将脚本转化为实际压力的地方。场景设计的目标是模拟真实用户的使用模型。4.1 负载生成器管理如果你的压力很大比如需要模拟上万用户一台机器可能无法生成足够的负载或者会先于被测系统成为瓶颈。这时就需要使用多台机器作为“负载生成器”Load Generator。 在 Controller 的“Load Generators”界面可以添加其他机器的 IP 地址。前提是那些机器上也安装了 LoadRunner 的负载生成器组件并启动了magentproc.exe进程。添加后状态必须显示为“Ready”才能使用。常见问题连接失败通常是因为目标机器的防火墙未关闭、magentproc进程未启动或网络不通。4.2 场景计划设置这是场景设计的核心主要设定两部分虚拟用户组和调度计划。虚拟用户组将 VuGen 脚本加载进来形成一个 VUser 组。你需要设定这个组总共使用多少个虚拟用户。这些用户可以被分配到不同的负载生成器上。调度计划Schedule定义压力如何随时间施加。这是模拟真实场景的关键。初始化Initialize所有虚拟用户以多快速度被初始化加载到内存中。通常选择“同时初始化所有虚拟用户”或“每隔一段时间初始化一部分”。启动Start Vusers压力如何上升。例如“每15秒启动2个VUser”这模拟了用户逐渐进入系统的过程。持续时间Duration压力达到峰值后持续运行多长时间。例如稳定并发100个用户运行30分钟。这个阶段的性能数据最具有分析价值。停止Stop Vusers压力如何下降。例如“每30秒停止5个VUser”。一个典型的压力模型是“缓步加压 - 稳定压力 - 缓步减压”。避免“瞬间拉到最大并发”和“瞬间停止所有用户”这种不真实的暴力模式。4.3 运行时设置与监控器配置在场景中可以统一修改 VUser 组的“Run-time Settings”比如思考时间Think Time、迭代次数、日志级别等。对于压力测试通常需要忽略或按比例缩短思考时间因为我们的目标是考察服务器处理能力而不是模拟用户发呆。另一个重点是配置监控器Monitors。Controller 可以连接到被测系统服务器上监控其资源使用情况。这通常需要在服务器上安装监控代理如 Windows 的PerfMon计数器Linux 的rstatd或SSH监控。 你需要添加计数器例如Windows%Processor TimeCPU使用率、Available MBytes可用内存、Avg. Disk Queue Length磁盘队列、Network Interface\Bytes Total/sec网络流量。Linux通过rstatd监控类似指标。实操心得场景执行前务必先“试跑”一下。设置一个很小的负载如5个用户跑1分钟目的是验证整个链路是否通畅脚本能否在所有负载生成器上成功启动监控计数器能否正常获取数据这能提前发现脚本路径错误、依赖文件缺失、监控权限不足等问题避免长时间压测跑到一半才失败。5. 结果分析与瓶颈定位从数据到结论压测执行完毕后Controller 会自动调用 Analysis 组件打开结果文件。面对几十张图表新手很容易眼花缭乱。分析的关键是关联分析和趋势分析。5.1 核心性能指标解读首先关注几个最核心的指标事务响应时间这是用户体验的直接体现。在“Analysis Summary”或“事务摘要”图中查看每个事务的平均响应时间、最小/最大响应时间以及是否满足预设的性能需求如登录事务2秒。更重要的是看“事务性能摘要图”它按时间轴展示响应时间变化能清晰看到系统何时开始变慢。每秒事务数TPS系统处理能力的核心指标。它表示系统每秒成功完成的事务数。TPS 曲线应该与施加的并发用户数曲线有合理的对应关系。当用户数增加而 TPS 不再增长甚至下降时说明系统达到了瓶颈。虚拟用户数正在运行的 VUser 数量。用于确认场景是否按计划执行。错误率失败事务或 HTTP 错误的比例。一个健康的系统在压力下错误率应该极低如0.1%。错误率飙升往往是系统崩溃或资源耗尽的先兆。系统资源利用率来自服务器的监控数据。CPU使用率持续高于80%可能成为瓶颈。内存使用率关注可用内存是否持续减少是否存在内存泄漏。磁盘I/O磁盘队列长度持续过高说明磁盘读写成为瓶颈。网络带宽检查是否达到网络带宽上限。5.2 关联分析与瓶颈定位流程Analysis 提供了“合并图”功能这是定位瓶颈的利器。一个标准的分析流程是确定性能拐点在“运行 Vuser”图中找到系统开始出现大量错误或响应时间急剧上升的时间点T。关联资源图将“运行 Vuser”图与“事务响应时间”图、“TPS”图合并。确认响应时间和 TPS 的恶化是否与用户数增加同步。关联系统资源图将上述合并图再与“Windows 资源”或“UNIX 资源”图合并。观察在时间点 T是否有某项系统资源CPU、内存、磁盘、网络达到了瓶颈如CPU持续100%内存耗尽磁盘队列激增。钻取分析如果资源未达瓶颈但性能下降则可能是应用层或中间件瓶颈。此时需要查看 Web 服务器如 Apache、Nginx、应用服务器如 Tomcat、WebLogic或数据库的监控指标如连接池使用率、慢查询日志。LoadRunner 本身可能无法直接监控这些需要结合其他工具如服务器日志、APM工具进行分析。常见瓶颈模式速查表现象可能瓶颈点下一步排查方向响应时间增加TPS持平或下降CPU使用率高应用服务器CPU瓶颈1. 用 profiling 工具如 JProfiler分析应用代码热点。2. 检查是否有低效算法或死循环。3. 考虑水平扩展应用服务器。响应时间增加TPS下降内存使用率持续增长内存泄漏1. 监控 GC 日志Java应用。2. 使用内存分析工具如 MAT检查堆转储。3. 检查缓存设置是否不当。响应时间波动大磁盘队列长度高磁盘I/O瓶颈1. 检查数据库慢查询优化索引和SQL。2. 检查日志写入是否过于频繁。3. 考虑使用更快的 SSD 或优化存储架构。网络吞吐量接近带宽上限响应时间增加网络带宽瓶颈1. 优化前端资源压缩图片、JS/CSS。2. 使用 CDN。3. 升级网络带宽。错误率突然飙升如大量超时或连接拒绝连接池耗尽或服务崩溃1. 检查应用服务器和数据库的连接池配置。2. 检查服务器日志是否有 OOM内存溢出错误。3. 检查是否有第三方服务调用失败。5.3 报告生成与解读Analysis 可以生成丰富的报告从简单的摘要到详细的 Word/PDF 报告。对于内部团队沟通我通常直接使用 Analysis 的“报告”功能生成一个包含关键图表的 HTML 报告。对于正式的交付物则需要整理出结构化的 Word 报告至少包含测试目标、测试环境、场景设计、核心结果摘要事务响应时间、TPS、错误率、资源利用率、瓶颈分析与建议、测试结论。最后再分享一个小技巧在分析结果时不要只盯着“平均值”。“90百分位响应时间”这个指标往往更能反映大多数用户的体验。比如平均响应时间是1秒但90%的用户响应时间在3秒以内这意味着有10%的用户体验很差。这个指标对于评估系统的稳定性至关重要。在 Analysis 的“事务性能摘要”图中可以很方便地看到各个百分位的数值。