LoadRunner性能测试实战：从脚本开发到瓶颈定位的完整工程指南-Seo优化-塔城地区网站建设公司

1. 从“录制回放”到“性能工程”：LoadRunner的定位与价值

如果你刚接触性能测试，可能觉得LoadRunner就是个“录脚本、跑并发、出报告”的工具。十年前，这个认知或许够用，但今天，如果你还这么想，那可能连性能问题的门都摸不着。我干了十多年性能测试，从LoadRunner 8.0一路用到最新的SaaS版本，最大的体会是：LoadRunner早已从一个单纯的“负载模拟器”，演变成了一个贯穿性能需求、设计、执行、分析和调优全生命周期的“性能工程平台”。它的核心价值，不在于录制了多少个脚本，而在于它如何帮你构建一套可量化、可复现、可归因的性能验证体系。

很多人一上来就急着问“怎么录制脚本”、“怎么设置并发数”，这就像学开车只关心怎么踩油门，却不懂交通规则和车辆原理，上路必出事故。LoadRunner的“详细使用”，第一步必须是理解其背后的工程思想。它解决的远不止“系统能扛多少人”这种粗放问题，而是更精细的：在特定业务场景下（比如双十一秒杀、月末报表生成），用户行为模型是怎样的？系统的响应时间、吞吐量、资源利用率等关键指标，随着负载增加是如何变化的？瓶颈在哪里？是应用服务器CPU、数据库锁，还是网络带宽？只有把这些问题想清楚了，你的脚本、场景、监控才有意义，否则就是一堆没有灵魂的数据。

所以，这篇教程不会只给你一堆按钮截图和操作步骤。我会带你走一遍一个资深性能测试工程师使用LoadRunner的标准工作流，穿插我踩过的坑和总结的技巧，目标是让你不仅能“用”起来，更能“用好”，真正发挥出这个重型武器的威力。无论你是测试新人想系统入门，还是有一定经验想提升对性能工程的理解，这篇内容都会对你有所帮助。

2. 性能测试的基石：需求分析与场景建模

在打开LoadRunner之前，80%的工作已经开始了。性能测试失败，十有八九是需求没搞清楚。这一章，我们抛开工具，先聊聊性能测试的“灵魂”——场景。

2.1 从业务指标到性能指标：需求拆解实战

业务方通常会提：“系统要快，要能扛住高峰流量。” 这是一个无效需求。作为性能测试工程师，你必须把它翻译成可量化的技术指标。我常用的拆解框架是“用户-业务-系统”三层法。

用户层指标：这是最直观的。比如，“登录操作在95%的情况下响应时间不超过2秒”。这里，“95%”和“2秒”就是关键。你不能只看平均响应时间，一个10秒的请求会拉高99个0.1秒请求的平均值，掩盖问题。LoadRunner的报告里，90th Percentile、95th Percentile这些百分位数比Average更重要。

业务层指标：这定义了负载的规模和模式。你需要和产品、运营确认：

并发用户数：是严格的同时操作（如秒杀），还是时间段内的在线用户（如论坛浏览）？两者天差地别。LoadRunner中对应的概念是“并发用户”和“每秒事务数（TPS）”。
业务模型：用户怎么用你的系统？比如，一个电商用户典型路径可能是：20%时间浏览首页，30%时间搜索商品，40%时间查看商品详情，10%时间下单。这个比例就是你的“业务混合模型”，它决定了脚本中各个事务的权重。
数据量：测试用的数据要和生产环境规模匹配。用100条商品数据测出的性能，和100万条数据下的性能可能完全不同。你需要准备或模拟相应规模的基础数据。

系统层指标：这是技术团队最关心的。包括：

服务器资源：CPU使用率（通常建议不超过70-80%）、内存使用率、磁盘I/O、网络I/O。
中间件指标：如Tomcat线程池活跃线程数、数据库连接池使用率、JVM GC频率和时长。
数据库指标：慢查询数量、锁等待时间、缓存命中率。

我的经验：一定要在测试开始前，和所有相关方（产品、开发、运维、DBA）一起评审并确认这些指标。形成一份《性能测试需求规格说明书》并签字。这能避免后期无尽的扯皮——“你说慢，我觉得挺快啊”。

