loadrunner混合场景测试

应用场景

假设有3个不同的测试场景，分别为并发登录、核心业务、可靠性测试，3个场景有先后执行顺序。由于白天测试机器另有用处，只能在晚上进行性能测试，这时我们的期望是能否把测试场景都设定好之后晚上自动运行，第二天我们回来看测试结果呢？ 答案是肯定的，可以有两种方式实现。 第一种，相对简单

充分利用LR Controller里面Group的功能。

新建一个场景把3个脚本都添加进来，在Edit Schedule中选择“Schedule by Group”的方式，在StartTime中设置3个脚本的运行顺序为“Start when Group xxx finished”，并在“Scenario Start Time”中设定场景在晚上的运行启动时间。设定完定时执行场景后，点击StartScenario按钮，会出现一个倒计时窗口，这样在固定的某个时间上，测试场景中的3个脚本将乖乖的按照设定的先后顺序进行测试。注意，如果没有点击StartScenario按钮激活测试，是不会真正进行测试的。（感谢Athenst朋友的提醒，^_^） 第二种，比较灵活

我们把应用场景稍微扩展一下，假设其中1、3场景只有一个测试脚本，而核心业务场景由数据录入、数据查询、数据上报3个脚本组成，同样的，3个场景仍需按顺序进行测试。这时如果采用第一种方式，由于第2个场景有3个脚本，所以第三个脚本的启动时间就是一个问题了。由于Controller中每个脚本都对应一个Group，而且GroupName不能重复，这时第三个场景的StartTime中“Start when group finished”则只能是选择第二个场景中的某个Group，而并非是第二个场景的3个脚本都完成之后再进行，无法达到我们的初衷。

这时，可以通过命令行的方式来进行。

首先创建并设置好3个测试场景，再创建一个一个批处理程序按先后顺序调用这3个场景进行测试，最后通过Windows的定时任务设定批处理的执行时间。 批处理示例如下： cls

SET M_ROOT=\%M_ROOT%\\wlrun.exe %M_ROOT%\\wlrun.exe %M_ROOT%\\wlrun.exe

-TestPath -TestPath -TestPath

\\\

Files\\MI\\Mercury Files\\MI\\Mercury Files\\MI\\Mercury

LoadRunner\\scenario\\Test\\TestScen_1.lrs\LoadRunner\\scenario\\Test\\TestScen_2.lrs\LoadRunner\\scenario\\Test\\TestScen_3.lrs\

这种方式比较灵活，但需要注意在Result Settings中设置“Automatically create a results directory for each scenario execution”，以免后面的测试结果覆盖了前面的。

另外补充一下，如果想对某个脚本进行50、100、150...等用户数递增的测试，也可以用以上方法实现，但需要注意的是将事务名称区分开以便进行分析。

有这样的一个案例：现网站有1000个同时在线用户，其中百分20%的用户浏览网页，30%的用户注册， 的用户登录，30%的用户查询，如何针对这种需求设计场景，（注不单设场景，要求使用混合场景全程模拟真实用户行为）： 设计 方法一：

1.录制完脚后，并对其进行完善，比如有这样三个脚本,Reg_Action,Login_Action,Order_Action

2.假如VU设为100个，30%的用户注册,20%的用户在登录，余下的用户做订票操作。 3.在场景中的run-time-setting中我们可以这样设置：在Run-Logic中在General Run Logic中设置run 属性，run有两种属性,一种是Sequential(顺序模式)，另一种是Random(随机模式)，通过Random这种方式，我们可以模拟30%的用户在注册，20%的用户在登录。（注，此设置是在控件器中的 run-time-setting中设置） 4.其中的 bloce块可以实现更为复杂的脚本运行策略 这种方法确少灵活性，下面描述如何用编程实现： 方法二：通过程序解决

1.用程序 来判断随机出来的概率和和其给定的值作判断，如果符合这个条件，则调用此函次（脚本一次）

2.比如说100个用户,20%就是20个用户,那么 【0-20】这个范围内， 在action中模拟20%的用户浏览网页，可以这么操作： Action{ int rowNum;

rowNum=rand()0+1; if (rowNum <=20%) //调用一个脚本 return 0;

}

例如：性能测试场景设计--混合业务场景下的脚本比例控制

在某个业务场景中，包含数据创建和数据查询两项业务；现需考察数据创建和数据查询两项业务在并发比例为2:1、总并发量为100用户情况下的混合响应时间。

在Vugen端实现

对混合比例的设置，可直接在脚本中进行，即通过随机函数rand实现，脚本设计如下所示。

int num; Action() {

num = rand()%3;

lr_start_transaction(\综合业务--数据创建与数据查询\ if(num<2){

Data_Create(); //数据创建 } else{

Data_Search(); //数据查询 }

lr_end_transaction(\综合业务--数据创建与数据查询\ return 0; }

该种方式的优缺点对比： 优点：

? 脚本本身实现了比例控制的功能，Controller端的设置较为简单，即在Controller中只需将该混合业务作为单一业务对待，设置也跟单一业务场景的设置方法完全相同；

? 测试得到响应时间即为混合业务的响应时间。

缺点：

?

在已有数据创建和数据查询脚本的情况下，针对混合业务场景需要单独创建一个混合业务脚本，且混合比例改变时需要重新修改脚本；

? 当需要考察混合业务场景中不同业务类型各自的响应时间时，通过该种方式无法实现。

2、在Controller端实现

在业务类型较多，混合业务场景较为复杂的情况下，采用修改脚本的方式会比较麻烦。例如，若共有5种业务类型，现需要对其任意两种业务的混合场景进行压力测试，如果仍采用第一种方式，那么我们就必须得针对两两业务的混合情况，创建10个混合业务脚本。当业务类型更多，或者混合场景更为复杂（如需考虑任意三种、任意四种业务等的混合情况）时，脚本的创建量会大大增加，且均为乏味的重复性工作。

针对这种情况，直接在Controller端进行设置会简单得多，只需要加载各个业务脚本，并设置不同脚本的并发数即可。对于本文中的案例，在Controller中的设置方法如下所示。

该种方式的优缺点对比： 优点：

? ?

无需单独创建混合业务脚本，特别是在业务类型较多的情况时优势更为明显； 测试得到的响应时间为各个业务独自的响应时间，可以实现对混合业务场景下各个业务的单独分析。

缺点：

?

计算混合业务的响应时间时，需要提取原始测试数据进行计算（不能直接对各个业务的平均响应时间取平均值来作为混合业务的平均响应时间），计算较为复杂。