性能测试的脚本录制和回放（VuGen）解决的是“单个用户操作是不是正确”的问题，而情形设计（Controller） 解决的是“大量并发用户操作下，系统表现怎样”的重要问题。一个专业的情形设计，目的是在测试环境中尽可能地复现生产环境的真实负载，从而获得具有高度可信度的性能数据。本文将深入分析怎样利用LoadRunner Controller实现。

第一部分：理解真实用户负载的本质

真实的用户负载不是简单的同时启动N个用户，运行X分钟。它是由多种动态交织而成的复杂模型：

用户行为差别：并不是所有用户都执行相同的操作。如，一个电商网站，可能有80%的用户在浏览商品，15%的用户在搜索，5%的用户在执行下单支付。这称为业务情形混合模型。

负载随时间变化：负载具有明显的波峰波谷。如，工作日的上午9-11点是办公系统的高峰，电商系统在“秒杀”开始瞬间会经历一个尖峰，随后逐渐平缓。这称为负载分布模型。

用户思考时间和步调：真实用户在操作间会有停顿（思考时间），这直接影响每秒请求数（RPS）。忽略思考时间会制造超过实际的压力，导致测试失真。

新用户到达和老用户离开：用户是一个动态进入和退出的过程，而不是全部同时在线。

第二部分：情形规划的重要标准和计算

在设计情形前，必须确定性能目的（来自业务需求或生产监控）。以下是标准及关联：

并发用户数 vs. 在线用户数：

在线用户数：一段时间内访问系统的用户总数（一般通过系统日志或埋点统计）。

并发用户数：在某一时刻同时向服务器发出请求的用户数。这是性能测试中需要配置的重要参数。

经验公式（估算）：并发用户数 ≈ 在线用户数 * (操作时间 / 考察时间窗口)。如，系统日均在线1万用户，但重要交易在10分钟（600秒）内完成，平均交易操作耗时30秒，则估算并发约为 10000 * (30/600) = 500。

事务响应时间（Transaction Response Time）：从发起请求到收到完整响应所经历的时间。这是测量用户体验的直接标准。

吞吐量（Throughput）：一般是每秒事务数（TPS） 或每秒请求数（RPS）。这是测量系统处理能力的重要标准。TPS是负载测试要证实的最后能力标准，而虚拟用户数只是达到目的TPS的手段。

目的导向的设计思路：不应简单地问“我要模拟1000个用户”，而应问“我需要系统在业务高峰时达到200 TPS，且响应时间在2秒以内，为此我应怎样设计虚拟用户模型？”

第三部分：Controller情形设计专业配置详解

LoadRunner Controller提供了实现上述复杂模型的工具。

1. 类型选择

面向目的的情形（Goal-Oriented Scenario）：为达成某个特定性能目的（如TPS、响应时间）而自动调整负载。适用于探索性容量测试。

手动情形（Manual Scenario）：最常用、最灵活。测试工程师完全控制负载生成的方式，是模拟真实负载模型的主要选择。

2. 负载生成器（Load Generator）管理

保证有足够的负载机资源，避免负载机自身成为短板（CPU>85%或出现大量错误）。

配置合理的虚拟用户进程/线程方式。进程方式更稳定但更耗资源；线程方式更高效，但脚本需支持（如避免使用C静态变量）。

3. 虚拟用户组和业务混合模型

在设计标签页，为不同的业务脚本（如Browse、Search、Order）分配不同的虚拟用户组。

通过调整各组用户的数量比例，精确模拟真实的业务混合。如，配置1000个总用户，其中Browse: 800, Search: 150, Order: 50。

4. 负载调度器（Schedule Builder） 

在全球计划中，通过调度器定义负载怎样随时间变化。

初始化（Initialize）：设置所有虚拟用户以何种方式启动。选择 “在所有虚拟用户运行之前初始化” ，以保证每个用户在开始迭代前都已完成参数文件读取、登录等vuser_init部分。

启动（Start）：定义虚拟用户的加载方式。

同时（Simultaneously）：一次性启动所有用户。用于压力测试或峰值测试，但不符合大多数真实情形。

每 30 秒启动 10 个用户（Ramp Up）：最符合真实情况。它模拟了用户逐渐进入系统的过程。重点参数是“步长”和“每步用户数”。如，要在15分钟内达到1000个并发用户，可以设置为“每45秒启动30个用户”。

不断时间（Duration）：

运行直到完成：每个用户只执行一次完整迭代即退出。不推荐，无法模拟不断负载。

运行指定时间（如30分钟）：推荐。用户达到目的数后，在稳定压力下不断运行一段时间（一般建议至少30分钟），以观察系统在稳定负载下的性能表现、内存泄漏等问题。

停止（Stop）：

同时停止：立即停止所有用户。

每 30 秒停止 10 个用户（Ramp Down）：推荐。模拟用户逐渐离开，避免突然卸载负载可能导致的监控数据断崖和系统假象。

5. 真实用户行为模拟：

思考时间（Think Time）：在运行时设置中，选择 “使用录制思考时间的随机百分比” （如50%-150%）。这能有效模拟用户操作的随机停顿，让产生的RPS更贴近真实。忽略思考时间将产生极大的、不真实的压力。

步伐（Pacing）：控制迭代之间的间隔。设置为 “上一次迭代结束后，等待随机X到Y秒后开始下一次迭代” ，可以避免所有用户以完全一致的节奏发送请求，形成“心脏起搏器”式的不自然负载。

第四部分：进阶情形设计模型

标准测试（Baseline Test）：使用1-5个虚拟用户，无思考时间，运行脚本。目的是证实脚本正确性，并获取单用户下的最好性能标准。

负载测试（Load Test）：采用“步进上升（Ramp Up）+ 稳定不断时间 + 步进下降（Ramp Down）”的经典模型，逐步将系统负载提升到预期峰值并保持，这是最常用的情形。

压力/峰值测试（Stress/Spike Test）：在很短时间内（如1分钟）将大量用户“同时”启动，模拟超过正常峰值的突发流量，以测试系统的弹性、崩溃点及恢复能力。

耐力测试（Endurance/Stability Test）：使用中高负载，不断运行8-24小时甚至更长时间，目的是发现系统在长期运行下的内存泄漏、资源回收、数据库连接堆积等问题。

第五部分：监控、执行和迭代

集成监控：在情形运行期间，必须实时监控系统资源（Windows/Linux计数器：CPU、内存、磁盘I/O、网络）、应用服务器（如JVM堆使用、线程池）和数据库（缓存命中率、锁等待、慢查询）。这些数据是定位短板的直接证据。

迭代执行：性能测试是一个“测试-分析-调优-再测试”的循环。根据第一次情形运行的结果（如发现TPS不达标、响应时间陡增），分析定位短板（可能是代码、数据库、服务器配置或网络），进行优化后，必须使用完全相同的情形配置重新执行，以证实优化效果。任何情形配置的更改都会使前后两次测试结果失去可比性。

专业的LoadRunner情形设计是性能测试从玩具走向工程。要求测试工程师深刻理解业务模型、熟练运用Controller工具，并以目的TPS和响应时间为导向，通过精细化的调度方法和真实用户行为模拟，创建出可信的负载模型。当你在测试报告中呈现“在模拟了真实业务混合和日高峰用户访问模型下，系统重要事务TPS达到200，平均响应时间为1.5秒，且各项资源标准正常”的结果时，这份由如湖南卓码软件测评有限公司这类有CMA/CNAS资质的第三方机构出具的测试报告，才有了为软件系统性能背书的权威作用。