LoadRunner场景设计

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

　　一、手动场景Schedule配置

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

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

　　1、场景名称(Schedule Name)

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

　　图4-7 配置Schedule　

　　图4-8 Schedule Name设置

　　2、按场景计划(Schedule by Scenario)

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

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

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

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

　　通常情况下选择第三种方式，在虚拟用户初始化的过程LoadRunner主要是将一个二进制文件发送给负载机，保证负载机能正常模拟多用户的运行指定的脚本，以及运行时的策略，所以只要在运行时，所以虚拟用户初始化完成即可，也即只有当所有虚拟用户都初始化完成后才开始运行脚本。第一种方式几乎不可能使用，因为这种情况不符合业务逻辑，并且可能会出现这种情况，在并发初始化所有虚拟用户时，初始化失败，导致刚开始运行时，虚拟用户数即没有达到定义的虚拟用户数;第二种方式也用的比较少，因为不好定义具体多长时间初始化多少个虚拟用户，所以一般使用第三种方式初始化。　　

　　图4-9 Initialize设置

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

　　图4-10 Start Vusers设置

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

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

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

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

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

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

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

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

　　图4-11 Duration设置

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

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

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

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

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

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

　　图4-12 Stop Vusers选项卡

　　3、按用户组计划(Schedule by Group)

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

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

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

　　图4-13 Start Group设置

　　运行方式一：场景执行时立即开始运行该脚本。

　　运行方式二：场景执行一段时间后才开始运行该脚本。

　　运行方式三：在某个特定的用户组运行结束后才开始运行该脚本，通俗的讲就是在某个脚本运行结束后才开始运行。

　　一般情况下使用场景组方式来运行场景时，会选中每个脚本分别进行设置。如果同时设置那么与普通的场景设置没有什么区别。

　　4、场景开始时间(Scenario Start Time)

　　如图4-14所示，场景启动时间设置有三种方式。　　

　　图4-14 Scenario Start Time设置

　　启动方式一：点击Start Scenario按钮后，场景立即开始，没有延误时间。

　　启动方式二：点击Start Scenario按钮后，推迟指定的时间后才开始运行。

　　启动方式三：点击Start Scenario按钮后，在指定的时间开始运行，如下午16:30运行。

　　假设在白天进行手工测试，晚上执行性能测试，这样就可以通过这个选项来设置指定的时间运行场景。

　　5、百分比模式

　　百分比模式是先设定好虚拟用户总数，然后按百分比的形式对所有的虚拟用户进行分配。该场景适合综合业务模型明确的性能测试。

　　百分比模式与“Manual Scenario(手动测试场景)”非常类似，但两者间还是存在一些不一致的地方。

　　单击下拉菜单【Scenario】→选择菜单项【Convert Scenario to the Vuser Group Mode】，即可以将手动场景模式转换为百分比模式。如图4-15所示，在“%”列中设置虚拟用户组所占总虚拟用户数的百分比。　　

　　图4-15 百分比模式中虚拟用户数设置

　　在运行综合业务时经常会用百分比模式，如银行业务一般就会使用百分比模式来运行，在测试过程中把查询、存款、取款等做成不同的业务(当然关于存款、取款又有很多种不同的方式，如银行卡向存折存款、存折向量银行卡存款等)，之后做出百分比的业务模型，再使用百分比模式进行运行。

　　那么使用百分比模型运行场景时，最重要的问题是如何确定业务的百分比模型，即在整个业务体系中每个业务各自占的百分比，通常确定业务的百分比模型有以下几种方法：

　　1) 分析历史数据

　　通过分析后台的历史数据是获得每种业务百分比最好的方式，可以分析一年或半年的业务量，如一年的总的业务量为10万笔，其中业务A做了3万笔业务、业务B做了5万笔业务、业务C做了2万笔业务。那么业务A、业务B、业务C占总的业务比分析为30%、50%、20%。

　　2) 参考其它同类产品

　　如果系统以前未上线，是第一个版本的测试，那么可以参考同类产品性能测试的情况，如果同类产品有百分比模式那是最理想的了，如果没有现成的百分比模型，那么可以分析同类产品中每个业务的并发用户数、点击率和吞吐量来估算一下百分比模型。

　　3) 试上线运行

　　如果既没有历史数据可分析也没有同类产品做参考，那么可以试上线运行，如果奥运会官方订票系统，类似这种系统是没有参考的，所以使用试上线运行的方式也是种不错的方法，通过试上线运行可以大体了解用户访问的情况以及每个业务被操作的次数，这样就可以得到一个估计的百分比模型。

　　二、面向目标场景Schedule配置

　　在面向目标场景中，首先定义测试需要达到的目标，然后LoadRunner会自动根据这一目标创建场景。

　　在“新建场景”对话框中，选择“面向目标场景(Goal-Oriented Scenario)”，如图4-16所示。　　

　　图4-16 启动面向目标场景

　　在场景设置界面，点击Edit Scenario Goal按钮，进入编辑该目标场景对话框，如图4-17所示，包含五种目标类型(Virtual Users、Hits per Second、Transactions per Second、Transaction Response Time和Pages per Minute)，以Hits per Second目标类型为例，讲述其各项设置。　　

