Controller控制器_controller控制器说明书

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

4.1 场景类型介绍

4.1.1手动测试场景

　　启动Controller控制器后，会弹出“新建场景”对话框，如图所示。
　　
　　“新建场景”对话框中有两种场景方法可以选择：手动场景和面向目标场景。一般手动测试场景使用得较多，因为手动场景更灵活，可以更好地接近用户真实的使用情况。
　　手动场景又包含两种模式：用户组模式和百分比模式，这两种模式的不同之处在于计算虚拟用户的方式不同。
　　手动用户组模式：
　　
　　在Controller控制器中，选择Scenario——Convert Scenario to the Percentage Mode命令，即可切换到百分比模式
　　手动百分比模式：
　　

4.1.2 面向目标测试场景

　　面向目标场景是一个闭环回馈关系。在这种情景模式下，首先定义要达到的目标，接着LoadRunner会自动基于该目标创建场景，在场景运行过程中，LoadRunner会不断地将结果与目标相比较，以决定下一步如何执行。
　　面向目标测试场景提供了Virtual Users、Hits Per Second、Transactions Per Second、Transaction Response Time和Pages per Minute五种目标。

4.2 场景设计

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

4.2.1 手动场景Schedule配置

　　在手动场景设计界面，可以看到 scenario Schedule 配置界面，如下图所示。
　　
　　Schedule配置主要是用来设置用户的行为方式，这里包括按场景计划和按用户组计划两种。
　　1、场景名称（Schedule Name）
　　可以添加一个场景，对场景进行重命名或删除某个场景，场景命名应该遵循一定的规则，场景名称能反映场景动作。
　　2、按场景计划（Schedule by Scenario）
　　（1）Initialize设置。设置脚本运行前如何初始化每个虚拟用户，包含3种初始化方式：
　　方式一：同时初始化所有虚拟用户。
　　方式二：每隔一段时间初始化一定数量的虚拟用户。
　　方式三：在脚本运行之前初始化所有虚拟用户。
　　
　　通常情况下选择方式三，在虚拟用户初始化的过程，LoadRunner主要是将一个二进制文件发送给负载机，保证负载机能正常模拟多用户的运行指定的脚本及运行时的策略，所以只要在运行时，所有虚拟用户初始化完成即可，也即只有当所有虚拟用户都初始化完成后才开始运行脚本。方式一几乎不可能使用，因为这种情况不符合业务逻辑，并且可能会出现在并发初始化所有虚拟用户时，初始化失败，导致刚开始运行时，虚拟用户数及没有达到定义的虚拟用户数；方式二也用的比较少，因为不好定义具体多长时间初始化多少个虚拟用户，所以一般使用方式三是初始化。
　　（2）Start Vusers设置。设置虚拟用户加载的过程，如下图所示。
　　
　　Start Vusers是指总的虚拟用户数。
　　加载方式一：同时加载所有的虚拟用户。（simultaneously：同时地）
　　加载方式二：每隔一定的时间加载一定数目的虚拟用户。
　　在实际测试过程中不会选择方式一进行加载虚拟用户，有以下几个方面的原因：
　　1）：实际测试过程中，操作一个业务时，不可能同时并发直接操作，而是有一定的先后顺序。如登录OA自动化办公系统，假设公司有800人，这800个员工不可能同时去登录，一定是有先后顺序，可能更多的情况是在半个小时内，这些员工全部登录上去。
　　2）同时加载可能会导致系统出现瓶颈，而此时并不一定说明系统不能同时并发这些虚拟用户。因为系统也需要热身，所以一帮情况下是选择每隔一段时间加载一定数目的虚拟用户。
　　但针对第二种选择，每隔一段时间加载多少虚拟用户的情况，又存在一个问题，到底每隔多长时间加载多少虚拟用户比较合理呢？目前并没有官方说明每隔一段时间应该添加多少虚拟用户，一般情况有两种方法加载：一是分段加载，一般情况将所有的虚拟用户分为4段进行加载，如一共有100个虚拟用户，分为4段即每一段为25个虚拟用户我，可以设置为每隔30秒加载25个虚拟用户；二是逐渐递增，每隔一定时间加载2~5个虚拟用户，使用这种加载方式，一般情况下可以每隔15s加载2~5个虚拟用户。对于这种方式运行结束后，性能会有一些差异，在测试过程中可以分别使用这两种方式进行测试。
　　（3）Duration设置，设置场景执行的时间
　　
　　方式一：一直运行，直到所有的虚拟用户运行完成后，结束整个场景的运行。
　　方式二：设置场景持续运行的时间，一般情况下在进行压力测试时，只需测试15~30min即可，但如果需要测试系统的可靠性和稳定性时，则需要持续运行24h或3X24h。
　　（4）Stop Vusers设置：设置场景执行完成后虚拟用户如何释放的策略，如图所示，需要注意，只有在Duration选项卡中设置为“按指定时间运行时”才需要设置该项。
　　
　　Stop Vusers：指释放多少虚拟用户，默认值为所有虚拟用户，也可以自定义释放多少虚拟用户。
　　释放方式一：当场景运行结束后，同时释放所有的虚拟用户。
　　释放方式二：每隔一段时间就停止一定量的虚拟用户，这项和Start Vusers中的第二项一样，区别在于前者是控制虚拟用户加载，，后者是控制虚拟用户释放。一般情况下，虚拟用户如何添加就如何停止。
　　3、按用户组计划（Schedule by Group）
　　按用户组计划设计场景比按场景计划设计场景的设置项中多出了Start Group选项卡，在按用户组计划设计场景中，以组为单位进行计划，每个组都要设置自己的Start Vusers、Duration和Stop Vusers。
　　按用户组假话方式更加灵活，能够创建实际应用中脚本与脚本之间的约束关系。如一组用户执行后产生的数据记录为另一组用户的输入，这种情况就需要使用“用户组计划”方式来配置场景。使用场景组设置场景策略时，LoadRunner默认将每个脚本定义为一个组。
　　Start Vusers、Duration和Stop Vusers选项卡的内容与按场景计划设计场景中的内容一致，故只对Start Group选项卡进行分析。
　　
　　运行方式一：场景执行时立即开始运行该脚本。
　　运行方式二：场景执行一段时间后才开始运行该脚本
　　运行方式三：在某个特定的用户组运行结束后才开始运行该脚本，通俗地讲就是在某个脚本运行结束后才开始运行。
　　一般情况下使用情景组方式来运行场景时，会选中每个脚本分别进行设置。如果同时设置则与普通的场景设置没有什么区别。
　　4、场景开始时间（Scenario Start Time）
　　场景启动时间设置有3种方式。
　　启动方式一：单击Start Scenario按钮后，场景立即开始，没有延误时间。
　　启动方式二：单击Start Scenario按钮后，推迟指定的时间后才开始运行。
　　启动方式三：单击Start Scenario按钮后，在指定的时间开始运行，如下午16：00运行。
　　假设在白天进行手工测试，晚上执行性能测试，这样就可以通过这个选项来设置指定的时间运行场景。
　　5、百分比模式
　　百分比模式是先设定好虚拟用户总数，然后按百分比的形式对所有的虚拟用户进行分配。该场景适合综合业务模式明确的性能测试。
　　百分比模式与“Manual Scenario（手动测试场景）”非常类似，但两者间还是存在一些不一致的地方。
　　选择Scenario—Convert Scenario to the Persentage Mode命令，即可将手动场景模式转换为百分比模式。在“%”列中设置虚拟用户组所占总虚拟用户数的百分比。
　　
　　通常确定业务的百分比模型有以下几种方法：
　　（1）分析历史数据。通过分析后台的历史数据是获得每种业务百分比最好的方式，可以分析一年或半年的业务量。
　　（2）参考其他同类产品。
　　（3）试上线运行。

