-
LR 中参数设置的更新方法和分配方法研究(三)
2007-12-07 02:09:57
3. Unique分配方法:
场景设置:10个VU,5次迭代
迭代
Each Iteration
(Abort Vuser,Automatically allocate block size)
Each Iteration
(Continue in a cyclic manner,Allocate 3 values for each Vuser)
Each Iteration
(Continuewith last value,Allocate 3 values for each Vuser)
1st
VU1在参数出现的所有位置都使用”001”;VU2为”006”;VU3为”011”;VU4为”016”
VU1在参数出现的所有位置都使用”001”;VU2为”004”;VU3为”007”;VU4为”010”; VU5为”014”; VU6为”017”
VU1在参数出现的所有位置都使用”001”;VU2为”004”;VU3为”007”;VU4为”010”; VU5为”014”; VU6为”017”
2nd
VU1在参数出现的所有位置都使用”002”;VU2为”007”;VU3为”012”;VU4为”017”
VU1在参数出现的所有位置都使用”002”;VU2为”005”;VU3为”006”;VU4为”011”; VU5为”015”; VU6为”018”
VU1在参数出现的所有位置都使用”002”;VU2为”005”;VU3为”006”;VU4为”011”; VU5为”015”; VU6为”018”
其余的迭代
依次类推,VU1在五次迭代中分别使用”001~005”,VU2为”006~010”,VU3为”011~015”,VU4为”016~020”,其余6个VU均失败
依次类推,VU1在五次迭代中分别使”001~003”,VU2为”004~006”,VU3为”007~009”,VU4为”010~013”,VU5为”014~016”;VU6为”017~019”,其余4个VU均因为分配不到足够的值而失败,而已分配到值的每个VU因迭代次数超过所分配到的值时,剩下的迭代将循环取值.
依次类推,VU1在五次迭代中分别使”001~003”,VU2为”004~006”,VU3为”007~009”,VU4为”010~013”,VU5为”014~016”;VU6为”017~019”,其余4个VU均因为分配不到足够的值而失败,而已分配到值的每个VU因迭代次数超过所分配到的值时,剩下的迭代将取最后一个值.
结果说明:从log分析来看,Unique的分配方法主要也是针对单个VU进行更新的,这里需要关注的是block size的设置. Automatically allocate block size其实和迭代的次数有关，如果迭代的次数为N，则LR会分配N个values给每个用户，所以当10个VU需要进行10次迭代，那参数列表中就需要提供10x10个参数值，每个VU分配到10个values，否则就会出现"insufficient records for param 'OutputValue' in table to provide the Vuser with unique data"这样的错误。如果手动设置block size，假如有N个VU，block设置为M，则，那么参数列表中就需要提供NXM个参数值，每个VU分配到M个values，至于when out of values发生后，到底是失败告终，或者是循环取值，还是取最后一个值，这只是设置上的策略问题而已了。
在unique分配方法下，当更新方法为Each occurrence, 则Vuser 将会为每一次参数的出现从数据表格中提取一个新的唯一值，即使它在同一次迭代中,block size 的设置可参考上表，这里不做详细说明。
在unique分配方法下，当更新方法为once, 则第一次迭代中分配的唯一值就会在接下来的所有迭代中使用，例如VU1使用“001”，VU2使用“002”…这里不做详细说明。
-
LR 中参数设置的更新方法和分配方法研究(二)
2007-12-07 02:08:51
2. Random分配方法:
场景设置:10个VU,10次迭代
迭代
Each Iteration
Each occurrence
Once
1st
VU1在参数出现的所有位置都使用从参数表中随机选取的一个值,例如”003”;
VU1在第一次参数出现的位置使用从参数表中随机选取的值,例如”002”,在第二次参数出现的位置又使用从参数表中随机选取的值,例如”012”,在第三次参数出现位置又使用从参数表中随机选取的值,例如”009”
VU1在参数出现的所有位置都使用第一个参数出现时从参数表中随机选取的一个值,例如”007”
2nd
VU1在参数出现的所有位置都使用从参数表中随机选取的一个值,例如”019”
VU1在第一次参数出现的位置使用从参数表中随机选取的值,例如”001”,在第二次参数出现的位置又使用从参数表中随机选取的值,例如”007”,在第三次参数出现位置又使用从参数表中随机选取的值,例如”013”.
VU1在参数出现的所有位置都使用第一次迭代中第一个参数出现时从参数表中随机选取的那个值,即”007”.
其余的迭代
依次类推,VU1在参数出现的所有位置都使用从参数表中随机选取的值,
依次类推,VU1在第一次参数出现的位置使用从参数表中随机选取的值,在第二次参数出现的位置又使用从参数表中随机选取的值,在第三次参数出现位置又使用从参数表中随机选取的值.
VU1在第一次迭代第一个参数出现的位置使用从参数表中随机选取的值,该值会在该VU1接下来的参数位置和所有迭代中使用.
结果说明:从log分析来看,Random的分配方法主要是针对单个VU进行更新的,所以上表也是对单个VU的更新进行说明,不同的VU的参数值也是随机的.
-
LR 中参数设置的更新方法和分配方法研究
2007-12-05 12:26:11
最近在用LR做性能测试的时候,总是在参数化问题上碰到一些问题,比如在参数化用户登陆时,照设置字面意思理解,选择了sequential和Each occurrence,以为每当一个VU碰到该参数就会顺序从参数表中取下一个值,结果导致执行测试时只有一个VU成功PASS,有时还在执行测试时,还会碰到"insufficient records for param 'OutputValue' in table to provide the Vuser with unique data"这样的错误,等等这些错误都是对LR中参数设置的更新方法和分配方法没有理解透彻.参考LR用户手册,但还是觉得有点糊涂,所以自己做了一些实践来加强对这些参数设置的理解.避免在以后工作中再碰到类似的错误.
在LR脚本中,我写了一段简单的C代码以供实践研究用,如下:
Action()
{
char * output1;
char * output2;
char * output3;
output1 = lr_eval_string("{OutputValue}");
output2 = lr_eval_string("{OutputValue}");
output3 = lr_eval_string("{OutputValue}");
lr_output_message("iteration%s: vu%s output1 is %s",lr_eval_string("{iteration}"), lr_eval_string("{vuID}") ,output1);
lr_output_message("iteration%s: vu%s output2 is %s",lr_eval_string("{iteration}"), lr_eval_string("{vuID}") ,output2);
lr_output_message("iteration%s: vu%s output3 is %s",lr_eval_string("{iteration}"), lr_eval_string("{vuID}") ,output3);return 0;
}参数化了三个值:OutputValue,iteration,vuID,其中OutputValue是我们要研究的对象,其参数类型为File,参数表中设置了20个参数值,分别是001~020,其他两个参数作为辅助参数以方便在log中进行查找使用,参数类型分别为Iteration Number和Vuser ID.
为了在log中看到详细的参数替换信息,可以在run-time settings中点选Extended log -> Parameter substitution.
1. sequential分配方法:
场景设置:10个VU,10次迭代
迭代
Each Iteration
Each occurrence
Once
1st
所有的VU在参数出现的所有位置都使用“001”
所有的VU在第一次参数出现的位置使用“001”，第二次参数出现的位置使用“002”，第三次参数出现位置使用“003”
所有的VU在参数出现的所有位置都使用”001”
2nd
所有的VU在参数出现的所有位置都使用“002”
所有的VU在第一次参数出现的位置使用“004”，第二次参数出现的位置使用“005”，第三次参数出现位置使用“006”
所有的VU在参数出现的所有位置都使用”001”
其余的迭代
依次类推，当取完20个参数值后，所有的VU循环从头继续顺序取值
依次类推，当取完20个参数值后，所有的VU循环从头继续顺序取值
依次类推，所有的VU在参数出现的所有位置都使用”001”
结果说明:从log分析来看,sequential的分配方法主要是针对所有的VU进行更新的.
-
深入理解并发用户
2007-12-04 23:19:14
提到软件性能测试,相信性能测试人员对"并发用户"这个词汇并不陌生吧.那什么是并发用户呢?怎么去理解并发用户这个概念呢?我想,在这里对这个概念做一个深入的探讨,相信会对大家有一个启示作用.
以前做过几个性能测试项目,但对并发用户这个概念,就只是从字面上泛泛的理解为:用户在同一时刻对系统进行请求操作,而被测系统在同一时刻收到所有用户发过来的请求操作并对其进行响应.这是我早期做性能测试所理解的一个概念，如果所有用户不在同一时间点上发出请求操作就不应该称之为并发用户,所以每当我做性能测试都会在请求操作前加上一个集合点.
通过自己不断的学习实践,现在对这个概念又有了新的认识.
在英文中，并发用户是concurrent users,concur是动词,是同时发生,共同起作用的意思,concur 同时发生+ -ent 形容词后缀,就是形容词,同时发生的,同时存在的,并存的意思.那么并发用户就是同时发生的用户,同时存在的用户,并存的用户的意思.
其实在实际的性能测试中,不能抛开实际的业务场景而去谈并发,我在以前对并发用户的理解其实体现的是一个服务器端所能承受的并发用户的概念.从这里出发,并发用户可以从两个角度去理解.
一,业务角度,从业务的角度模拟真实的并发用户访问.这种并发的概念通常在性能测试(Performance Testing)方法中使用.在实际性能测试中,还有几个和并发用户相关的概念,就是"并发用户数","系统用户数","同时在线用户数".假如有一个OA系统,该系统一共有5000个使用用户,极端情况就是5000个用户同时在线,但实际情况中很少发生,这里5000就是系统的"系统用户数";大多数论坛都设计了在线统计功能和最高峰时的在线人数,这里统计的数字就是显示在这一个时间段上登陆该系统的用户数及"同时在线用户数",而最高峰时的"同时在线用户数"就是系统使用时最大的业务"并发用户数",但这个并发用户数并不代表服务器实际承受的压力,服务器实际承受的压力不仅取决于"并发用户数",还取决于用户的业务场景.至于并发用户数的具体值该如何估算,会再以后文章中深入.
二,从服务器承受压力的角度来考虑,这里提到并发的概念通常在并发测试(Concurrency Testing)方法中使用,当大量用户同时对系统进行请求操作时,体现的是服务器端承受的最大并发访问数.和我以前理解的并发用户是一个概念,这主要是针对同一个应用,同一个操作,同一个模块或者数据记录进行多用户并发访问.
从上面两种不同角度对并发用户的解释,引出了两种测试方法:性能测试方法和并发测试方法,不同的测试方法对于并发用户在场景中的设计也是截然不同的，说到这里,大家对并发用户这个概念应该有了一个更清晰的概念了吧.
