1. 项目概述为什么模拟真实用户压力是性能测试的基石刚入行做性能测试那会儿我最常听到的一句话就是“我们服务器配置很高为什么用户一多就卡” 这个问题背后往往隐藏着一个核心误区开发环境或测试环境的少量请求根本无法模拟生产环境中成百上千、行为各异的真实用户并发访问。这就好比用一辆家用轿车在空荡荡的赛道上测试然后宣称它能应对F1赛事的激烈缠斗结论显然是站不住脚的。性能测试的核心价值就在于用尽可能贴近真实的方式提前发现系统在高压下的瓶颈和隐患。而LoadRunner作为一款老牌且功能强大的性能测试工具其核心组件Virtual User GeneratorVUGen正是实现这一目标的“剧本编写器”。它不像一些简单的HTTP压测工具那样只会“傻发请求”VUGen的精髓在于它能录制、编辑和增强用户与应用程序交互的每一个步骤生成一个可以模拟人类思考、等待、操作序列的“虚拟用户”脚本。本次我们就以LoadRunner自带的经典演示程序WebTours为例深入拆解如何利用VUGen设计出高质量的脚本并构建出能反映真实业务压力的测试场景。WebTours是一个模拟机票预订的Web应用包含了登录、查询航班、选择航班、支付等典型电商业务流程是学习脚本设计的绝佳沙盒。如果你正面临系统上线前心里没底、线上偶发性卡顿无从复现、或者想科学评估系统扩容需求的困境那么掌握从脚本到场景的完整方法论将是你从“功能测试思维”转向“用户体验与系统健壮性思维”的关键一步。接下来我将结合多年踩坑经验为你还原一个完整的实操过程。2. 脚本设计超越“录制-回放”的五个核心细节很多人对LoadRunner脚本的认知停留在“用VUGen录制一遍操作然后直接拿去跑”。这是性能测试中最常见的“浅水区陷阱”这样得到的脚本往往脆弱、不真实且无法有效暴露问题。一个健壮的脚本必须经过精心设计和增强。下面我们以WebTours的“登录-查询航班-订票”主流程为例拆解五个必须关注的细节。2.1 事务定义衡量性能的标尺事务是性能测试中度量响应时间的核心单元。它标记了脚本中一系列操作的开始和结束最终测试报告会告诉你每个事务的平均响应时间、通过率等关键指标。定义事务不是简单地包裹几个请求而是需要从用户感知和业务逻辑两个维度进行思考。在WebTours脚本中我们至少应定义三个事务lr_login 从输入用户名密码到成功跳转到首页。lr_search_flight 输入出发地、目的地、日期到返回航班列表。lr_book_ticket 选择航班、填写乘客信息、完成支付到出现订票成功页面。关键细节事务的起始点和结束点。很多人容易把web_submit_form或web_url函数直接当作事务。更专业的做法是事务应该开始于一个用户明确触发动作的请求如点击“登录”按钮对应的web_submit_data(“login.pl”)结束于下一个用户可交互页面加载完成如登录后首页的web_url(“welcome.pl”)。在VUGen中使用lr_start_transaction(“事务名”)和lr_end_transaction(“事务名”, LR_AUTO)来包裹这些操作。实操心得事务名最好有统一前缀如lr_便于在结果分析中快速筛选。LR_AUTO参数让LoadRunner自动判断事务状态成功/失败通常够用但对于需要根据业务结果如检查文本“Booking Confirmation”来判断成功的情况需手动使用LR_PASS或LR_FAIL。2.2 参数化让虚拟用户“活”起来如果100个虚拟用户都用同一个账号“jojo”和密码“bean”去登录WebTours会发生什么首先这不符合真实场景其次可能会因为会话冲突、数据库锁等问题导致测试结果失真。参数化就是将脚本中的常量如用户名、密码、出发城市替换为从数据源读取的变量。以登录用户名为例原始脚本可能是web_submit_data(“login.pl”, “Nameusername”, “Valuejojo”, ENDITEM, ...);我们需要将其改造为web_submit_data(“login.pl”, “Nameusername”, “Value{Username}”, ENDITEM, ...);这里的{Username}就是一个参数。接下来在VUGen的Parameter List中我们可以为Username参数创建一个文件如users.dat里面按行存放不同的用户名jojo,test1,test2,john... 并为该参数设置“Select next row”为“Unique”“Update value on”为“Each iteration”。关键细节参数化策略的选择。这是最容易出错的地方之一。唯一性Unique 每个Vuser在每次迭代中取一个唯一值用完为止。适用于注册、创建订单等不能重复的业务。随机Random 每次从数据池中随机取。模拟真实用户的不确定性但可能重复。顺序Sequential 按顺序取循环往复。简单但可能不够真实。与Vuser ID绑定 根据虚拟用户编号来取确保同一个Vuser在整个场景中行为一致。对于WebTours登录我们通常采用“Unique”策略确保并发用户使用不同账号避免服务端会话覆盖。对于搜索的出发城市则可以采用“Random”或“Sequential”来模拟不同用户的查询需求。2.3 关联处理动态会话标识现代Web应用大量使用动态值来维持状态如Session ID、ViewState、CSRF Token等。录制时这些值被硬编码在脚本里回放时服务器会生成新的值如果脚本仍发送旧值请求就会失败。关联就是自动捕获服务器响应中的动态值并将其保存为参数供后续请求使用。LoadRunner VUGen有自动关联和手动关联两种方式。对于WebTours一个典型的关联点是用户会话标识。录制脚本后你可能会在多个请求中看到一个长的、类似sessionid7F8C3A2B4D5E的参数。关键细节如何精准定位需要关联的动态值对比录制与回放日志 回放失败时查看VUGen的回放日志Replay Log找到第一个出错的请求。对比该请求在录制日志Recording Log和回放日志中的差异不同的那个值很可能就是需要关联的动态值。使用扫描功能 在VUGen中选择“Tools” - “Scan Script for Correlations”工具会自动扫描并建议关联点。这是一个很好的起点但并非100%准确需要人工复核。手动关联最可靠 在树形视图Tree View中找到生成该动态值的服务器响应通常在出错请求的前一个请求。在响应体Response Body中找到该动态值如name”userSession” value”12345.ABC”。右键点击该值选择“Create Parameter”并为其命名如Corr_UserSession。然后VUGen会在脚本中插入类似web_reg_save_param_ex(“ParamNameCorr_UserSession”, “LBname\”userSession\” value\””, “RB\””, SEARCH_FILTERS, …);的函数。这个函数必须在发出使用该参数的请求之前被调用。注意事项web_reg_save_param_ex是一个“注册型”函数它告诉LoadRunner“请留意接下来的服务器响应并按照我给的左右边界LB/RB把中间的内容存起来”。它必须放在web_url或web_submit_data等请求函数之前否则不会生效。这是关联操作中最常见的错误之一。2.4 检查点验证业务是否真的成功脚本回放成功返回HTTP 200状态码并不代表业务成功。比如搜索航班时可能因为无匹配结果服务器返回了一个“No flights found”的页面HTTP状态码依然是200。如果不加验证我们会错误地认为搜索事务成功了。检查点就是在服务器返回的页面内容中查找特定的文本或图片来验证业务逻辑的正确性。在WebTours中登录成功后页面通常会有“Welcome”字样订票成功后会有“Invoice”或“Confirmation”字样。我们可以在这些关键步骤后添加文本检查点。在VUGen中你可以在脚本视图Script View中在需要添加检查点的请求函数如web_url(“welcome.pl”)之后插入web_reg_find函数。更直观的方法是在树形视图Tree View中右键点击某个请求的响应体选择“Add Text Check”然后输入要查找的文本。关键细节检查点的作用域与性能影响。web_reg_find也是一个注册型函数必须放在它要检查的请求之前。它的作用是“请检查下一个请求的响应内容中是否包含某文本”。检查点会消耗一定的系统资源。在负载极高的场景下过多的检查点可能影响测试机性能从而影响测试结果精度。因此只在对业务成功至关重要的关键步骤上添加检查点例如登录、提交订单、支付成功页。对于中间的数据查询列表页可以酌情省略。2.5 思考时间与步调模拟真实用户的操作节奏真实用户不会像机器一样毫不停歇地点击。他们在页面间浏览、阅读、比较、思考这些停顿时间就是“思考时间”。在录制脚本时VUGen默认会记录这些间隔。但在回放时我们需要决定是否保留以及如何设置这些思考时间。关键细节思考时间的两种处理模式与步调控制。忽略思考时间Ignore think time 用于测试系统在最大吞吐量下的表现即“服务器在单位时间内最多能处理多少笔业务”。此时虚拟用户会以最快速度循环执行脚本不考虑人为延迟。这用于探测系统的极限能力。回放思考时间Replay think time 用于模拟真实并发用户场景。可以按录制时的原始时间回放也可以使用一个倍数如0.5倍加速2倍减速或者设置为一个固定范围随机在3-7秒之间。这用于评估在真实用户操作节奏下系统的响应时间是否达标。步调是另一个重要概念它控制一个虚拟用户完成一次脚本迭代比如完成一次完整的订票流程后需要等待多长时间才开始下一次迭代。设置步调可以更精确地控制业务到达率每秒产生多少笔业务。例如如果希望模拟每秒产生2个订单而一个虚拟用户完成一次迭代平均需要10秒那么大约需要20个并发虚拟用户不考虑思考时间才能达到这个速率。在Controller中可以在“Schedule Builder”的“Start Vusers”和“Duration”设置中更精细地控制Vuser的启动、停止节奏这比简单的迭代循环更贴近真实。3. 场景构建从脚本到真实压力模型的转化有了一个健壮的脚本就像有了一个优秀的演员剧本。但一场大戏的效果还取决于导演如何调度这些演员——这就是LoadRunner Controller的场景构建环节。场景设计决定了压力如何施加到系统上其科学性直接决定了测试结果的可信度。3.1 虚拟用户组与负载生成器管理在Controller中你需要将VUGen生成的脚本.usr文件加载进来形成一个虚拟用户组。一个场景可以包含多个用户组模拟不同类型的用户行为例如80%的用户只浏览搜索20%的用户执行下单。关键细节负载生成器的配置与“多机负载”。 当需要模拟的并发用户数成百上千时单台测试机的网络、CPU、内存可能成为瓶颈导致无法产生足够的压力或者测试结果包含测试机本身的性能损耗。此时需要使用多台机器作为负载生成器。在Controller机器上确保LoadRunner Agent Process默认为magentproc.exe服务已启动。在负载生成器机器上安装LoadRunner并确保LoadRunner Agent Process服务已启动且防火墙允许了相应的端口默认50500、54345等。在Controller的“Load Generators”对话框中添加负载生成器的IP地址并点击“Connect”进行连接。状态显示为“Ready”方可使用。在场景设计界面可以将虚拟用户分配到不同的负载生成器上实现压力分流。实操心得务必监控负载生成器自身的资源使用率CPU、内存、网络。如果某台生成器资源使用率持续超过70%它本身就可能成为瓶颈需要减少其分配的Vuser数量或增加新的负载生成器。测试结果中如果出现大量“Timeout”或“Error -27796”错误首先要排查负载生成器网络是否通畅、性能是否吃紧。3.2 调度策略压力曲线设计艺术调度策略是场景设计的灵魂它定义了虚拟用户如何随着时间启动、运行和停止。Controller提供了强大的调度器Schedule Builder主要包含以下几个阶段初始化Initialize 所有Vuser在运行前先执行一次vuser_init部分通常用于登录。可以选择“同时初始化所有Vuser”或“在运行前初始化”。对于需要建立独立会话的场景建议选择“在运行前初始化”避免所有用户在同一瞬间登录对系统造成不真实的冲击。启动Start Vusers 定义Vuser如何逐渐启动。例如“每15秒启动2个Vuser”这模拟了用户逐渐进入系统的情况比“瞬间启动所有100个用户”更真实也更容易观察系统负载上升过程中的表现。持续时间Duration 定义Vuser全部启动后持续运行多长时间。可以设置为“一直运行直到手动停止”或“运行指定时间如30分钟”。后者对于稳定性测试和获取稳定状态下的性能数据至关重要。停止Stop Vusers 定义Vuser如何停止。可以“同时停止所有”或“每X秒停止Y个”。逐渐停止同样有助于观察系统负载下降时的恢复情况。关键细节如何设计有意义的压力曲线阶梯上升式 适用于容量规划和找出性能拐点。例如每5分钟增加50个用户持续30分钟。观察在哪个用户数级别响应时间开始急剧上升或错误率开始增加这个点就是系统的性能瓶颈点。高峰脉冲式 模拟秒杀、抢购等场景。在短时间内如1分钟内快速启动大量用户如1000个持续高压几分钟后快速停止。用于测试系统的瞬时峰值处理能力和缓存、队列等组件的有效性。长时间稳定性测试 以预期的平均并发用户数如200个持续运行8小时甚至24小时。目的是发现内存泄漏、连接池耗尽、数据库连接不释放等长时间运行才会暴露的问题。3.3 运行时设置精细化控制脚本行为在场景中你可以覆盖单个脚本在VUGen中设置的“运行时设置”实现更灵活的控制。右键点击场景中的脚本选择“运行时设置”即可进入。关键细节几个容易被忽略但至关重要的设置日志Log 在调试阶段可以开启“Enable logging”和“Extended log”下的“Parameter substitution”和“Data returned by server”这能帮助你在回放失败时看到详细的参数替换过程和服务器返回值。但在正式负载测试时务必关闭日志或仅启用“Send messages only when an error occurs”因为写日志是磁盘I/O密集型操作会严重影响负载生成器性能扭曲测试结果。速度模拟Speed Simulation 可以模拟不同的网络带宽如拨号、宽带这对于测试网络传输量大的应用如图片、视频非常重要能更真实地反映终端用户的体验。浏览器模拟Browser Emulation 可以设置浏览器缓存、是否下载非HTML资源如图片、JS、CSS。在测试Web服务器静态资源处理能力时需要根据实际情况设置。通常第一次迭代会下载所有资源后续迭代可以利用缓存这更符合真实浏览器行为。3.4 监控器配置收集系统性能数据性能测试不只是看事务响应时间还需要知道在压力下服务器系统的资源状态。Controller可以连接被测试系统的服务器监控其性能计数器。Windows服务器 使用Windows自带的性能监视器计数器。需要在被监控服务器上开启“Remote Registry”服务并确保Controller机器有权限访问。关键计数器包括% Processor Time CPU使用率。Available MBytes 可用内存。Avg. Disk Queue Length 磁盘队列长度反映磁盘I/O压力。Network Interface\Bytes Total/sec 网络吞吐量。Linux/Unix服务器 通常需要先在服务器上安装rstatd或xinetd等服务Controller通过rpc机制获取数据。关键监控项包括CPU、Memory、Disk I/O、Network。中间件/数据库 LoadRunner提供了针对WebLogic、WebSphere、Apache、IIS、SQL Server、Oracle等的专用监控器。需要配置正确的连接信息如JDBC URL、用户名密码。关键细节监控的黄金法则——建立基线关联分析。测试前建立基线 在没有任何负载的情况下先监控一遍服务器的主要计数器记录下它们的“健康值”。这有助于在负载测试中判断资源消耗是否异常。关联事务与资源 在分析结果时最关键的是将事务响应时间的曲线与服务器资源CPU、内存、磁盘I/O、数据库连接数的曲线在时间轴上对齐。例如当“订票”事务响应时间飙升时如果发现数据库服务器的Average Wait Time也同步飙升那么瓶颈很可能在数据库。这种关联分析是定位性能瓶颈的最有效手段。4. 结果分析与问题定位从数据到结论的侦探工作场景执行完毕后会生成大量的原始数据。LoadRunner Analysis 组件的作用就是将这些数据可视化并帮助我们找出问题。分析不是简单地看报告最后的几个平均数而是一个层层下钻的过程。4.1 核心性能指标解读打开Analysis你会看到一系列图表。首先要关注以下几个核心指标事务响应时间Transaction Response Time 这是用户体验的直接体现。重点关注平均响应时间 整体水平但容易被极端值拉平。百分比响应时间如90th Percentile 更有参考价值。它表示90%的事务响应时间都低于这个值。如果90%线是3秒但最大响应时间有30秒说明有少量请求体验极差需要排查。随时间变化的趋势图 响应时间是平稳上升还是出现周期性尖峰平稳上升可能预示资源逐渐耗尽如线程池尖峰则可能与定时任务、缓存失效等有关。每秒事务数Transactions per Second, TPS 系统吞吐能力的直接指标。TPS越高说明系统处理能力越强。在压力持续增加的过程中TPS会随着Vuser数增加而增加但到达一个拐点后TPS会持平甚至下降此时增加压力只会增加响应时间而不会增加吞吐量这个拐点就是系统的最佳并发点。虚拟用户数Running Vusers 与实际产生的TPS、响应时间曲线对照可以判断压力是否有效施加以及系统在特定并发下的表现。错误率Errors per Second 任何非零的错误率都需要严肃对待。需要点击错误信息查看具体的错误类型和发生时间并与事务响应时间尖峰进行关联。4.2 下钻分析与瓶颈定位当发现某个事务例如lr_book_ticket响应时间过长时需要按下钻分析分解事务时间 在Analysis中可以查看该事务的“细分图”。它会将事务响应时间分解为网络时间 从发送请求到收到第一个响应字节的时间。过长可能意味着网络延迟或服务器处理请求过慢。服务器时间 从收到第一个字节到收到最后一个字节的时间。这大致反映了服务器应用的处理时间。客户端时间 渲染时间对于HTTP协议通常很小。如果这里时间异常长可能是测试脚本本身有性能问题如检查点过于复杂。 通过分解可以快速将问题定位到“网络”、“前端服务器”、“后端服务”或“数据库”等层面。关联资源监控图 将事务响应时间图与服务器CPU、内存、磁盘I/O图叠加。如果事务变慢时CPU使用率达到100%则是CPU瓶颈如果内存可用量持续下降且伴随大量磁盘交换Page Faults则是内存瓶颈。分析Web资源图 查看每秒点击率、吞吐量字节数/秒。如果点击率很高但TPS很低可能意味着服务器返回了大量错误页面如404、500需要检查脚本关联和检查点。如果吞吐量异常高可能意味着服务器返回了非预期的巨大数据如未分页的查询结果。4.3 常见性能问题模式与排查思路根据多年经验性能问题通常表现为以下几种模式每种模式都有相对固定的排查路径问题现象可能原因排查思路响应时间随并发线性增长TPS上不去1. 应用存在全局锁或串行化瓶颈。2. 数据库连接池配置过小。3. 外部单点服务如支付网关响应慢。1. 检查应用日志查找等待或锁信息。2. 监控数据库连接池使用率。3. 使用工具如tcping测试外部服务网络延迟。响应时间周期性出现尖峰1. 定时任务如日志归档、缓存刷新启动。2. 数据库统计信息更新或备份。3. 垃圾回收GC停顿。1. 核对尖峰时间与应用/系统的定时任务计划。2. 监控数据库服务器在尖峰时刻的进程和SQL。3. 分析Java应用的GC日志。低并发下正常高并发下错误率飙升1. 资源耗尽如端口、线程、数据库连接。2. 中间件如Web服务器、应用服务器配置限制如MaxClients,maxThreads。3. 数据库锁竞争激烈。1. 监控服务器在出错时的资源使用极限值。2. 检查中间件配置文件中关于连接和线程的配置项。3. 检查数据库的锁等待和死锁日志。测试初期TPS正常运行一段时间后持续下降1. 内存泄漏导致可用内存减少GC频繁。2. 数据库连接未正确释放连接池逐渐耗尽。3. 缓存策略不当缓存命中率下降。1. 监控内存使用趋势分析堆内存转储。2. 监控数据库连接数趋势检查代码连接关闭逻辑。3. 监控缓存命中率检查缓存失效策略。5. 从WebTours到真实项目经验迁移与避坑指南WebTours是一个理想化的学习环境而真实项目往往复杂得多。将这里学到的思路迁移过去需要注意以下几个关键点这些都是我踩过无数坑才总结出的经验。5.1 脚本录制与协议选择对于现代复杂的Web应用单页应用SPA、大量Ajax/WebSocket通信选择“Web - HTTP/HTML”协议录制可能不够。你可能需要同时启用多个协议 例如“Web - HTTP/HTML” “WebSocket”。使用浏览器插件 LoadRunner的“Click and Script”或类似工具通过浏览器扩展录制用户操作能更好地捕获动态内容。手动编写脚本 对于API接口测试直接根据接口文档用web_custom_request函数手动编写脚本可能更高效、更稳定。避坑技巧录制前务必彻底清理浏览器缓存和Cookie。一个陈旧的缓存可能会让你录到一个本地的静态资源请求而回放时这个请求不会发生导致脚本行为不一致。在VUGen的录制选项中可以设置浏览器启动时自动清除缓存。5.2 处理动态数据与复杂关联真实系统的动态值可能更隐蔽、更复杂比如藏在JSON响应里或者需要经过多次重定向才能获取。对于JSON响应 使用web_reg_save_param_ex函数时左右边界LB/RB可以设置为JSON的键名。例如对于{“token”: “abc123”}可以设置LB”token”:””, RB”}。注意引号和空格。使用关联函数的高级参数 如Ordinal取第几个匹配项、SaveOffset保存值的偏移量等可以处理更复杂的情况。借助调试工具 使用Fiddler或Chrome开发者工具抓包仔细分析请求/响应的完整链条是定位复杂关联点的唯一捷径。5.3 场景设计中的“思考时间”哲学在真实项目中思考时间的设置需要基于生产环境的用户行为数据分析如果有的话。如果没有数据可以采用以下策略采用随机思考时间 为每个思考时间设置一个范围如lr_think_time(5 rand() % 5);表示思考5-10秒这比固定值更真实。区分业务类型 浏览型操作如查看商品列表的思考时间可以设置得长一些10-20秒而决策型操作如填写订单可以设置得短一些3-8秒。压力测试与负载测试的区别 在压力测试找系统极限中通常会忽略或大幅缩短思考时间。在负载测试模拟真实用户模型中必须使用合理的思考时间否则你测试的只是一个“机器人攻击场景”而非真实的业务场景。5.4 结果分析的“置信区间”性能测试不是一次性的。由于网络波动、测试环境干扰、垃圾回收的不确定性等因素单次测试结果可能存在偶然性。执行多次迭代 每个测试场景至少执行3-5次取结果的平均值或中位数作为参考。关注趋势而非绝对值 在对比不同版本或不同配置的性能时关注响应时间、TPS的变化趋势如提升了20%比关注具体的数值如从200ms降到160ms更有意义因为测试环境很难与生产环境完全一致。记录测试环境变量 每次测试时记录下测试环境的软硬件配置、网络状况、数据量大小、其他后台进程等信息。这些是解读测试结果的重要上下文没有它们结果将无法被复现和理解。性能测试是一项结合了技术、经验和严谨思维的工作。从VUGen中一个精巧的关联函数到Controller里一条精心设计的压力曲线再到Analysis中一次关键的关联分析每一步都影响着最终结论的准确性。掌握这些细节你才能真正让LoadRunner成为你手中洞察系统性能、保障业务稳定的利器。