4.2.2 面向目标场景Schedule配置

　　在面向目标场景中，首先定义测试需要达到的目标，然后LoadRunner会自动根据这一目标创建场景。
　　
　　在场景设置界面，单击Edit Scenario Goal按钮，如下图所示，进入编辑该目标场景对话框，如图所示，包含5种目标类型（Virtual Users、Hits per Second、Transactions per Second、Transactions Response Time、Pages per Minute），以Hits per Second目标类型为例，讲述其各项设置。
　　
　　
　　1、Scenario Setings选项卡
　　Scenario Setings选项卡包括设置Run Time和If target cannot be reached两部分设置内容。
　　在Run Time栏中设置一个时间值，表示当执行达到目标后，该场景还会持续运行一段时间（设置的时间值）才结束运行。
　　If target cannot be reached设置表示如果目标无法达到，Controller将如何处理场景。有两种选择，可以选择“停止运行场景并保存结果（Stop scenario and save results）”或“继续运行场景直到达到目标（Continue scenario without reaching goal）”。
　　2、Load Behavior选项卡
　　设置加载行为，如图所示。
　　加载行为一：让Controller自动加载用户。
　　加载行为二：设定一个时间，在该时间后达到目标。
　　加载行为三：每隔一段时间增加一定的目标量。
　　
　　3、目标类型（Goal Type）
　　（1）Virtual Users目标类型
　　这种目标类型主要是用来测试服务器对并发用户的处理能力，这种目标类型与手动设置类型相似，如图所示，假设将虚拟用户设置为100个，那么loadRunner会逐渐递增虚拟用户，直到加载到100个为止，如果加载到100个虚拟用户之前系统已经出现，那么LoadRunner将会采用If target cannot be reached中设置的策略来继续运行当前的场景。
　　
　　（2）Hits per Second目标类型
　　设置的目标是点击数/秒，如图所示。同时要设置最小虚拟用户数和最大虚拟用户数。
　　
　　当设置好目标点击率和虚拟用户数后，接下来的运行原理如下：
　　1）当场景执行时，Controller首先会使用最小的虚拟用户去执行待步骤，执行结束后判断点击率的值是否达到目标值。
　　2）如果达到了，则停止运行当前的场景。
　　3）如果未达到目标值，则继续增加虚拟用户，再判断结果是否达到预期目标值。
　　4）重复上面1~3直到达到目标。
　　如果使用最大的虚拟用户数还是如法达到目标值，那么场景将会停止运行，并保存相应的结果。
　　（3）Transactions per Second目标类型。
　　设置的目标为每秒处理的事务数，但需要注意的是，在脚本中一定要定义事务，否则事务名称栏为空白，如图所示。
　　
　　如果从业务的角度来看，每秒钟处理的事务数即为系统每秒钟处理的业务笔数，所以该项指标其实更多的用于衡量系统每秒钟处理的业务数。
　　同样地，在设置每秒钟处理的事务数后还必须设置最大和最小虚拟用户数，因为要改变每秒钟处理的事务数，就必须通过虚拟用户数来改变，但需要注意的是，当虚拟用户数成倍增长时，处理的事务数并不会成倍增长，如假设当前虚拟用户数为50，平均每秒种处理的事务数为40，但当虚拟用户增加到100个时，每秒钟处理的事务数肯定不可能达到80，因为随着虚拟用户数增多，事务的平均响应时间也增加了，这样在相同的时间内，每个虚拟用户处理的事务数就相当少了，所以处理的事务数不可能成倍增长。
　　当设置每秒中处理的事务数和虚拟用户后，接下来的运行原理如下：
　　1）当场景执行时，Controller首先会使用最小的虚拟用户去执行，待执行结束后判断每秒钟处理的事务是否达到目标值。
　　2）如果达到了，则停止运行当前的场景。
　　3）如果未达到目标值，则继续增加虚拟用户，再判断结果是否达到预期目标值。
　　4）重复上面1~3直到达到目标。
　　如果使用最大的虚拟用户数还是无法达到目标值时，那么场景将会停止运行，并保存相应的结果。
　　（4）Transactions Response Time目标类型.
　　这类目标是设置在多用户并发时事务的响应时间。同时需要设置最大和最小虚拟用户数。
　　在场景执行时，如果部分虚拟用户并发就达到了定义的最大响应时间，那么需要调整策略后再重新执行。如图所示，该目标类型要求在脚本中一定要有事务，否则事务名称栏为空白。
　　
　　需要注意的是，虚拟用户数与事务响应时间的关系，可能很容易理解错，因为随着虚拟用户数的增加，事务响应时间会变长，同理，当虚拟用户数少时事务的响应时间也就较短，如果事务响应时间没有达到目标值，就说明当前的事务响应时间还是可以接受的，也说明系统还可以支持更多的虚拟用户。
　　当设置好事务响应时间和虚拟用户数后，接下来的运行原理如下：
　　1）当场景执行时，Controller首先会使用最小的虚拟用户去执行，待执行结束后判断事务响应时间是否达到目标值。
　　2）如果达到了，则停止运行当前的场景。
　　3）如果未达到目标值，则继续增加虚拟用户，再判断结果是否达到预期目标值。
　　4）重复上面1~3直到达到目标。达到目标后，假设当前虚拟用户数为M个，那么说明系统最多只能处理M个用户同时请求。
　　如果使用最大的虚拟用户数还是无法达到目标值时，那么场景将会停止运行，并保存相应的结果。同时也说明系统可以支持更多的虚拟与用户同时运行。
　　（5）Pages per Minute目标类型。
　　设置目标为每分钟处理的页面数，如图所示
　　
　　每秒钟处理的页面数与每秒钟处理的事务数，其本质是一样的，因为一个事务可能由多个页面组成，当一个事务只由一个页面组成时，那么每秒钟处理的页面数与每秒中处理的事务数完全一致。
　　如果定义的类型为Hits per Second、Transactions per Second、Pages per Minute，控制器首先使用最小用户数除以定义的目标数，得到一值，通过这个值来确定每个用户应该达到的Hits per Second、Transactions per Second、Pages per Minute的值，接下来控制器将按Load Behavior选项卡中的设置加载虚拟用户。
　　1）如果选择的控制器自动加载虚拟用户，控制器首先会加载50个虚拟用户。如果定义的最大虚拟用户数小于50，那么会一次性将所有的虚拟用户加载完成。
　　2）如果选择在场景执行后一段时间内达到目标，那么LoadRunner会尝试在定义的时间内达到目标，并且根据时间限制和计算出来的Hits per Second、Transactions per Second、Pages per Minute的值来确定第一批需要加载的用户数
　　3)如果选择一段时间内增加一定的目标量，那么LoadRunner会计算每个用户达到的值后，再确定下一批需要加载的虚拟用户数
　　每次加载完一批用户后，LoadRunner会判断是否达到目标值，如果没有达到预期目标值，LoadRunner会重新计算每个虚拟用户应该达到的目标数，再重新调整下一批加载用户的数量如果控制器加载到最多数量的虚拟用户还没有达到预定的目标，那么LoadRunner会重新计算每个用户的目标值，然后使用最大的用户数量去执行场景，尝试达到预期的目标。
　　在以下清苦时，Hits per Second、Transactions per Second、Pages per Minute类型的场景结果中会被置Faied状态。
　　1）控制器使用指定的最大用户数，并且执行两次都没有达到目标。
　　2）负载机不够
　　3）所有的用户都运行失败。
　　4）控制器增加了几批虚拟用户后，Hits per Second、Transactions per Second、Pages per Minute的值没有增加。

