1. 项目概述为什么性能测试是项目交付前的“必考科目”刚入行那会儿我总觉得性能测试是个“锦上添花”的活儿功能跑通了不就行了直到有一次我们团队辛苦开发了三个月的电商系统在上线大促时直接“趴窝”页面加载慢如蜗牛支付接口频频超时用户投诉像雪片一样飞来。那次事故后我才真正明白性能测试不是选修课而是项目上线前必须通过的“压力测试”它直接关系到用户体验、业务收入和公司声誉。而LoadRunner就是这场“压力测试”中历史最悠久、功能最强大的“主考官”之一。虽然现在开源工具如JMeter、Locust风头正劲但LoadRunner在企业级复杂场景、协议支持深度和分析报告的专业性上依然有着不可替代的地位。特别是对于银行、电信、航空这类核心交易系统LoadRunner往往是性能测试团队的标配工具。这个教程就是带你从“零”开始亲手用LoadRunner完成一次完整的性能测试实战。我们不谈空泛的理论直接上手一个最经典的练手场景——飞机订票系统。你会学到如何录制脚本、模拟成千上万的虚拟用户、分析瓶颈在哪里最终拿出一份有说服力的性能测试报告。无论你是刚接触测试的新人还是想从JMeter等工具扩展到LoadRunner的工程师这篇“从零开始”的指南都能让你获得立即可用的实战能力。2. 环境准备与工具部署搭建你的第一个性能实验室工欲善其事必先利其器。在开始“施压”之前我们需要一个稳定、干净的测试环境。这里最容易踩坑的就是环境冲突和授权问题。2.1 LoadRunner的获取与安装要点首先明确一点LoadRunner是Micro Focus公司的商业软件个人学习可以通过其官网申请评估版Trial Version通常有30天或60天的完整功能使用期。绝对不要从任何非官方、来路不明的渠道下载所谓“破解版”这不仅涉及法律风险更可能捆绑恶意软件导致你的测试环境甚至开发网络出现严重安全问题。安装过程本身是图形化的向导比较直接但有三个关键决策点需要注意版本选择目前主流版本是LoadRunner 2022或2024。对于新手我建议选择稍早一点的稳定版如2022 R2因为网络上的教程和问题解决方案会更丰富。最新版可能引入了新特性但也可能伴随未知的Bug。组件选择典型安装包括Virtual User Generator (VuGen)用于录制和开发测试脚本的核心工具。Controller用于设计场景、管理和监控负载测试的控制中心。Analysis用于生成和分析测试结果报告的分析器。Load Generator (LoadGen)负载生成器负责真正执行脚本、产生压力的机器。对于初学者可以全部安装在一台性能较好的PC上建议16GB内存以上。在生产环境Load Generator通常部署在独立的服务器上。安装路径与权限安装路径避免使用中文或带有空格的目录例如D:\LoadRunner就比D:\性能测试工具\LoadRunner 2022要好得多。同时最好以管理员身份运行安装程序避免因权限不足导致某些服务如监控代理安装失败。安装完成后首次启动可能会要求你配置代理或输入许可证。评估版会自动配置临时许可证。如果遇到许可证错误请检查系统时间是否正确以及是否关闭了防火墙对LoadRunner通信端口的拦截默认端口通常为54345、8080等具体需查看文档。2.2 测试目标系统飞机订票系统部署为了实战我们需要一个可以“折腾”的系统。HP现Micro Focus官方提供了一个经典的样例程序叫做“HP Web Tours”这是一个模拟飞机订票的Web应用。它通常作为LoadRunner安装包的一部分被一起安装。你可以在开始菜单或安装目录下找到“HP Web Tours”的启动项。启动后它会运行一个本地的小型Web服务器默认端口通常是1080或8080。在浏览器中访问http://localhost:1080/WebTours你应该能看到一个航班订票网站的登录界面。这里有个关键步骤首次使用前需要点击页面上的“sign up now”链接注册一个新用户比如用户名jojo密码bean。这个操作会在后台初始化用户数据库。很多新手卡在第一步录制不到脚本就是因为没注册用户无法完成登录操作。把这个Web Tours服务保持运行它就是我们将要“攻击”的目标。把它想象成一个即将上线的小型航空公司官网我们的任务就是模拟大量用户同时来查询航班、订票、付款。2.3 基础概念扫盲脚本、场景、虚拟用户与事务在动手前快速理解LoadRunner的四个核心概念能让你后续操作不迷糊脚本 (Script)模拟单个用户的操作流程。比如“打开首页 - 登录 - 查询航班 - 选择航班 - 输入乘客信息 - 付款 - 登出”这一系列HTTP请求会被VuGen录制下来生成一个脚本。脚本是性能测试的“原子单位”。虚拟用户 (VUser)由LoadRunner模拟出来的、执行脚本的“机器人”。一个虚拟用户对应一个独立的线程或进程执行一份脚本。当我说“模拟1000个用户”就是指创建1000个VUser。场景 (Scenario)定义性能测试如何执行的“剧本”。在Controller中你告诉LoadRunner用多少个VUser负载模型运行哪个脚本在哪些负载生成器上运行运行多久要监控哪些服务器的指标如CPU、内存。事务 (Transaction)为了衡量系统性能我们在脚本中把关键的业务操作标记为事务。例如把“登录”操作标记为一个名为lr_login的事务。LoadRunner会统计这个事务的响应时间、成功率等。响应时间是性能测试最核心的指标之一它直接代表了用户的等待时间。理解了这些我们就可以进入下一步录制第一个能“动”起来的脚本。3. 脚本录制与开发让你的虚拟用户“学会”操作录制脚本是性能测试的第一步也是最容易出“杂音”的一步。一个录制得不好的脚本就像让一群没经过训练的演员上台结果要么演不下去要么演得完全不对。3.1 首次录制捕获飞机订票流程打开VuGen创建一个新的“Web - HTTP/HTML”协议脚本。给脚本起个名字比如Flight_Booking。录制配置在录制开始前弹出录制选项对话框。这里至关重要Application type选择Internet Applications。URL Address填入我们的目标地址http://localhost:1080/WebTours。Record into Action选择Action。LoadRunner脚本默认由vuser_init、Action、vuser_end三部分组成。通常我们把登录放在vuser_init只执行一次核心业务操作放在Action可以循环执行登出放在vuser_end只执行一次。首次录制我们先全放在Action里简化操作。录制方式确保选中“基于HTML的录制”这对于现代Web应用更友好能自动处理关联。开始录制点击OKVuGen会启动一个内置浏览器。你在这个浏览器里的所有操作都会被记录下来。现在请手动完整执行一遍订票流程访问http://localhost:1080/WebTours在登录框输入之前注册的用户名jojo和密码bean点击Login。点击“Flights”进入航班查询页面。选择出发城市和到达城市例如Denver到London点击“Continue”。选择航班班次比如第一班点击“Continue”。填写乘客信息姓名、地址等可随意填点击“Continue”。在支付页面输入信用卡信息样例程序不校验可随意填点击“Purchase”。看到订票成功的确认页面。最后点击右上角的“Sign Off”退出登录。停止录制完成操作后回到VuGen点击停止按钮。你会看到VuGen自动生成了一大段C语言的代码里面充满了web_urlweb_submit_data这样的函数每一个都对应着你刚才操作的一个HTTP请求。3.2 脚本优化与增强从“录像”到“智能脚本”刚录制的脚本是“死的”只能原样回放。如果直接用于压力测试所有虚拟用户都会用相同的账号jojo、订相同的航班这不符合真实情况也容易导致服务器缓存命中率异常高测试结果失真。因此必须对脚本进行参数化和关联。参数化 (Parameterization) 将脚本中的常量如用户名、密码、城市、航班日期替换为从数据文件中读取的变量。为什么这么做模拟真实世界中不同用户的不同行为。例如1000个用户应该使用1000个不同的用户名登录查询不同的航线。如何操作在VuGen中选中一个常量值如用户名“jojo”右键选择“Replace with a Parameter”。创建一个新参数如username选择参数类型为“File”。然后你需要创建一个文本文件如accounts.dat里面每一行就是一个用户名和密码的组合用逗号分隔。在参数属性中设置“Select next row”为“Unique”“Update value on”为“Each iteration”。这样每个虚拟用户每次迭代都会取一个唯一的用户名。关联 (Correlation) 处理服务器返回的动态值。这是LoadRunner脚本开发中最核心、也最容易出错的技术点。为什么需要关联Web应用经常使用Session ID、Token、动态生成的订单号等。这些值每次请求都会变化。录制时脚本里记录的是当时的一个具体值如sessionid12345。回放时服务器会生成一个新的值如sessionid67890如果脚本还发送旧的12345服务器就会拒绝请求导致脚本失败。如何操作LoadRunner有自动关联和手动关联两种。对于Web Tours一个常见的关联点是登录后服务器返回的userSession值。你需要找到这个值在响应中的位置通常通过“Scan Script for Correlations”功能或查看“Recording Log”然后使用web_reg_save_param函数将它捕获到一个参数中如lr_userSession并在后续请求中用这个参数{lr_userSession}替换掉硬编码的session值。一个关键技巧 关联函数如web_reg_save_param必须放在它要捕获的请求之前。因为它是注册一个“规则”告诉LoadRunner“在下一个请求的响应中按照这个规则去抓取数据”。添加事务 (Transaction) 在关键步骤前后插入lr_start_transaction和lr_end_transaction函数。例如把从点击“Flights”到出现航班列表的整个过程标记为“查询航班”事务。这能让我们在最终报告里清晰地看到每个业务环节的耗时。添加检查点 (Checkpoint) 使用web_reg_find或web_image_check函数验证页面是否包含关键文本如“Payment Details”以确保脚本执行到了正确的位置而不仅仅是服务器返回了HTTP 200状态码。经过这些步骤你的脚本就从简单的操作录像变成了一个可以模拟真实、多样用户行为的智能测试单元。接下来我们就要指挥千军万马虚拟用户来执行这个脚本了。4. 场景设计与执行指挥一场可控的“压力风暴”脚本准备好后我们移步到LoadRunner的“大脑”——Controller。在这里我们把单个用户的脚本编排成一场模拟真实用户访问的压力测试。4.1 构建基础负载场景在Controller中新建一个场景选择“Manual Scenario”手动场景它给我们最大的控制灵活性。将优化好的Flight_Booking脚本添加进来。设计负载模型这是场景设计的灵魂决定了压力如何施加。虚拟用户数初期可以设置一个较小的值比如50个VUser用于调试。负载生成器 (Load Generators)默认使用本地机。如果压力较大需要配置远程负载机。确保状态为“Ready”。Schedule计划这是核心配置区。Ramp Up逐步加压设置VUser如何启动。例如设置50个用户在5分钟内逐步启动完毕每6秒启动一个。这比瞬间启动50个用户更温和也更能观察系统在压力逐渐增大时的表现。Duration持续时间压力保持时间。例如所有用户启动后持续运行10分钟。这个时间要足够长以便观察系统在稳定压力下的性能表现如内存是否有缓慢泄漏。Ramp Down逐步退出设置用户在几分钟内逐步停止。给系统一个缓冲期来结束会话。配置运行时设置 (Run-time Settings)双击脚本进入运行时设置。这里有几个关键项Run Logic定义Action部分迭代执行的次数。Pacing设置迭代之间的间隔时间。可以固定间隔也可以随机间隔这能更真实地模拟用户思考时间。Log为了性能在正式压测时通常选择“Enable logging only when an error occurs”仅在出错时记录日志。调试阶段可以选“Standard log”。Think Time录制时捕获的用户操作间隔时间。在压测时我们通常忽略或按比例缩放思考时间以产生更大的压力。但要注意完全忽略思考时间会使压力远超真实情况可能得出不合理的结论。4.2 监控系统资源找到瓶颈在哪压力测试不只是看脚本能不能跑通更重要的是看服务器在压力下的状态。Controller提供了强大的监控功能。点击“Run”标签页在右侧的“Available Graphs”中将关键的监控指标拖到中央图表区。对于Web Tours这个本地应用我们需要监控运行它的Windows机器的资源System Resources-Windows Resources添加对localhost的监控。关键计数器包括% Processor TimeCPU使用率。持续高于80%可能成为瓶颈。Available Mbytes可用内存。如果持续下降可能有内存泄漏。Disk Time或Avg. Disk Queue Length磁盘IO情况。Network Interface\Bytes Total/sec网络吞吐量。Web Tours应用本身由于它是简单的CGI应用我们还可以通过Web Server Resource Monitor监控其连接数等如果支持。一个重要的实操心得在正式压测开始前先记录下服务器在无压力状态下的这些指标基线值。这样在压测中看到的增长才有对比意义。例如CPU基线是5%压测中涨到70%那就是显著的增长如果基线就是40%涨到70%则压力相对没那么大。4.3 执行测试与实时诊断点击“Start Scenario”按钮测试开始。Controller界面会动态显示虚拟用户的状态就绪、运行中、已完成、错误。事务的响应时间曲线。每秒点击率Hits per Second。吞吐量Throughput。以及你添加的各种资源监控计数器。这时你要像一个急诊室医生一样紧盯这些仪表盘如果错误数Errors突然飙升立即停止测试查看错误日志。常见原因是脚本关联没做好或者服务器应用崩溃了。如果事务响应时间随着用户数增加而线性增长说明系统处理能力可能已达到瓶颈。如果吞吐量曲线先上升后持平而用户数还在增加响应时间急剧上升这就是典型的系统饱和状态。第一次执行目标不是把系统压垮而是验证整个测试链条脚本-场景-监控是否通畅获取一个初步的性能数据。根据这次的结果我们再调整脚本、调整场景设计进行更深度的测试。5. 结果分析与报告生成从数据中讲述性能故事测试执行完毕数据都收集好了接下来是最关键的一步——分析。LoadRunner Analysis工具的作用就是把Controller收集到的海量原始数据变成一份能说明问题的性能报告。5.1 核心性能指标解读打开Analysis加载本次测试的结果文件。你会看到很多图表重点关注以下几类事务响应时间分析平均响应时间这是最直观的指标但要注意其局限性。如果90%的请求都很快但10%的请求极慢平均时间可能看起来“还行”但实际上用户体验很差。百分比响应时间这才是黄金指标。重点关注90th Percentile和95th Percentile响应时间。例如“登录”事务的90%响应时间是2秒意味着90%的用户在2秒内完成了登录。这比平均响应时间更能代表大多数用户的体验。如果业务要求是“95%的订单支付在3秒内完成”那么就直接看95%分位的响应时间是否达标。吞吐量与点击率吞吐量 (Throughout)单位时间内服务器成功处理的数据量通常以字节/秒计。它反映了系统的处理能力。吞吐量随着用户数增加而增加直到达到系统瓶颈后趋于平缓或下降。每秒点击率 (Hits per Second)单位时间内客户端向服务器发出的请求数。这个指标有助于判断负载是否真的施加上了。虚拟用户与错误运行中虚拟用户数对照你设计的场景计划看实际运行曲线是否符合预期如是否平滑上升、平稳保持、平滑下降。错误统计有哪些错误发生在什么阶段错误率是多少一个健康的系统在目标压力下的错误率应该极低例如0.1%。5.2 关联性分析与瓶颈定位单一指标很难定位问题必须进行关联性分析Merge Graphs。这是Analysis的精髓。经典关联将“运行中虚拟用户数”图与“事务平均响应时间”图合并。你会看到一条清晰的曲线随着用户数增加响应时间如何变化。如果响应时间在用户数达到某个点后急剧上升那个点可能就是系统的最佳并发用户数。资源瓶颈关联将“事务响应时间”图与“Windows Resources - % Processor Time”图合并。如果响应时间变差的同时CPU使用率也飙升至90%以上那么CPU就很可能是瓶颈。同理可以关联内存、磁盘IO等。以我们的飞机订票系统为例分析发现“查询航班”事务在用户数超过30后响应时间显著变长。同时监控到运行Web Tours服务的机器CPU使用率超过了85%。而磁盘和网络IO都很低。那么初步结论就是这个单机部署的Web Tours应用其处理能力很可能是CGI进程处理能力或数据库查询在30个并发用户左右达到了瓶颈CPU是主要制约资源。5.3 生成专业测试报告Analysis提供了强大的报告生成功能。你可以使用内置模板也可以完全自定义。一份合格的性能测试报告应包含测试概述测试目标、测试时间、测试环境服务器/客户端配置、测试工具及版本。场景设计虚拟用户数、加压策略、脚本业务逻辑简述。性能摘要核心事务的响应时间平均、90%分位、通过/失败事务数、总吞吐量。关键图表用户数-响应时间关联图、资源监控图突出显示瓶颈点。错误分析列出主要错误类型及数量。结论与建议这是报告的价值所在。基于数据给出明确的结论如“系统在30并发用户下满足3秒响应要求超过40并发则响应时间超标”并给出可操作的建议如“建议优化航班查询的SQL语句或对查询结果增加缓存预计可将瓶颈提升至60并发”。最后一个小技巧在生成报告前使用Analysis的“Auto Correlate”功能它有时能自动帮你找到与事务响应时间相关性最高的资源计数器为你的瓶颈分析提供线索。性能测试是一个“设计-执行-分析-优化-再测试”的循环过程。LoadRunner提供了完成这个循环所需的完整工具链。通过这个从零开始的实战你不仅学会了工具操作更重要的是理解了性能测试的核心思想通过模拟真实负载量化系统表现定位瓶颈所在为系统优化和容量规划提供数据支撑。下次当你再面对一个系统时你就能有计划、有步骤地对它进行“体检”确保它能在真正的业务洪流中屹立不倒。
LoadRunner性能测试实战：从零开始完成飞机订票系统压力测试
发布时间：2026/6/24 4:40:36
1. 项目概述为什么性能测试是项目交付前的“必考科目”刚入行那会儿我总觉得性能测试是个“锦上添花”的活儿功能跑通了不就行了直到有一次我们团队辛苦开发了三个月的电商系统在上线大促时直接“趴窝”页面加载慢如蜗牛支付接口频频超时用户投诉像雪片一样飞来。那次事故后我才真正明白性能测试不是选修课而是项目上线前必须通过的“压力测试”它直接关系到用户体验、业务收入和公司声誉。而LoadRunner就是这场“压力测试”中历史最悠久、功能最强大的“主考官”之一。虽然现在开源工具如JMeter、Locust风头正劲但LoadRunner在企业级复杂场景、协议支持深度和分析报告的专业性上依然有着不可替代的地位。特别是对于银行、电信、航空这类核心交易系统LoadRunner往往是性能测试团队的标配工具。这个教程就是带你从“零”开始亲手用LoadRunner完成一次完整的性能测试实战。我们不谈空泛的理论直接上手一个最经典的练手场景——飞机订票系统。你会学到如何录制脚本、模拟成千上万的虚拟用户、分析瓶颈在哪里最终拿出一份有说服力的性能测试报告。无论你是刚接触测试的新人还是想从JMeter等工具扩展到LoadRunner的工程师这篇“从零开始”的指南都能让你获得立即可用的实战能力。2. 环境准备与工具部署搭建你的第一个性能实验室工欲善其事必先利其器。在开始“施压”之前我们需要一个稳定、干净的测试环境。这里最容易踩坑的就是环境冲突和授权问题。2.1 LoadRunner的获取与安装要点首先明确一点LoadRunner是Micro Focus公司的商业软件个人学习可以通过其官网申请评估版Trial Version通常有30天或60天的完整功能使用期。绝对不要从任何非官方、来路不明的渠道下载所谓“破解版”这不仅涉及法律风险更可能捆绑恶意软件导致你的测试环境甚至开发网络出现严重安全问题。安装过程本身是图形化的向导比较直接但有三个关键决策点需要注意版本选择目前主流版本是LoadRunner 2022或2024。对于新手我建议选择稍早一点的稳定版如2022 R2因为网络上的教程和问题解决方案会更丰富。最新版可能引入了新特性但也可能伴随未知的Bug。组件选择典型安装包括Virtual User Generator (VuGen)用于录制和开发测试脚本的核心工具。Controller用于设计场景、管理和监控负载测试的控制中心。Analysis用于生成和分析测试结果报告的分析器。Load Generator (LoadGen)负载生成器负责真正执行脚本、产生压力的机器。对于初学者可以全部安装在一台性能较好的PC上建议16GB内存以上。在生产环境Load Generator通常部署在独立的服务器上。安装路径与权限安装路径避免使用中文或带有空格的目录例如D:\LoadRunner就比D:\性能测试工具\LoadRunner 2022要好得多。同时最好以管理员身份运行安装程序避免因权限不足导致某些服务如监控代理安装失败。安装完成后首次启动可能会要求你配置代理或输入许可证。评估版会自动配置临时许可证。如果遇到许可证错误请检查系统时间是否正确以及是否关闭了防火墙对LoadRunner通信端口的拦截默认端口通常为54345、8080等具体需查看文档。2.2 测试目标系统飞机订票系统部署为了实战我们需要一个可以“折腾”的系统。HP现Micro Focus官方提供了一个经典的样例程序叫做“HP Web Tours”这是一个模拟飞机订票的Web应用。它通常作为LoadRunner安装包的一部分被一起安装。你可以在开始菜单或安装目录下找到“HP Web Tours”的启动项。启动后它会运行一个本地的小型Web服务器默认端口通常是1080或8080。在浏览器中访问http://localhost:1080/WebTours你应该能看到一个航班订票网站的登录界面。这里有个关键步骤首次使用前需要点击页面上的“sign up now”链接注册一个新用户比如用户名jojo密码bean。这个操作会在后台初始化用户数据库。很多新手卡在第一步录制不到脚本就是因为没注册用户无法完成登录操作。把这个Web Tours服务保持运行它就是我们将要“攻击”的目标。把它想象成一个即将上线的小型航空公司官网我们的任务就是模拟大量用户同时来查询航班、订票、付款。2.3 基础概念扫盲脚本、场景、虚拟用户与事务在动手前快速理解LoadRunner的四个核心概念能让你后续操作不迷糊脚本 (Script)模拟单个用户的操作流程。比如“打开首页 - 登录 - 查询航班 - 选择航班 - 输入乘客信息 - 付款 - 登出”这一系列HTTP请求会被VuGen录制下来生成一个脚本。脚本是性能测试的“原子单位”。虚拟用户 (VUser)由LoadRunner模拟出来的、执行脚本的“机器人”。一个虚拟用户对应一个独立的线程或进程执行一份脚本。当我说“模拟1000个用户”就是指创建1000个VUser。场景 (Scenario)定义性能测试如何执行的“剧本”。在Controller中你告诉LoadRunner用多少个VUser负载模型运行哪个脚本在哪些负载生成器上运行运行多久要监控哪些服务器的指标如CPU、内存。事务 (Transaction)为了衡量系统性能我们在脚本中把关键的业务操作标记为事务。例如把“登录”操作标记为一个名为lr_login的事务。LoadRunner会统计这个事务的响应时间、成功率等。响应时间是性能测试最核心的指标之一它直接代表了用户的等待时间。理解了这些我们就可以进入下一步录制第一个能“动”起来的脚本。3. 脚本录制与开发让你的虚拟用户“学会”操作录制脚本是性能测试的第一步也是最容易出“杂音”的一步。一个录制得不好的脚本就像让一群没经过训练的演员上台结果要么演不下去要么演得完全不对。3.1 首次录制捕获飞机订票流程打开VuGen创建一个新的“Web - HTTP/HTML”协议脚本。给脚本起个名字比如Flight_Booking。录制配置在录制开始前弹出录制选项对话框。这里至关重要Application type选择Internet Applications。URL Address填入我们的目标地址http://localhost:1080/WebTours。Record into Action选择Action。LoadRunner脚本默认由vuser_init、Action、vuser_end三部分组成。通常我们把登录放在vuser_init只执行一次核心业务操作放在Action可以循环执行登出放在vuser_end只执行一次。首次录制我们先全放在Action里简化操作。录制方式确保选中“基于HTML的录制”这对于现代Web应用更友好能自动处理关联。开始录制点击OKVuGen会启动一个内置浏览器。你在这个浏览器里的所有操作都会被记录下来。现在请手动完整执行一遍订票流程访问http://localhost:1080/WebTours在登录框输入之前注册的用户名jojo和密码bean点击Login。点击“Flights”进入航班查询页面。选择出发城市和到达城市例如Denver到London点击“Continue”。选择航班班次比如第一班点击“Continue”。填写乘客信息姓名、地址等可随意填点击“Continue”。在支付页面输入信用卡信息样例程序不校验可随意填点击“Purchase”。看到订票成功的确认页面。最后点击右上角的“Sign Off”退出登录。停止录制完成操作后回到VuGen点击停止按钮。你会看到VuGen自动生成了一大段C语言的代码里面充满了web_urlweb_submit_data这样的函数每一个都对应着你刚才操作的一个HTTP请求。3.2 脚本优化与增强从“录像”到“智能脚本”刚录制的脚本是“死的”只能原样回放。如果直接用于压力测试所有虚拟用户都会用相同的账号jojo、订相同的航班这不符合真实情况也容易导致服务器缓存命中率异常高测试结果失真。因此必须对脚本进行参数化和关联。参数化 (Parameterization) 将脚本中的常量如用户名、密码、城市、航班日期替换为从数据文件中读取的变量。为什么这么做模拟真实世界中不同用户的不同行为。例如1000个用户应该使用1000个不同的用户名登录查询不同的航线。如何操作在VuGen中选中一个常量值如用户名“jojo”右键选择“Replace with a Parameter”。创建一个新参数如username选择参数类型为“File”。然后你需要创建一个文本文件如accounts.dat里面每一行就是一个用户名和密码的组合用逗号分隔。在参数属性中设置“Select next row”为“Unique”“Update value on”为“Each iteration”。这样每个虚拟用户每次迭代都会取一个唯一的用户名。关联 (Correlation) 处理服务器返回的动态值。这是LoadRunner脚本开发中最核心、也最容易出错的技术点。为什么需要关联Web应用经常使用Session ID、Token、动态生成的订单号等。这些值每次请求都会变化。录制时脚本里记录的是当时的一个具体值如sessionid12345。回放时服务器会生成一个新的值如sessionid67890如果脚本还发送旧的12345服务器就会拒绝请求导致脚本失败。如何操作LoadRunner有自动关联和手动关联两种。对于Web Tours一个常见的关联点是登录后服务器返回的userSession值。你需要找到这个值在响应中的位置通常通过“Scan Script for Correlations”功能或查看“Recording Log”然后使用web_reg_save_param函数将它捕获到一个参数中如lr_userSession并在后续请求中用这个参数{lr_userSession}替换掉硬编码的session值。一个关键技巧 关联函数如web_reg_save_param必须放在它要捕获的请求之前。因为它是注册一个“规则”告诉LoadRunner“在下一个请求的响应中按照这个规则去抓取数据”。添加事务 (Transaction) 在关键步骤前后插入lr_start_transaction和lr_end_transaction函数。例如把从点击“Flights”到出现航班列表的整个过程标记为“查询航班”事务。这能让我们在最终报告里清晰地看到每个业务环节的耗时。添加检查点 (Checkpoint) 使用web_reg_find或web_image_check函数验证页面是否包含关键文本如“Payment Details”以确保脚本执行到了正确的位置而不仅仅是服务器返回了HTTP 200状态码。经过这些步骤你的脚本就从简单的操作录像变成了一个可以模拟真实、多样用户行为的智能测试单元。接下来我们就要指挥千军万马虚拟用户来执行这个脚本了。4. 场景设计与执行指挥一场可控的“压力风暴”脚本准备好后我们移步到LoadRunner的“大脑”——Controller。在这里我们把单个用户的脚本编排成一场模拟真实用户访问的压力测试。4.1 构建基础负载场景在Controller中新建一个场景选择“Manual Scenario”手动场景它给我们最大的控制灵活性。将优化好的Flight_Booking脚本添加进来。设计负载模型这是场景设计的灵魂决定了压力如何施加。虚拟用户数初期可以设置一个较小的值比如50个VUser用于调试。负载生成器 (Load Generators)默认使用本地机。如果压力较大需要配置远程负载机。确保状态为“Ready”。Schedule计划这是核心配置区。Ramp Up逐步加压设置VUser如何启动。例如设置50个用户在5分钟内逐步启动完毕每6秒启动一个。这比瞬间启动50个用户更温和也更能观察系统在压力逐渐增大时的表现。Duration持续时间压力保持时间。例如所有用户启动后持续运行10分钟。这个时间要足够长以便观察系统在稳定压力下的性能表现如内存是否有缓慢泄漏。Ramp Down逐步退出设置用户在几分钟内逐步停止。给系统一个缓冲期来结束会话。配置运行时设置 (Run-time Settings)双击脚本进入运行时设置。这里有几个关键项Run Logic定义Action部分迭代执行的次数。Pacing设置迭代之间的间隔时间。可以固定间隔也可以随机间隔这能更真实地模拟用户思考时间。Log为了性能在正式压测时通常选择“Enable logging only when an error occurs”仅在出错时记录日志。调试阶段可以选“Standard log”。Think Time录制时捕获的用户操作间隔时间。在压测时我们通常忽略或按比例缩放思考时间以产生更大的压力。但要注意完全忽略思考时间会使压力远超真实情况可能得出不合理的结论。4.2 监控系统资源找到瓶颈在哪压力测试不只是看脚本能不能跑通更重要的是看服务器在压力下的状态。Controller提供了强大的监控功能。点击“Run”标签页在右侧的“Available Graphs”中将关键的监控指标拖到中央图表区。对于Web Tours这个本地应用我们需要监控运行它的Windows机器的资源System Resources-Windows Resources添加对localhost的监控。关键计数器包括% Processor TimeCPU使用率。持续高于80%可能成为瓶颈。Available Mbytes可用内存。如果持续下降可能有内存泄漏。Disk Time或Avg. Disk Queue Length磁盘IO情况。Network Interface\Bytes Total/sec网络吞吐量。Web Tours应用本身由于它是简单的CGI应用我们还可以通过Web Server Resource Monitor监控其连接数等如果支持。一个重要的实操心得在正式压测开始前先记录下服务器在无压力状态下的这些指标基线值。这样在压测中看到的增长才有对比意义。例如CPU基线是5%压测中涨到70%那就是显著的增长如果基线就是40%涨到70%则压力相对没那么大。4.3 执行测试与实时诊断点击“Start Scenario”按钮测试开始。Controller界面会动态显示虚拟用户的状态就绪、运行中、已完成、错误。事务的响应时间曲线。每秒点击率Hits per Second。吞吐量Throughput。以及你添加的各种资源监控计数器。这时你要像一个急诊室医生一样紧盯这些仪表盘如果错误数Errors突然飙升立即停止测试查看错误日志。常见原因是脚本关联没做好或者服务器应用崩溃了。如果事务响应时间随着用户数增加而线性增长说明系统处理能力可能已达到瓶颈。如果吞吐量曲线先上升后持平而用户数还在增加响应时间急剧上升这就是典型的系统饱和状态。第一次执行目标不是把系统压垮而是验证整个测试链条脚本-场景-监控是否通畅获取一个初步的性能数据。根据这次的结果我们再调整脚本、调整场景设计进行更深度的测试。5. 结果分析与报告生成从数据中讲述性能故事测试执行完毕数据都收集好了接下来是最关键的一步——分析。LoadRunner Analysis工具的作用就是把Controller收集到的海量原始数据变成一份能说明问题的性能报告。5.1 核心性能指标解读打开Analysis加载本次测试的结果文件。你会看到很多图表重点关注以下几类事务响应时间分析平均响应时间这是最直观的指标但要注意其局限性。如果90%的请求都很快但10%的请求极慢平均时间可能看起来“还行”但实际上用户体验很差。百分比响应时间这才是黄金指标。重点关注90th Percentile和95th Percentile响应时间。例如“登录”事务的90%响应时间是2秒意味着90%的用户在2秒内完成了登录。这比平均响应时间更能代表大多数用户的体验。如果业务要求是“95%的订单支付在3秒内完成”那么就直接看95%分位的响应时间是否达标。吞吐量与点击率吞吐量 (Throughout)单位时间内服务器成功处理的数据量通常以字节/秒计。它反映了系统的处理能力。吞吐量随着用户数增加而增加直到达到系统瓶颈后趋于平缓或下降。每秒点击率 (Hits per Second)单位时间内客户端向服务器发出的请求数。这个指标有助于判断负载是否真的施加上了。虚拟用户与错误运行中虚拟用户数对照你设计的场景计划看实际运行曲线是否符合预期如是否平滑上升、平稳保持、平滑下降。错误统计有哪些错误发生在什么阶段错误率是多少一个健康的系统在目标压力下的错误率应该极低例如0.1%。5.2 关联性分析与瓶颈定位单一指标很难定位问题必须进行关联性分析Merge Graphs。这是Analysis的精髓。经典关联将“运行中虚拟用户数”图与“事务平均响应时间”图合并。你会看到一条清晰的曲线随着用户数增加响应时间如何变化。如果响应时间在用户数达到某个点后急剧上升那个点可能就是系统的最佳并发用户数。资源瓶颈关联将“事务响应时间”图与“Windows Resources - % Processor Time”图合并。如果响应时间变差的同时CPU使用率也飙升至90%以上那么CPU就很可能是瓶颈。同理可以关联内存、磁盘IO等。以我们的飞机订票系统为例分析发现“查询航班”事务在用户数超过30后响应时间显著变长。同时监控到运行Web Tours服务的机器CPU使用率超过了85%。而磁盘和网络IO都很低。那么初步结论就是这个单机部署的Web Tours应用其处理能力很可能是CGI进程处理能力或数据库查询在30个并发用户左右达到了瓶颈CPU是主要制约资源。5.3 生成专业测试报告Analysis提供了强大的报告生成功能。你可以使用内置模板也可以完全自定义。一份合格的性能测试报告应包含测试概述测试目标、测试时间、测试环境服务器/客户端配置、测试工具及版本。场景设计虚拟用户数、加压策略、脚本业务逻辑简述。性能摘要核心事务的响应时间平均、90%分位、通过/失败事务数、总吞吐量。关键图表用户数-响应时间关联图、资源监控图突出显示瓶颈点。错误分析列出主要错误类型及数量。结论与建议这是报告的价值所在。基于数据给出明确的结论如“系统在30并发用户下满足3秒响应要求超过40并发则响应时间超标”并给出可操作的建议如“建议优化航班查询的SQL语句或对查询结果增加缓存预计可将瓶颈提升至60并发”。最后一个小技巧在生成报告前使用Analysis的“Auto Correlate”功能它有时能自动帮你找到与事务响应时间相关性最高的资源计数器为你的瓶颈分析提供线索。性能测试是一个“设计-执行-分析-优化-再测试”的循环过程。LoadRunner提供了完成这个循环所需的完整工具链。通过这个从零开始的实战你不仅学会了工具操作更重要的是理解了性能测试的核心思想通过模拟真实负载量化系统表现定位瓶颈所在为系统优化和容量规划提供数据支撑。下次当你再面对一个系统时你就能有计划、有步骤地对它进行“体检”确保它能在真正的业务洪流中屹立不倒。
