一、参数替代

我们以tk系统(http://topka.cn/)的前台注册功能为例,来说明“参数化”的基本操作,如下图,为提交注册信息的部分脚本:

%E6%88%AA%E5%9B%BE37.png?version=1&modif     %E6%88%AA%E5%9B%BE38.png?version=1&modif

注:在参数化前一定要更改一下参数运营脚本进行测试,看脚本是否正常注册。举例把email:xiaoqiang01@163.com  改为xiaoqiang02@163.com等

在这里,我们根据实际业务情况,分析得出,如果让脚本注册另外一个新的用户信息,需要替换“邮箱”、“昵称”(密码和确认密码可以不用替换,因为他们不是唯一的值)两个数值,这就需要对两个数值进行“参数化”操作,在脚本执行时,让参数按照我们设定的规则,从数据源中获取不同的数值。

提到“数据源”,我们来掌握一种在实际工作中相对简便又适用的一种“数据源”——“txt记事本文件”。

实际的性能测试过程中,大量的测试数据来源或从数据库中导出,或由测试人员自行创建。我们使用Excel表格进行数据的整理或者创建。在Excel表格中,每一列代表一个参数,列头为参数名称,自行创建。建议使用具备表达含义的字母组合。Excel 表格中的数据完备后,直接复制到记事本中。然后将记事本文件放入“数据”目录下,以方便调用。如下图:

%E6%88%AA%E5%9B%BE39.png?version=1&modif

现在开始对脚本中相关数值,用参数进行替换。在脚本中,选中数值,点击右键,选择“Replace with a Parameter”。如图:

%E6%88%AA%E5%9B%BE40.png?version=1&modif

进行参数属性设置:

%E6%88%AA%E5%9B%BE41.png?version=1&modif

Parameter name: 填写参数名称,注意:这里名称与txt文本中相关参数列名相同;

Parameter type: 参数类型保持默认“File”;

我们将脚本中需要进行“参数替换”的数值,处理完毕后,见下图:

%E6%88%AA%E5%9B%BE43.png?version=1&modif

 这里提及一个技巧:我们注意到,关于“邮箱信息”的参数设置。无论在“txt数据源”中,还是在脚本的参数替代中,我们都没有设置专门的“邮箱参数”。在实际性能测试中,当某些测试数据存在一定的规律性,例如:邮箱信息@前的内容等于用户名,我们完全可以进行参数复用,对邮箱信息进行“部分参数化”;

二、参数设置:

 完成脚本中的“参数替换”,接下来我们要进行重要的“参数设置”。

 点击工具栏上的“参数设置按钮”,如图:

%E6%88%AA%E5%9B%BE44.png?version=1&modif

 在参数设置的窗体中,左侧列出所有参数名称。我们需要对每个参数进行分别设置。我们以“email”为例来说明,选择“email”。

2.1 连接数据源

%E6%88%AA%E5%9B%BE45.png?version=1&modif

由于默认的数据源是LR默认指定的email.dat文件,其数据量只有一条录制脚本时使用的参数原始值email,可以通过编辑该.dat文件来丰富数据源。

为了使性能测试工作更加规范化,方便统一维护,我们采取调用事先准备好的txt文件来作为数据源。

Txt和dat文件都可以作为数据源供参数化使用。为了获得更好的参数读取性能,建议将.txt文件更改为.dat文件使用。.dat文件同样可以使用记事本编辑。

点击“Browse”,在项目目录下的“数据”目录中,选择相关dat数据文件:

%E6%88%AA%E5%9B%BE46.png?version=1&modif

 把email和name都分别选择一下。

2.2  Select column设置区域

%E6%88%AA%E5%9B%BE47.png?version=1&modif

 该区域设置参数所对应的数据列。设置方式分为两种:

 “By number”,即按照列序号来指定,工具默认方式;

 “By name”,即按照列名称来指定;

  为了增强脚本可读性,我们统一使用“By name”方式来指定参数数据列。在下拉列表中选择与参数名一致的“email”。

2.3  File format 设置区域

 %E6%88%AA%E5%9B%BE48.png?version=1&modif

 

“Column” ,对文本文件进行“列识别”的方式,保持默认的“Tab”;

 “First data”,设置参数第一次取值时,从列表中第几行数据开始获取,默认为1,此处设置在实际工作中经常用到,某些情景下是需要随时改变设置的。例如,某系统注册模块,要求用户名不能重复。我们每次注册100个新用户,当第一次场景执行完毕,列表中前100个用户数据已经录入系统。第二次场景执行时,重新利用这些用户数据进行注册,显然是失败的。再次执行场景之前,需要在脚本中,修改此处设置为从101开始。下一次修改为从201开始……以此类推,当然前提是,要保证数据源中的数据量是完全充足的。

2.4 参数化取值规则

%E6%88%AA%E5%9B%BE50.png?version=1&modif

Select next row 与 Update value on

这两个选项的设置,直接决定性能测试场景运行的成败,重要程度不言而喻。

通过灵活的组合配置,可以实现多种复杂业务场景的正确参数供应,想要熟练使用LoadRunner测试工具,本知识点的掌握为重要的必备技能。

为了更好地掌握理解,我们详细解释各选项的含义 :

Select next row  取值规则

设置参数如何取值,也就是该参数对记事本中的那列数据,按照什么规则进行取值。其中三种选项分别为:Sequential 按顺序取值、Random 按随机取值、Unique 按全新理念取值。下面章节,我们详细研讨三种取值规则。

 Update value on 换值时机

当参数具备了自己的取值规则,也只能决定了自己可以成功获取第一个值,那么自己什么时候再去记事本里获取下一个值,来换掉目前的取值呢,Update value on正是为此设立。其中三种选项分别为:Each Iteration 每次迭代时换值、Each Occurrence 该参数每次出现即换值、Once 按照取值规则取得第一个值后,一直不再换值了。

在进一步细化学习设置“取值规则”、“换值时机”之前,我们需要先理清一下杂乱的思绪:这两项设置,永远是针对单虚拟用户的个体行为而言。并非对场景中宏观的用户群的行为秩序进行约束。

2.4.1 Sequential

按顺序取值。这个“顺序”,顾名思义,从数据列中第一条数据开始,逐一向下取值,即为按顺序取值。那么,是谁按顺序呢?

%E6%88%AA%E5%9B%BE51.png?version=1&modif

我们先来一起思考一个例子:假设我们模拟5个虚拟用户(Virtual User简称VU)进行登录操作,记事本里提供name1到name5五条数据供取值,是否可以理解为:在场景执行时,Sequential设置,约束5个虚拟用户按照顺序进行取值,即:第一个VU取值name1,第二个VU取值name2,第三个取值name3,以此类推。是事实否?

2.4.2  Random

随机取值。这是一种没有规则的规则。即为随意取值。我们实际工作中貌似运用不多。

2.4.3 Unique

 

按全新理念取值。“Unique”,字面理解为“唯一的,独一无二的”。参数化中,选择该种取值方式,即注定了这个VU非常有个性的性格,此个性可概括为“顺序+挑剔(全新)”。

 

有序,某种程度上等同于“Sequential”。挑剔,特指具备该设置的VU在一个场景运行周期内,去数据源中取值时,凡是遇到非全新的,即被用过的数据均不采用,继续按照有序状态寻找全新数据。注意:这个“被用过的数据”不仅包括其他VU采用过的,也包括它自己采用过的,多么有个性的一面!

 

可以说Unique的出现,开创了并发场景运行中,庞大的VU队伍,各有所执的逼真风景。

 

那么,Unique的选择,是否就是针对对整个VU用户群的行为约束呢?非也,“只用全新”就是单个VU的取值理念。

2.4.4 “行看齐”取值规则

 

新版LR,增加了“行看齐”的取值规则。如果具备“行对应关系”的多个参数,保存在同一个txt文本中。如下图所示的“email”与“name”:

%E6%88%AA%E5%9B%BE53.png?version=1&modif    %E6%88%AA%E5%9B%BE54.png?version=1&modif

 

如何保证email取值“xiaoqiang02”时,name取同行的值“xiaoqiang02”,email换值“xiaoqiang03”时,name换同行的对应值“xiaoqiang03”? 

我们可能会挺直腰板、昂首挺胸地回答,将两个参数的“取值规则”设置相同即可,例如:都设置为“Unique”,每个参数都按照从头到尾的顺序、逐一采用全新的数据换值,就保证对应了……

可以说,对于单VU来执行脚本,参数的取值方式都设置为“Unique”,可以完全保证参数之间的“数据行对应”。但对于多VU来同时执行这个脚本,只能说大部分情况下可以保证参数之间的“数据行对应“。科学是严谨的,哪怕有一丝漏洞的误差,都会有出现故障的几率,我们不妨来认识一下,多VU下如何产生这个几率极小的故障: 

极端假设:2个VU同时执行脚本,VU1执行到email时,txt列表中都是新值,VU1非常坦然的为自己的email取得xiaoqiang02 ,于是继续向下执行脚本,待执行name参数 时,再去txt中为name取新值……

再说VU2,按理说VU1、VU2被我们的Controller设置为同时出发的,唉但毕竟由于各种因素还是有很微妙的先后,让VU1脚本率先执行到了参数email,抢到了xiaoqiang02,刹那间,说时迟,那时快!随后VU2也执行到了email,赶着去txt里为自己的 email取值,发现晚了0.000001秒,刚被VU1抢走了头彩xiaoqiang02,VU2恼恨啊,但自己天生被设置了Unique属性,注定了自身必须取全新的个性,因此取了xiaoqiang03,继续回去向下执行脚本,心想,待执行到name参数时,老夫再来“抢值“! 

OK!时间暂停!! 

我们来裁判下,从脚本开始运行,一直执行到出现第一个参数email,这段路程,VU1显然以0.000001秒的微弱差距领先,因此抢到了name1。那么,下一段赛程:从email参数位置,执行到出现第二个参数name,这段路程中可能有很多其它脚本、其他风景……那么,VU1、VU2在这段赛程中,谁会领先到达name参数位置呢? 

你还能斩钉截铁保证,VU1还会以领先0.0000001秒的差距再次险胜吗?可能是,也可能不是。 

如果不是,那么VU2先执行到name,立刻去txt中的“name数据列”中抢到头彩“xiaoqiang02”,或许刹那间的0.0000000000001秒之后,VU1疯了似的冲进txt中,但一切晚矣……

事实表明,在这次极端并发中,VU1执行脚本分别为参数取值:xiaoqiang02 , xiaoqiang03 ;VU2执行一次脚本分别为参数取值:xiaoqiang03,xiaoqiang02; 

想要解决此不和谐境况吗?请使用“Same line as……”。 

还以上边的例子说明,如果脚本中第二个参数name的取值方式设置为“Same line as email”,那么就注定了name与email每次取值,都在同一行。那么VU1在第一次以0.000001秒领先抢到xiaoqiang02时,也注定了同行的数据“xiaoqiang02”也被自己为自己脚本中的第二个参数name预定了。VU2失守了第一轮赛跑,取得了数据name2,在接下来的第二轮奔向name的赛程中,即使超光速执行,也早已注定,自己的name参数早被“Same line as……” 预定了xiaoqiang03的同行“xiaoqiang03”。 

为保证我们的性能测试在大量VU、业务场景相对复杂的情况下,所有参数化取值严密有序。统一遵照如下规范:在同一“txt”文本中的所有参数,当需要设置Unique取值方式,只设置第一个参数为Unique,其他参数的取值设置,都通过“Same line as 第一个参数”来实现。 

%E6%88%AA%E5%9B%BE55.png?version=1&modif %E6%88%AA%E5%9B%BE57.png?version=1&modif %E6%88%AA%E5%9B%BE56.png?version=1&modif

2.5 参数化换值时机

%E6%88%AA%E5%9B%BE51.png?version=1&modif

2.5.1 Each Iteration

每次迭代时换值。“迭代”,我们前面有所学习,即脚本中有关“Action”的部分重复执行。某参数选择此项换值时机,脚本每重复执行一次Action里的内容,Action中的该参数就去数据源中换取一个新值。该参数在Action中无论出现几次,都处于本次迭代的执行中,因此只取一次值。

思考一下:如果某脚本Action中有两处出现参数logname,数据源如上图记事本内容,参数取值逻辑中取值方式为Sequential,换值时机为Each Iteration。该脚本中对Action设置了迭代规则,迭代次数为2次。那么,脚本执行结束后,logname分别取了哪些值呢?

2.5.2 Each Occurrence

每次出现即换值。我们打开脚本,如果参数“logname”在脚本中多个位置出现,那么设置该选项,当脚本执行时,每遇到“logname”出现,就去数据源中换一个值。

思考一下:如果某脚本Action中有两处出现参数logname,数据源如上图记事本内容,参数取值逻辑中取值方式为Sequential,换值时机为Each Occurrence。该脚本中对Action设置了迭代规则,迭代次数为2次。那么,脚本执行结束后,logname分别取了哪些值呢?

2.5.3 Once

一直不再换值。脚本执行从开始到执行结束,无论迭代多少次,无论某参数出现多少次,始终保持第一次的取值,不再换值,直到脚本执行完成。即,某VU测试跑完。在场景中,每个VU都遵守这个同样的“专一规则”。

思考一下:如果某脚本Action中有两处出现参数logname,数据源如上图记事本内容,参数取值逻辑中取值方式为Sequential,换值时机为Once。该脚本中对Action设置了迭代规则,迭代次数为2次。那么,脚本执行结束后,logname分别取了哪些值呢?