4.2.3 配置View Script

在场景设计界面，用户脚本加载后，如果需要对加载的脚本进行修改，可以点击页面中间列的View Script按钮对脚本进行修改，如图所示。需要注意的是，对脚本修改后，一定要在Controller中重新加载该脚本，才能确保场景执行中的脚本是修改后的脚本。

4.2.4 配置Load Generator

　　Load Generator又称为负载发生器，当控制器发出执行命令时，Load Generator负责和其他的负载机建立起联系并强制负载机执行。一般情况下，在一台机器上安装好LoadRunner，会自动安装好Load Generator。一个Controller可以通过Load Generator来控制多台负载机。
　　单击上图的Generators按钮，会弹出Load Generator对话框，如下图所示：
　　
　　在Load Generator对话框中，单击Add按钮，可以添加负载机，添加完成后，单击Connect按钮，测试负载机与控制机连接的情况，如果Status为Ready，表示连接成功；如果为Failed，表示连接失败，这时要检查网络是否存在问题。
　　在使用负载机模拟多用户测试系统时，需要注意以下几个问题：
　　（1）计算需要负载机的台数
　　在使用负载机时首先需要解决的第一个问题是测试时需要多少台负载机才能满足测试的需要（如测试时需要500个虚拟用户），在确定该问题之前需要先确定每个虚拟用户需要消耗的系统资源。前面介绍过，当把每个虚拟用户按进程的方式来运行时，那么当场景运行时，每添加一个虚拟用户都会增加一个进程，而每个进程都是需要消耗内存和CPU资源的。
　　通常情况下每个虚拟用户消耗多少资源受操作系统、录制时选择的协议及LoadRunner的版本3个方面的影响，以HTTP/HTML协议为例，LoadRunner官方发布的系统资源消耗情况如图所示。
　　
　　官方公布的数据只是参考值，在实际测试过程中，应该以实际运行时资源消耗的数据为准。
　　假设在windows XP操作系统下每个虚拟用户消耗的内存资源大概为6800K左右，这样如果以500个虚拟用户为例大概需要3320MB的内存，如果每台测试机的内存为1GB，那么至少需要4台这样的测试机。
　　（2）控制器如何控制负载机运行
　　设置好负载机后，控制器是如何控制负载机产生并发用户并进行模拟运行的呢？LoadRunner运行的原理是，控制器通过代理程序去控制负载机运行（代理程序的名称为LoadRunner Agent Process），所以首选需要在控制器和客户端启动代理程序。
　　选择“开始”—“所有程序”—HP LoadRunner—Tools—Agent Runtime Settings Configuration选项，启动LoadRunner Agent程序后，弹出LoadRunner Agent设置对话框，如图所示
　　
　　Allow virtual users to run on this machine without user login:允许所有的虚拟用户不用登陆即可运行，但需要设置登陆主机的名称、用户名和密码。
　　Manual log in to this machine:手动登陆服务器。一般使用手动去登陆即可。
　　启动代理程序后（需要注意的是控制器和负载机都需要启动代理程序），当场景在初始化时，控制器会向负载机发送一个二进制文件，该二进制文件中就包括所有带运行的脚本信息，当初始化之后，负载机就会产生虚拟用户来模拟测试。

