摘要

Controller组件是LoadRunner的控制中心，主要包括场景设计和场景执行两部分。在VuGen中编辑完脚本并将脚本加载到Controller组件中，即开始对脚本运行时的场景进行设计，当场景设计完成后，即可执行该场景。场景设计主要是依据需求说明书制定脚本如何执行的策略，使脚本的运行更接近真实用户使用。场景执行是指当场景设计完成后手动运行场景，在场景执行过程中可以实时对场景产生的数据进行监控。

主要讲述以下几部分内容：

1.场景类型介绍

2.场景设计

3.场景执行

场景类型介绍

Controller控制器提供了手动和面向目标两种测试场景。一般情况下使用手动场景设计方法来设计场景，手动设计场景最大的优点是能够更灵活地按照需求来设计场景模型，使场景能更好地接近用户的真实使用。面向目标场景则是测试性能是否能达到预期的目标，在能力规划和能力验证的测试过程中经常使用到。

Controller的启动有两种方式，可以在“开始”菜单→“所有程序”→HP LoadRunner→Applications→Controller中启动，如图所示。也可以在VuGen发生器菜单Tools→Create Controller Scenario中启动，如图所示。

手动测试场景

启动Controller控制器后，会弹出“新建场景”对话框，如图所示。

“新建场景”对话框中有两种场景方法可以选择：手动场景和面向目标场景。一般手动测试场景使用得较多，因为手动场景更灵活，可以更好地接近用户真实的使用情况。

手动场景又包含两种模式：用户组模式与百分比模式，这两种模式的不同之处在于计算虚拟用户的方式不同。

手动用户组模式如图所示。

在Controller控制器中，点击菜单Scenario→Convert Scenario to the Percentage Mode即可切换到百分比模式，如图所示。

面向目标测试场景

面向目标场景是一个闭环回馈关系。在这种场景模式下，首先定义要达到的目标，接着LoadRunner会自动基于该目标创建场景，在场景运行过程中，LoadRunner会不断地将结果与目标相比较，以决定下一步如何执行。

面向目标测试场景提供了Virtual Users、Hits per Second、Transactions per Second、Transaction Response Time和Pages per Minute五种目标。

如图所示是面向目标测试场景界面。

场景设计

主要介绍手动和面向目标两种场景设计，包括Schedule、View Script和Generator参数的设置。手动和面向目标两种场景的不同主要体现在Schedule参数的设置上，二者的View Script和Generator参数设置都是一致的，故主要介绍手动场景Schedule配置和面向目标场景Schedule配置两部分。

手动场景Schedule配置

在手动场景设计界面，可以看到Scenario Schedule配置界面，如图所示。

Schedule配置主要是用来设置用户的行为方式，这里包括按场景计划和按用户组计划两种。

场景名称（Schedule Name）

可以添加一个场景、对场景进行重命名或删除某个场景，场景命名应该遵循一定的规则，场景名称能反映场景动作，如图所示。

按场景计划（Schedule by Scenario）

Initialize设置：设置脚本运行前如何初始化每人虚拟用户，如图所示。包含三种初始化方式：

方式一：同时初始化所有虚拟用户。

方式二：每隔一段时间初始化一定数量的虚拟用户。

方式三：在脚本运行之前初始化所有虚拟用户。

通常情况下选择第三种方式，在虚拟用户初始化的过程LoadRunner主要是将一个二进制文件发送给负载机，保证负载机能正常模拟多用户的运行指定的脚本，以及运行时的策略，所以只要在运行时，所以虚拟用户初始化完成即可，也即只有当所有虚拟用户都初始化完成后才开始运行脚本。

第一种方式几乎不可能使用，因为这种情况不符合业务逻辑，并且可能会出现这种情况，在并发初始化所有虚拟用户时，初始化失败，导致刚开始运行时，虚拟用户数即没有达到定义的虚拟用户数；

第二种方式也用的比较少，因为不好定义具体多长时间初始化多少个虚拟用户，所以一般使用第三种方式初始化。

Start Vusers设置：设置虚拟用户加载的过程，如图所示。

Start Vusers是指总的虚拟用户数。

加载方式一：同时加载所有的虚拟用户。

加载方式二：每隔一定的时间加载一定数目的虚拟用户。

在实际测试过程中不会选择第一种方式进行加载虚拟用户，有以下几个方面的原因：

第一：实际测试过程中，操作一个业务时，不可能同时并发直接操作，而是有一定的先后顺序。如登录OA自动化办公系统，假设公司有800号人，这800号员工不可能同时去登录，一定是有先后顺序，可能更多的情况是在半个小时内，这样员工全部登录上去。

第二：同时加载可能会导致系统出现瓶颈，而此时并不一定说明系统不能同时并发这些虚拟用户。因为系统也需要“热身”，就像运动员在进行激烈运动之前需要进行热身时一样，所以一般情况都是选择每隔一段时加载一定数目的虚拟用户。

但针对于第二种选择，每隔一段时间加载多少虚拟用户的情况，又存在一个问题，到底隔多长时间加载多少虚拟用户比较合理呢？目前并没有官方说明每隔一段时间应该添加多少虚拟用户， 一般情况有两种方法加载：一是分段加载，一般情况将所有的虚拟用户分为4段进行加载，如一共为100个虚拟用户，分为四段即每一段为25个虚拟用户，可以设置为隔30秒加载25个虚拟用户；二是逐渐递加，每多少时间加载2到5个虚拟用户，使用这种加载方式，一般的情况下可以每隔15秒加载2到5个虚拟用户。对于这种方式运行结束后，性能会有一些差异，在测试过程中可以分别使用这两种方式进行测试。

Duration设置：设置场景执行运行的时间，如图所示。

方式一：一直运行，直到所有的虚拟用户运行结束后，结束整个场景的运行；

方式二：设置场景持续运行时间，一般情况下在进行压力测试时，只需要测试15-30分钟即可，但如果需要测试系统的可靠性和稳定性时，则需要持续运行24小时或3×24小时。

Stop Vusers设置：设置场景执行完成后虚拟用户如何释放的策略，如图所示。需要注意只有在Duration选项卡中设置为“按指定时间运行”时，才需要设置该项。

Stop Vusers：是指释放多少虚拟用户，缺少值为所有虚拟用户，也即释放所有的虚拟用户，但也可以自定义释放多少虚拟用户。

释放方式一：当场景运行结束后，同时释放所有的虚拟用户。

释放方式二：每隔一段时间就停止一定量的虚拟用户，这项和Start Vusers中的第二项一样，区别在于前者是控制虚拟用户加载，后者是控制虚拟用户释放。一般情况下虚拟用户如何添加就如何停止即可。

按用户组计划（Schedule by Group）

按用户组计划设计场景比按场景计划设计场景的设置项中多出了Start Group选项卡，在按用户组计划设计场景中，以组为单位进行计划，每个组都要设置自己的Start Vusers、Duration和Stop Vusers。

按用户组计划方式更加灵活，能够创建实际应用中脚本与脚本之间的约束关系。如一组用户执行后产生的数据记录为另一组用户的输入，这种情况就需要使用“用户组计划”方式来配置场景。使用场景组设置场景策略时，LoadRunner默认将每个脚本为定义为一个组。

Start Vusers、Duration和Stop Vusers选项卡的内容与按场景计划设计场景中的内容一致，故只对Start Group选项卡进行分析，Start Group选项卡内容如图所示。