　　图4-17 Scenario Settings选项卡

　　1、Scenario Settings选项卡

　　Scenario Settings选项卡包括设置Run Time和If target cannot be reached两部分设置内容，如图4-18所示。　

　　图4-18 Scenario Settings选项卡

　　在Run Time中设置一个时间值，表示当执行达到目标后，该场景还会持续运行一段时间(设置的时间值)才结束运行。

　　If target cannot be reached设置表示如果目标无法达到，Controller将如何处理场景。有两种选择，可以选择“停止运行场景并保存结果(Stop Scenario and save results)”，或“继续运行场景直到达到目标(Continue scenario without reaching goal)”。

　　2、Load Behavior选项卡

　　设置加载行为，如图4-19所示。

　　加载行为一：让Controller自动加载用户。

　　加载行为二：设定一个时间，在该时间后达到目标。

　　加载行为三：每隔一段时间增加一定的目标量。　　

　　图4-19 Load Behavior选项卡

　　3、目标类型(Goal Type)

　　(1)Virtual Users目标类型

　　这种目标类型主要是用来测试服务器对并发用户的处理能力，这种目标类型与手动设置类型相类似，如图4-20所示。假设将虚拟用户设置为100个，那么LoadRunner会逐渐递增虚拟用户，直到加载到100个为止，如果在加载到100个虚拟用户之前系统已经出现，那么LoadRunner将会采用“If target cannot be reached”中设置的策略来继续运行当前的场景。　　

　　图4-20 Virtual Users目标类型

　　(2)Hits per Second目标类型

　　设置的目标是点击数/秒，如图4-21所示。同时要设置最小虚拟用户数和最大虚拟用户数。那么为什么不直接只每秒点击率的值呢?而同时还需要设置最大和最小虚拟用户数?因为如果点击率的值大小与虚拟用户数成正比，假设测试时测试出来的点击率的值达不到目标值，那么就必须增加虚拟用户数，否则点率击的值就不可能会增加，所以在设置点击率的值为目标时，就必须限定虚拟用户数的范围，也即最多和最小虚拟用户数的值。　　

　　图4-21 Hits per Second目标类型

　　当设置好目标点击率和虚拟用户数后，接下来的运行原理如下：

　　1) 当场景执行时，Controller首先会使用最小的虚拟用户去执行，待执行结束后判断点击率的值是否达到目标值;

　　2) 如果达到了，则停止运行当前的场景

　　3) 如果未达到目标值，则继续增加虚拟用户，再判断结果是否达到预期目标值;

　　4) 重复上面1-3步的步骤，直到达到目标。

　　如果使用最大的虚拟用户数还是无法达到目标值是，那么场景将会停止运行，并保存相应的结果。

　　(3)Transactions per Second目标类型

　　设置的目标为每秒处理的事务数，但需要注意的是，在脚本中一定要定义事务，否则事务名称栏为空白，如图4-22所示。　

　　图4-22 Transactions per Second目标类型

　　如果从业务的角度来看，每秒钟处理的事务数即为系统每秒钟处理的业务笔数，所以该项指标其实更多的用于衡量系统每秒钟处理的业务数。

　　同样的，在设置每秒钟处理的事务数后还必须设置最大和最小虚拟用户数，因为要改变每秒钟处理的事务数就必须通过虚拟用户数来改变，但需要注意的是，当虚拟用户数成倍增长时，处理的事务数并不会增倍增长，如假设当前虚拟用户数为50，平均每秒钟处理的事务数为40，但当虚拟用户增加到100个时，每秒钟处理的事务数肯定不可能到达80，因为随着虚拟用户数增多，事务的平均响应时间也增加了，这样在相同的时间内，每个虚拟用户处理的事务数就相当少了，所以处理的事务数不可能成倍增长。

　　当设置每秒钟处理的事务数和虚拟用户数后，接下来的运行原理如下：

　　1) 当场景执行时，Controller首先会使用最小的虚拟用户去执行，待执行结束后判断每秒钟处理的事务是否达到目标值;

　　2) 如果达到了，则停止运行当前的场景

　　3) 如果未达到目标值，则继续增加虚拟用户，再判断结果是否达到预期目标值;

　　4) 重复上面1-3步的步骤，直到达到目标。

　　如果使用最大的虚拟用户数还是无法达到目标值是，那么场景将会停止运行，并保存相应的结果。

　　(4)Transactions Response Time目标类型

　　这类目标是设置在多用户并发时事务的响应时间。同时需要设置最大和最小虚拟用户数。

　　在场景执行时，如果部分虚拟用户并发就达到了定义的最大响应时间，那么需要调整策略后再重新执行，如图4-23所示。该目标类型要求在脚本中一定要有事务，否则事务名称栏为空白。　　

　　图4-23 Transactions Response Time目标类型