4.3 场景执行

　　场景设计完成之后，接下来要执行场景，在场景执行过程中要关注场景的运行情况，主要包括3个对象，即场景、Vuser组和Vuser。

4.3.1 场景控制

　　切换到“运行（run）”选项卡，在“运行”选项卡中主要包括两部分：场景组运行控制信息和数据图两部分。场景组运行控制信息如图所示。
　　
　　场景组的左边显示每个用户组的运行状态，右边为场景的控制操作，包括开始场景、场景停止、场景复位、虚拟用户控制、和运行/停止Vuser。
　　Start Scenario（开始场景）：单击该按钮，场景即开始运行。此时Controller开始初始化虚拟用户，并将这些虚拟用户服务分配到负载发生器，开始运行脚本。
　　Stop（停止场景）：在场景未开始运行时，该按钮为灰色，不可用，只有当场景已经开始运行后，该按钮才呈可用状态。在运行期间单击该按钮场景即停止运行。对于如何控制场景停止运行有3种方式。
　　选择Tools菜单下的Options命令，弹出Options对话框，如图所示，选中Run-Time Settings选项卡，有3种设置方式。
　　
　　方式一：等当前迭代运行结束后，再停止运行场景
　　方式二：等当前的Action运行结束后，再停止运行场景
　　方式三：不等待，立即停止运行场景。
　　Restart（重置/复位）：将方案中所有Vuser组重置为方案运行前的“关闭”（Down）状态，准备下一次场景的执行。
　　Vusers（虚拟用户组）：单机该按钮，能打开Vuser对话框，在Vuser对话框中可以查看Vuser组中每个Vuser的详细状态，如图所示，显示出该组中每个Vuser的ID、运行状态、脚本、负载发生器和所用的时间。
　　
　　在这里可以选择单个Vuser进行以下操作：
　　● 选择单个Vuser，单击Run按钮，运行该Vuser。
　　● 选择单个Vuser，单击Stop按钮，可以停止该Vuser的运行，选择Tools菜单下的Options命令，弹出Options对话框，如图所示，选中Run-Time Settings选项卡，可以设置Vuser以
　　哪种方式停止运行，包括“等当前迭代运行结束后，再停止运行场景”或“等当前的Action运行结束后，再停止运行场景”两种方式，如果希望逐渐停止处于“运行”状态的Vuser，则单机Gradual Stop按钮，该Vuser的状态将变为“正在逐步退出”并逐渐退出场景。
　　也可以右键单击，对Vuser进行以下的操作：
　　
　　● 选择Pause命令，可以暂停该Vuser，但是暂停Vuser将影响其事务响应时间。
　　● 选择Reset命令，可以重置该Vuser，使其重新回到“关闭”状态。
　　● 选择Initialize Vuser/s命令，可以初始化该Vuser。
　　● 选择Renumber命令，可以对该Vuser编号重新定义。
　　● 选择Filter Vusers命令，筛选显示出来的Vuser，可以选择不同的筛选条件进行筛选，也可以在Vuser对话框的筛选器中选择需要使用的筛选条件。
　　● 选择Sort Vusers命令，选择不同的排序方式对Vuser进行排序。
　　● 选择Show Vusers命令，查看正在执行所分配脚本的Vuser。此时会弹出运行查看器，并返回到Vuser的页面快照中，查看正在执行脚本的Vuser。运行查看器的功能与浏览器的功能不同，查看器显示的图像是快照，而不是回放的所有特征。
　　● 选择show Vuse log命令，会显示出该Vuser的脚本日志，收集到的日志信息由Run-Time Settings对话框中的Log选项卡中所设置的日志文件的信息决定，并且需要确定是收集所有的日志信息还是只收集错误日志信息。
　　
　　Run/Stop Vusers(运行/停止Vusers)：单击该按钮，打开Run/Stop Vusers对话框，在这里可以设置是继续执行还是停止某个用户组。
　　在运行期间，可以在Run/Stop Vusers对话框中手动控制新添加的Vuser。该对话框因运行场景的模式不同而有所不同。
　　在手动模式下，可以控制添加到Vuser组中的Vuser数，以及运行这些添加Vuser的负载发生器。如下图所示。
　　
　 也可以单击场景组中的Vuser按钮，在弹出的虚拟用户列表对话框中单击右侧控制区域的Add Vuser（s）按钮，弹出Add Vusers（添加虚拟用户）对话框，可以在此对话框中添加虚拟用户信息。如下图所示。
　
　 如果在百分比模式下运行场景，能够根据定义的百分比，在Vuser脚本中分配新的Vuser数，以及运行这些添加的Vuser的负载发生器。