2.2. 构建LoadRunner测试场景：从理论到配置

理解了需求，我们才能开始在LoadRunner中构建有意义的场景。在LoadRunner Controller（场景控制器）中，场景设计是核心。

虚拟用户组（Vuser Groups）：根据业务模型，你会创建多个脚本，每个脚本模拟一类用户行为（如“浏览用户”、“购买用户”）。在场景中，你需要为每组虚拟用户设置不同的数量、加载策略和运行时设置。

负载生成器（Load Generators）：如果你的并发数很大（比如超过1000），一台机器可能无法模拟，或者会先成为瓶颈。这时就需要在多台机器上部署Load Generator，由Controller统一调度。这里有个大坑：负载生成器本身会消耗资源。你需要监控负载机的CPU和内存，确保其资源充足，否则虚拟用户可能无法正常启动或运行，导致测试结果失真。我一般会确保负载机的CPU使用率在测试期间低于50%。

调度器（Schedule）：这是场景设计的精华部分，它定义了负载如何随时间变化。

初始化（Initialize）：所有虚拟用户是同时初始化，还是分批初始化？对于需要登录的脚本，我通常选择“同时初始化所有用户”，然后在脚本中设置集合点，等所有用户初始化完成后再开始真正操作，这样能模拟真实的“瞬间并发”压力。
启动（Start Vusers）：用户是同时启动，还是每隔一段时间启动一批（Ramp Up）？对于系统预热或寻找最大并发点，Ramp Up非常有用。例如，每15秒启动50个用户，直到达到1000用户，观察系统指标何时出现拐点。
持续时间（Duration）：负载达到峰值后，需要持续运行一段时间（如30分钟）。这能检验系统在持续压力下的稳定性，是否有内存泄漏、连接池耗尽等问题。短时冲刺和长时稳压，发现的问题类型完全不同。
停止（Stop Vusers）：是同时停止所有用户，还是逐渐停止？通常选择“同时停止”，以观察压力释放后系统的恢复情况。

一个经典的“波浪形”场景配置可能是：5分钟内逐步加载500个虚拟用户 -> 保持500用户并发持续运行30分钟 -> 在2分钟内全部退出。通过这样的场景，你可以分析系统在负载上升期、平稳期和下降期的表现。

3. VuGen脚本开发：不仅仅是录制

LoadRunner的Virtual User Generator (VuGen) 是用来录制和开发脚本的。很多人以为脚本开发就是“点录制，操作一遍，停止”，这是最基础的，也是最脆弱的。一个健壮的脚本，需要大量的手工增强。

3.1 录制与协议选择：选错全盘皆输

打开VuGen第一步不是点录制，而是选择协议。这是第一个关键决策点。LoadRunner支持几十种协议，选错了，要么录不到任何请求，要么录到的请求无法回放。

Web (HTTP/HTML)：这是最常用的，用于测试基于浏览器的Web应用。它录制的是HTTP请求。这里又有HTML-based script和URL-based script的区别。
- HTML-based：默认选项。它将用户操作（点击、输入）录制为一个个函数（如web_link,web_submit_form），更贴近用户视角，脚本易读性强。适用于大多数前后端耦合、页面跳转频繁的传统Web应用。
- URL-based：它将所有请求（包括页面、图片、JS、CSS等）录制为独立的web_url函数。脚本看起来是一长串URL请求。适用于前后端分离（如单页应用SPA）或需要精细控制每个请求的场景。对于现代大量使用Ajax的Web应用，我越来越多地使用URL-based模式，因为它能更准确地捕捉到异步请求。
Web Services：用于测试SOAP或RESTful API。这是目前微服务架构下的测试重点。你需要手动导入WSDL文件或直接输入API地址，VuGen会生成对应的调用函数。对于API测试，参数化和验证点设置更为关键。
Java Vuser/C Vuser：这是协议无关的，直接编写Java或C代码来模拟用户行为。功能最强大也最灵活，可以测试任何基于Socket通信的协议，或者直接调用JAR包中的方法。但要求测试人员有较高的编程能力。
数据库协议（如ODBC, Oracle NCA）：直接测试数据库存储过程或SQL语句的性能。

