引言
在阅读本文时，请先查看我们上期的文章哦！
场景开始时间
如图所示，场景启动时间设置有三种方式。
启动方式一：点击Start Scenario按钮后，场景立即开始，没有延误时间。
启动方式二：点击Start Scenario按钮后，推迟指定的时间后才开始运行。
启动方式三：点击Start Scenario按钮后，在指定的时间开始运行，如下午16:30运行。
假设在白天进行手工测试，晚上执行性能测试，这样就可以通过这个选项来设置指定的时间运行场景。
百分比模式
百分比模式是先设定好虚拟用户总数，然后按百分比的形式对所有的虚拟用户进行分配。该场景适合综合业务模型明确的性能测试。
百分比模式与“Manual Scenario（手动测试场景）”非常类似，但两者间还是存在一些不一致的地方。
单击下拉菜单【Scenario】→选择菜单项【Convert Scenario to the Vuser Group Mode】，即可以将手动场景模式转换为百分比模式。如图所示，在“％”列中设置虚拟用户组所占总虚拟用户数的百分比。
在运行综合业务时经常会用百分比模式，如银行业务一般就会使用百分比模式来运行，在测试过程中把查询、存款、取款等做成不同的业务（当然关于存款、取款又有很多种不同的方式，如银行卡向存折存款、存折向量银行卡存款等），之后做出百分比的业务模型，再使用百分比模式进行运行。
那么使用百分比模型运行场景时，最重要的问题是如何确定业务的百分比模型，即在整个业务体系中每个业务各自占的百分比，通常确定业务的百分比模型有以下几种方法：
分析历史数据
通过分析后台的历史数据是获得每种业务百分比最好的方式，可以分析一年或半年的业务量，如一年的总的业务量为10万笔，其中业务A做了3万笔业务、业务B做了5万笔业务、业务C做了2万笔业务。那么业务A、业务B、业务C占总的业务比分析为30%、50%、20%。
参考其它同类产品
如果系统以前未上线，是第一个版本的测试，那么可以参考同类产品性能测试的情况，如果同类产品有百分比模式那是最理想的了，如果没有现成的百分比模型，那么可以分析同类产品中每个业务的并发用户数、点击率和吞吐量来估算一下百分比模型。
试上线运行
如果既没有历史数据可分析也没有同类产品做参考，那么可以试上线运行，如果奥运会官方订票系统，类似这种系统是没有参考的，所以使用试上线运行的方式也是种不错的方法，通过试上线运行可以大体了解用户访问的情况以及每个业务被操作的次数，这样就可以得到一个估计的百分比模型。
面向目标场景
在面向目标场景中，首先定义测试需要达到的目标，然后LoadRunner会自动根据这一目标创建场景。
在“新建场景”对话框中，选择“面向目标场景（Goal-Oriented Scenario）”，如图所示。
在场景设置界面，点击Edit Scenario Goal按钮，进入编辑该目标场景对话框，如图所示，包含五种目标类型（Virtual Users、Hits per Second、Transactions per Second、Transaction Response Time和Pages per Minute），以Hits per Second目标类型为例，讲述其各项设置。
Scenario Settings选项卡
Scenario Settings选项卡包括设置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）”。
Load Behavior选项卡
设置加载行为，如图所示。
加载行为一：让Controller自动加载用户。
加载行为二：设定一个时间，在该时间后达到目标。
加载行为三：每隔一段时间增加一定的目标量。
目标类型（Goal Type）
Virtual Users目标类型
这种目标类型主要是用来测试服务器对并发用户的处理能力，这种目标类型与手动设置类型相类似，如图所示。假设将虚拟用户设置为100个，那么LoadRunner会逐渐递增虚拟用户，直到加载到100个为止，如果在加载到100个虚拟用户之前系统已经出现，那么LoadRunner将会采用“If target cannot be reached”中设置的策略来继续运行当前的场景。
Hits per Second目标类型
设置的目标是点击数/秒，如图所示。同时要设置最小虚拟用户数和最大虚拟用户数。那么为什么不直接每秒点击率的值呢？而同时还需要设置最大和最小虚拟用户数？因为如果点击率的值大小与虚拟用户数成正比，假设测试时测试出来的点击率的值达不到目标值，那么就必须增加虚拟用户数，否则点击率的值就不可能会增加，所以在设置点击率的值为目标时，就必须限定虚拟用户数的范围，也即最多和最小虚拟用户数的值。
当设置好目标点击率和虚拟用户数后，接下来的运行原理如下：
1.当场景执行时，Controller首先会使用最小的虚拟用户去执行，待执行结束后判断点击率的值是否达到目标值；
2.如果达到了，则停止运行当前的场景
3.如果未达到目标值，则继续增加虚拟用户，再判断结果是否达到预期目标值；
4.重复上面1-3步的步骤，直到达到目标。
如果使用最大的虚拟用户数还是无法达到目标值时，那么场景将会停止运行，并保存相应的结果。
Transactions per Second目标类型
设置的目标为每秒处理的事务数，但需要注意的是，在脚本中一定要定义事务，否则事务名称栏为空白，如图所示。
如果从业务的角度来看，每秒钟处理的事务数即为系统每秒钟处理的业务笔数，所以该项指标其实更多的用于衡量系统每秒钟处理的业务数。
同样的，在设置每秒钟处理的事务数后还必须设置最大和最小虚拟用户数，因为要改变每秒钟处理的事务数就必须通过虚拟用户数来改变，但需要注意的是，当虚拟用户数成倍增长时，处理的事务数并不会增倍增长，如假设当前虚拟用户数为50，平均每秒钟处理的事务数为40，但当虚拟用户增加到100个时，每秒钟处理的事务数肯定不可能到达80，因为随着虚拟用户数增多，事务的平均响应时间也增加了，这样在相同的时间内，每个虚拟用户处理的事务数就相当少了，所以处理的事务数不可能成倍增长。
当设置每秒钟处理的事务数和虚拟用户数后，接下来的运行原理如下：
1.当场景执行时，Controller首先会使用最小的虚拟用户去执行，待执行结束后判断每秒钟处理的事务是否达到目标值；
2.如果达到了，则停止运行当前的场景
3.如果未达到目标值，则继续增加虚拟用户，再判断结果是否达到预期目标值；
4.重复上面1-3步的步骤，直到达到目标。
如果使用最大的虚拟用户数还是无法达到目标值时，那么场景将会停止运行，并保存相应的结果。
Transactions Response Time目标类型
这类目标是设置在多用户并发时事务的响应时间。同时需要设置最大和最小虚拟用户数。
在场景执行时，如果部分虚拟用户并发就达到了定义的最大响应时间，那么需要调整策略后再重新执行，如图所示。该目标类型要求在脚本中一定要有事务，否则事务名称栏为空白。
需要注意的是，虚拟用户数与事务响应时间的关系，可能很容易理解错，因为随着虚拟用户数增多，事务响应时间会变长，那么同理，当虚拟用户少时事务的响应时间也就比短，如果事务响应时间没有达到目标值，就说明当然的事务响应时间还是可以接受的，这就说明系统还可以支持更多的虚拟用户。
当设置好事务响应时间和虚拟用户数后，接下来的运行原理如下：
1.当场景执行时，Controller首先会使用最小的虚拟用户去执行，待执行结束后判断事务响应时间是否达到目标值；
2.如果达到了，则停止运行当前的场景
3.如果未达到目标值，则继续增加虚拟用户，再判断结果是否达到预期目标值；
4.重复上面1-3步的步骤，直到达到目标。达到目标后，假设当前虚拟用户数为M个，那么说明系统最多只能处理M个用户同时请求。
如果使用最大的虚拟用户数还是无法达到目标值时，那么场景将会停止运行，并保存相应的结果，同时也说明系统可以支持更多的虚拟用户同时运行。
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类型的场景结果中会被置Failed状态：
1.控制器使用指定的最大用户数，并且执行两次都没有达到目标。
2.负载机不够。
3.所有的用户都运行失败。
4.控制器增加了几批虚拟用户后，Hits per Second、Transactions per Second、Pages per Minute的值没有增加。
配置View Script
在场景设计界面，用户脚本加载后，如果需要对加载的脚本进行修改，可以选中需要配置的脚本，点击右键在弹的菜单中选择View Script菜单对脚本进行修改，如图所示。需要注意的是，如果对脚本修改后，一定要在Controller中重新加载该脚本，才能确保场景执行中的脚本是修改后的脚本。
配置Load Generator
Load Generator又叫负载发生器，当控制器发出执行命令时，Load Generator负责和其他的负载机建立起联系并强制负载机执行。一般情况下在一台机器上安装好LoadRunner，会自动安装好Load Generator。一个Controller可以通过Load Generator来控制多台负载机。
点击右边的Generators按钮，会弹出Load Generators对话框，如图所示。
在Load Generators对话框中，点击Add按钮，可以添加负载机，添加完成后，点击Connect按钮，测试负载机与控制机连接的情况，如果Status为Ready，表示连接成功；如果为Failed，表示连接失败，这时就要检查网络是否存在问题。
在使用负载机模拟多用户测试系统时，需要注意以下几个问题：
如何计算需要多数台负载机
在使用负载机时首先需要解决的第一个问题是测试时需要多少台负载机才能满足测试的需要（如测试时需要测试500个虚拟用户），在确定该问题之前需要先确定每个虚拟用户需要消耗的系统资源，前面介绍过，当把每个虚拟用户按进程的方式来运行时，那么当场景运行时，每添加一个虚拟用户都是会增加一个进程，而每个进程都是需要消耗内存和CPU资源的。
通常情况下每个虚拟用户消耗多少资源受操作系统、录制时选择的协议以及LoadRunner的版本三个方面的影响，以Http/Html协议为例，LoadRunner官方公布的系统资源消耗的情况如图所示。
但官方公布的数据只是参考值，在实际测试过程中，应该以实际运行时资源消耗的数据为准，前面的章节中介绍过，如果与进程的方式运行时，每个虚拟用户都会添加一个进程，在测试需要观察每个进程消耗资源的情况，如图所示，在Window XP操作系统下，每个虚拟用户消耗的内存资源大概为6800KB左右。这样如果以500个虚拟用户为例大概需要消耗3320MB的内存，如果每台测试机的内存为1GB，那么至少需要4台测试这样的测试机。
控制器如果控制负载机运行
设置好负载机后，控制器是如何控制负载机产生并发用户并进行模拟运行的呢？LoadRunner运行的原理是，控制器通过代理程序去控制负载机运行（代理程序的名称为LoadRunner Agent Process），所以首先需要在控制器和客户端启动代理程序。
在开始菜单中选择所有程序，在弹出的所有程序中选择【HP LoadRunner】程序，再选择【Tools】菜单中的【LoadRunner 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：手动登录服务器。一般使用手动去登录即可。
启动代理程序后（需要注意的是控制器和负载机都需要启动代理程序），当场景在初始化时，控制器会向负载机发送一个二进制文件，该二进制文件中就包括所有待运行的脚本信息，当初始化之后，负载机就会产生虚拟用户来模拟测试。