51Testing软件测试论坛

标题: LoadRunner中实现一个系统下多用户多业务同时并发的场景设计 [打印本页]

作者: Athenst    时间: 2007-6-29 17:18
标题: LoadRunner中实现一个系统下多用户多业务同时并发的场景设计
不得不多说几句,
1、这个是土办法,但是可行的,下面有人说不可行,愿意的话就拿出证据来,咱们来辨一辨;
2、集合点是可以跨脚本的,后面已经这么确认过了。
另外可参考这个帖子http://bbs.51testing.com/viewthread.php?tid=81698


下面是本文原文:

LoadRunner中实现一个系统下多用户多业务同时并发的场景设计


场景要求如下:100个用户,其中10个用户执行A业务逻辑、20个用户执行B业务逻辑、30个用户执行C业务逻辑、40个用户执行D业务逻辑;要求这100个用户的操作是同时并发的。

由于多业务操作,那么首先会想到录制4个脚本+Group方式去执行这个场景,但是真的能做到吗?
每个单独的脚本中,都能控制同时执行A、或者B;但是怎么样控制ABCD同时执行呢?

所以我的办法是录制1个脚本,脚本中分别包含ABCD四个业务逻辑,分别用TrasactionA、TrasactionB、TrasactionC、TrasactionD表示。
首先确认以上操作是能够完成的,哪怕是录制4个脚本,然后手工将这四个脚本合并。

完成以上操作之后我们就有了这样的1个脚本,在这个脚本中是一个顺序执行的脚本,ABCD,如下:

Action

TransactionA;
TransactionB;
TransactionC;
TransactionD;


然后通过判断VUserID的方式来进行用户的分配,首先在ParameterList中新建一个VUserID类型的参数,定义为NewParam_VUserID;
那么在LoadRunner脚本中可以这样子引用到;

char ParamVUID_Nbr[24];
int ParamVUID_INT;
sprintf(ParamVUID_Nbr,"%s",lr_eval_string("{NewParam_VUserID}"));
lr_save_string(ParamVUID_Nbr,"ParamVUID_Nbr");
通过atoi函数进行字符串和数字之间的转换;
ParamVUID_INT = atoi( lr_eval_string("{ParamVUID_Nbr}"));