我的踩坑记录：曾经测试一个混合了Web页面和Socket长连接的系统，只用Web协议录制，结果长连接的心跳包完全没录上，测试场景完全失真。后来改用多协议（Multiple Protocols），同时选择Web和Windows Sockets，才完整模拟了用户行为。所以，对于复杂系统，务必分析其通信架构，必要时组合使用多种协议。

3.2 脚本增强四大核心：参数化、关联、检查点、事务

录制好的裸脚本几乎无法直接用于压力测试，必须增强。

3.2.1 参数化（Parameterization）：让虚拟用户“活”起来如果所有虚拟用户都用同一个账号登录、查同一条数据，压力会集中到数据库的某一行（热点），产生大量锁等待，这不符合真实情况，也测不出系统的真实并发处理能力。

目的：用不同的数据替换脚本中的常量。比如登录用户名、密码、搜索关键词、商品ID等。
操作：在VuGen中选中要替换的值，右键选择“Replace with a Parameter”。
数据文件设计：你可以使用.dat文件、数据库作为数据源。我强烈建议为不同的参数创建独立的数据文件，并注意数据量要远大于虚拟用户数，避免循环使用相同数据。对于“唯一性”要求的数据（如注册用户名），要选择Unique模式，并设置数据耗尽时的行为（如Abort Vuser）。
技巧：对于订单号、时间戳这类需要运行时动态生成的数据，光参数化不够，需要使用lr_save_string,lr_save_datetime等函数在代码中动态生成。

3.2.2 关联（Correlation）：处理动态值这是新手最容易栽跟头的地方。服务器返回的很多值是动态的，比如Session ID、Token、CSRF令牌、订单流水号。脚本回放时如果还用录制时的旧值，请求就会失败。

目的：自动捕获服务器返回的动态值，并保存到参数中，供后续请求使用。
方法：
1. 自动关联：LoadRunner可以扫描脚本，识别可能需要关联的地方。在录制时或回放后，使用Scan for Correlation功能。但它不是万能的，很多自定义的Token它识别不了。
2. 手动关联（必须掌握）：这是核心技能。通过对比录制和回放的服务器返回（在Recording Log或Replay Log中查找），定位动态值。然后使用web_reg_save_param或web_reg_save_param_ex函数（注意是reg，注册型函数，必须放在请求之前）来捕获它。
```
// 例如，捕获一个名为"csrf_token"的隐藏域值 web_reg_save_param_ex( "ParamName=csrf_token", "LB=<input type=\"hidden\" name=\"csrf_token\" value=\"", "RB=\">", SEARCH_FILTERS, "Scope=Body", LAST); // 紧接着才是提交表单的请求 web_submit_form(...); // 后续请求中就可以用`{csrf_token}`参数了
```
经验：关联做得是否彻底，是脚本能否成功回放的关键。对于现代应用，尤其要关注JSON返回中的Token。你可以写自定义函数来解析JSON并提取值。

3.2.3 检查点（Checkpoint）：验证业务是否正确压力测试不只是压测，还要验证在高压下业务逻辑是否正确。比如，支付成功后页面是否跳转到了成功页，搜索是否返回了结果。

目的：在脚本中设置验证点，检查服务器返回的内容中是否包含预期的字符串。
函数：web_reg_find（注册型，放在请求前）或web_find（放在请求后，效率低且只对HTML模式有效，已逐渐淘汰）。
最佳实践：对关键业务步骤（如登录、下单、支付）设置检查点。在Controller场景中，可以设置“当检查点失败时，事务状态为失败”，这样在分析报告时，你能清晰地看到有多少虚拟用户业务执行失败了，而不仅仅是HTTP状态码200。

3.2.4 事务（Transaction）：定义你要测量的操作事务是性能指标度量的基本单位。你需要把一系列操作组合成一个逻辑上的业务单元。

目的：衡量某个业务操作的响应时间，如“用户登录”、“添加商品到购物车”、“提交订单”。
操作：在脚本中插入lr_start_transaction和lr_end_transaction。
命名规范：事务名要有意义，如T01_Login,T02_SearchProduct。避免使用默认的Action。
思考时间（Think Time）：用户操作之间的间隔。录制时会包含思考时间。在压力测试时，通常需要在运行时设置（Run-time Settings）中忽略或按比例缩放思考时间，以产生更大的压力。但在稳定性测试或模拟真实用户模型时，需要保留。

