LoadRunner性能测试实战：从脚本开发到瓶颈分析全流程-北京尧图网络

简介面向性能测试初学者的一份LoadRunner实验报告基于Mercury Tours示例应用适配软件测试课程作业、实验报告撰写及工具自学场景。报告系统地梳理了实验目的与内容要求掌握脚本录制、编辑与执行技巧并灵活控制并发用户量、运行时间和数据量等参数以评估系统在不同负载下的性能表现。同时重点引入事务管理、集合点协调和参数化处理三类高级策略确保业务流程完整性与测试复用性。正文详细展示LoadRunner四大核心步骤Virtual User Generator创建和校验脚本Controller设计场景并调度虚拟用户运行负载模型以及分析响应时间、吞吐量、资源利用率等关键性能指标。此外还给出了录制Web登录、浏览、预订操作及查看测试结果的具体方法便于读者快速上手。资源包含1个docx文件大小1.83MB已有1872人学习既可作为课程报告的写作模板也能为实际项目的性能测试提供操作参考。1. 实验准备与测试环境搭建1.1 实验目标与需求拆解拿到这份LoadRunner测试实验报告先别急着打开Virtual User Generator录脚本。我做性能测试这十年见过太多同学把LoadRunner当成一个“录脚本工具”来用录完回放一遍就完事结果到了面试或者真实压测现场一问三不知。这次实验报告的核心目标很清晰通过LoadRunner对一个典型Web系统完成一次完整的性能测试闭环——从脚本开发、场景设计、结果采集到瓶颈分析。选择LoadRunner而不是JMeter、Gatling这类开源工具主要是因为LoadRunner在企业级性能测试领域的生态非常成熟它能把脚本开发、压力生成、系统监控、结果分析全部收在一个平台里尤其是Controller的监控集成能力和Analysis的报告体系在传统企业项目里依然是主流选择。做实验之前一定要先明确被测系统的边界和性能指标。比如这次实验针对的是一个带登录、查询、提交三类典型业务的Web应用重点考查并发用户数从50逐步提升到400的过程中系统吞吐量、响应时间和错误率的变化趋势。这里的核心需求不是说“把系统压挂”而是要找到系统在可接受响应时间比如90%请求在3秒内完成下的最大支撑能力顺便定位可能的瓶颈点。1.2 LoadRunner安装与版本选择安装这块我踩过不少坑多说几句。LoadRunner的版本迭代很快如果你只是做实验建议直接选择社区版或者当前企业常用的稳定版本不需要追求最新。我在实验中用的是较经典的版本它在Windows Server和Windows 10专业版上都能稳定运行不太容易出现兼容性问题。安装时有几个关键点安装路径不要带中文和空格默认路径是C:\Program Files\Micro Focus\LoadRunner如果你有洁癖想改路径务必保证整个目录没有中文。安装前关闭杀毒软件和Windows Defender实时防护否则License组件很容易被杀掉激活时会报错。Controller和Load Generator如果部署在同一台机器需要注意端口占用情况默认的54345端口不能被占用。如果系统装了多个版本的LoadRunner建议先彻底卸载再装新版。卸载不干净是执行场景时报错的高频原因卸载后最好手动删除残留的C:\Program Files\Micro Focus目录并清理注册表里的HKEY_LOCAL_MACHINE\SOFTWARE\Mercury Interactive相关内容。安装完成后先别急着写脚本用自带的示例项目比如自带的Web Tours订票系统跑一遍录制和回放确认整个链路是通的。这个习惯帮我排掉了无数环境问题。1.3 测试环境规划与基线数据收集性能测试有个铁律测试环境要独立至少要做到数据和业务逻辑和生产保持同构。这次实验我用的是一台8核16G的Windows机器部署被测Web应用LoadRunner的Controller和Load Generator在另一台4核8G的机器上避免压力机的资源竞争干扰测试结果。在正式做压力测试之前必须先做一次基准测试Baseline Test。所谓基准测试就是用少量并发用户比如10个跑一遍典型业务场景拿到基线数据平均响应时间、吞吐量、错误率。这一步非常关键后续所有压力测试的结论都要和基线对比。如果基线阶段响应时间就超过2秒说明系统本身就有问题后面压力测试的结论就没有意义了。我在实验报告里记录了一个很重要的基线数据登录接口的90%响应时间是180ms查询业务是520ms提交业务则是850ms。基于这组数据才能在后面判断400并发时哪些指标已经不可接受了。2. 测试脚本开发与核心增强技巧2.1 脚本录制流程与协议选择LoadRunner的VuGen支持HTTP/HTTPS、WebService、Socket、FTP等几十种协议。做Web系统压测时绝大多数场景选择Web - HTTP/HTML协议就够了除非你明确知道被测系统使用的是其他传输协议。录制前的设置建议花两分钟检查一下在VuGen的Recording Options里把“Recording Mode”选为HTML-based还是URL-based要看你后面的参数化和关联需要。HTML-based录制生成的脚本可读性好但某些动态请求会藏在上下文里URL-based录制更接近真实请求报文适合需要精确控制请求内容的场景。我这次实验采用的是URL-based模式因为需要手工改造的参数比较多这种模式下脚本的透明度和可控性更高。录制过程中有一个很实用的技巧不要一上来就把业务全部点一遍而是分层录制。比如先把登录流程单独录一段再录查询流程最后录提交流程。这样后面做脚本增强时可以单独处理每一段脚本也方便在Controller里按事务Transaction拆分统计。我见过很多新人把整个过程录成一个2000行的巨型脚本参数化、关联一上手就崩溃就是这个原因。2.2 参数化让脚本模拟真实用户行为压力测试最大的真实性障碍就是每个虚拟用户都提交一模一样的请求。你想想如果400个用户都用同一个账号登录被测系统大概率会触发会话冲突或者缓存命中的假象测出来的数据根本不准。参数化就是解决这个问题的核心手段。LoadRunner里做参数化很成熟在选中要替换的文本后右键选择“Replace with a Parameter”然后在参数列表里配置数据源即可。我这次的实验把登录账号、查询关键字、提交表单里的用户名都做了参数化。操作层面的经验参数的数据源尽量用文件File类型而非自动生成的随机数。随机数虽然省事但很难模拟真实的用户分布。比如查询关键字我用了一个几百行的文本文件内容是从线上日志里脱敏后的真实查询词。这样压测时系统产生的SQL查询分布更接近真实情况结果才有参考价值。参数化还有两个细节容易被忽视。第一参数分配策略Select Next Row在单用户多次迭代时要选“Sequential”或者“Random”而每个虚拟用户独立迭代时更常用“Unique”配合“Allocate Vuser values”来控制数据量的分配防止多个虚拟用户拿到相同数据。第二参数更新方式Update value on选择“Each iteration”会在每次迭代时重新取值选“Once”则在整个场景运行中保持不变这个要根据业务逻辑来判断选错了数据冲突率会明显上升。2.3 关联处理动态Session与Token如果说参数化是性能测试脚本的“外科手术”那关联就是“心脏手术”。服务器返回的动态数据比如Session ID、Token、时间戳如果下一次请求直接使用录制时的静态值回放必挂。我实验里遇到的最典型的关联场景是登录后的Session ID处理。录制脚本时从登录接口的返回报文里能看到一串类似sessionidAB12CD34EF56的内容后续所有业务请求的Header里都会带上它。处理办法是在登录请求后面加一个web_reg_save_param注册函数先从返回内容里解析出Session值再在其他请求中用{session_param}引用。实际写的时候是这样web_reg_save_param(session_id, LBsessionid, RB;, SearchBody, LAST);这段代码的意思是从上一个请求的响应体Response Body里找到sessionid开头、分号结尾的内容把匹配到的值存入session_id参数。之后在后续请求的Header中写入web_custom_request(...,URL/api/order, MethodPOST, EncTypeapplication/json, Body{request_body}, LAST);其中request_body再由其他关联参数拼接而成。如果你处理的系统用了JWT类的Token机制关联逻辑会复杂一些因为Token可能隐藏在JS代码里或者需要先调一个加密接口生成。我的习惯是先把服务器返回的所有内容通过web_reg_save_param的SearchAll选项抓下来然后在Replay Log里逐一排查确认哪些变量是动态的、哪些是静态的再逐个处理。这个排查过程虽然枯燥但非常必要跳过任何一个动态参数后面回放都会在某个环节突然报错。2.4 事务与思考时间设计脚本录好了、参数化关联都做完了紧接着就是要给脚本划分事务边界。事务是LoadRunner统计响应时间的最小单位你需要在业务关键操作前后插入lr_start_transaction和lr_end_transaction来标记lr_start_transaction(login); // 登录请求 lr_end_transaction(login, LR_AUTO);我在实验里设置的三个事务分别是“login”“search”“submit”对应三类核心业务。注意事务的粒度不要太小也不要太大。粒度太小比如把一次HTTP请求都拆成一个事务出来的报告密密麻麻根本没法定位问题粒度太大把登录和查询的整个流程包在一起一旦出问题你又不知道瓶颈到底在哪个环节。合理的事务边界是“一个完整的用户业务操作”比如“登录”和“登录后第一次查询”。思考时间Think Time是很多新人忽略的参数。虚拟用户的操作速度是毫秒级的真实用户每步操作之间必然有阅读、思考和输入的时间。如果没有思考时间压测出来的并发压力会远高于真实场景造成数据虚高或者系统被瞬间打死。LoadRunner里的lr_think_time会在录制的操作之间自动生成默认是开着的但很多人在实验里会给它“清零”来追求更高的压力值。我个人的建议是如果你的测试目标是“系统最大容量”思考时间可以适当缩短但不能完全去掉如果你的测试目标是“真实用户场景”思考时间应该保留并做随机化处理比如在lr_think_time中设置范围。在实验报告里我把思考时间统一设置为3秒的固定值并在备注里说明这是为了消除随机性、保证多次实验结论可比。3. 场景设计与压力施压策略3.1 Controller场景设计核心参数脚本准备就绪后就进入了LoadRunner最核心的部分场景设计。Controller里可以创建两类场景手动场景Manual Scenario和目标导向场景Goal-Oriented Scenario。手动场景适合做梯度压测你可以自己控制并发用户数、加载策略和持续时间目标导向场景则适合验证系统是否能达到某个明确指标比如每秒处理3000个请求。这次实验我选择的是手动场景。场景设计里最核心的参数是四个初始化方式Initialize、启动策略Start、持续时间Duration和停止策略Stop。初始化方式一般选“Initialize all Vusers before run”让所有虚拟用户在场景启动前完成脚本加载这样并发加压时才不会因为脚本初始化耗时导致压力不均匀。启动策略我用的是“每隔30秒启动10个虚拟用户”这样可以让系统有一个逐步承载的过程也能观察到系统在不同并发阶段的响应时间变化曲线。如果一上来就瞬间启动300个用户系统往往会因为瞬时连接泛滥而出现和真实瓶颈无关的错误。持续时间设置了十分钟配合持续期的监控能看出系统在稳定并发下有没有内存泄漏、连接泄漏之类的问题。结束策略选“停止所有虚拟用户”在停止前把还在处理中的请求跑完避免因为强行终止造成数据统计偏差。3.2 并发梯度设计与“拐点定位法”梯度加压是性能测试最重要的实践思路没有之一。一次压测不能只跑一个并发数那样你只能得到一个“数据点”而不是一条“性能曲线”。这次实验的并发梯度设计是50、100、200、300、400共五档每档跑10分钟中间休息5分钟让系统自动恢复。为什么要从50开始而不是直接上400因为性能测试的核心目标不是“压死系统”而是找到系统健康运行的边界。逐级加压可以观察到系统的响应时间、吞吐量和错误率如何随并发数变化尤其是找到“拐点”——也就是吞吐量不再增长甚至开始下跌的那个并发值这个值通常就是系统的容量上限。具体的操作步骤是在Controller的Scenario Group设置里把这几个梯度值设为不同Schedule的Start值或直接用多场景方式执行。我实验里比较习惯的做法是先用50并发跑一轮收集数据然后修改并发数再跑一轮最后把几轮的数据在Analysis里做叠加对比。这样虽然费点时间但每轮数据都是干净的比在一个场景里用Ramp Up曲线硬切并发更可控。需要特别关注的一个指标是“吞吐量-并发数”曲线的形态。随着并发数上升吞吐量应该先是近似线性上升然后增长放缓最后出现回落。回落的那个峰值点对应的并发数就是系统的“最优点”。在实际项目中我会在这条曲线的拐点附近加测一轮更细粒度的并发比如250、275、300把拐点的位置定位得更精确。3.3 监控指标与实时数据采集Controller的运行界面可以实时看到Running Vusers、Hit Rate、Throughput、Response Time等十几个关键指标但只看这些默认指标远远不够。做性能测试要有的放矢在运行场景的同时打开Controller的“Diagnostics → Configuration”把关键网页细分和组件细分都打开这样Analysis里才能拿到每个页面的细分耗时数据。我这次配置的监控项主要包括虚拟用户运行数和错误数判断加压过程是否正常。吞吐量Throughput单位时间内服务器返回的字节数反映系统处理能力。每秒HTTP响应数HTTP Responses per Second反映应用层的请求处理速率。平均响应时间与90%响应时间注意平均响应时间容易被极端值拉高要看百分位数更准确。系统资源监控在Controller的Unix Resources和Windows Resources里填写被测服务器的IP用管理员账号连接后就能采集CPU、内存、磁盘队列、网络流量等指标。命令行的资源监控我也习惯一起开着。在服务器上执行top或者vmstat把输出留档一份方便后续和LoadRunner的监控数据交叉比对。这个习惯帮我排过一次大坑当时LoadRunner显示的是应用响应时间飙升但Windows资源监控里CPU和内存都是正常的后面查出来是数据库连接池满了。如果没有操作系统的独立监控日志对照光看LoadRunner的图很难定位到这一层。4. 测试执行过程与结果深度分析4.1 执行过程记录与实时观测要点场景开始运行后我习惯把Controller的界面布局调成“左侧是虚拟用户运行数的时间序列图右侧是响应时间和吞吐量的实时图”。这样一眼就能看出三者之间的关系。在50并发阶段响应时间和吞吐量的曲线都很平稳平均响应时间在200ms左右浮动这说明系统状态健康。到200并发阶段平均响应时间开始从上到下出现起伏吞吐量还在缓步上升但已经不像50到100那段那么陡峭。等到了300并发阶段现象就很明显了吞吐量曲线几乎走平而平均响应时间开始翻倍上涨错误率从0开始有了零星的数值。到了400并发阶段错误率直接跳到了4.6%90%响应时间也突破了3秒大关。执行过程中最值得记录的就是这些“瞬时变化”。我会在实验报告的备注栏里记录每个时段观察到的异常现象比如“15:23300并发阶段响应时间出现明显尖峰大约持续30秒后回落疑似Full GC导致。”这种现场记录对后续定位问题非常有帮助比事后看曲线猜原因要准确得多。4.2 分析报告核心图表解读方法场景运行结束后LoadRunner会自动生成Analysis报告。很多人打开报告后一脸懵不知道从哪里看起。我给你一个固定的分析路径第一步看Summary Report里的“Transaction Summary”表。这里能直接看到每个事务的平均响应时间、90%响应时间、通过率和失败率。我这次实验的结果是login事务在400并发时90%响应时间为3.2秒search和submit事务分别为4.1秒和6.8秒。一眼就能看出submit事务是最薄弱的环节。第二步看“Average Transaction Response Time”图。这张图能看出事务响应时间随运行时间的变化趋势如果曲线呈现“阶梯式上涨”说明压力递增导致了系统性能的逐步恶化如果曲线是“过山车式”的剧烈波动那就要怀疑是不是有定时任务或者后台批处理在干扰。第三步看上图“Throughput”和“HTTP Responses per Second”的对比。如果吞吐量持续走高但每秒事务数TPS不再增加说明系统进入了“处理能力饱和区”——服务器还在拼命收发包但应用的处理速度已经跟不上了。第四步去“Web Page Breakdown”里看每个页面的细分耗时。这里能拆出DNS解析、连接建立、首字节时间TTFB、下载时间等环节帮你定位是网络传输问题还是服务器处理问题。4.3 瓶颈定位与调优建议结合LoadRunner的监控数据和操作系统层面的资源数据这次实验的瓶颈定位非常明确从Web Page Breakdown里看submit事务的TTFB占了总响应时间的78%。TTFB过高说明问题出在服务器端处理环节而不是网络传输。配合被测服务器的Windows资源监控数据CPU在400并发时确实到了85%以上但CPU队列并不是瓶颈反而是磁盘的% Disk Time长期处于90%以上说明磁盘I/O出现了严重瓶颈。再往下一层查submit业务每次提交都要做一次文件上传和数据库写入文件的落盘操作在高并发下触发了磁盘队列堆积导致整个事务被拖慢。这个结论在现场记录里也有印证——300并发时响应时间出现尖峰那次正好是磁盘队列从个位数飙到20以上。针对这个瓶颈我给出的建议排序是优先把上传文件的存储从本地磁盘迁移到SSD或者对象存储服务降低单盘I/O压力其次优化数据库写入逻辑考虑批量提交最后才是考虑增加应用服务器节点做水平扩展。做性能测试的意义就在这——不是压完了事而是把问题的层级和前后顺序摸清楚让开发和运维能按优先级去整改。5. 常见问题与实操排坑实录5.1 脚本回放失败的典型原因做实验时脚本回放失败是最打击人信心的环节但其实90%的失败原因都是下面几个参数化数据不足。如果参数文件里的数据量小于虚拟用户数乘迭代次数LoadRunner会自动循环使用数据看似没问题但如果选择了“Unique”分配策略就会报“no more values”错误。解决方法是把文件名后缀改成.dat并按行组织数据同时估算好数据量。关联漏失。最典型的特征是回放时登录成功但下一个请求报错“session invalid”或“401 Unauthorized”。解决办法是把动态值先通过web_reg_save_param全部抓出来再逐个替换请求中的硬编码。录制环境代理设置残留。如果录制时走的是本机代理回放时代理未关闭会导致请求发不出去。VuGen里在“Tools → Recording Options → Proxy”里仔细检查即可。我还遇到过一种比较隐蔽的情况回放时某个接口偶尔成功偶尔失败后面发现是因为录制脚本里的Content-Type写死了而实际的请求在某种条件下会用另一种Content-Type。这种问题用Response Body里的错误提示完全看不出来必须在Replay Log里打开“Extended log”的Parameter substitution把请求报文完整打出来才能发现请求头和录制时的差异。5.2 场景执行中的测试机与网络坑场景跑到一半突然报错“Connection refused”或“Timed out”第一反应不要怪被测系统先检查负载生成器Load Generator的状态。常用命令是rstat查看负载机资源如果负载机自身CPU都100%了那产生出来的压力数据本身就不可信。还有一次实验我用的负载机和被测服务器之间有防火墙流量一大就触发了连接数限制的规则导致大量请求被拦在防火墙层。这时LoadRunner报告里的错误率和响应时间完全反映的是防火墙的行为而不是被测系统的性能。排查办法是先用ping和telnet确认网络链路的稳定性再做一次小压力验证确认连接数不会触发安全策略。负载机的时间同步问题也很重要。如果Controller和Load Generator的时间偏差超过几秒事务开始时间和结束时间记录会错位最终Analysis里的响应时间数据就失真了。实验前用NTP同步一下时间成本极低收益很大。5.3 结果数据异常时的排查思路压测结果和直觉严重不符时不要急着改脚本重跑先按下面几个方向排查对比同一次执行中LoadRunner的事务响应时间和服务器端的Tomcat/Apache访问日志耗时是否一致。不一致说明中间有传输层或代理层的额外耗时。检查场景是否出现了“思考时间未生效”或者“迭代间隔被压缩”的问题。很多团队在Controller里会默认开启“Ignore think time”如果开了又不知道真实用户的思考时间会完全消失数据必然虚高。看是否有“Pacing”设置介入导致迭代节奏异常。Pacing本意是控制两次迭代之间的间隔时间但设置不当会导致用户在压力到达前就排队等待。确认脚本中是否因为事务嵌套导致数据统计重复。多层lr_start_transaction标签混用可能出现计时重叠让某个事务的响应时间异常拉长。实验数据出现异常时我总提醒自己一句话LoadRunner只是一个工具它老老实实地记录了你给的脚本和场景产生的流量问题是人配置出来的。6. 实验结论与个人经验小结6.1 数据结论汇总与可交付成果这次LoadRunner性能测试实验最终输出的成果不只是几个图表和一堆参数而是三个可以直接交付的产物一份压测数据报告、一份瓶颈分析报告和一份调优建议清单。三者分开写是因为面向的读者不同——数据报告给项目管理层看趋势瓶颈分析给开发团队看问题点调优建议给运维和实施团队看改法。从压测数据看被测系统在200并发以内表现健康300并发开始出现性能分化400并发时submit事务的响应时间和失败率已经不可接受。这个结论是明确的但也要说明它的边界条件实验环境、数据量、网络拓扑都和线上有差距这里的“最大并发数”不能直接等同于生产环境的容量上限必须经过等比换算和经验修正才能用于容量规划。6.2 给初学者的建议与复盘感悟如果你正在学习LoadRunner我建议你先把精力放在“理解业务流程”和“理解系统架构”上工具操作反而是最不花时间的部分。一个优秀的性能测试工程师拿到一个系统时最先想的不是“这个脚本怎么录”而是“这个系统的压力会从哪里进来、瓶颈最可能出现在哪一层、我该用什么样的场景去验证我的判断”。另一点是性能测试的报告思维。每次压测完成后花点时间把结论整理成简洁的表格和曲线图标注清楚测试条件、样本量和异常现场而不是只丢出几个数字。这份实验报告如果能让一个没参与测试的人也快速看懂系统的性能画像那它就是一份合格的作品。我在实际工作里见过太多测试工程师把时间花在反复调脚本上却不关心压测结论能不能指导系统优化。工具终会迭代但“先假设、再验证、后下结论”的测试方法论才是这份实验真正值得沉淀下来的能力。做完这次实验你至少应该掌握一件事当领导问你“这系统能撑多少人”时你不再拍脑袋而是能拿出数据、说出理由、给出建议。本文还有配套的精品资源点击获取

LoadRunner性能测试实战：从脚本开发到瓶颈分析全流程

相关推荐

Hasura GraphQL Engine 中的托管资源管理：从 `Managed` 到 `ManagedT` 的 Monad 变换器实践

com.blankj:utilcodex:1.26.0 装不上 Android 12？让走 TaoToken 的 Codex 查

免费把QQ空间所有说说导出到本地：GetQzonehistory 使用指南

更多资讯

GBrain Ingest 技能深度解析：路由式内容摄取管线与大脑写入契约

基于树莓派与ONNX的50Hz双足机器鸭神经控制闭环实战

Luigi 工作流构建指南：深入理解 Task、Target 与 Parameter 三大核心抽象

嵌入式AI重构传感器：TinyML在MCU上的工程实践

软考高项论文写作攻略：十大管理领域框架与实战技巧

Readest 固定版式书籍的 RTL 页面顺序修复：从 5591 看横向从右到左（RTL）阅读的实现与调试

今日更新

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本周精选

深入解析Transformer多头注意力机制与工程优化

OpenClaw 的 Skills 跑学习任务，模型通道改到 TaoToken 通道行不行？

ChatGPT报错Oops, an error occurred! 全链路排查指南

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？