4.3.2 场景执行期间查看场景

　　在场景运行过程中，可以查看Vuser执行的情况，主要包括以下几个方面的内容：
　　● Vuser运行状态
　　● 事务详细信息
　　● 查看“输出”窗口
　　1、Vuser运行状态
　　在场景执行期间，可以在“运行”视图中的“场景组”窗口中查看所有Vuser和Vuser组运行的状态，如图所示：
　　
　　场景组中这些状态的含义如下表所示。
　　
　　2、事务详细信息
　　可以在“运行”视图右上角的框中查看正在运行场景的概况，如图所示。
　　
　　单击右上角的窗口按钮可以将“场景状态”窗口从“运行”视图中分离出来。这将放大“场景组”窗格。
　　“场景状态”窗口中各参数项的含义如下表所示：
　　
可以单击“场景状态”窗口中“通过的事务数”或“失败的事务数”右侧的“显示快照”按钮，弹出“事务”对话框，在该对话框可以看到事务的详细信息，如图所示：

“事务”对话框中各列值得含义如下：
名称（Name）：显示脚本中所有事务的名称。
TPS：表示每秒的事务数。
通过数（Passed）：表示运行已通过的事务数。
失败（Failed）：表示运行已失败的事务数。
停止（Stopped）：表示运行已停止的事务数。
　　3、查看“输出”窗口
　　在场景运行时，Vuser和负载发生器会向Controller发送错误、通知、警告、调试和批处理消息，这些消息可以在“输出”窗口中查看到。
　　在开始执行场景是，LoadRunner会消除“输出”窗口中的消息。但是如果重置场景，消息还会保留在“输出”窗口中，除非设置LoadRunner在重置场景时删除“输出”窗口中的消息。
　　选择View—Show Output命令，或者单击场景状态错误列表右侧的“显示快照”按钮。弹出“输出”对话框，如图所示。该对话框默认显示的是错误信息。
　　
　　在Type of Message（消息类型）下拉列表框中，可以选择要显示的消息类型。
　　分析输出信息时，需要确定以下几个方面的问题：
　　（1）出错是由于性能测试引起的还是由于脚本编写的错误引起；
　　（2）找到出错的日志信息。
　　要找到出错的具体日志信息，必须通过输出的信息找到这几方面的信息，错误信息是来自哪台负载机，错误信息是来自哪个虚拟用户。确定这两方面的信息后就可以找到场景运行时的日志信息了，否则在运行大量虚拟用户时，如果一个一个地查看每个虚拟用户的日志信息，则效率很低。