3.3 调试与回放：确保脚本基石稳固

脚本增强后，必须在VuGen中单用户迭代运行多次，确保：

回放通过（Replay Pass）：没有错误。
日志清晰（Log Enabled）：打开扩展日志（Extended Log），查看参数替换、关联捕获的值是否正确。
数据流正确：使用VuGen的集成浏览器或查看Generation Log，确认业务流程走通，检查点都通过。

只有单用户脚本100%稳定，才能放到多用户场景中去压测。否则，场景中的错误会多到无法分析。

4. Controller场景设计与执行监控：施加压力的艺术

脚本准备好了，就进入LoadRunner的“大脑”——Controller。这里是把虚拟用户组织起来，向系统发起总攻的地方。

4.1 场景类型选择：目标场景 vs. 手工场景

Controller提供两种主要场景类型：

手工场景（Manual Scenario）：你直接定义每个脚本的虚拟用户数。这是最常用、最灵活的方式，可以精细控制每组用户的数量和调度策略。前面讲的调度器（Schedule）就是在手工场景中配置。适用于大多数性能验证、容量规划、瓶颈定位测试。
目标场景（Goal-Oriented Scenario）：你设定一个测试目标（例如，每秒完成50个登录事务），LoadRunner自动调整虚拟用户数来达到这个目标。这更像是一种“探索性”测试，用来回答“要达到某个性能指标，需要多少并发用户？”这个问题。适用于已知性能指标，反推系统容量的场景。

我90%的情况使用手工场景，因为它能让我完全掌控测试过程。

4.2 运行时设置（Run-time Settings）：微调虚拟用户行为

在场景中，你可以为不同的脚本组设置不同的运行时策略，这是一个非常强大的功能。

迭代（Iteration）：每个虚拟用户运行脚本的次数。对于长时间稳定性测试，可以设置为“无限”，直到场景停止。
日志（Log）：为了性能考虑，在压力测试时通常只启用“出错时发送消息”或完全禁用日志。但在调试阶段，可以启用扩展日志。
思考时间（Think Time）：如前所述，可以忽略、按比例缩放，或使用录制的时间。
速度模拟（Speed Simulation）：模拟不同的网络带宽（如拨号、宽带）。这在测试网络敏感型应用时很有用。
浏览器模拟（Browser Emulation）：模拟浏览器的缓存和Cookie行为。现代浏览器缓存机制复杂，选择合适的模拟级别对结果有影响。

4.3 监控器（Monitors）：为系统做“全身CT”

压测过程中，如果只盯着LoadRunner的虚拟用户状态和事务响应时间，那就是“盲人摸象”。你必须实时监控被压测系统的各项资源指标，这需要配置监控器。

Windows资源监控：对于Windows服务器，可以直接添加Windows Resources监控器，输入服务器IP、管理员账号密码，即可监控CPU、内存、磁盘、网络等。
UNIX/Linux资源监控：需要在目标服务器上安装并启动rstatd或SSH服务，然后在Controller中添加UNIX Resources监控器。我更喜欢用SSH方式，更安全通用。监控指标包括%usr（用户CPU）、%sys（系统CPU）、average load（平均负载）、disk busy等。
SNMP监控：对于网络设备（路由器、交换机）或支持SNMP的服务，可以使用SNMP协议监控。
应用服务器监控：这是重中之重。需要配置特定的监控器。
- Apache / Nginx：需要开启mod_status模块，监控请求数、连接数等。
- Tomcat / JBoss：需要开启JMX远程管理，监控线程池、内存池、请求队列等。
- .NET：监控.NET CLR内存、异常等。
数据库监控：
- Oracle：通过OCI接口或配置Oracle Server监控器，监控缓冲区命中率、锁等待、Top SQL等。
- SQL Server：通过ODBC或配置SQL Server监控器。
- MySQL：可以使用SiteScope（LoadRunner组件）或通过自定义脚本收集SHOW GLOBAL STATUS信息。

监控配置的坑：监控本身会产生开销。我曾遇到过因为开启了过于频繁的JMX监控（每秒一次），导致Tomcat在高压下额外消耗了5%的CPU。因此，监控粒度要权衡，通常5-10秒一次即可。另外，防火墙和权限一定要提前开通，否则压测开始后监控连不上，会非常被动。

