LoadRunnerController场景设计指南

一、场景设计想测试什么？

在打开Controller之前明白测试目的。场景参数：

标准测试：用少量Vuser单跑业务，确定单用户或低并发下的性能标准。

负载测试：按预期生产负载施压，测试系统在正常峰值下表现是不是稳定，标准是不是达标。

压力测试：不断增加负载，直到系统短板暴露或崩溃，找出系统极限和恢复能力。

容量测试：阶梯式加压，确定系统在不同配置下能支撑的最大并发用户数或吞吐量。

稳定性/耐久测试：以中等负载长时间运行，观察是不是有内存泄漏、连接未释放等问题。

二、创建场景的步骤

打开Controller，点击新建场景：

手动场景：自己完全控制Vuser的启动、运行时长和停止方式，适合绝大多数精细控制的负载和压力测试。

面向目的场景：设定一个性能目的如每秒事务数、响应时间，让Controller自动调整Vuser数量来达成目的，用于测试系统能否在特定目的下正常工作。

以下是手动场景的设计流程，这也是最常用的方式。

1.添加脚本，确定要压的业务

将VuGen录制的脚本添加到场景组中。一个场景可以包含多个脚本，模拟不同业务的混合比例。

如：登录脚本占10%，浏览商品占50%，下单占30%，搜索占10%。通过组的Vuser数量来分配比例。

2.设置Vuser总数和负载生成器

根据目的设定总Vuser数，比如模拟500并发用户。

将负载生成器分配到不同的物理机器上，避免Controller本身的资源成为短板。在生成器栏添加机器名并测试连接。

3.设计加压方式

切换到“计划”视图，一般包括三个部分：

启动Vuser(Ramp Up)

决定用户怎样开始执行。常用方式：

同时启动：全部Vuser一瞬间开始，用于模拟秒杀、抢购等突发并发。

阶梯递增：每间隔一段时间启动一批Vuser，比如每30秒启动50个，直到达到峰值。

自定义计划：可以分段设置不同速率，模拟午餐、晚间高峰等不规则流量。

不断时间(Duration)

规定在峰值保持多久。常用方式：

完成指定迭代次数后停止：每个Vuser跑完N遍脚本就退出，总负载会自然下降。适合需要精确控制事务执行总量的场景。

运行指定时间后停止：保持在最大Vuser数下运行30分钟、2小时。这是稳定性测试的标准做法，能观察稳态下的各项标准。

停止Vuser(Ramp Down)

一般设置为每间隔一段时间停止一批用户，模拟流量逐渐消散。除非测试瞬间掉流量的场景，否则不建议让所有用户同时退出，那样观察不到资源的回卷过程。

一个典型负载测试的计划示如下：

每15秒启动20个Vuser，一共启动100个（达到峰值需75秒）。

在100Vuser负载下不断运行30分钟。

然后每30秒停止20个用户，直到全部停止。

4.设置运行时行为，让虚拟用户像真实用户

在运行时设置中配置几项重点参数，直接影响负载真实性：

思考时间：开启随机思考时间，设置一个范围（如3-8秒）。实际用户操作时会有停顿，忽略思考时间会制造过高的压力，导致结果失真。

日志级别：设计场景执行时，标准做法是设为标准日志或仅出错时记录日志，避免大量调试日志消耗负载生成器资源并拖慢脚本执行。

网络模拟：如需要模拟弱网或不同带宽，可在运行时开启网络仿真，并选择相应的网络类型。

迭代和错误处理：设定出错时继续可避免一个脚本错误让整个Vuser停止，使场景更贴近真实，因为在真实世界中极少用户会因为一个页面报错就完全放弃系统。

5.配置监控，抓住性能证据

没有监控的性能测试只是盲测。在Controller的运行视图中，添加以下资源监控：

服务器层：CPU、内存、磁盘IO、网络吞吐量。Windows系统可添加相关计数器，Linux/Unix通过rstatd或SiteScope等获取。

应用层：Web服务器请求队列、应用服务器线程池、数据库连接数和慢查询。

LoadRunner层：添加运行时和事务图表，实时观察事务响应时间、吞吐量、点击数、Vuser状态等。

可设定SLA（服务级别协议）：如登录事务平均响应时间不能超过3秒，超过时场景中会有醒目告警，事后报告中会直接标记SLA通过和否。

三、模拟真正的高并发

集合点用于让多个Vuser在某个操作点上等待，直到足够数量的用户到达后，再同时向服务器发出请求，以此模拟秒杀、抢购、考试报名等并发瞬间。

设计：

只在需要很高峰值的少数重点事务前插入集合点（如在“提交订单”之前），滥设会让整个场景失去真实性。

集合点方法可设定为“当xx%的到达用户时释放”或“当x个用户到达时释放”，前者更灵活。

注意等待超时设置，避免因少数用户迟迟不到造成大量用户一直阻塞。

四、场景设计一些问题

脚本未做参数化和关联：这是导致回放失败或把缓存数据压进数据库的第一要务原因。设计场景前，保证脚本已处理好登录令牌、会话ID等动态数据，并对重点业务数据做了参数化和唯一性处理。

负载生成器本身成为短板：一台机器能模拟的用户数有限，当CPU或内存先被打满，产生的负载就不准确了。一般一台普通负载生成器建议限制在几百Vuser内，大并发必须分布到多台生成器。

忽略带宽和网络限制：测试环境可能都是千兆网络，而生产环境可能存在带宽短板。如果不模拟，得到的TPS可能超过实际能力。

只看平均响应时间：90%响应时间可能已经严重恶化，却被平均值掩盖了。设计场景时就应该在监控图表中同时重视平均、中位数和90/95分位值。

不做渐进式摸底：一上来就用预想的最大负载压测，发现系统崩溃也无法判断是在哪个量级开始劣化。正确的做法是：先用一个较小的负载找出第一个性能拐点，再逐步加大。

场景结束后不保留数据和审计：每次执行后，及时保存原始结果文件，并导出图表或报告。很多有作用的性能短板信息，事后复盘时才发现。