发布新日志

  • [论坛] Loadrunner性能测试一个实例(经典)

    2007-06-15 11:54:11

    Loadrunner性能测试一个实例                 
      随着测试越来越重要,其中的性能测试也受到越来越多的关注。比较普遍的性能测试工具是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”其中,每个脚本有一个用户执行。
    6、 执行Scenario。

    北京地区对软件测试感兴趣的朋友可以和我交流:qq:306513768
    我的博客:http://www.51testing.com/?uid/110105


    [ 本帖最后由 rendaoyuan 于 2007-6-13 16:04 编辑 ]
  • [论坛] 性能测试的几个主要术语

    2007-06-15 11:13:13



    响应时间(response time

    响应时间,是指系统对用户操作的反馈时间。我们可以举一个163邮箱登录的例子:
    我们如何来测试邮箱的登录响应时间呢?我们首先进入[size=10.5pt]mail.163.com网页,输入合法的用户名和密码,点击“登录”,直到登录后的邮箱界面完全显示出来为止。那么响应时间从什么时候开始计算呢?是我们输入用户名的时候,还是点击“登录”的时候?
    显然,我们应该从按下“登录”按钮的那一瞬间开始计时,到登录后页面完全显示出来为止,这才是真正的用户登录时间,而不包括用户输入用户名和密码的时间以及思考停顿的时间([size=10.5pt]think time



    登录响应时间其实包括3个部分:网络传输时间,服务器处理时间,浏览器显示时间
    登录响应时间=网络传输时间*2+服务器处理时间+客户端显示时间
    网络传输是双向的,所以要乘以2。网络传输时间又可以包括接入网的传输时间和互联网中的传输时间,它的大小和你所使用的上网方式有关,比如光纤一般要比adsl要快。
    服务器包括web服务器和数据库服务器,服务器处理时间是我们测试的重点,也是我们能够控制的部分,因为最终用户用什么机器上网,什么接入方式上网我们是控制不了的。我们要重点测试服务器的处理速度如何,以及能否承受较大的压力,我们可以用工具(比如[size=10.5pt]LoadRunner)来模拟大量用户同时登录访问服务器,来查看服务器的承载能力。
    客户端显示时间,如何将服务器传过来的页面尽快地显示到浏览器上,是开发人员需要考虑的问题,这里面涉及到算法优化的问题,这也是开发人员容易忽略的地方。
    由此可见,响应时间是可以分解成若干个时间段的,任何一个环节出问题都会影响到最终的响应时间,这就需要我们在实际工作中结合具体情况加以分析。
    最后再说明一点,响应时间的快慢是一个相对的概念,没有绝对的标准,比如对于163邮箱登录来说,用户可以接受的时间可以在10秒以内,而对于一个实时的军工软件来说,相应时间要精确到毫米级别甚至更低。
    对于普通的web网站来说,一个普遍被接受的响应时间标准是2/5/10,即用户对2秒钟以内的的响应时间非常满意,对于5秒钟以内的响应时间基本满意,对于10秒钟以上的响应时间则无法接受,如图2-3


    吞吐量(throughput

    吞吐量,是指单位时间内流经被测系统的数据流量,一般单位为b/s,即每秒钟流经的字节数。
    吞吐量是大型门户网站以及各种电子商务网站衡量自身负载能力的一个很重要的指标,一般吞吐量越大,系统单位时间内处理的数据越多,系统的负载能力也越强。
    吞吐量和很多因素有关,比如服务器的硬件配置,网络的拓扑结构,软件的技术架构等。实际工作中,我们往往对升级客户的硬件配置无能为力,大多数情况下,我们还是在软件的技术架构上做文章:
    比如后台数据库装oracle还是装sql s[size=10.5pt]erver,显然前者的处理能力更强;
    web服务器是用w[size=10.5pt]eblogic还是iis,要看服务器端的语言是jsp还是asp…
    测试的时候多跟项目经理,系统架构师以及用户沟通,来获取系统架构的第一手材料。

    2.2.3并发(concurrency

    并发,是指多个同时发生的操作。比如有10个用户同时点击“登录”按钮(注意是同时),来登录163邮箱,我们就说此次登录163邮箱的并发数为10。
    需要注意的是,并发和并行不是一个概念,并发是同时发生,并行是同步运行。10个用户并发登录163邮箱,只是在点击“登录”按钮那一瞬间是并行的,而登录后各个用户的操作则不同步。

    稳定性测试(reliability testing


    稳定性测试,也叫可靠性测试([size=10.5pt]reliability testing),是指连续运行被测系统,检查系统运行时的稳定程度。


    我们通常用mtbf([size=10.5pt]mean time between failure,即错误发生的平均时间间隔)来衡量系统的稳定性,mtbf越大,系统的稳定性越强


    稳定性测试的方法也很简单,即采用24*7(24小时*7天)的方式让系统不间断运行,至于具体运行多少天,是一周还是一个月,视项目的实际情况而定。

    负载测试(load testing

    负载测试,是性能测试的一种,通常是指让被测系统在其能忍受的压力的极限范围之内连续运行,来测试系统的稳定性。
    可以看出负载测试和稳定性测试比较相似,都是让被测系统连续运行,区别就在于负载测试需要给被测系统施加其刚好能承受的压力,比如我们还是测试163邮箱系统的登录模块,我们先用1个用户登录,再用两个用户并发登录,再用5个,10个…在这个过程中,我们每次都需要观察并记录服务器的资源消耗情况(可以通过任务管理器中的性能监视器或者控制面板中的性能监视器),当发现服务器的资源消耗快要达到临界值时(比如cpu的利用率90%以上,内存的占有率达到80%以上),停止增加用户,假如现在的并发用户数为20,我们就用这20个用户同时多次重复登录,直到系统出现故障为止。
    负载测试为我们测试系统在临界状态下运行是否稳定提供了一种办法。

    压力测试(stress testing

    压力测试,是性能测试的一种,通常是指持续不断的给被测系统增加压力,直到将被测系统压垮为止,用来测试系统所能承受的最大压力。
    比如我们不断增加并发的登录用户数,20,30,50…比如,当增加到70个用户并发登录时,系统崩溃了,我们就可以知道163邮箱所能承载的最大登录并发数为70个左右。

    我们把上面的思路整理一下,编写一下163邮箱登录模块性能测试用例,供大家参考(假设163邮箱要求登录的时间最多不超过10秒,测试环境略)


    关于性能测试的分类,可以举一个比较通俗的例子方便大家理解:
    假设一个人很轻松就能背1袋米,背2袋米很吃力,最多就能背3袋米
    稳定性测试--我让他背1袋米,但是让他去操场上跑圈,看多久累倒。
    负载测试--我让他背2袋米去操场上跑圈,看多久累倒。
    压力测试--我让他背2袋米,3袋米,4袋米…发现他最多就能背3袋。
    北京地区对软件测试感兴趣的朋友可以加我qq交流:306513768
    欢迎访问我的博客:http://www.51testing.com/?110105

    [ 本帖最后由 rendaoyuan 于 2007-6-13 14:21 编辑 ]
Open Toolbar