4.4 执行与现场诊断：压测不是“设好就等”

点击“Start Scenario”只是开始。在执行过程中，你必须像指挥官一样紧盯几个关键面板：

运行视图（Run View）：查看虚拟用户的状态（就绪、运行、完成、错误）、每秒事务数、事务响应时间趋势图。如果错误用户数急剧增加，或响应时间曲线突然飙升，就要立刻警觉。
监控器图表：观察服务器CPU、内存、磁盘IO、网络IO是否出现瓶颈。数据库活动连接数是否暴增。
错误信息（Errors）：实时查看错误日志，快速判断是脚本问题（如关联失败）、网络问题（如连接超时）还是服务器问题（如500内部错误）。

如果发现问题，不要急着停止。可以先尝试：

分析当前日志：从出错的虚拟用户中采样，查看其执行日志。
调整负载：如果怀疑是某个特定功能导致，可以尝试在场景运行时，动态减少该脚本组的用户数，观察系统是否恢复。
收集即时数据：登录服务器，快速执行一些命令（如top,vmstat 1,jstack）抓取现场信息。

压测执行阶段，是发现和定位问题最黄金的时期。

5. Analysis结果深度解读：从数据到洞见

压测结束后，LoadRunner Analysis会生成一份详细的报告。很多人只看个平均响应时间和通过率就结束了，这简直是暴殄天物。Analysis里的数据，是诊断系统性能问题的“金矿”。

5.1 核心图表解读：看懂这些图，你就懂了八成

运行虚拟用户数图（Running Vusers）：对比你设置的场景计划，看虚拟用户是否按计划加载和退出。如果图形有异常凹陷，说明有大量用户中途失败退出。
每秒事务数图（Transactions per Second）：这是系统吞吐量的直接体现。健康的曲线应该是：随着用户数增加而上升，在用户数稳定后也保持相对稳定。如果曲线在压力稳定后持续下降，说明系统处理能力在衰退，可能有资源泄漏。如果曲线出现剧烈锯齿状波动，说明系统处理不稳定。
事务响应时间图（Transaction Response Time）：一定要结合“运行虚拟用户数图”一起看。响应时间应该随着用户数增加而平缓上升。如果出现拐点，即用户数增加一点，响应时间急剧上升，那个拐点对应的用户数可能就是系统的“最佳并发用户数”。超过这个点，系统体验会急剧恶化。
点击率图（Hits per Second）：每秒向服务器发出的HTTP请求数。这个图可以和TPS图对照。如果TPS上不去，但点击率很高，可能意味着前端页面包含了大量无效的静态资源请求，或者服务器在处理每个请求时做了很多无用功。
系统资源监控图：将上述性能指标图与Windows/UNIX资源图叠加（Overlay）在一起看，是定位瓶颈的杀手锏。例如：
- 当TPS上不去时，如果发现CPU使用率已经达到95%以上，那么瓶颈很可能在应用服务器计算能力。
- 如果TPS和CPU都不高，但事务响应时间很长，同时发现磁盘%busy或await时间很高，那么瓶颈可能在磁盘I/O。
- 如果数据库服务器的lock waits或latch waits指标很高，那么瓶颈可能在数据库锁竞争。

5.2 关键数据表分析：细节决定成败

除了图表，报告中的“事务摘要”、“事务性能摘要”等数据表提供了量化依据。

平均响应时间 vs. 百分位数响应时间：再次强调，不要迷信平均值。关注90th Percentile和95th Percentile。比如，平均响应时间1秒，但90%线是5秒，说明有10%的用户体验极差。
通过/失败事务数：检查点失败的事务也会被计入失败。分析失败事务的原因，是脚本问题还是服务器错误。
标准差（Std. Deviation）：响应时间的标准差越大，说明系统性能越不稳定。

5.3 瓶颈定位与调优建议：输出有价值的报告

一份好的性能测试报告，不应该只是数据的罗列，而应该包含：

