loadrunner11性能测试的完整过程,LoadRunner 11 性能测试完整流程

题图来自Unsplash，基于CC0协议

导读

LoadRunner 11作为HP（现Micro Focus）推出的经典性能测试工具，尽管版本较老，但其核心的Vuser Generator（VuGen）、Controller和Analysis三大组件构成了一套完整的性能测试体系。以下将以一个标准的B/S架构Web应用性能测试为例，详细阐述从脚本录制到结果分析的全过程，并在其中穿插常见问题的解决方法。

整个流程的第一步是脚本录制与开发。使用VuGen组件，通过选择“Web（HTTP/HTML）”协议来创建新脚本。录制前，务必在“Recording Options”中设置浏览器的录制端口为localhost:7777，并关闭代理设置。点击“Start Record”后，输入待测系统的URL，VuGen会启动浏览器并开始捕获所有HTTP请求。实际操作中，需要注意录制的内容通常包含大量的无关请求（如静态资源、图片、CSS、JS文件）。为了减少脚本体积并提升回放效率，建议在“Recording Options”的“HTTP Properties”->“Advanced”中，设置“Non-Resources: ‘Do not record this content types’”或者将jpeg、gif、css等扩展名加入排除列表。录制一个典型业务操作流程，例如：用户登录 -> 查询某记录 -> 提交表单 -> 退出。结束录制后，LR会自动生成类似“vuser_init”、“Action”、“vuser_end”的脚本结构。其中，“vuser_init”和“vuser_end”分别用于初始化与清理（如登录和退出），而迭代部分应放在“Action”中。脚本录制完成后，必须进行参数化和关联处理。参数化方面，对于登录用户，可以将用户名和密码设置为参数表，以便模拟多用户使用不同账号。常见问题：录制时通过“web_reg_save_param”函数无法正确捕获动态数据（如SessionID）。解决方法：在录制设置中开启“CORRELATION”自动关联，或手动在脚本中插入“web_reg_save_param”函数，并设置正确的左右边界（如左边界为“name=sessionid">””，右边界为“<”）。完成参数化和关联后，务必在“Run-Time Settings”中设置“Think Time”为“Ignore think time”，并在“Browser Emulation”中取消“Simulate a new user on each iteration”，以控制回放稳定性。脚本调试通过（即无错误回放）即完成此阶段。

第二步是场景设计与执行。打开Controller组件，选择“Manual Scenario”手动场景或“Goal-Oriented Scenario”目标导向场景。对于日常压测，推荐手动场景。先将准备好的脚本添加到场景中，然后设置用户数。例如，计划模拟50个虚拟用户并发执行查询操作。在“Schedule”中，设置“Start Vusers”：每15秒启动5个用户，持续2分钟；然后“Duration”：运行5分钟；最后“Stop Vusers”：每15秒停止5个用户。这种阶梯式加载可以观察系统在逐渐增加压力下的表现。同时，必须添加Windows资源监控和服务器监控：右击场景中的“Run”选项卡，选择“Add Measurements”，添加待测服务器的IP，输入管理员凭据后即可监控CPU、内存、磁盘I/O和网络带宽。常见问题：监控连接失败，提示“Cannot connect to the machine”。解决方法：确保目标服务器开启了“Remote Registry”和“Performance Logs & Alerts”服务，并关闭防火墙；若为Windows 7/2008及以上版本，需在注册表HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystem下添加DWORD值“LocalAccountTokenFilterPolicy”为1。配置完成后，点击“Start Scenario”开始执行。在运行过程中，要注意观察“Running Vusers”曲线是否平稳，以及“Error Statistics”是否出现HTTP 500、Connection timed out等错误。如果错误率超过5%，建议立即停止场景，检查应用服务器日志，而非盲目等待。

第三步是结果分析与调优。当场景执行完毕后，点击Controller中的“Results”->“Analyze Results”启动Analysis组件。重点查看以下几个核心图：1）“Average Transaction Response Time”及其随时间变化的曲线。如果曲线有突然向上的尖峰，说明服务器在该时间点出现瓶颈；2）“HTTP Responses per Second”和“Throughput”图：吞吐量下降而响应时间上升，通常意味着系统资源耗尽；3）“Windows Resources”图：关键是CPU、Memory和Disk Time。CPU利用率持续超过80%、可用内存不断减少、磁盘队列长度持续大于2，都指示了资源瓶颈。例如，在一次测试中，50个虚拟用户并发时，登录事务的平均响应时间从2秒突增到15秒，同时Web服务器CPU维持在95%以上。通过“SLA”设置，可以将响应时间阈值设为5秒，自动生成达标率报告。进一步分析“Error Statistics”发现大量“HTTP 500 - Internal Server Error”，结合服务器IIS日志，定位到是数据库连接池耗尽。此时，将问题反馈给开发团队，建议优化数据库连接池大小至200，并增加一次查询的SQL索引。常见问题：Analysis中的“Web Page Breakdown”不显示元素响应时间。解决方法：在VuGen脚本的“Run-Time Settings”中，勾选“Enable the following”下的“Web Page Breakdown”，并设置“Generate Web Page Breakdown automatically”，然后重新执行场景收集数据。

最后，形成一套完整的测试报告：包括测试目标、环境拓扑（硬件配置、网络带宽）、场景配置（并发数、Pacing）、关键指标（TPS、平均响应时间、错误率）、资源使用峰值，以及最终的瓶颈定位和优化建议。例如，结论可以写为：在50并发下，登录接口TPS为12.3/s，响应时间平均5.2秒，远高于目标值3秒；问题根因是Web服务器CPU高负载及数据库连接池不足；建议升级服务器CPU或增加前端应用节点，并调整数据库连接池参数。同时，附上Lr结果图（如“Windows Resources”中CPU曲线和“Average Transaction Response Time”曲线）。整个流程中，最容易遇到的两个额外常见问题是：1）录制时浏览器崩溃——解决：使用LR自带的IIE 6或7兼容模式，或者将录制的应用程序类型选为“Win32 Applications”；2）执行场景后没有数据——解决：确保在Controller的“Results”设置中，勾选了“Auto Collate Results”并且保存路径中无中文字符或空格。通过以上从脚本、场景到分析的闭环操作，即可完成一次完整的LoadRunner 11性能测试。