随着测试越来越重要,其中的性能测试也受到越来越多的关注。比较普遍的性能测试工具是Loadrunner7.51,但是很多人对此性能工具不是很熟悉。本人也是总结心得体会,将做过的性能测试实例以饷大家,希望对各位做测试的朋友有所帮助。 该方案是针对某公司试题库的性能测试。该试题库是用来对公司内部员工培训结果的一个考核。试题库在公司内部web服务器上,假设开设50个账号和密码可供50个考生同时参加考试。要求,每台机器只能由一个用户使用,每个用户只能使用各自不同的账号登录考试系统,做完题目后,要求提交考试结果,若在制定的时间内不提交,则系统强制提交考试结果。
但是,一般测试部门不可能有50台机器同时进行测试的。所以,可以借Loadrunner7.51模拟IP地址,修改脚本来协助测试。但是,为了保证测试结果,建议搜罗公司中所有可用的机器进行复测,因为有时候是不可以完全信赖工具的。
现场测试环境
硬件:50台PC机,Web服务器
软件:Loadrunner7.0,Win2000,IE5.0和IE6.0
人员:质控部2人,执行现场测试
项目部22人,提供现场环境
技术部各1人,提供技术支持
测试要求
50个用户拥有独立IP地址,不同的用户及密码登录,试题完成后各自同时提交。
测试内容
50个用户以不同的用户名和密码登录试题库。试题完成后,提交考试结果。测试考试结果是否能正常提交以及正确评分。
测试方案
1、 完全20台实际的PC机进行现场测试。
(1) 准备工作,并做计划。第一轮测试执行三遍,设定用户考试内容全部同时提交,第一遍全部使用IE5.0,第二遍10台使用IE5.0,10台使用IE6.0,第三遍全部使用IE6.0
(2) At 9:00 ,20个用户同时登录系统
(3) At 9:05 ,20个用户同时全部提交
(4) 分别记录第一轮测试(三遍)的结果
(5) 第二轮测试准备工作,设定15个用户考试内容同时提交,另外5个用户延时5分钟提交,全部使用IE5.0
(6) At 9:15 ,20个用户同时登录系统
(7) At 9:20 ,15个用户同时提交
(8) At 9:25 ,剩余5个用户同时提交
(9) 记录第二轮测试结果
(10) 第三轮测试准备工作,设定15个用户考试内容同时提交,另外5个用户延时5分钟提交,全部使用IE6.0
(11) At 9:15 ,20个用户同时登录系统
(12) At 9:20 ,15个用户同时提交
(13) At 9:25 ,剩余5个用户同时提交
(14) 记录第三轮测试结果
(15) 第四轮测试准备工作,设定15个用户考试内容同时提交,另外5个用户延时5分钟提交,正常提交用户使用IE5.0,延时提交用户使用IE6.0
(16) At 9:15 ,20个用户同时登录系统
(17) At 9:20 ,15个用户同时提交
(18) At 9:25 ,剩余5个用户同时提交
(19) 记录第四轮测试结果
(20) 第五轮测试准备工作,设定15个用户考试内容同时提交,另外5个用户延时5分钟提交,正常提交用户使用IE6.0,延时提交用户使用IE5.0
(21) At 9:15 ,20个用户同时登录系统
(22) At 9:20 ,15个用户同时提交
(23) At 9:25 ,剩余5个用户同时提交
(24) 记录第五轮测试结果
(25) 第六轮测试准备工作,设定15个用户考试内容同时提交,另外5个用户延时5分钟提交,正常提交用户其中10个使用IE5.0,5个使用IE6.0,延时提交用户使用IE5.0
(26) At 9:15 ,20个用户同时登录系统
(27) At 9:20 ,15个用户同时提交
(28) At 9:25 ,剩余5个用户同时提交
(29) 记录第六轮测试结果
(30) 第七轮测试准备工作,设定10个用户考试内容同时提交,另外10个用户分两次分别延时5分钟、15提交
(31) At 9:35 ,20个用户同时登录系统
(32) At 9:40 ,10个用户同时提交
(33) At 9:45 ,剩余的其中5个用户同时提交
(34) At 9:55 ,剩余的5个用户同时提交
(35) 记录第七轮测试结果,参见第二轮测试-第六轮测试过程分别对IE5.0和IE6.0的情况进行测试
(36) 第八轮测试准备工作,设定其中10个用户不提交,由系统强行提交
(37) At 10:10 ,20个用户同时登录系统
(38) At 10:15 ,10个用户同时提交
(39) 其余用户的内容由系统强行提交
(40) 记录第八轮测试结果,参见第二轮测试-第六轮测试过程分别对IE5.0和IE6.0的情况进行测试
(41) 第九轮测试准备工作,设定其中10个用户同时提交,5个用户延时5分钟提交,其余用户由系统强行提交
(42) At 10:25 ,20个用户同时登录系统
(43) At 10:30 ,10个用户同时提交
(44) At 10:35 ,剩余的其中5个用户同时提交
(45) 剩余5个用户系统强制提交
(46) 记录第九轮测试结果,参见第二轮测试-第六轮测试过程分别对IE5.0和IE6.0的情况进行测试
2、 模拟20个用户进行测试。其中,10台是PC机,另外10台机器的IP地址是Loadrunner模拟出来的。
(1) 在10台实际的PC机中抽取其中一台虚拟10个IP地址,包括自身的IP地址,该机器上共11个IP地址,这11个IP地址只能全部使用IE5.0或者全部使用IE6.0
(2) 其余9台实际的PC机分别由9个人操作,另外一台机器由一位质控部人员操作
(3) 对于异常情况,延时提交和强制提交全部由实际的机器来模拟
(4) 其余过程参见1
3、 模拟20个用户进行测试。其中,5台是PC机,另外15台机器的IP地址是用Loadrunner模拟出来的。
(1) 在5台实际的PC机中抽取其中一台虚拟15个IP地址,包括自身的IP地址,该机器上共16个IP地址,这16个IP地址只能全部使用IE5.0或者全部使用IE6.0
(2) 其余4台实际的PC机分别由4个人操作,另外一台机器由一位质控部人员操作
(3) 对于异常情况,延时提交和强制提交全部由实际的机器来模拟
(4) 其余过程参见1
4、 模拟35个用户进行测试。其中,20台是PC机,另外15台机器的IP地址是用Loadrunner模拟出来的。
(1) 在20台实际的PC机中抽取其中两台分别虚拟7个、8个IP地址,这17个IP地址只能全部使用IE5.0或者全部使用IE6.0
(2) 其余18台实际的PC机分别由18个人操作,另外两台机器由两位质控部人员操作
(3) 对于异常情况,延时提交和强制提交全部由实际的机器来模拟
(4) 其余过程参见1
5、 模拟50台用户进行测试。其中,20台是PC机,另外30台机器的IP地址是用分别用两台实际的PC机模拟出来的。记录测试结果。
(1) 在20台实际的PC机中抽取其中两台分别虚拟15个IP地址,这32个IP地址只能全部使用IE5.0或者全部使用IE6.0
(2) 其余18台实际的PC机分别由18个人操作,另外两台机器由两位质控部人员操作
(3) 对于异常情况,延时提交和强制提交全部由实际的机器来模拟
(4) 其余过程参见1
6、 对5中所述情况重复测试两次。
7、 为了保证结果的正确性,完全50台实际的PC机进行现场测试。过程参见1
测试过程
注:该测试过程针对虚拟IP地址情况。
1、 一台PC机上创建15个虚拟的IP地址。首先,启动IP Wizard,如下:开始程序->Loadrunner->Tools->IP Wizard
点击"Add",添加你计划虚拟的IP地址。但是注意不能添加已经被占用的IP地址。
2、 启动Virtual User Generator,并录制脚本,由于50个用户的账号和密码各不相同,所以,要修改脚本,设置参数。我是录制了一个脚本,复制了49份,在每个脚本中手工修改了各自不同的地方。
3、 启动Loadrunner Controller,先将刚才保存的脚本添加进来。然后点击"Scenario"菜单,激活其中的"Enable IP Spoofer"。
4、 点击屏幕右方的"Generators",添加已经建立的IP,然后connect建立连接。
5、对连接起来的不同用户(IP地址)分配不同的脚本,在Controller中的"design"中,点击"Load Generators"其中,每个脚本有一个用户执行。
LoadRunner中的90%响应时间是什么意思?这个值在进行性能分析时有什么作用?本文争取用最简洁的文字来解答这个问题,并引申出"描述性统计"方法在性能测试结果分析中的应用。
为什么要有90%用户响应时间?因为在评估一次测试的结果时,仅仅有平均事务响应时间是不够的。为什么这么说?你可以试着想想,是否平均事务响应时间满足了性能需求就表示系统的性能已经满足了绝大多数用户的要求?
假如有两组测试结果,响应时间分别是{1,3,5,10,16}和{5,6,7,8,9},它们的平均值都是7,你认为哪次测试的结果更理想?
假如有一次测试,总共有100个请求被响应,其中最小响应时间为0.02秒,最大响应时间为110秒,平均事务响应时间为4.7秒,你会不会想到最小和最大响应时间如此大的偏差是否会导致平均值本身并不可信?
为了解答上面的疑问,我们先来看一张表:
在上面这个表中包含了几个不同的列,其含义如下:
CmdID 测试时被请求的页面
NUM 响应成功的请求数量
MEAN 所有成功的请求的响应时间的平均值
STD DEV 标准差(这个值的作用将在下一篇文章中重点介绍)
MIN 响应时间的最小值
50 th(60/70/80/90/95 th) 如果把响应时间从小到大顺序排序,那么50%的请求的响应时间在这个范围之内。后面的60/70/80/90/95 th也是同样的含义
MAX 响应时间的最大值
我想看完了上面的这个表和各列的解释,不用多说大家也可以明白我的意思了。我把结论性的东西整理一下:
1. 90%用户响应时间在LoadRunner中是可以设置的,你可以改为80%或95%;
2. 对于这个表,LoadRunner中是没有直接提供的,你可以把LR中的原始数据导出到Excel中,并使用Excel中的PERCENTILE函数很简单的算出不同百分比用户请求的响应时间分布情况;
3. 从上面的表中来看,对于Home Page来说,平均事务响应时间(MEAN)只同70%用户响应时间相一致。也就是说假如我们确定Home Page的响应时间应该在5秒内,那么从平均事务响应时间来看是满足的,但是实际上有10-20%的用户请求的响应时间是大于这个值的;对于Page 1也是一样,假如我们确定对于Page 1的请求应该在3秒内得到响应,虽然平均事务响应时间是满足要求的,但是实际上有20-30%的用户请求的响应时间是超过了我们的要求的;
4. 你可以在95 th之后继续添加96/ 97/ 98/ 99/ 99.9/ 99.99 th,并利用Excel的图表功能画一条曲线,来更加清晰表现出系统响应时间的分布情况。这时候你也许会发现,那个最大值的出现几率只不过是千分之一甚至万分之一,而且99%的用户请求的响应时间都是在性能需求所定义的范围之内的;
5. 如果你想使用这种方法来评估系统的性能,一个推荐的做法是尽可能让你的测试场景运行的时间长一些,因为当你获得的测试数据越多,这个响应时间的分布曲线就越接近真实情况;
6. 在确定性能需求时,你可以用平均事务响应时间来衡量系统的性能,也可以用90%或95%用户响应时间来作为度量标准,它们并不冲突。实际上,在定义某些系统的性能需求时,一定范围内的请求失败也是可以被接受的;
7. 上面提到的这些内容其实是与工具无关的,只要你可以得到原始的响应时间记录,无论是使用LoadRunner还是JMeter或者OpenSTA,你都可以用这些方法和思路来评估你的系统的性能。
事实上,在性能测试领域中还有更多的东西是目前的商业测试工具或者开源测试工具都没有专门讲述的——换句话说,性能测试仅仅有工具是不够的。我们还需要更多其他领域的知识,例如数学和统计学,来帮助我们更好的分析性能数据,找到隐藏在那些数据之下的真相。