4.4 场景监视

　　在前面场景信息中介绍了如何观察虚拟用户运行的状态，通过日志文件可以追溯虚拟用户运行失败是由脚本中哪条语句引起的。但是仅仅依靠这些信息还是无法更好地分析性能瓶颈，因为性能测试最重要的是找到服务器性能瓶颈出现的原因及调优方法，因此，需要通过监视器来获得更多的数据，帮助分析服务器性能瓶颈。所以要了解如何添加监视器和分析监视曲线图。

4.4.1 关于联机监控

　　通过联机监控器，LoadRunner可以查看场景执行期间生成的数据。使用LoadRunner联机图，可以指定场景执行期间Controller要监控的计算机，并可以查看监控器收集的数据。
　　在场景监控之前，必须安装和配置LoadRunner监控组件。LoadRunner监控的整个过程如下图所示：
　　
　　整个监控过程由控制器来执行并在监控过程中收集相关的数据，在场景运行时控制收集的信息主要包括以下几个方面：
　　（1）负载机执行时的数据
　　在监控过程中，负载机会先收集每个虚拟用户运行时的相关数据，再将这些数据发送到控制器，由监控器保存在一个数据库中，最后由分析器来重新整理这些数据，画成不同的曲线图。
　　（2）服务器运行时的相关数据。
　　关于服务器的监控主要包括以下几个方面：Web服务器（如微软的IIS、WebSphere、WebLogic、Tomcat、Apache等）、数据库服务器（如MySQL、SQL、Oracle等）。对于服务器的相关数据收集包括两个方面：一是服务器资源使用的情况；二是每种服务器其自身的一些特性；但使用LoadRunner性能测试时，LoadRunner更多的是监控每种服务器资源消耗的情况，对于其自身的一些特性需要使用其他的相关工具进行监控。在场景运行时，可以通过相关的监视图或计数器来获得服务器资源消耗的数据，最后由分析器重新整理并分析。
　　如需监控服务器自身的一些特性，往往需要借助第三方监控工具来实现，所以在整个性能测试过程中仅仅使用LoadRunner来监控还是不够的，还需要借助第三方工具来辅助监控。
　　LoadRunner主要提供的监视器包括：Runtime Graphs（运行时视图）、Transactions Graphs（事务视图）、Web Resource Graphs（Web资源视图）、System Resource Graphs（系统资源视图）、Network Graphs（网络视图）、Firewalls（防火墙视图）、Web Server Resource Graphs（Web服务器资源视图）、Web Application Sever Graphs（web应用服务器视图）、Database Server Resource Graphs（数据库服务器资源视图）、ERP/CRM Server Resource Graphs（ERP/CRM服务器资源视图）、Application Component Graphs（应用组件视图）、Application Deployment Solutions（应用程序部署解决方案）、Middleware Performance Graphs（中间件性能视图）、Infrastructure Resource Graphs（基本资源视图）。
　　运行时视图主要包括虚拟用户运行视图、用户自定义数据点视图、错误统计视图、出错的虚拟用户。
　　虚拟用户运行视图是指在整个场景过程中虚拟用户加载的过程，虚拟用户运行图与虚拟用户加载的图几乎一致。如下图所示
　　
　　
　　用户自定义视图是指通过LoadRunner自带函数lr_user_data_point绘制自己需要的视图，其实LoadRunner中所有视图都是由lr_user_data_point(画图函数)来绘制的。
　　lr_user_data_point函数格式：lr_user_data_point（const char *sample_name,double value）
　　参数sample_name表示视图名称：参数double value表示当前绘制视图点的值，数据类型为双精度类型。

int iDLSize=0;
web_url("WebTours",
    "URL=http://localhost:1080/WebTours/",
    "Resource=0",
    "RecContentType=text/html",
    "Referer=",
    "Snapshot=t1.inf",
    "Mode=HTTP",
    LAST);
    //获得页面属相，属性为页面的大小
    iDLSize=web_get_int_property(HTTP_INFO_DOWNLOAD_SIZE);
    lr_user_data_point("DownLoadSize",iDLSize);