然后改写脚本为
Action
{
在这里加入集合点;
if (ParamVUID_INT<=10)
TransactionA;
if (((ParamVUID_INT>10)&&(ParamVUID_INT<=30))
TransactionB;
if (((ParamVUID_INT>30)&&(ParamVUID_INT<=60))
TransactionC;
if (ParamVUID_INT>60)
TransactionD;
}

OK,这下子应该可以顺利实现100个用户的按比例分发,并且让A、B、C、D并发执行了。

[ 本帖最后由 Athenst 于 2007-7-13 09:16 编辑 ]
作者: zhuzhu3431    时间: 2007-6-29 17:50
真的可以实现吗?学习了,试一下
作者: ppent    时间: 2007-6-29 22:11
我记得集合点好像可以跨脚本的吧。

[ 本帖最后由 ppent 于 2007-6-29 22:47 编辑 ]
作者: bluemoon1999    时间: 2007-6-30 09:01
这样做的话,只能通过设置循环次数来增加负载。
不能通过增加 虚拟用户人数来增加负载。
因为你是通过判断人员数量 来选择执行脚本的。
不知道我说的是否正确。。
作者: Athenst    时间: 2007-6-30 09:53
原帖由 ppent 于 2007-6-29 22:11 发表
我记得集合点好像可以跨脚本的吧。


确认一下:集合点跨脚本,能做到么,能做到的话就不用我这么麻烦了。
作者: Athenst    时间: 2007-6-30 10:19
原帖由 bluemoon1999 于 2007-6-30 09:01 发表
这样做的话,只能通过设置循环次数来增加负载。
不能通过增加 虚拟用户人数来增加负载。
因为你是通过判断人员数量 来选择执行脚本的。
不知道我说的是否正确。。



嗯,脚本一旦写好并已经在运行后,通过后续增加用户来加压就只能加到其中的一个业务逻辑上了。
作者: stevenhappy    时间: 2007-7-4 16:45
你这样真的能够实现吗?
也可以这样去做:做4个action,然后各自添加到group去运行。
作者: stevenhappy    时间: 2007-7-4 16:45
你这样真的能够实现吗?
也可以这样去做:做4个action,然后各自添加到group去运行。
作者: stevenhappy    时间: 2007-7-4 16:46
你这样真的能够实现吗?
也可以这样去做:做4个action,然后各自添加到group去运行。
作者: Athenst    时间: 2007-7-4 17:05
原帖由 stevenhappy 于 2007-7-4 16:46 发表
你这样真的能够实现吗?
也可以这样去做:做4个action,然后各自添加到group去运行。


真的可以实现的,呵呵,就是办法比较土。
作者: Athenst    时间: 2007-7-5 10:35
原帖由 ppent 于 2007-6-29 22:11 发表
我记得集合点好像可以跨脚本的吧。



^_^

真的可以,我刚才试了一下,sdlkfj5 ,抛出一块砖,引来一块玉啊。

sdlkfj1~~
作者: huangning    时间: 2007-7-8 16:05
原帖由 Athenst 于 2007-6-29 17:18 发表
Action
{
在这里加入集合点;       集合用户100
if (ParamVUID_INT<=10)
TransactionA;      1
if (((ParamVUID_INT>10)&&(ParamVUID_INT<=30))
TransactionB; 2
if (((ParamVUID_INT>30)&&(ParamVUID_INT<=60))
TransactionC;    3
if (ParamVUID_INT>60)
TransactionD;    4
}
...

1 2 3 4 这样可以实现并发操作吗?
作者: renheyou    时间: 2007-7-12 14:33
obviously not
作者: sophiaxin    时间: 2007-7-13 00:59
正好可以学习以下拉
作者: persist    时间: 2007-7-13 09:41
原帖由 ppent 于 2007-6-29 22:11 发表
我记得集合点好像可以跨脚本的吧。



能够吗,没有看到相关的介绍啊。结合点不是在脚本里设的吗,怎么跨脚本啊。
作者: bearding    时间: 2007-7-13 10:20
学习到了,但是集合点真的可以跨脚本么
作者: 断寒    时间: 2007-7-13 11:02
楼主你的脚本没有考虑清楚场景要求。
你说的场景在100人的情况下ABCD的执行比例。
但在你的脚本中体现一种思维定式。
应该考虑下,当有10个用户的时候,这10个用户可能是在做A这件事情,也有可能是B、C、D,或者混合。
应该讲,考虑的多点的话,混合的情况比较符合真实环境,就是取虚拟用户数为N,
N*10%------>A
N*20%------>B
N*30%------>C
N*40%------>D
需要从场景这样考虑脚本改写,就算用笨办法,也要用虚拟用户数的百分比的形式进行加压。
呵呵,还望指正。
作者: 断寒    时间: 2007-7-13 11:06
从LR的执行机制上就不难理解只要在一个场景的GROUP中,集合点名称相同的那几个脚本就会在那个集合点满足那个集合点策略下进行集合或释放
作者: 断寒    时间: 2007-7-13 11:09
Action
{
在这里加入集合点;
if (ParamVUID_INT<=10)
TransactionA;
if (((ParamVUID_INT>10)&&(ParamVUID_INT<=30))
TransactionB;
if (((ParamVUID_INT>30)&&(ParamVUID_INT<=60))
TransactionC;
if (ParamVUID_INT>60)
TransactionD;
}

这个IF语句是LZ故意写错还是怎么,这样显然在任何情况下就不可能满足ABCD都被执行。
只能执行ABCD中的一个。
作者: wangyong3552128    时间: 2007-7-13 11:47
TransactionA;是否执行了50次??
作者: wangyong3552128    时间: 2007-7-13 11:47
if (ParamVUID_INT<=10)
TransactionA;
是进来一个vu就判断吗?
作者: Athenst    时间: 2007-7-13 11:53
这个土办法脚本是不适合以下情况的:
在脚本运行过程中增加虚拟用户,这在上面6#已经回复过。

另外再和断寒兄唠嗑唠嗑~:)

这个脚本里面的IF是故意这样写的,就是要将100个虚拟用户分配到不同的业务逻辑上去~~
根据每个虚拟用户的ID来分配的,而判断条件就是ParamVUID_INT这个值~

欢迎再提意见和建议~
作者: Athenst    时间: 2007-7-13 11:55
原帖由 wangyong3552128 于 2007-7-13 11:47 发表
if (ParamVUID_INT


是这样子的,并发的时候100个用户是一起执行到集合点的;每个用户都有一个ID值。

通过这个ID值,在集合点释放之后,这些虚拟用户被分配到各个不同的事务上去。
作者: ppent    时间: 2007-7-13 13:11
Athenst朋友非常具有思考探索精神,测试人员就该具备这样的精神,这里先拍一下他的MP,以后好说话。sdlkfj2

再说一下,其实这种方法不是你所说的土方法,在Scott Barber的“User Experience, Not Metrics”系列的第三章有详细的介绍,文章将其成为灵活脚本方法(smart script method),这种方法使用起来非常灵活、快捷,其与脚本分组策略的区别从使用的角度其实没多大区别,但从负载服务器的资源使用方面就有很大的不同了。

我们知道,脚本在运行之前是需要先进行初始化的,这包括脚本的加载,以及参数(Rational robot中称为数据池)的初始化,这就意味着所有的分支操作脚本都会被加载进内存,而更大的开销是数据池,可以想象一下大量的数据池加载时的系统开销。(这里我认为参数池是在脚本初始化时就已经都准备好的,但我没有经过验证,如果有朋友验证过或有不同意见也请说一下)对于执行的用户而言,它只会执行其中的某条路径,其它分支对它来说是冗余的,而这些冗余的开销又会降低负载服务器所能承担的并发用户数。

在Scott Barber的文章介绍中,当只有少量的分支操作时,可以用灵活脚本的方式,当分支操作较多的时候,建议分开脚本并使用场景设置的方式。有兴趣的朋友可以去研究研究,中文版已经翻译完,但还在校验中,估计会在下周在我的博客上发表,不喜欢看英文的朋友也可以等一等。sdlkfj2
作者: 断寒    时间: 2007-7-13 13:47
标题: 回复 #24 ppent 的帖子
24楼的兄弟还能把E文电子档的发给我看看啊?
wang-r@neusoft.com.
谢谢啊~~
作者: ppent    时间: 2007-7-13 17:06
标题: 回复 #25 断寒 的帖子
You can download the doc from this url:http://www.perftestplus.com/resources/UENM3.pdf
作者: 断寒    时间: 2007-7-16 09:49
恩,谢了,这个网站里面的资源还满多的。呵呵。
作者: Hbxlhm    时间: 2007-7-17 22:21
谢谢楼主!
作者: tanbofish    时间: 2007-8-8 23:19
可以同时执行多个场景吗?如果可以同时执行多个场景就不可以了.没必要用这种方法啦.
作者: zxyu1982    时间: 2007-8-9 00:36
学习
作者: 泉声    时间: 2007-8-14 16:52
标题: 事务是可以跨action的.
事务是可以跨action的.但集合点好象没有听说过可以跨脚本的吧,只做过不同脚本命名同一个集合点.楼上的用例,其实可以做成四个脚本,分成4个group来,4个脚本的集结点设成同名就行了.不用搞得那么复杂哦.
作者: macco    时间: 2008-1-30 12:35
谢谢楼主,真是好东西!
作者: dominge    时间: 2013-8-29 16:42
实际上一个用户还是执行了某一个事务而已,楼主能否实现一个用户执行多个事务时候的并发吗
作者: lulu3    时间: 2013-9-2 17:31
逻辑不对,看业务需求,是100个不同的用户同时执行不同的操作,而楼主的逻辑是根据用户的数量执行不同的操作,所以你的脚本同时只能执行一个操作,不能够达到100个并发.也不能多操作
这是我理解的逻辑,不知道其他人怎么理解的




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2