性能测试实战指南：从LoadRunner脚本到场景分析的完整流程
1. LoadRunner性能测试入门：工具与基础概念
第一次接触性能测试时，我被各种专业术语搞得晕头转向。直到用LoadRunner完成第一个项目后，才发现这套工具其实就像汽车仪表盘——能直观显示系统在"高速行驶"时的各项指标。LoadRunner主要由三部分组成：Virtual User Generator（脚本开发）、Controller（场景控制）和Analysis（结果分析），这三大模块构成了完整的测试闭环。
以测试一个电商网站为例，我们需要模拟用户从登录、浏览商品到下单的全流程。LoadRunner的神奇之处在于，它能用虚拟用户（VUser）模拟真实用户行为，就像同时雇佣上千人操作网站。最新版的LoadRunner 12.21支持HTTP/HTTPS、WebSocket等多种协议，对于Web应用测试特别友好。安装时建议选择默认路径，避免后期出现兼容性问题。
提示：首次启动时建议关闭杀毒软件实时防护，某些组件可能被误判为风险程序
录制脚本前需要做好两项准备：一是确保测试环境网络稳定，二是准备好测试账号等基础数据。我曾在项目中发现，网络波动会导致录制的请求不完整，后期调试要花双倍时间补救。建议在局域网环境操作，避免使用公共WiFi。
2. 脚本开发全流程详解
2.1 脚本录制实战
打开Virtual User Generator，选择Web(HTTP/HTML)协议创建新脚本。点击录制按钮时，有个关键设置经常被忽略——Recording Options里的"UTF-8 Encoding"选项必须勾选，否则中文操作会录制成乱码。上周帮客户排查问题时，就遇到因编码问题导致登录失败的情况。
录制过程就像屏幕录像机：输入测试网址后，LoadRunner会自动打开浏览器并记录所有操作。以Redmine系统为例，完整的操作链应该包括：
- 访问登录页面
- 输入账号密码
- 点击登录按钮
- 执行核心业务操作
- 退出系统
录制完成后，会自动生成类似这样的代码片段：
web_url("login", "URL=http://test.com/login", "TargetFrame=", LAST);2.2 关联处理技巧
动态参数是性能测试最大的"坑"。比如CSRF token这类每次请求都变化的参数，必须通过关联(Correlation)处理。LoadRunner 12的智能关联已经能自动识别80%的常见参数，但关键参数仍需手动确认。
找到动态参数最有效的方法是：
- 在Tree View模式查看请求响应
- 搜索变化的值（如token=后面的字符串）
- 确定左右边界（就像用剪刀裁剪纸张）
关联函数典型结构如下：
web_reg_save_param_ex( "ParamName=token", "LB=name=\"csrf-token\" content=\"", "RB=\"", SEARCH_FILTERS, LAST);2.3 事务与断言配置
事务(Transaction)就像秒表，用来测量关键操作的耗时。创建事务要注意：
- 开始/结束必须成对出现
- 名称要有明确业务含义（如"Login"比"T1"更易读）
- 包含的请求要完整但不宜过多
断言(Assertion)则是质量守门员，我用得最多的是检查响应内容：
web_reg_find("Text=退出", LAST);这个检查点会验证登录成功后页面是否出现"退出"按钮。曾有个项目因忘记加断言，直到测试结束才发现所有请求都返回了错误页面。
2.4 参数化实战
真实场景需要模拟不同用户登录，这就用到参数化(Parameterization)。创建参数文件的要点：
- 用记事本保存为.dat格式
- 第一行定义参数名（如username,password）
- 后续行按行存储参数值
参数化设置对话框中有几个关键选项：
- Select next row：Sequential（顺序取值）更适合基准测试
- Update value on：Each iteration（每次迭代更新）
- When out of values：Abort Vuser（参数用完终止）
3. 场景设计与执行
3.1 基准测试配置
基准测试就像体检的基础项目，用于确认脚本能正常运行。Controller中设置：
- 虚拟用户数：1
- 运行时长：按迭代次数控制（建议50-100次）
- 思考时间：保留(Think Time)
重点观察平均响应时间是否稳定。某次测试发现响应时间从200ms逐步升到2s，最后查明是测试环境数据库连接池配置不当。
3.2 负载测试策略
模拟真实压力需要阶梯式增加用户。典型设置：
- 初始5用户
- 每2分钟增加5用户
- 达到50用户后持续10分钟
在Runtime Settings中要关闭日志（Log->Disable logging），否则会产生大量IO操作影响测试结果。监控重点包括：
- 事务响应时间曲线
- TPS（每秒事务数）波动
- 错误率变化
3.3 稳定性测试要点
马拉松式的稳定性测试最能暴露内存泄漏问题。配置要点：
- 虚拟用户数：最大并发数的70%
- 持续时间：8小时以上
- 思考时间：按实际业务比例设置
曾监测到某系统在运行6小时后内存占用从2GB飙升到8GB，最终定位到是缓存未设置过期时间。
4. 结果分析与报告
4.1 关键指标解读
Analysis生成的图表中，这几个指标最重要：
- 事务响应时间：重点关注90百分位数
- TPS曲线：理想状态应保持平稳
- 错误率：超过1%就需要排查
- 系统资源：CPU使用率超过80%即达瓶颈
4.2 监控工具集成
除了LoadRunner自带的监控，我习惯用nmon补充监控Linux服务器：
./nmon -f -t -s 30 -c 120这个命令会每30秒采集一次数据，持续1小时。生成的数据文件可以用nmon_analyser工具解析成直观图表。
4.3 报告制作技巧
导出HTML报告前，建议：
- 合并相同时间段的图表
- 添加问题分析注释
- 标记性能拐点
- 对比不同测试场景数据
最终报告应该像病历本，既呈现症状（性能指标），也包含诊断（分析结论）和处方（优化建议）。