1
2
3
4
5
6
7
8
9
10
11
12

　　事务视图主要包括事务响应时间和每秒处理的事务数（每秒处理的事务数又包括３种：结果为Passed的事务、失败和停止的事务和总的Passed的事务）。
　　其中事务响应时间是需要重点分析的视图，如图所示，其他3种视图分析的相对较少。
　　

　　需要注意的是，事务响应时间并不是平均事务响应时间，二是一个即时时间，并且统计出来的时间包括思考时间在内。
　　Web资源视图主要分析点击率视图和吞吐量视图。
　　点击率视图主要反映客户端虚拟用户每秒的点击数。
　　点击率必须与虚拟用户数成正比，如果点击率与虚拟用户不成正比，说明客户端提交的请求并未发送到服务器端。
　　吞吐量视图反映服务器的处理能力，它不但与虚拟用户成正比，同生死也与点击率成正比，即吞吐量的视图趋势应该与点击率的视图趋势一致，如果点击率正确，而吞吐量趋势图与之不一致，则说明服务器没有正确地处理客户用户提交的请求。
　　系统资源视图主要包括Windows系统资源、UNIX系统资源使用情况和SiteScope工具监控，这两种系统也是平常测试过程中最常见的两种系统。但在实际测试过程中，很少使用LOadRunner来监控Unix系统资源使用的情况，可能更多的是用于监控Windows系统资源的使用情况，针对Unix或linux系统通常会使用另外两种监控方式：一是使用命令监控，二是使用nmon监控工具进行监控，关于Unix和Linux系统的监控在后面会详细介绍。
　　SiteScope是LoadRunner提供的一个开源的、无需代理的监控工具，后面会详细介绍它的使用方法。
　　网络视图只包括一个视图网络延迟视图，它主要是观察测试过程中网络延迟的情况，一般情况下，在测试过程中一般不会使用LoadRunner来监控网络延迟的情况，网络工程师会使用专业的网络监控工具进行监控，不仅仅是监控其是否延迟，还会监控每个端口接受的请求数。
　　Web服务器资源视图主要包括Apache和MS IIS两种，在实际测试过程中，监控最多的是Apache服务器，主要需要监控的是每秒处理的字节数、Apache服务器资源使用的情况，但在实际测试过程中可能很少使用LoadRunner来监控，Apache自带了一个监控的模块，只要启动这个模块就可以监控Apache自身的情况了。后面会有详细介绍。
　　“Web应用程序服务器资源”监控器：度量场景运行期间应用程序服务器MS Active Server Pages和WebLogic（SNMP）统计信息的情况。
　　数据库服务器资源视图主要监控一些常用的数据库（DB2、Oracle和SQL Server）资源消耗的情况，但是关于数据库的监控包括两个方面的内容：一是数据库消耗系统资源的情况；二是每条查询语句执行的响应时间；对于LoadRunner来说，它只能监控第一种情况，如果想得到每条查询语句的执行的时间，还必须使用响应的数据库监控工具，后面会详细介绍数据库监控的情况。
　　“流媒体”监控器：用来度量场景运行期间RealPlayer和Media Player客户端以及Windows Media服务器和RealPlayer音频/视频服务器的统计信息。
　　“ERP/CRM服务器资源”监控器：用来度量场景执行期间SAP R/3系统、SAP Portal、Siebel Server Manager、Siebel Web服务器和PeopleSoft（Tuxedo）服务器的统计信息。
　　“应用程序组件”监控器：用来度量场景执行期间Microsoft COM服务器的统计信息。
　　“应用程序部署解决方案”监控器：用来度量场景执行期间Citeix MetaFrame XP和1.8服务器的统计信息。
　　“中间件性能”监控器:度量场景执行期间Tuxedo和IBM WebSphere MQ服务器的统计信息。
　　“基础结构资源”监控器：用于度量场景执行期间网络客户端数据点的统计信息。

4.4.2 监控器与度量

