1. 项目概述Controller与场景设计的核心地位在性能测试领域LoadRunner的Controller组件常被比作交响乐团的指挥。脚本Vuser脚本是乐谱虚拟用户Vusers是乐手而Controller就是那位掌控全局、协调节奏、确保最终演出效果系统性能表现符合预期的指挥家。今天我们不谈基础的脚本录制与回放而是深入这个“指挥中心”的核心操作——场景Scenario的运行与设计特别是其中颇具智能色彩的“面向目标场景Goal-Oriented Scenario”。很多测试工程师在初步掌握脚本录制后往往在Controller环节感到迷茫虚拟用户怎么加压力怎么施目标怎么定结果怎么看这恰恰是区分“脚本执行者”与“性能测试工程师”的关键分水岭。本文将基于一个资深性能测试工程师的实战视角拆解Controller运行手工场景的每一个细节并重点剖析面向目标场景的设计哲学与实操要点让你不仅能“跑起来”更能“测得准”、“看得懂”。2. Controller运行视图与手工场景深度解析启动Controller后你会看到两个核心视图选项卡设计Design和运行Run。这不仅仅是界面切换更代表了性能测试的两个阶段规划与执行。2.1 设计视图构建你的压力蓝图在设计视图中我们完成所有测试前的配置工作。其核心是创建和管理场景Scenario。LoadRunner主要支持两种场景类型手工场景Manual Scenario和面向目标场景Goal-Oriented Scenario。我们先从最常用、最基础的手工场景讲起。手工场景符合我们进行压力测试最直观的思路第一步设定要模拟多少用户、运行什么脚本、以何种方式运行第二步执行测试获取服务器的响应时间、吞吐量等指标。它提供了极高的灵活性和控制力。创建与配置虚拟用户组Vuser Group 在Controller中添加一个脚本即创建了一个虚拟用户组。组内的所有Vuser将执行相同的脚本。关键的配置项包括Quantity数量设定该组虚拟用户的总数。这是压力大小的直接体现。Load Generators负载生成器指定由哪台或哪些机器来生成这些虚拟用户负载。Controller本身可以作为一个负载生成器但对于大规模测试通常需要配置额外的负载机。这里有一个至关重要的步骤添加负载机后务必点击“Connect”按钮确保状态Status显示为“Ready”。如果显示“Failed”需要检查网络连通性、防火墙设置以及LoadRunner Agent进程是否在负载机上正常运行。Run-time Settings运行时设置这是脚本行为的总控台。即使脚本中包含了思考时间Think Time和迭代Iterations也需要在此进行统一或覆盖式的管理。例如你可以选择忽略脚本中的思考时间以施加最大压力或者统一设置迭代次数。2.2 运行时设置与负载策略精讲运行时设置Run-time Settings是手工场景的“微操面板”许多测试结果的不确定性都源于这里的配置不当。思考时间与步调Pacing思考时间模拟真实用户操作间隔。在基准测试或寻找最大吞吐量时通常选择“忽略思考时间”Ignore think time。在模拟真实用户行为场景时则使用“按录制时的思考时间”As recorded或“乘以一个比例”Multiply recorded think time by。步调控制迭代之间的间隔。例如设置“上一次迭代结束后等待30秒开始下一次迭代”可以控制请求的发送频率避免对服务器造成不自然的、持续不断的冲击。日志Log为了性能在正式压测时通常选择“仅在错误时发送消息”Send messages only when an error occurs。调试阶段可以开启“标准日志”Standard Log甚至“扩展日志”Extended Log。网络速度模拟Speed Simulation这是模拟真实用户网络环境的关键。默认是“使用最大带宽”Use maximum bandwidth即本地网络全速发送。为了更真实地模拟不同终端用户如使用Modem、ADSL、4G的客户需要在这里选择特定的带宽级别如56Kbps, 1.5Mbps或自定义带宽值。这个设置会直接影响事务响应时间因为数据包在网络层的传输时间被模拟进去了。2.3 集合点策略真正的并发控制集合点Rendezvous是手工场景中实现真正并发压力的核心机制。它让虚拟用户在脚本的某个点如登录按钮点击前等待直到满足特定条件后再一起释放以模拟瞬间高并发。配置集合点策略Policy是高级用法双击场景中的“Rendezvous”打开设置释放所有Vuser当所有正在运行的Vuser都到达集合点后才一起释放。这用于测试严格的、所有用户同时操作的场景。释放部分Vuser当指定数量的Vuser到达集合点后即释放这批用户。这用于模拟分批次的峰值压力。超时释放当第一个Vuser到达集合点后开始计时。在设定的超时时间如30秒内满足上述任一策略即释放超时后无论条件是否满足都会释放所有已到达的Vuser。这防止了因个别Vuser异常导致整个测试“卡死”在集合点。实操心得集合点虽然强大但滥用会导致压力模型失真。在真实世界中用户操作不可能完全同步。通常只在测试登录、秒杀、抢购等特定高并发业务点时使用。在设置集合点的脚本中务必配合合理的思考时间和步调否则压力曲线会呈现不自然的“锯齿状”。2.4 调度器绘制压力曲线图手工场景的精华在于其调度器Schedule。它允许你精细地控制压力的施加、持续和消退过程从而模拟出复杂的用户行为模型。调度器配置分为四个阶段初始化Initialize决定Vuser如何准备就绪。同时初始化所有Vuser测试一开始所有Vuser立即进入“就绪”状态。这会给系统带来巨大的初始化冲击如同时建立数据库连接常用于压力极限测试。每隔一段时间初始化一定数量的Vuser更温和的方式。例如每15秒初始化5个Vuser直到全部就绪。这模拟了用户逐渐进入系统的过程。启动VuserStart Vusers决定Vuser如何开始运行脚本。同时启动所有Vuser所有已初始化的Vuser立即开始执行。与初始化结合形成“瞬间高压”。逐渐启动每隔一段时间启动一定数量的Vuser。这是最常用的方式用于模拟负载的逐步攀升。持续时间Duration决定负载的稳定阶段。运行完一次迭代就结束每个Vuser执行一次脚本后停止。不适合稳定性测试。运行指定时间所有Vuser启动后持续运行一段设定的时间如30分钟。这是考察系统在稳定压力下性能表现如内存泄漏、响应时间稳定性的标准做法。停止VuserStop Vusers决定负载如何退出。同时停止所有Vuser瞬间撤走所有压力。逐渐停止每隔一段时间停止一定数量的Vuser。模拟用户逐渐离开系统更为真实。通过组合这四个阶段你可以设计出诸如“阶梯式上升-平稳保持-阶梯式下降”的经典压力曲线或者更复杂的“波浪形”压力曲线以验证系统的弹性。3. 面向目标场景让测试工具为你思考如果说手工场景是“开手动挡”需要你精确控制每一个参数那么面向目标场景Goal-Oriented Scenario就是“开自动挡”。你只需要告诉Controller你想要达到什么目标例如平均事务响应时间低于3秒或每秒点击率达到200Controller会自动调整运行中的Vuser数量尝试达到并维持这个目标。3.1 目标场景的核心逻辑与适用场景这是一种基于反馈的闭环控制逻辑你定义目标比如“登录”事务的平均响应时间不超过2秒。Controller设计并运行场景它会从一个较小的Vuser数开始然后根据实时监控到的事务响应时间与目标值的差距动态地增加或减少Vuser数量。持续比较与调整在整个运行过程中Controller不断比较当前结果与目标并调整负载形成一个“测量-比较-调整”的闭环。它最适合什么场景容量规划你想知道“为了将响应时间保持在SLA服务等级协议以内系统最多能支持多少用户”面向目标场景可以通过不断尝试增加用户来找到这个临界点。验证性测试你想验证“系统在响应时间不超过2秒的前提下是否能支持500 TPS每秒事务数”。你可以将目标设为500 TPS看Controller能否调整出合适的并发用户数以达成此目标并观察系统资源是否吃紧。寻找性能拐点自动寻找系统从性能平稳到性能下降的转折点。3.2 五大目标类型详解在创建面向目标场景时你需要从以下五类目标中选择一种虚拟用户数Virtual Users目标就是达到并维持指定的并发虚拟用户数。这其实退化成了手工场景的“稳定用户数”模式但设置更简单。每秒点击次数Hits per Second目标是达到指定的每秒HTTP请求数点击率。Controller通过调整Vuser数来尝试达到这个吞吐量指标。这常用于测试Web服务器的静态处理能力。每秒事务数Transactions per Second目标是达到指定的事务吞吐量。这比点击率更有业务意义。你需要事先在脚本中定义事务如“登录”、“查询”。事务响应时间Transaction Response Time目标是控制指定事务的平均响应时间在某个阈值内。这是最常见的SLA验证场景。例如设置“支付”事务响应时间目标为小于5秒。每秒页面数Pages per Second目标是达到指定的每秒页面刷新率。3.3 配置目标场景的实战步骤与策略选择目标类型后需要进行详细配置设置目标值明确你的目标数字如300 Virtual Users 或 50 Transactions/Second 或 3-second Response Time。设置负载行为Load Behavior自动Controller完全自主决定如何增减Vuser。这是最常用的模式。逐步达到目标Controller会以固定的步长如每次10个用户逐步增加负载直到达到目标。这提供了更平滑、可预测的压力曲线。逐步运行在达到目标后Controller会尝试逐步减少负载然后再增加以观察系统在目标值附近的稳定性。设置最小和最大Vuser数这是非常重要的安全边界。你必须告诉Controller调整的范围。例如目标响应时间是2秒你可以设置最小用户数为10最大为1000。Controller只会在10到1000个用户之间进行调整防止因算法误判而启动过多Vuser压垮测试机本身或启动过少用户导致测试无意义。设置停止条件Stop Condition如果目标无法达成怎么办你可以设置“如果在X分钟内无法达到目标则停止场景”。这避免了无意义的长时间运行。注意事项面向目标场景的“自动化”是一把双刃剑。它的调整算法并非完美在系统响应出现剧烈波动时可能会做出错误的判断导致Vuser数振荡。因此它通常不适合用于稳定性测试耐力测试因为稳定性测试要求负载在长时间内保持恒定。它更适用于负载测试和压力测试的探索阶段。4. 场景运行监控与结果分析准备无论使用手工场景还是目标场景一旦点击“Start Scenario”Controller便切换到运行视图。此时你的角色从“压力设计师”转变为“空中交通管制员”需要实时监控整个测试过程。4.1 运行视图核心面板解读运行视图主要由以下几部分组成场景组Scenario Groups显示各Vuser组的运行状态Down, Pending, Ready, Run, Rendezvous, Passed, Failed, Error, Gradual Exiting, Stopped。不同状态的颜色标识让你一眼就能看出测试是否健康。可用图Available Graphs这是性能数据的宝库。你可以将关注的图表如“运行Vuser数”、“每秒事务数”、“平均事务响应时间”、“Windows资源计数器”拖拽到右侧的监控区域。事务监控实时显示各个事务的通过、失败数量以及响应时间最小、平均、最大。错误信息实时滚动显示运行时错误是定位问题的最直接入口。4.2 关键监控图表与计数器添加仅仅看默认图表是不够的一个专业的性能测试工程师必须知道如何添加关键的系统资源计数器以建立“压力输入-系统状态-性能输出”的关联分析。添加被测系统监控在运行视图中右键点击“Windows Resources”或“UNIX Resources”等图选择“Add Measurements”。输入被测试服务器的IP地址并选择有管理员或足够权限的账户进行连接。添加关键计数器例如CPU% Processor Time总使用率% Privileged Time内核态% User Time用户态。内存Available Mbytes可用内存Pages/sec硬缺页率过高表示内存不足。磁盘% Disk Time磁盘繁忙度Avg. Disk Queue Length磁盘队列长度。网络Bytes Total/sec网络吞吐量。对于Web服务器如IIS, Apache、应用服务器如Tomcat, WebLogic、数据库如SQL Server, Oracle还需要添加其特有的性能计数器。建立关联视图将“运行Vuser数”、“平均事务响应时间”和“系统CPU使用率”三个图放在一起观察。你会清晰地看到随着Vuser数上升响应时间如何变化同时CPU使用率是否同步增长并最终成为瓶颈。这种关联分析是性能瓶颈定位的基础。4.3 运行过程中的干预与控制测试并非启动后就放任不管可能需要动态干预暂停/停止发现问题如响应时间激增、错误率飙升时可以暂停或停止场景。调整Vuser在手工场景中可以手动增加或减少某个组的Vuser数量。查看日志双击失败的Vuser可以查看其详细执行日志定位脚本或服务器错误原因。5. 常见问题排查与实战技巧实录即使按照手册操作在实际运行场景时也总会遇到各种“坑”。以下是一些典型问题及排查思路5.1 负载生成器连接失败问题现象在Design视图添加Load Generator后Status始终为“Failed”或无法连接。排查网络从Controller机器ping负载机确认网络连通性。检查防火墙是否阻止了TCP端口默认是50500、54345等具体查看安装文档。检查进程登录到负载机确认LoadRunner Agent Process (magentproc)或Network Virtualization Driver等相关服务是否已启动。验证安装在负载机上运行LoadRunner安装目录\bin\magentservice.exe -install手动安装代理服务并重启服务。检查主机文件确保Controller和负载机之间能通过主机名正确解析IP地址有时需要在hosts文件中添加映射。5.2 虚拟用户大量失败或在“Pending”状态停滞问题现象场景开始后大量Vuser无法进入“Run”状态停留在“Pending”或直接“Failed”。负载机资源不足这是最常见原因。登录负载机检查CPU、内存使用率。一台负载机能承载的Vuser数是有限的取决于脚本复杂度和硬件。需要分散负载到多台机器。License限制检查你的LoadRunner License允许的最大并发Vuser数。Pending状态可能是在排队等待License释放。运行时设置过严例如设置了过短的“超时Timeout”网络稍有延迟就导致Vuser初始化失败。可以适当增加超时时间。脚本本身错误在少量用户时运行正常的脚本在大并发下可能因资源竞争如文件、端口、全局变量而失败。需要审查脚本的并发适应性。5.3 面向目标场景无法达到目标或剧烈振荡问题现象设置了目标如响应时间2秒但Controller不断增加用户响应时间却一直超标或者用户数在某个范围内来回剧烈波动。目标设定不合理可能目标值超出了系统的实际能力。先用一个简单的手工场景以阶梯方式增加用户摸清系统的性能基线再设定一个合理的目标值。最小/最大用户数范围太窄或太宽范围太窄限制了Controller的调整空间范围太宽可能导致它在无效区域盲目搜索。应根据基线测试结果设定一个合理的范围。系统存在瓶颈当系统遇到硬瓶颈如CPU 100%数据库锁等待时增加用户只会让响应时间变得更差Controller的反馈算法会陷入混乱。此时应停止测试先定位并解决系统瓶颈。监控事务选择不当确保你选择作为目标的事务是具有代表性且执行频率稳定的。如果一个事务本身执行时间就非常离散会导致目标基准不稳。5.4 结果分析与报告生成误区常见误区只关注“平均响应时间”和“通过率”。必须看“百分比响应时间”90%或95%的响应时间即90%的事务响应时间低于此值比平均响应时间更有意义。它反映了大多数用户的体验避免了极端值对平均值的扭曲。必须关联系统资源一个事务响应时间变慢必须结合当时的CPU、内存、磁盘I/O、数据库活动等指标一起分析。例如响应时间变慢时如果磁盘队列长度持续很高那么磁盘IO可能就是瓶颈。区分“服务器时间”与“网络时间”在LoadRunner的细分图中可以查看事务响应时间中网络传输、服务器处理、客户端渲染各占多少比例。这有助于确定问题是出在后台服务器、中间件还是前端或网络。生成报告前先“过滤”场景刚开始的“爬坡”阶段和结束时的“退出”阶段的数据通常不能代表系统稳定状态下的性能。在Analysis工具中应该过滤掉这些时间段的数据只分析稳定压力期间的数据这样得出的结论才更准确。Controller的运行与场景设计是性能测试从理论走向实践的核心环节。手工场景提供了无与伦比的灵活性和控制力适合进行探索性测试、稳定性测试和复杂的用户行为模拟。而面向目标场景则提供了一种智能化的、以业务指标为导向的测试方法特别适合用于容量规划和SLA验证。掌握两者并能根据不同的测试目的灵活选用是性能测试工程师专业能力的重要体现。记住工具只是工具背后的设计思想和对系统行为、用户模型的理解才是做好性能测试的根本。每一次场景的设计与执行都是一次与系统深度对话的过程观察它、理解它、挑战它最终才能驾驭它。