qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

LoadRunner中Action的迭代次数的设置和运行场景中设置

 LoadRunner是怎么重复迭代和怎么增加并发运行的呢?
  另外,在参数化时,对于一次压力测试中均只能用一次的资源应该怎么参数化呢?就是说这些资源用了一次就不能在用了的。
  --参数化时,在select  next row选择unique,update value on选择 each occurence,
  1. 迭代跟虚拟用户数没什么必然联系
  迭代是这样的:
  迭代1次   迭代2次  迭代3次
  用户1     X1           X2             X3
  用户2     Y1           X2             Y3
  其中的X1-3 Y1-3是参数,参数规则就是二楼说的
  这么两个用户是根据你的rump up 上来的,比如5秒上两个用户,那么用户1和2就在5秒之内加载进来的,不知道说清楚了没。
  第二个问题就简单了,只能用一次的参数,首先确保你的参数足够,另外规则选择的时候,注意选择唯一
  迭代次数只是对你设置了迭代次数的action进行迭代,而用户数可以理解为对整个录制过程的迭代(只是各个用户不同) 而且增加并发量可以通过增加用户来达到 还可以设置集合点来增加某个操作的并发量
  假如一个脚本,设置最大并发量为10,每5秒中增加2个并发用户,而Action设置的迭代为10次:
  当开始至2秒时,加载了2个用户,这2个用户分别开始运行,并都运行10次,不管这个2个用户运行10次是否结束,当下一个2两秒到来时,即开始至第4秒时又加载了2个用户,这2个又运行10次;就这样一直加载到10个并发用户,然后当每个用户都运行完10次时就结束。
  这样中间最大并发是10个,但不一定能达到10个,因为在加载最后几个时,前面的有可能已经运行结束,所以如果要真正达到最大并发10就必须设置集合点来完成
  不过也不一定非要设置集合点才能实现同时处在running的状态有10个用户。
  设置duration也是可以的。不过那就不只每个用户运行10次了。
  如果想实现用户迭代10次,并且想同时running为10个用户,就应该设置集合点。
  迭代(Iterate)设计,或者我们称之为增量(Incremental)设计的思想和XP提倡的Evolutionary Design有异曲同工之妙。
  注意:1、 参数类型:在创建参数的时候,我选择了参数类型为File。参数类型共有9 种,现在来简单介绍一下所有的参数类型以及意义。
  1.1、   DateTime:在需要输入日期/时间的地方,可以用 DateTime 类型来替代。其属性设置也很简单,选择一种格式即可。当然也可以定制格式。
  1.2、   Group Name:很少用到。在实际运行中,LoadRunner 使用该虚拟用户所在的Vuser Group 来代替。但是在 VuGen 中运行时,Group Name将会是None。
  1.3、   Load Generator Name :在实际运行中, LoadRunner   使用该虚拟用户所 在LoadGenerator   的机器名来代替。
  1.4、   Iteration Number :在实际运行中,LoadRunner 使用该测试脚本当前循环的次数来代替。
  1.5、   Random Number:随机数。很简单。在属性设置中可以设置产生随机数的范围。
  1.6、   Unique Number:唯一的数。在属性设置中可以设置第一个数以及递增的数的大小。
  注意:使用该参数类型必须注意可以接受的最大数。例如:某个文本框能接受的最大数为99。当使用该参数类型时,设置第一个数为 1,递增的数为1,但100个虚拟用户同时运行时,第100 个虚拟用户输入的将是 100,这样脚本运行将会出错。这里说的递增意思是各个用户取第一个值的递增数,每个用户相邻的两次循环之间的差值为 1。举例说明:假如起始数为 1,递增为 5,那么第一个用户第一次循环取值 1,第二次循环取值 2;第二个用户第一次循环取值为 6,第二次为 7;依次类推。
 1.7、   Vuser ID:设置比较简单。在实际运行中,LoadRunner 使用该虚拟用户的 ID   来代替,该 ID   是由 Controller 来控制的。但是在 VuGen 中运行时,Vuser ID   将会是 –1。
  1.8、   File:需要在属性设置中编辑文件,添加内容,也可以从现成的数据库中取数据
  1.9、   User Defined Function:从用户开发的 dll 文件提取数据。
  用HTTP协议录制了一个包含登录、浏览、退出过程的脚本,录制时都放到Action部分,这时脚本设置了迭代后可以多次重复运行,但是出于处理逻辑,一旦将登录脚本放到Init部分后,就无法正常进行迭代运行了。今天专门找个时间做了尝试,发现可能出现这两种错误。
  1、这是我犯的一个低级错误。在我将登录脚本移到Init部分时,将登录脚本之后的浏览操作前面的web_reg_find脚本也一起移了过去,结果运行完Init部分脚本就出错了。错误提示:
  Error -27259: Pending web_reg_save_param/reg_find/create_html_param[_ex] request(s) detected and reset at the end of the Init section
  这种错误的现象是没有进行迭代已经出错了,错误提示也很明确。这时只要把web_reg_find放回Action部分的正确的位置即可。
  2、单次运行正确,但是多次迭代运行时出错,错误提示:
  Error -27985: There is no context for HTML-based functions. A previous function may not have used "Mode=HTML" or downloaded only non-HTML page(s), or the context has been reset (e.g., due to a GUI-based function)
  这种错误可能比较常见,原因是在Runtime Settings的Browse Emulation中设置了Simulate a new user on each iteration引起的。由于这个设置导致每次迭代时都会模拟一个新的用户,此时这个新的用户并没有执行init操作而失败了,也即是错误提示中的There is no context。
  这里涉及到一个知识点就是在Rumtime Settings的迭代设置中,迭代运行次数只对Action部分有效,而Init部分和End部分还是只运行一次的。这时如果设置了“Simulate a new user on each iteration”,将出现上面的第2种错误。

posted on 2014-06-16 10:18 顺其自然EVO 阅读(7820) 评论(0)  编辑  收藏 所属分类: loadrunner


只有注册用户登录后才能发表评论。


网站导航:
 
<2014年6月>
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