简介这份资源是面向高校软件测试课程学习者与性能测试入门者的实验资料包对应软件测试质量保证课程中LoadRunner性能测试工具实验二重点解决并发批量注册用户与并发订票操作两类场景的脚本增强、参数化配置与结果分析问题。包内共356个文件以log运行日志、dat数据文件、txt说明、def定义文件、html报告、xml配置及c、h源码等为主另有少量cfg、ini、mdb等配置与数据库文件压缩包约2.19MB目录结构保留了脚本、参数文件与结果报告的原始组织方式。资源围绕集合点、事务、文本检查点等函数添加以及虚拟用户数、迭代次数、资源监控与Analyze Results分析流程展开并附有50并发20次迭代、10用户订票、阶梯加压至50并发等练习题参考。已有692人学习适合需要对照实验步骤、复盘脚本配置与排错思路的读者参考。1. 软件测试质量保证LoadRunner 性能测试工具实验二到底在测什么很多人第一次接触 LoadRunner 性能测试工具实验二会以为它只是实验一录制脚本的重复劳动。实际上实验一解决的是“能不能跑通”实验二解决的是“跑得够不够真、够不够狠、数据能不能信”。我带过几届新人做性能测试十个人里有八个卡在实验二脚本能回放报告也能生成但一问并发用户数怎么来的、事务响应时间为什么忽高忽低就答不上来。这篇笔记就围绕 LoadRunner 性能测试工具实验二这个场景把参数化、关联、集合点、场景设计和结果分析这条链路拆开讲。适合已经跑通过一次录制回放、准备把性能测试做扎实的测试工程师也适合要交实验报告但不想只交截图的学生。读完你至少能独立设计一个可信的并发场景并知道报告里哪些数字不能直接拿去汇报。2. 实验二的核心增量从单用户回放到多用户真实并发实验一和实验二最大的区别不是工具换了按钮而是测试目标变了。实验一只需要证明脚本能跑实验二要证明系统在压力下的表现。这个转变带来三个必须处理的问题数据不能重复、会话不能串、压力要能同步。下面先把这三个问题的原理讲清楚再落到具体操作。2.1 参数化为什么同一份数据跑十次就失效录制脚本时登录用的账号密码是写死的。回放一次没问题回放十次、一百次要么被系统当成重复请求拦截要么所有虚拟用户共用一条数据测出来的根本不是并发。参数化的本质是把脚本里的常量替换成变量让每个虚拟用户取到不同的值。常见做法是准备一个数据文件比如user.dat每行一组账号密码用逗号或制表符分隔。在 VuGen 里选中要替换的字符串右键选择替换为参数新建一个参数类型选文件指向这个数据文件。关键在“选择下一行”的策略默认是顺序取十个用户取十行第十一个用户会从头开始。如果数据文件只有十行而你要跑五十个并发就必须改成“唯一”或者“每次迭代取新值”否则后四十个用户拿到的还是前十个账号。user.dat 示例内容 testuser001,Pass001 testuser002,Pass002 testuser003,Pass003参数化之后还要注意一件事数据文件里的账号必须在被测系统里真实存在且没有被锁定。我见过有人用生产环境的账号做参数化跑完一轮把真实用户锁了一片这就是血泪经验。实验环境里最好提前用接口批量注册一批专用测试账号账号名带固定前缀方便跑完清理。2.2 关联动态值不处理脚本第二次就翻车关联是实验二最容易翻车的地方。录制的时候服务器返回一个动态的会话标识脚本把它当成固定值写死了。第一次回放服务器认第二次服务器生成新的标识脚本还在用旧的直接报错。这个动态值可能是登录后的 token、表单里的隐藏字段、或者某个校验码。处理关联的步骤分三步。第一步在录制日志或回放日志里找到报错位置确认是哪个请求的参数对不上。第二步在服务器返回的响应里定位这个动态值的来源通常在一个隐藏域或者 JSON 字段里。第三步在 VuGen 里用关联函数把这个值提取出来存成变量再替换到后续请求里。// 从登录响应中提取动态 token web_reg_save_param(AuthToken, LBname\token\ value\, RB\, SearchBody, LAST); // 后续请求引用提取到的变量 web_custom_request(submit_order, URLhttp://test-server/order/submit, MethodPOST, Bodytoken{AuthToken}item1001, LAST);web_reg_save_param必须写在产生该动态值的请求之前这是注册函数不是执行函数。LB和RB是左右边界用来在响应文本里定位目标值。SearchBody表示在响应正文里找如果动态值在响应头里要改成SearchHeaders。提取出来的变量用花括号引用比如{AuthToken}。如果边界找错了提取结果为空后续请求就会带着空 token 发出去报错信息往往指向后续请求容易误导排查方向。2.3 集合点并发不是同时点按钮那么简单很多人以为设置一百个虚拟用户就是一百个并发其实 LoadRunner 默认是逐步启动的每个用户跑自己的迭代彼此之间没有同步。要制造真正的瞬时压力必须用集合点。集合点的作用是让虚拟用户跑到某个位置时停下来等等够指定数量再一起放行。在脚本里插入集合点函数通常放在事务开始之前。然后在 Controller 的场景设置里配置集合点的策略比如“当百分之多少的用户到达集合点时释放”。如果策略设成百分之百而某个用户因为前置步骤失败永远到不了集合点整个场景就会卡死。所以实际做的时候我一般设成百分之八十到九十留一点容错空间。// 在事务开始前插入集合点 lr_rendezvous(login_rendezvous); lr_start_transaction(login); web_submit_data(login_action, Actionhttp://test-server/login, MethodPOST, EncTypeapplication/x-www-form-urlencoded, Nameusername, Value{username}, ENDITEM, Namepassword, Value{password}, ENDITEM, LAST); lr_end_transaction(login, LR_AUTO);集合点名字要和 Controller 里配置的一致大小写敏感。事务的起止位置也要卡准集合点放在事务外面否则等待时间会被算进事务响应时间数据就失真了。这一点在实验报告里经常被忽略导致响应时间虚高。3. 场景设计与执行把并发模型落到 Controller 里脚本调通只是第一步实验二的重头戏在 Controller 里设计场景。场景设计决定了你测出来的数据有没有参考价值。下面从场景类型选择、负载曲线设计、监控指标配置三个方面讲。3.1 手动场景还是面向目标场景先想清楚要回答什么问题Controller 提供两种场景类型。手动场景是你指定虚拟用户数和运行时长适合回答“系统在两百并发下能撑多久”。面向目标场景是你指定一个目标比如事务响应时间不超过两秒让工具自动调整用户数适合回答“系统最多能承受多少用户”。实验二通常要求做手动场景因为要观察不同并发梯度下的表现。我一般会设计三到四个梯度比如五十、一百、两百、三百用户每个梯度跑十分钟中间留五分钟冷却。这样能画出趋势曲线看出系统在哪个点开始劣化。如果只跑一个并发数报告里只有一个点说明不了容量拐点在哪里。场景设计里还有一个容易忽略的参数启动方式。同时启动所有用户会造成瞬间冲击逐步启动更接近真实流量。我一般用每十五秒启动五个用户的方式让压力平滑上升观察系统在不同负载阶段的反应。3.2 负载曲线与思考时间别把压测跑成 DDoS思考时间是虚拟用户两次操作之间的等待时间。录制脚本时VuGen 会记录你真实操作时的间隔回放时默认按录制值等待。如果直接忽略思考时间每个用户会以极限速度发请求测出来的吞吐量虚高响应时间也失真。在场景设置里思考时间有三种处理方式按录制值、按比例缩放、忽略。做容量测试时我一般按录制值的百分之五十到七十来缩放模拟用户操作快一点但还没到疯狂点击的程度。做稳定性测试时按录制值原样保留跑几个小时看系统会不会内存泄漏。Runtime Settings 中思考时间配置项 - Replay thinking time: As recorded / Multiply recorded thinking time by / Ignore - 建议容量测试Multiply by 0.5 ~ 0.7 - 建议稳定性测试As recorded如果完全忽略思考时间一百个用户可能产生上千 QPS被测系统如果没做限流直接被打挂。这不是系统性能不行是压测方式不对。实验报告里要写清楚思考时间的处理策略否则数据没法复现。3.3 监控指标光看 LoadRunner 的报告不够LoadRunner 自己会收集事务响应时间、吞吐量、虚拟用户数这些指标但系统层面的瓶颈它看不到。CPU 飙到百分之百、内存泄漏、数据库连接池耗尽这些信息要靠外部监控。常见做法是在被测服务器上开性能计数器Windows 用 PerfMonLinux 用 nmon 或 sar把数据导出来和 LoadRunner 的报告对齐时间轴。我一般会重点看四个指标事务平均响应时间、每秒事务数、服务器 CPU 使用率、数据库慢查询数量。如果响应时间上升的同时 CPU 没上去瓶颈可能在 IO 或者锁等待。如果 CPU 上去了但吞吐量没涨说明系统已经到处理极限。这些交叉分析才是实验二真正要练的能力。4. 避坑与排查实验二里最容易翻车的五个地方性能测试的坑大多不在工具本身而在环境、数据和理解偏差上。下面五条是我踩过或者见别人踩过的按现象、原因、解决三段写。4.1 回放成功但场景里大量报错现象在 VuGen 里单用户回放全部通过放到 Controller 里跑多用户错误率超过百分之三十。原因最常见的是参数化数据不够或者重复。单用户回放时只用第一行数据当然没问题。多用户并发时如果数据文件只有几行后面的用户取到重复账号被系统拒绝。另一个原因是关联没做全单用户时某些动态值恰好没变多用户时变了。解决先检查参数化文件的“选择下一行”策略改成唯一取值并确认数据行数大于最大并发用户数。再检查回放日志里有没有动态值警告把所有变化的字段都做关联。最后在 Controller 里先跑五个用户验证没问题再往上加。4.2 事务响应时间忽高忽低标准差比平均值还大现象报告里平均响应时间两秒但最大值二十秒标准差三秒数据没法用。原因通常是集合点策略设成了百分之百部分用户卡在集合点等待等待时间被算进了事务。或者是思考时间没设用户以极限速度发请求系统排队严重。还有一种可能是被测系统本身有定时任务在跑和压测时间重叠了。解决把集合点释放策略改成百分之八十到九十并把集合点放在事务外面。设置合理的思考时间不要忽略。确认压测期间没有其他定时任务或备份任务在跑。如果还不行把压测时间拉长看响应时间是不是周期性波动是的话就是系统内部有定时操作。4.3 吞吐量上不去但服务器资源很闲现象并发用户加到两百每秒事务数卡在一个值不动了服务器 CPU 和内存都很低。原因瓶颈可能在 LoadRunner 压测机本身。一台普通笔记本跑两百个虚拟用户CPU 和网络可能先到瓶颈。也可能是脚本里有同步等待比如某个请求串行执行限制了整体速度。还有可能是网络带宽不够请求发不出去。解决先看压测机的资源使用率如果压测机 CPU 满了换一台性能更好的机器或者用多台压测机分布式加压。检查脚本里有没有不必要的lr_think_time或者同步点。用ping和traceroute确认网络延迟正常。如果都没问题再回头查被测系统的中间件配置比如线程池大小、连接数限制。4.4 关联函数提取为空但边界看起来没错现象web_reg_save_param返回的变量是空字符串后续请求带着空值发出去报参数错误。原因边界字符串里有特殊字符没转义比如引号、反斜杠。或者响应内容被压缩了LoadRunner 默认不解压导致在压缩后的乱码里找边界当然找不到。还有一种情况是动态值在响应头里但Search参数写的是Body。解决在 VuGen 的 Generation Log 里看原始响应内容确认边界字符串和实际内容完全一致包括空格和引号。如果响应是 gzip 压缩的在 Runtime Settings 里开启“自动解压响应”。确认动态值的位置头里就用SearchHeaders正文里就用SearchBody。实在找不到用web_reg_save_param_regexp正则提取容错性更好。4.5 实验报告数据漂亮但无法复现现象报告里写了两百并发平均响应时间一点五秒但别人照着同样的脚本和场景跑结果差很远。原因没有记录环境信息。被测系统的版本、数据库数据量、中间件配置、压测机配置、网络环境这些都会影响结果。只写并发数和响应时间等于没写。解决报告里必须包含环境清单。被测系统版本和部署方式、数据库类型和数据量级、压测机 CPU 和内存、网络带宽、思考时间策略、集合点策略、参数化数据量。这些信息写清楚别人才有可能复现。我一般会做一个环境配置表跑之前填好跑完直接贴进报告。5. 从实验到实战让性能测试数据真正能用来做决策实验二做完你手里会有一份报告里面有响应时间、吞吐量、错误率。但这份报告能不能拿去支撑一个上线决策取决于你有没有做下面三件事。第一件事建立基线。性能测试不是跑一次就完要在系统稳定版本上跑一次基线记录各项指标。以后每次迭代或者上线前再跑和基线对比。如果响应时间涨了百分之二十以上就要查原因。没有基线的性能测试数据再漂亮也只是孤立的数字。我一般会把基线数据存成表格每次压测后更新形成趋势。第二件事做瓶颈定位而不是只报结果。报告里写“两百并发下响应时间三秒”这只是现象。要往下挖一层是应用服务器 CPU 满了还是数据库慢查询多了还是网络延迟大了。用前面说的交叉分析方法把 LoadRunner 的数据和系统监控数据对齐找到根因。这样开发团队才知道往哪个方向优化。第三件事区分容量测试和稳定性测试。容量测试是逐步加压找拐点稳定性测试是在百分之七十到八十的负载下跑几个小时甚至过夜。两种测试的脚本配置、思考时间策略、监控重点都不一样。实验二通常只做容量测试但实际项目里稳定性测试更能暴露内存泄漏和连接池耗尽这类问题。我一般会在容量测试找到拐点后用拐点百分之七十的负载跑一个四小时的稳定性测试观察内存和句柄数是否持续增长。下面是一个简单的稳定性测试场景配置参考用表格说明关键参数。配置项容量测试稳定性测试虚拟用户数梯度递增至拐点拐点的百分之七十运行时长每梯度十分钟四小时以上思考时间录制值的百分之五十录制值原样集合点启用百分之八十释放可选或不启用监控重点响应时间、吞吐量拐点内存、句柄、连接池趋势最后说一个我自己的习惯。每次跑完 LoadRunner 场景我不会马上关掉 Controller而是先把原始结果文件另存一份命名带上日期、版本、并发数。然后在报告里只放分析后的图表原始数据留档。因为过两周有人问你“当时那个两百并发的数据还在吗”你翻出原始文件比重新跑一遍省事得多。性能测试这行后悔药就是留档。希望帮到你。本文还有配套的精品资源点击获取