　　需要注意的是，虚拟用户数与事务响应时间的关系，可能很容易理解错，因为随着虚拟用户数增多，事务响应时间会变长，那么同理，当虚拟用户少时事务的响应时间也就比短，如果事务响应时间没有达到目标值，就说明当然的事务响应时间还是可以接受的，这就说明系统还可以支持更多的虚拟用户。

　　当设置好事务响应时间和虚拟用户数后，接下来的运行原理如下：

　　1) 当场景执行时，Controller首先会使用最小的虚拟用户去执行，待执行结束后判断事务响应时间是否达到目标值;

　　2) 如果达到了，则停止运行当前的场景

　　3) 如果未达到目标值，则继续增加虚拟用户，再判断结果是否达到预期目标值;

　　4) 重复上面1-3步的步骤，直到达到目标。达到目标后，假设当前虚拟用户数为M个，那么说明系统最多只能处理M个用户同时请求。

　　如果使用最大的虚拟用户数还是无法达到目标值是，那么场景将会停止运行，并保存相应的结果，同时也说明系统可以支持更多的虚拟用户同时运行。

　　(5)Pages per Minute目标类型

　　设置目标为每分钟处理的页面数，如图4-24所示。　　

　　图4-24 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菜单对脚本进行修改，如图4-25所示。需要注意的是，如果对脚本修改后，一定要在Controller中重新加载该脚本，才能确保场景执行中的脚本是修改后的脚本。　　

　　图4-25 配置View Script

　　四、配置Load Generator

　　Load Generator又叫负载发生器，当控制器发出执行命令时，Load Generator负责和其他的负载机建立起联系并强制负载机执行。一般情况下在一台机器上安装好LoadRunner，会自动安装好Load Generator。一个Controller可以通过Load Generator来控制多台负载机。

　　点击右边的Generators按钮，会弹出Load Generators对话框，如图4-26所示。　　

　　图4-26 Load Generator设置

　　在Load Generators对话框中，点击Add按钮，可以添加负载机，添加完成后，点击Connect按钮，测试负载机与控制机连接的情况，如果Status为Ready，表示连接成功;如果为Failed，表示连接失败，这时就要检查网络是否存在问题。

　　在使用负载机模拟多用户测试系统时，需要注意以下几个问题：

　　1) 如何计算需要多数台负载机

　　在使用负载机时首先需要解决的第一个问题是测试时需要多少台负载机才能满足测试的需要(如测试时需要测试500个虚拟用户)，在确定该问题之前需要先确定每个虚拟用户需要消耗的系统资源，前面介绍过，当把每个虚拟用户按进程的方式来运行时，那么当场景运行时，每添加一个虚拟用户都是会增加一个进程，而每个进程都是需要消耗内存和CPU资源的。

　　通常情况下每个虚拟用户消耗多少资源受操作系统、录制时选择的协议以及LoadRunner的版本三个方面的影响，以Http/Html协议为例，LoadRunner官方公布的系统资源消耗的情况如图4-27所示。　

　　图4-27 虚拟用户消耗内存资源参考值

　　但官方公布的数据只是参考值，在实际测试过程中，应该以实际运行时资源消耗的数据为准，前面的章节中介绍过，如果与进程的方式运行时，每个虚拟用户都会添加一个进程，在测试需要观察每个进程消耗资源的情况，如图4-28所示，在Window XP操作系统下，每个虚拟用户消耗的内存资源大概为6800KB左右。这样如果以500个虚拟用户为例大概需要消耗3320MB的内存，如果每台测试机的内存为1GB，那么至少需要4台测试这样的测试机。　　

　　图4-28 每个虚拟用户消耗内存的真实值

　　1) 控制器如果控制负载机运行

　　设置好负载机后，控制器是如何控制负载机产生并发用户并进行模拟运行的呢?LoadRunner运行的原理是，控制器通过代理程序去控制负载机运行(代理程序的名称为LoadRunner Agent Process)，所以首先需要在控制器和客户端启动代理程序。

　　在开始菜单中选择所有程序，在弹出的所有程序中选择【HP LoadRunner】程序，再选择【Tools】菜单中的【LoadRunner Agent Runtime Settings Configuration】选项，如图4-29所示。　　

　　图4-29 启动LoadRunner Agent程序

　　启动LoadRunner Agent程序后，弹出LoadRunner Agent设置对话框，如图4-30所示。　　

　　图4-30 LoadRunner Agent设置

　　Allow virtual users to run on this machine without user login：允许所有的虚拟用户不用登录即可运行，但需要设置登录主机的名称、用户名和密码。

　　Manual log in to this machine：手动登录服务器。一般使用手动去登录即可。

　　启动代理程序后(需要注意的是控制器和负载机都需要启动代理程序)，当场景在初始化时，控制器会向负载机发送一个二进制文件，该二进制文件中就包括所有待运行的脚本信息，当初始化之后，负载机就会产生虚拟用户来模拟测试。

　　本章节关于“LoadRunner场景设计”的内容就学习完了，大家喜欢的话记得每天来这里学习涨薪技能哦。(笔芯)

　　附：川石信息全国校区最新开班时间，课程资料获取13691729932(微信同号)。