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

在Vugen端实现

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

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

int num;
Action()
{
    num = rand()%3;
    lr_start_transaction("综合业务--数据创建与数据查询");
    if(num<2){
        Data_Create();  //数据创建
    }
    else{
        Data_Search();  //数据查询
    }
    lr_end_transaction("综合业务--数据创建与数据查询", LR_AUTO);
    return 0;
}

该种方式的优缺点对比：

优点：

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

缺点：

  • 在已有数据创建和数据查询脚本的情况下，针对混合业务场景需要单独创建一个混合业务脚本，且混合比例改变时需要重新修改脚本；
  • 当需要考察混合业务场景中不同业务类型各自的响应时间时，通过该种方式无法实现。

在Controller端实现

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

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

该种方式的优缺点对比：

优点：

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

缺点：

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