　　在场景执行过程中，可以监控各服务器的运行情况，在监视服务器之前还要做一些工作来确保监视连接成功。
　　（１）修改被监视主机访问模式。进入“系统和安全”—“管理工具”—“本地安全设置”—“安全选项”—“网络访问：本地账户的共享和安全模式”，将访问方式更改为“经典—本地用户以自己的身份验证”。还有一个需要注意的地方是，一定要设置密码，否则在Monitor Configuration中添加Measurements仍然会提示拒绝登录。
　　
　　（2）保证被监视系统开启了以下3个服务：Remote Procedure Call（RPC）、Remote Registry Service和Remote Registry。其中，Remote Procedure Call（RPC）Locator的登录选项中要输入当前主机账户和密码，然后重启该服务，其他服务设置不变。
　　注意：有时只要开启两个服务Remote Procedure Call（RPC）和Remote Registry Service即可，但是Windows XP必须开启Remote Registry这个服务。
　　（3）确认安装Controller的机器可以连接到被监视的机器。如果监控失败，并且LoadRunner找不到指定的服务器，请确认指定的服务器是否可用，在Controller或优化控制台计算机命令行中输入ping< server_name>（或ip），执行ping操作。
　　（4）验证可以正常连接后，如果仍有其他问题，可以参考表4-3所列的解决方法。
　　（5）确认并打开共享文件。首先，在被监视的机器上右击“我的电脑”—选择“管理”—共享文件夹—共享，在这里要有C$这样一个共享文件夹。没有的话就创建一个，然后，在安装LoadRunner的机器上使用运行，在命令行中输入“\\被监控机器IP\C$”,然后输入管理员账号和密码，如果能看到被监视机器的C盘了，就说明LoadRunner所在计算机具有被监视机器的管理员权限，可以使用LoadRunner去连接了。
　　
　　接下来要在Controller控制器中添加要监控的计算机资源。
　　选择菜单Monitors—Add Measurements命令或在视图中单击鼠标右键，在弹出的快捷菜单中选择Add Measurements命令。
　　
　　弹出系统资源对话框，如下图所示：
　　
　　在该对话框单击add按钮，可以添加要监控的计算机，添加好要监控的计算机后，可以在“资源度量位于:<计算机>”中选择要监视的一些指标进行添加。（监控服务器的资源度量指标）
　　

4.4.3 联机监视器

　　在场景运行期间，可以在监控视图中查看数据变化的情况。默认情况下显示运行Vuser、事务响应时间、每秒点击次数和Windows资源4个视图，如图所示：
　　
　　可以双击某个视图，将其最大化，再次双击又还原为平铺视图。
　　同时显示视图的个数也可以设置，右击并在弹出的快捷菜单中选择View Graphs命令，可以设置同时显示1、2、4、8个视图，也可以选择自定义同时显示视图的个数，自定义显示视图最多只能设置16个视图同时显示。如下图所示：
　　
　　关于监视器选择设置。在菜单Tool—options中的Monitors选项卡中设置。使用该选项卡可以启用事务监控器，配置事务数据的行为，并设置联机监控器的数据采样速率、错误处理、调试和频率，如下图所示
　　
　　事务数据：用来配置“事务”、“数据点”、“Web资源”联机图的数据行为，要注意的一点是，更改设置后，要重新连接负载机后才能生效。
　　●　启用事务监视器：使联机的Vuser事务监控器在场景开始时监控事务；
　　●　频率：用来设置联机监控器为生成“事务”、“数据点”、“Web资源”联机图采集数据的频率，以秒（s）为单位。默认值为5s。对于小型场景，建议设置场景为1s；对于大型场景，建议设置为3~5s。频率越高，网络流量越低。在这个指定的时间段内，系统将计算数据的平均值，并仅向Controller发送一个值。
　　●　数据采样速率：采样速率是连续采样之间的时间间隔，以秒为单位。用来设置LoadRunner在场景中采集监控数据的速率。默认情况下，联机监控器采集数据的时间间隔为3S。如果增大采样速率，则数据的监控频率将会降低。此设置将应用于所有的视图。
　　错误处理：用来控制LoadRunner发出错误消息的方式，可以选择发送至“输出”窗口或弹出错误消息框中的一种。
　　●　将错误发送至“输出”窗口：将执行场景过程中所有的错误发送至“输出”窗口。
　　●　弹出错误消息框：把错误发送至消息框。
　　调试：用来调试场景。
　　●　显示调试信息：把与调试有关的信息发送至输出日志。可以指定一个调试级别，调试级别可选范围为１～９.其中调试级别仅与网络监控有关。
　　在场景执行过程中为了更好地监控视图可以对视图的属性进行设置。选择“监控器”—“联机图”—“配置”，或者右击某个图，在弹出的快捷菜单中选择“配置”命令，将打开“Graphs Configuration（图配置）”对话框，
　　● Refresh rate（see）：输入刷新率。
　　● Time：设置X轴显示时间的方式。
　　● Graph Time（see）：设置X轴显示的是时间长度。
　　● Display Type：设置视图的类型，包括“线形图”和“条形图”两种。如果选择“条形图”，那么下面的Bar Values Type选项可用，可供选择的值有“平均值”、“最后值”、“最小值”、或“最大值”。
　　●　Y-Axis Scale：设置Y轴的最大值和最小值，也可以勾选“自动”复选框使用默认的Y轴比例查看图。
　　●　设置使用范围：设置当前的视图属性只适用于当前选择的视图还是适用于所有的视图。
　　

4.5 小结

本章主要介绍Controller控制器的内容，Controller控制器主要包括两部分的内容——场景设置和场景监控。场景设置主要包括两部分内容——手动模式和目标模式，重点需要掌握场景设计中每个选项的设置的情况；场景监控主要是监控场景运行过程中服务器的表象情况，主要监控的内容有错误输出信息、点击率视图、吞吐量视图、事务响应时间和如何添加计数器。