测试结论：在给定的场景和指标下，系统是否通过测试？
性能表现：核心事务的响应时间、TPS、资源利用率等关键数据。
瓶颈分析：结合图表和数据，明确指出发现的性能瓶颈在哪里，并尽可能分析根因。例如：“在500并发用户下，‘提交订单’事务的响应时间超过5秒，不符合≤3秒的要求。同时观察到数据库服务器CPU使用率达92%，且存在大量‘CPU wait’状态，推测是某条SQL语句未使用索引导致的全表扫描。”
调优建议：给出具体的、可操作的改进建议。例如：“建议对orders表的user_id字段添加索引，并优化GetUserOrders存储过程的逻辑，避免在循环内执行查询。”
风险与后续计划：指出未覆盖的场景、测试的局限性，以及是否需要补充测试（如疲劳测试、异常测试）。

6. 高级话题与实战避坑指南

掌握了基础流程，我们再来聊聊那些让新手头疼、老手翻车的高级问题和实战技巧。

6.1 脚本开发中的“硬骨头”：动态令牌、异步请求与SSL证书

动态令牌（如JWT）：现代API常用JWT。处理方法是：在登录事务后，使用web_reg_save_param_ex捕获返回的Token（通常在响应头的Authorization字段或JSON Body中）。然后在后续请求的Header中，使用web_add_header函数添加Authorization: Bearer {token}。
异步请求（Ajax）：对于URL-based脚本，Ajax请求会被录制成独立的web_url，顺序可能和实际有差异。你需要分析请求间的依赖关系，必要时使用web_concurrent_start和web_concurrent_end函数来模拟并发请求，或者手动添加等待（lr_think_time）以确保数据就绪。
SSL证书问题：在录制或回放HTTPS网站时，可能会遇到证书错误。可以在VuGen的Recording Options->Network->Port Mapping中，将捕获级别设置为WinINet（用于IE浏览器）或Socket，并勾选“Capture level”下的相关SSL选项。对于自签名证书，需要将证书导入到系统的信任库。

6.2 场景执行中的典型问题与排查

虚拟用户无法初始化/启动失败：
- 错误提示“Failed to create Vuser”：检查License是否支持这么多用户，负载生成器机器资源（内存）是否充足。
- 错误提示“Failed to connect to load generator”：检查负载生成器上的Agent Process是否启动，Controller与负载机之间的防火墙端口（默认50500、54345）是否开放。
大量错误“Action.c(x): Error -27796: Failed to connect to server”：
- 这是连接超时。首先检查被压测服务器网络是否可达，端口是否监听。
- 更常见的原因是，压力过大，服务器端的连接池（如Web服务器、数据库）被耗尽，新的连接无法建立。此时需要监控服务器端的活动连接数。在运行时设置中适当增加HTTP-request connect timeout和HTTP-request receive timeout可能缓解，但根本解决需要调整服务器配置。
事务响应时间逐渐变长，TPS逐渐下降：
- 这是典型的内存泄漏或资源未释放症状。检查应用服务器的内存使用曲线是否持续上升。检查数据库连接是否在执行后正确关闭。进行长时间（如8-24小时）的稳定性测试（耐力测试）最容易暴露这类问题。

6.3 结果分析中的常见误区

只看汇总报告，不看细分事务：系统整体平均响应时间达标，但某个核心事务（如支付）可能很慢。必须逐个分析关键事务。
忽略基础资源监控：有时TPS和响应时间看起来正常，但磁盘队列长度已经很高，这是潜在瓶颈，一旦数据量增大就会爆发。
将一次测试结果当作最终结论：性能测试结果受环境（数据、网络、其他进程）、参数（思考时间、迭代次数）影响很大。关键结论需要多次测试验证，特别是调优前后，必须保证测试环境、场景、数据的一致性，才能进行有效对比。

LoadRunner是一个强大的工具，但工具背后的性能工程思维和严谨的方法论更为重要。它要求你既是懂业务的测试者，也是能看透系统架构的侦探。从精准的需求分析开始，到健壮的脚本开发，再到科学的场景设计和严谨的结果分析，每一步都环环相扣。真正的“详细使用”，是把这个工具融入到你保障系统性能质量的完整工作流中，让每一次压测都有的放矢，让每一份报告都言之有物。这个过程没有捷径，唯有多实践、多思考、多总结。当你能够通过LoadRunner的数据，清晰地描绘出系统在压力下的行为图谱，并精准地指出它的“阿喀琉斯之踵”时，你才算真正掌握了它。