厚积薄发,和喜欢测试的人一起进步!

发布新日志

  • web application stress tool 使用方法

    2010-03-29 17:02:53

    一、准备工作

        为了测试数据的准备性,首先需要删除缓存和Cookies等临时文件。启动IE后打开“工具”菜单下的“Internet”选项命令,在打开的“Internet选项”窗口的“常规”选项卡中,单击“Internet临时文件”区域的“删除Cookies”和“删除文件”按钮将临时文件删除。

        二、录制测试脚本

        安装并启动WAS,程序运行时会打开“Cteate new script”对话框,即建立一个新的脚本窗口(如图1),如果运行WAS没有打开该窗口可以单击WAS主程序窗口工具栏上第一个按钮“New Script”即可。

     

    web application stress tool 1.1 使用方法
    图1

     

        因为是初次使用,所以在新建脚本窗口上单击“Record”按钮打开创建向导对话框“Browser Recorder-Step 1 of 2”,其中三个选项的作用是选择要记录的内容,分别为Request(请求)、Cookies(网上信息块)以及Host headers(主机标题),可根据需要选择(图2),然后单击“Next”即会打开“Browser Recorder-Step 2 of 2”窗口,单击“Finish”按钮。这样WAS会自动启用,并且会打开一个浏览器窗口,此时我们就可以在浏览器的地址栏中输入要测试的网站网址。随着要测试的网站内容的不断显示,在WAS主界面的“Recording”选项卡中的信息会实时更新(如图3)。

     

    web application stress tool 1.1 使用方法
    图2

     

     

    web application stress tool 1.1 使用方法
    图3

     

        当浏览器的状态栏显示为“完成”时,我们就可以返回WAS窗口,单击“Stop Recording”按钮返回脚本窗口。

        三、测试设置

        为了使测试更加准确,更加接按真实效果,需要对录制的测试脚本进行一些设置。

        去除静态干扰

        由于网页是由图片、文字以及其它动态源码组成的,而一般的静态内容消耗的带宽并不是很大,因此我们可以将其排除在外。在脚本中选中指向图像、文字以及其它静态文件项目前的灰色按钮,然后单击工具栏上的“Delete”按钮将其删除(图4)。

     

    web application stress tool 1.1 使用方法
    图4

     

        设置并发数

        然后在单击“New Recorded Script”下的“Settings”标签,其中“Concurrent Connections”是设置并发连接数的,其下面的“Stress level (threads)”和 “Stress multiplier(sockets perthread)” 分别设置对目标服务器的压力及负载程度的,其中Level是客户端所产生的线程数目,一个线程可以产生多个Socket并发请求,因此将两者的数值相乘,所获得的数字就是客户端同时连接的并发数(图5)。

     

    web application stress tool 1.1 使用方法
    图5

     

        时间设置

        时间设置包括“Test Run Time”(测试运行时间)和“Request Delay”(停止响应)以及“Suspend”(挂起时间)三项。其中测试运行时间是以日、小时、分钟和秒来设定的,建议该项时间不宜太短,如果设置的并发数较多,那么时间应该按比较增长,以便产生足够多的请求;而停止时间是指连接时超出这个时间即作超时处理;在挂起时间处部分为Warmup和Cooldown两项,一般可以设置为两三分钟为宜,这样做的目的是避免测试开始和结束时数据的变形,影响测试的准确性。

        指定带宽瓶颈

        “Bandwith”是指定带宽瓶颈的,即选择访问该网站大多数用户所使用的带宽。例如访问该网站的绝大部分用户是拨号,那么可以选择56K。

        四、开始测试

        做好基本的设置工作后,就可以在左侧选中新建的脚本“New Recorded Script”项,然后单击工具栏上的“Run Script”按钮,或者打开“Scripts”菜单下的“Run”命令,这样就开始测试了。测试过程中会以进度条的方式实时显示,待进度条结束我们即可进行测试结果分析了。

        五、数据分析

        现在我们就可以打开测试报告来查看测试结果了。单击“View”菜单,选择“Reports”,在打开的窗口左侧会按时间显示所有测试报告。根据时间选择本次测试报告,在窗口右侧即可查看具体内容。

        在测试报告中最重要的部分就是“Socket Errors”部分和“Result Codes”部分。其中Socket Errors部分共分为Connect、Send 、Recv和Timeouts。其中Connect表示客户端不能与服务器取得连接的次数;Send表示客户端不能正确发送数据到服务器的次数;Recv表示客户端不能正确从服务器接次的次数;Timeouts表示超时的线程数目。由此我们可以如果这四个数值都比较小,甚至为0则说明我们的服务器是经得起考验的;如果数值居高不下,甚至接近设置的并发数,那么则要好好的检查你的服务器了(图6)。

     

    web application stress tool 1.1 使用方法
    图6

     

        另外在“Result Codes”部分,如果Code列表下的数值都为200,那么表示所有请求都经服务器成功返回,如果数值出现400或大于400,例如404,那么则需要在左侧找到“Page Data”节点,查看具体的错误项目,然后作出改正了。

        其实要完整的反映出一个网站在服务器上的运行情况,需要不断增减其并发数,并且进行多次测试,才能了解服务器所能承受的限度,然后才可以在IIS中设置允许连接的最大数目,从而保证网站正常运行。

  • 软件测试应该遵循的十条基本原则

    2008-06-18 12:11:32

    从用户的角度出发,就是希望通过软件测试能充分暴露软件中存在的问题和缺陷;从开发者的角度出发,就是希望测试能表明软件产品不存在错误,已经正确地实现了用户的需求。软件测试的原则尚没有标准的说法,大多只是经验之谈,以下可以作为测试的基本原则。

      (1)所有的测试都应追溯到用户需求。

      软件测试的目标在于揭示错误。从用户角度来看,最严重的错误是那些导致程序无法满足需求的错误。

      (2)应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭。

      应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始,详细的测试用例定义可以在设计模型被确定后立即开始。因此,所有测试应该在任何代码被产生前就进行计划和设计。

      (3)pareto原则:测试发现的错误中80%很可能起源于20%的模块中。

      当某个功能出问题,其对用户的影响有多大?然后根据风险大小确定测试的优先级。优先级高的测试,优先得到执行,一般来讲,针对用户最常用的20%功能(优先级高)的测试会得到完全执行,而低优先级的测试(另外用户不经常用的80%功能)就不是必要的,如果时间或经费不够,就暂时不做或少做。

      (4)完全测试是不可能的,测试需要终止。

      测试无法显示软件潜在的缺陷,“测试只能证明软件存在错误而不能证明软件没有错误”。最初的测试通常把焦点放在单个程序模块上,进一步测试的焦点则转向在集成的模块簇中寻找错误,最后在整个系统中寻找错误。在测试中不可能运行路径的每一种组合。然而,充分覆盖程序逻辑,并确保程序设计中使用的所有条件是有可能的。

      (5)应由独立的第三方来构造测试。

      第三方测试最大的特点在于它的专业性、独立性、客观性和公正性。对于软件开发商来说,经过第三方测试机构的测试,不仅可以通过专业化的测试手段发现软件错误,帮助开发商提升软件的品质,而且可以对软件有一个客观、科学的评价,有助于开发商认清自己产品的定位。对于行业主管部门以及软件使用者来说,由于第三方测试机构独立公正的地位,可以对被测试的软件有一个客观公正的评价,帮助用户选择合适、优秀的软件产品。

      (6)充分注意测试中的群集现象。

      测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。不要在某个程序段中找到几个错误就误认为该程序段就没有错误而不再测试,相反应该对错误群集的程序段进行重点测试。

      (7)尽量避免测试的随意性。

      测试计划应包括:所测软件的功能,输入和输出,测试内容,各项测试的进度安排,资源要求,测试资料,测试工具,测试用例的选择,测试的控制方法和过程,系统的配置方式,跟踪规则,调试规则,以及回归测试的规定等以及评价标准。

      (8)兼顾合理的输入和不合理的输入数据。

      (9)程序修改后要回归测试

      修改程序后,应该重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。

      (10)应长期保留测试用例,直至系统废弃。

      妥善保存软件测试计划,测试用例,出错统计和最终分析报告,为维护等提供方便。

  • 解决WEB性能测试中的验证码问题

    2008-05-19 23:28:21

    现在越来越多的网站为了安全性或是防止Spam的侵害,采用了验证码的校验技术。简单地说,验证码就是在进行登录或是内容提交的时候,页面上会随机出现一个人工可识别,但机器不可识别的验证字符串(一般是采用背景、扭曲等方式产生的图片),要求登录或是提交内容时同时输入这个验证码。
        验证码可以有效防止对口令的刺探和所谓的网络推广软件带来的大量的Spam内容,目前已经被许多Internet或是Intranet应用接受为标准的实现方式。但对性能测试来说,这种验证码又带来了很大的问题。
        最突出的问题是,性能测试工具本身是自动化工具,由于这种验证码采用的是“防止自动化工具尝试”的方法,因此,在录制了脚本之后会发现,很难对脚本进行调整,以使其适应验证码验证的需要。已经不止一次有人提到这个问题,并询问有没有较好的解决方案。对这个问题,我个人的看法是,基本上可以考虑从三个途径来解决该问题:
    1、第一种方法,也是最容易想到的,在被测系统中暂时屏蔽验证功能,也就是说,临时修改应用,无论用户输入的是什么验证码,都认为是正确的。这种方法最容易实现,对测试结果也不会有太大的影响(当然,这种方式去掉了“验证验证码”这个环节,不过这个环节本来就很难成为系统性能瓶颈)。但这种方法有一个致命的问题:如果被测系统是一个实际已上线的系统,屏蔽验证功能会对已经在运行的业务造成非常大的安全性的风险,因此,对于已上线的系统来说,用这种方式就不合适了;
    2、第二种方法,在第一种方法的基础上稍微进行一些改进。第一种方法带来了很大的安全性问题,那么我们可以考虑,不取消验证,但在其中留一个后门,我们设定一个所谓的“万能验证码”,只要用户输入这个“万能验证码”,我们就验证通过,否则,还是按照原先的验证方式进行验证。这种方式仍然存在安全性的问题,但由于我们可以通过管理手段将“万能验证码”控制在一个小的范围内,而且只在性能测试期间保留这个小小的后门,相对第一种方法来说,在安全性方面已经有较大的改进了;
    3、如果安全性对应用来说真的是至关重要的,不容许有一丝一毫的闪失,那我们还可以用更进一步的方法来处理这个问题。一般的性能测试工具(MI的LR、Seague的Silk performer等)都能够调用外部的DLL或是组件接口,因此,可以考虑获得“验证码验证”部分的实现,写一个验证码获取的DLL,在测试脚本中进行调用即可。
        除了这三种方法以外,可能还会有其他的方法存在,也希望各位能提供一些其他的思路。在我的实践中,第二种方法用得比较多,对未上线系统系统的内部性能测试,有时候也用第一种方法。但要提醒的是,如果针对的是已上线系统,无论用哪种方法,测试完成后,都必须立刻将应用恢复,并对系统进行一次安全审计,以免在测试期间被他人入侵。第三种方法用得比较少,而且具体上还依赖于验证组件是否能提供这样的接口。
Open Toolbar