Controller组件是LR的控制中心，主要包括场景设计和场景执行两部分。在VuGen中编辑完脚本并将脚本加载到Controller组件中，即开始对脚本运行时的场景进行设计，当场景设计完成后，即可执行该场景。
Controller控制器提供了手动设计和面向目标两种测试场景。一般情况下使用手动测试场景设计方法，因为能够更灵活地按照需求来设计场景模型，使场景能更好地接近用户的真实使用。面向目标场景则是测试性能是否能达到预期的目标，在能力规划和能力验证的测试过程中经常使用到。
启动方式有两种：第一种是在开始菜单中启用；第二种是在VuGen发生器的Tools菜单中启动，如图1所示。
图1
启动Controller控制器后，会弹出‘新建场景’对话框，如图2所示。
图2
这里选中的是手动测试场景，该场景包含两种模式：用户组模式与百分比模式，不同之处在于计算虚拟用户的方式不同。
手动用户组模式如图3所示。
图3（手动用户组模式）
百分比模式如图4所示。（scenario->convert senario to the percentage mode，即可切换到百分比模式）
图4（手动百分比模式）
首先定义要达到的目标，接着LR会自动基于该目标创建场景，在场景运行过程中，LR会不断地将结果与目标相比较，以决定下一步如何执行。
该场景提供了Virtual Users、Hit per Secnod、Transactions per Second、Transaction Response Time和Pages per Minute一种目标。
如图5所示是面向目标测试场景界面。
图5
这里主要介绍Schedule、View Script和Generator参数的设置。而两种场景模式的区别主要体现在Schedule参数的设置上，另外两个参数的设置都是一致的。
主要是用来设置用户的行为方式，这里包括按场景计划和按用户组计划（切换为用户组模式才会有group选项）两种（如图6所示）。
图6（scenario schedule配置界面）
initialize ：设置脚本运行前如何初始化每个虚拟用户。包含3种方式：
a.同时初始化所有虚拟用户；b.每隔一段时间初始化一定数量的虚拟用户；c.在脚本运行之前初始化所有虚拟用户。（通常情况下选择方式三）。
start vusers ：设置虚拟用户加载的过程（是指总的虚拟用户数）。包含2种加载方式：
a.同时加载所有的虚拟用户；b.每隔一定的时间加载一定数目的虚拟用户。（在实际测试过程中不会选择方式一进行加载虚拟用户）
duration ：设置场景执行的时间，包含2种方式：
a.一直运行，直到所有的虚拟用户运行完成后，结束整个场景的运行；b.设置场景持续运行时间，一般情况下在进行压力测试时，只需测试15~30min即可，但如果需要测试系统的可靠性和稳定性时，则需要持续运行24h或3*24h。
stop vusers ：设置场景执行完成后虚拟用户如何释放的策略。（只有duration设置为按指定时间运行时才需要设置该项）
a.当场景运行结束后，同时释放所有的虚拟用户；b.每隔一段时间就停止一定量的虚拟用户。（一般情况下，虚拟用户如何添加就如何停止）
比按场景计划多出了start gruop选项，在该场景中，是以组为单位进行计划的，每个组都要设置自己的start vusers、duration和stop vusers。比较灵活，能够创建实际应用中脚本与脚本之间的约束关系。如一组用户执行后产生的数据记录为另一组用户的输入，这种情况就需要使用该方式来配置场景。使用该场景时，LR默认将每个脚本定义为一个组。
这里只对start group选项卡进行分析，包含3种方式：
a.场景执行时立即开始运行该脚本；b.场景执行一段时间后才开始运行该脚本；c.在某个特定的用户组运行结束后才开始运行该脚本，即就是在某个脚本运行结束后才开始运行。
一般情况下使用场景组方式来运行场景时，会选中每个脚本分别进行设置。如果同时设置则与普通的场景设置没有什么区别。
如图7所示，有3种方式（针对run页面的start scenario）：
a.场景立即开始，没有延误时间；b.推迟指定的时间后才开始运行；在指定的时间开始运行，如晚上8点运行。
图7
是先设定好虚拟用户总数，然后按百分比的形式对所有的虚拟用户进行分配。该场景适合综合业务模型明确的性能测试。（比如银行的查存取业务）
在面向目标场景中，首先定义测试需要达到的目标，然后LR会自动根据这一目标创建场景。
在场景设置界面，单击edit scenario goal，进入编辑该目标场景对话框，如图8所示，以hit per second目标类型为例，讲述其各项设置。
图8
run time：表示当执行达到目标后，该场景还会持续运行一段时间（设置的时间值）才结束运行。
if target cannot be reached：表示如果目标无法达到，controller将如何处理场景。有2种选择：a.停止运行场景并保存结果；b.继续运行场景直到达到目标。
设置加载行为，有3种方式：a.让controller自动加载用户；b.设定一个时间，在该时间后达到目标；c.每隔一段时间增加一定的目标量。
a.virtual users
主要是用来测试服务器对并发用户的处理能力，假如将虚拟用户设置为100个，那么LR会逐渐递增虚拟用户，直到加载到100个为止，如不能达到，将采取if target cannot be reached中设置的策略来继续运行当前的场景。（如图9所示）
图9
b.hits per second
设置的目标是点击数/秒，如图10所示，同时要设置最大和最小虚拟用户数。因为点击率的值大小与虚拟用户数成正比，假设测试出来的点击率的值达不到目标值，那么就必须增加虚拟用户数，否则点击率的值就不可能增加，所以在设置点击率的值为目标时，就必须限定虚拟用户数的范围，也即最大和最小虚拟用户数的值。
运行原理：当场景执行时，controller会先用最小虚拟用户数去执行，结束后判断点击率的值是否达到目标值，如果达到了则停止当前运行的场景；否则继续增加虚拟用户，再判断结果是否达到预期目标值。一直重复，直到达到目标 。如果使用最大虚拟用户数还是无法达到目标值时，那么场景将会停止运行，并保存相应的结果。
图10
c.transaction per second
设置的目标为每秒处理的事务数，如图11所示，注意在脚本中一定要定义事务，否则事务名称栏为空白。
图11
如果从业务的角度看，每秒钟处理的事务数即为系统每秒钟处理的业务笔数，所以该项指标更多的是用于衡量系统每秒钟处理的业务数。同样的也要设置最大和最小虚拟用户数，因为要改变每秒钟处理的事务数就必须通过虚拟用户数来改变，但要注意的是，当虚拟用户数成倍增长时，处理的事务数并不会成倍增长，因为随着虚拟用户数增多，事务的平均响应时间也增加了，这样在相同的时间内，每个虚拟用户处理的事务数就相当少了，所以处理的事务数不可能成倍增长。
运行原理：跟hits per second的原理相同
d.transaction response time
设置的目标为多用户并发时事务的响应时间，如图12所示
图12
运行原理：跟hits per second的原理相同，假设当前虚拟用户数为10个，那么说明系统最多只能处理10个用户同时请求。如果使用最大的虚拟用户数还是无法达到目标值时，那么场景将会停止运行，并保存相应的结果，同时也说明系统可以支持更多的虚拟用户同时运行。
e.pages per minute
设置的目标为每分钟处理的页面数，如图13所示。
图13
每秒钟处理的页面数与每秒钟处理的事务数，其本质是一样的，因为一个事务可能由多个页面组成，当一个事务只由一个页面组成时，那么每秒种处理的页面数一每秒钟处理的事务数完全一致。
在以下情况下，hits per second、transactions per second、pages per minute类型的场景结果中会被置为failed状态：
a.控制器使用指定的最大用户数，并且执行两次都没有达到目标；b.负载机不够；c.所有的用户都运行失败；d.控制器增加了几批虚拟用户后，hits per second、transactions per second、pages per minute的值没有增加。
在场景设计界面，脚本加载后，如需对加载的脚本进行修改，可以选中需要配置的脚本并单击右键，选择View Script对脚本进行修改。
要注意修改后，一定要重新加载该脚本才能确保场景执行中的脚本是修改后的脚本
Load Generator 又称负载发生器，当控制器发出执行命令时，Load Generator 负责和其他的负载机建立起联系并强制负载机执行。一个controller可以通过Load Generator 来控制多台负载机。如图14所示
图14
可以add负载机，完成后connect，测试负载机与控制机连接的情况，如果status为ready，表示连接成功；如果为failed，表示连接失败，这时就要检查网络是否存在问题。
在使用负载机模拟多用户测试系统时，需要注意以下几个问题：
1）计算需要负载机的台数。
在使用负载机时首先需要解决的第一个问题是测试时需要多少台负载机才能满足测试的需要（如测试时需要测试500个虚拟用户），在确定该问题之前需要先确定每个用户需要消耗的系统资源，当把每个虚拟用户按进行的方式来运行时，那么当场景运行时，每添加一个虚拟用户都会增加一个进程，而每个进程都是需要消耗内存和CPU资源的。通常情况下每个虚拟用户消耗多少资源受操作系统、录制时选择的协议及LR的版本3个方面的影响，可百度下官方公布的虚拟用户消耗内存资源参考值。
比如每个虚拟用户消耗的内存资源大概为6800KB左右，如果以500个虚拟用户为例大概需要消耗3320MB（6800KB*500/1024=3320MB）的内存，如果每台测试机的内存为1GB（3320MB/1024=3.2421875），那么至少需要4台这样的测试机。
2）控制器如何控制负载机运行。
控制器通过代理程序去控制负载机运行（代理程序的名称为loadrunner agent process），所以首先需要在控制器和客户端启动代理程序（开始菜单->HP LR->Tools->loadrunner agent runtimes..）。
启动后弹出loadrunner agent设置对话框，如图15所示
图15
a.允许所有的虚拟用户不用登录即可运行，但需要设置登录主机的名称、用户名和密码。
b.手动登录服务器。一般使用手动去登录即可。
启动代理程序后（注意控制器和负载机都需要启动代理程序），当场景在初始化时，控制器会向负载机发送一个二进制文件，该二进制文件中就包括所有待运行的脚本信息，当初始化后，负载机就会产生虚拟用户来模拟测试。
在Run选项卡中，主要包括场景运行控制信息和数据图两部分，如图16所示。（注：截图是手工测试场景模式，如果是目标测试场景模式的话，down是为空的，是根据设置的目标来加载的）
图16（run选项卡界面图）
关于scenario groups讲解：左边显示每个用户组的运行状态，右边为场景的控制操作。
start scenario：开始场景，此时controller开始初始化虚拟用户，并将这些虚拟用户服务分配到负载发生器，开始运行脚本。
stop：停止场景，对于如何控制场景停止运行有3种方式（tools->options），如图17所示：
a.等当前迭代运行结束后，再停止运行场景；b.等当前的action结束后，再停止运行场景；c.不等待，立即停止运行场景
图17（场景停止设置方式）
reset：将方案中所有的vuser组重置为方案运行前的‘关闭（Down）’状态，准备下一次场景的执行。
vusers：虚拟用户组，如图18所示，可以看到每个vuser的详细状态（ID、运行状态、脚本、负载发生器和所用时间），在这里可以选择单个vusers进行操作（那些右键的其他操作可以自己去点一下）
图18
run/stop vusers：（目标测试场景的该按钮是置灰的）设置继续执行还是停止某个用户组，如图19所示，在运行期间可以在这里手动控制新添加的vuser（注意：该对话框因运行场景的模式不同而有所不同）
图19（手动模式run/stop vusers设置）
图20，是在百分比模式下运行场景，能够根据定义的百分比，分配新的vusers数，以及运行这些添加 的vuser的负载发生器。
图20（百分比模式run/stop vusers设置）
如图21所示，及各参数项的含义
图21
如图22所示，可以看到事务的详细信息。TPS：每秒的事务数；Passed/Failed/Stopped：表示运行已通过/已失败/已停止的事务数。
图22（事务详细信息）
view->show output，可调出输出窗口，如图23所示，vuser和负载发生器会向controller发送错误、通知、警告、调试和批处理消息，这些信息可以在输出窗口中查看到。（重置时消息仍会保留）
图23
details可查看详细消息文本，如果需要查看更加详细的信息，可以单击相应列的蓝色链接，如图24所示。
图24
分析输出信息时，需要确定以下几个方面的问题：
1）出错是由于性能测试引起的还是由于脚本编写的错误引起；
2）找到出错的日志信息。
要找到出错的具体日志信息，必须通过输出的信息找到这几方面的信息，错误信息是来自哪台负载机，错误信息是来自哪个虚拟用户。确定这两方面的信息后就可以找到场景运行时的日志信息了，否则在运行大量虚拟用户时，如果一个一个地查看每个虚拟用户的日志信息，则效率很低。
