《Web测试工具对比--自动化软件测试.doc》由会员分享，可在线阅读，更多相关《Web测试工具对比--自动化软件测试.doc（15页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、针对xxx(java开发）软件进行测试，对winrunner7.0,Rational Robot,Quick Test 进行评测，评测主要包括易用性，扩展性，稳定性等三方面. xxx登陆功能是使用最频繁的功能，为了把这部分功能让测试人员从手工测试中解脱出来，现在进行自动化测试实现。 首先，进行录制回放登陆操作目的是检验三种测试工具的易用性（功能前大与否）程度：操作的步骤 ： 启动ie,输入地址，输入用户名密码，登陆。WinRunner 7.01. 启动WinRunner 7.02. 录制上边的操作步骤脚本如下点任务栏，启动ie# Shell_TrayWndset_window (Shell_T
2、rayWnd, 3);toolbar_button_press (ToolbarWindow32_0, T/ R Internet Explorer mO Vh ); # Button Number 0;地址栏输入地址# Browser Main Window_1set_window (Browser Main Window_1, 14);edit_set (browser_main_edit_location, http:/192.168.1.42);输入账号密码win_type (html_frame_2,adminjetspeed);win_mouse_click (html_frame
3、_2, 566, 33);win_check_gui(html_frame_2, list1.ckl, gui1, 1); 录制完成后的脚本如上，测试回放发现粉色字体受环境影响很大，所以需要对脚本进行优化，改动后的脚本如下启动ie，并且到http:/192.168.1.42的地址 web_browser_invoke(IE,http:/192.168.1.42); win_mouse_click (html_frame_2, 402, 36); win_type (html_frame_2,adminjetspeed); win_mouse_click (html_frame_2, 566,
4、33); win_check_gui(html_frame_2, list1.ckl, gui1, 1);替换脚本为一个函数 web_browser_invoke(IE,http:/192.168.1.42)3.回放 测试通过替换原因 一.上边粉色部分脚本随机性较大，如果脚本移植到其他测试机器上，由于测试环境的改变（假如任务栏没有快捷方式图标，粉色脚本将无法回放下去），导致无法执行。替换为ie启动函数，不管ie安装在任何地方可以直接启动。 二进行脚本优化，避免错误，没有修改前的脚本太冗长，修改后脚本减少，功能稳定。 Rational Robot：1. 启动robot2. 录制操作脚本如下：Su
5、b Main Dim Result As Integer Dim Temp as Integer /启动ie,连接到http:/192.168.1.42 StartBrowser http:/192.168.1.42, WindowTag=WEBBrowser /让ie窗口获得焦点 Window SetContext, WindowTag=WEBBrowser, /打开新的页面Browser NewPage,HTMLTitle=Dynaweb EPS 2003企业门户服务器,/点用户名文本框 EditBox Click, Name=username, Coords=35,12 /输入用户名密码
6、 InputKeys adminTABjetspeed / 点登陆 PushButton Click, Name=submit /进入新页面Browser NewPage,HTMLTitle=Dynaweb EPS 2003企业门户服务器,/ 点退出连接 HTMLImage Click, Index=7, Coords=11,7 /关闭ieWindow CloseWin, , End Sub3.回放 测试通过Quick Test 6.51. 启动quick test2. 录制操作 脚本如下/打开browser对象 object (page是个对象)方法的object（webedit也是个方法）
7、的set方法，意思就是设置文本框username,内容为adminBrowser(Dynaweb EPS).Page(Dynaweb EPS_2).WebEdit(username).Set admin/同上，这回调用的是setsecure方法，作用是将password文本框中的文本进行加密Browser(Dynaweb EPS).Page(Dynaweb EPS_2).WebEdit(password).SetSecure 3fe6931be2aac0bbbc/调用对象webbutton对象的click方法Browser(Dynaweb EPS).Page(Dynaweb EPS_2).We
8、bButton(v _U ).Click/调用Image对象的click方法，目的退出Browser(Dynaweb EPS).Page(Dynaweb EPS_3).Image(T_ S y R 梑 g h_ ).ClickBrowser(Dynaweb EPS).Page(Dynaweb EPS_3).Link(2333).ClickBrowser(Dynaweb EPS).Page(Dynaweb EPS_4).Image(logout).Click/等待页面操作完毕Browser(Dynaweb EPS).Page(Dynaweb EPS_5).Sync易用性总结：1. 操作简单但各个
9、脚本都需要进行二次开发2. 脚本语言的异同：Winrunner 脚本支持c语言Robot脚本支持vb脚本（可以扩展脚本语言支持 其他如 perl，java等语言）使测试人员选择度很大Quick test脚本支持vbScript脚本一 学习脚本：robot和quick test为vb语言，容易掌握，winrunner脚本为c语言，掌握有难度，短期内提高对测试人员要求比较高。二 调试脚本：robot脚本支持step，animate等调式方式，winrunner和quick test支持step等几种调试方式，相互比较来看robot调试功能强大，比较直观。三 测试环境兼容性：改变测试环境配置,将ie
10、打开后变化窗口大小，关闭，重新运行测试脚本。Winrunner脚本回放失败，其他两种工具测试回放成功，对比发现由于winrunner脚本依靠坐标来确认对象位置，而robot和quick test是以对象来确认。稳定性上后两种测试工具更加占优。如：winrunner脚本中函数win_mouse_click (html_frame_2, 566, 33)以坐标来记录点击位置，当对象位置改变，脚本将无法执行。针对winrunner有两种解决对象识别的方法：1.坐标固定：启动ie后，使ie窗口最大化，窗口坐标得到固定，修改脚本后如下 web_browser_invoke(IE,http:/192.16
11、8.1.42);/让窗口最大化，坐标固定了，这里不考虑机器分辨率的问题win_max(Browser main Window); win_mouse_click (html_frame_2, 402, 36);win_type (html_frame_2,adminjetspeed);win_mouse_click (html_frame_2, 566, 33);win_check_gui(html_frame_2, list1.ckl, gui1, 1);录制的脚本基本回放通过（这里没有考虑分辨率的情况，否则脚本开发难度增大。）这种方法不是根本解决方法。2.让winrunner认识对象 解决
12、方法是开发dll让winrunner引用，windows提供了mshtml对象，借用他可以实现winrunner认识对象。这里我用word的开发环境简单实现这个功能动态添加用户名密码（可以改写编译成dll给winrunner引用）。主要代码（vb版本）：思路：ie加载网页后，枚举所有元素对象，找到要找的元素，然后赋值。这里是找username和password文本框，把用户名密码添加进去。 Dim hdoc As HTMLDocument Dim eleColl As IHTMLElementCollection Dim sElement As IHTMLElement Dim i As In
13、teger Set hdoc = WebBrowser1.Document Set eleColl = hdoc.all For Each sElement In eleColl If sElement.isTextEdit Then If sElement.outerHTML = Then sElement.setAttribute value, admin End If If sElement.outerHTML = Then sElement.setAttribute value, jetspeed End If End If Next同理可以实现winrunner识别网页任何对象。（自
14、己开发测试工具）Web应用程序的整体测试随着Internet的日益普及，现在基于B/S结构的大型应用越来越多，可如何对这些应用进行测试成为日益迫切的问题。有许多测试人员来信问我B/S的测试如何做，由于工作较繁忙，对大家提出的问题也是头痛医头脚痛医脚，没有对WEB的测试过程做一个整体的概述。 希望通过本篇能够让大家了解大型Web应用是如何来进行测试的。 B/S下的功能测试比较简单，关键是如何做好性能测试。 目前大多数的测试人员认为只要跑一些测试工具证明我的产品是可以达到性能的就ok了，为了证明而去测试是没有任何价值的，关键是要发现产品性能上的缺陷，定位问题，解决问题，这才是测试要做的。 首先我们
15、从两个方面分析如何进行WEB测试，从技术实现上来讲一般的B/S结构，无论是.NET还是J2EE,都是多层构架，有界面层，业务逻辑层，数据层。而从测试的流程上来说，首先是发现问题，分析问题，定位问题，再由开发人员解决问题。那么B/S的结构的测试如何来做？ 如何发现问题是我首先要介绍的，在做WEB测试之前你需要一些资料，比如产品功能说明书，性能需求说明书，不一定很完善，但一定要有，明确测试目标，这是基本的常识，可是我往往看到的是已经开始动手测了，但还不知自己的系统要达到的性能指标是什么。这里我简单讲一下测试的性能指标：l 通用指标（指Web应用服务器、数据库服务器必需测试项）:* Processo
16、rTime: 指服务器CPU占用率，一般 平均达到70%时，服务就接近饱和；* Memory Available Mbyte : 可用内存数，如果测试时发现内存有变化情况也要注意，如果是内存泄露则比较严重；* Physicsdisk Time: 物理磁盘读写时间情况； Web服务器指标：l* Avg Rps: 平均每秒钟响应次数 总请求时间 / 秒数；* Avg time to last byte per terstion （mstes）:平均每秒业务角本的迭代次数 ,有人会把这两者混淆；* Successful Rounds：成功的请求；* FailedRounds ：失败的请求；* Suc
17、cessfulHits ：成功的点击次数；* FailedHits ：失败的点击次数；* Hits Per Second ：每秒点击次数；* SuccessfulHits Per Second ：每秒成功的点击次数；* FailedHits Per Second ：每秒失败的点击次数；* AttemptedConnections ：尝试链接数； 数据库服务器指标：l* User 0Connections ：用户连接数，也就是数据库的连接数量；* Number of deadlocks：数据库死锁；* Butter Cache hit ：数据库Cache的命中情况；上面的指标只是一些通用的指标,
18、起到抛砖引玉的作用，对于不同的应用你还必需作相应的调整，比如程序使用的是.NET技术的，则必需加入一些针对性的测试指标。对于这些指标的详细了解，你可以参考Windows 下面的 SystemMonitor的帮助与LoadRunner、ACT的帮助。对于发现问题，指标的设置非常重要，它会帮你定性的发现一些错误。对于定性的压力测试我就不做过多的分析，工具很多，流行的主要有LoadRunner,ACT,WAS,WebLoad,各个工具有它的使用范围，其中我各个认为LoadRunner 最全面，它提供了多种协议的支持，对复杂的压力测试都可以胜任，WAS与ACT则对微软的技术支持的比较好，其中WAS支持
19、分布式机群测试,ACT则是与.NET集成比较好，支持ViewState （.NET 下控件缓存的支持） 的测试，当时我用时，其它测试工具还不支持，现在应该支持了吧，呵呵。在这一阶段测试你要不断的跟据系数的测试目标进行变化，一开始由于系统过于庞大，所以我们要分成若干个子系统，各个子系统的性能目标必需明确，主要是并发指标定一个阀值，同时设定一些与系统相关的测试参数，应用服务器，数据库服务器都要有，对达不到阀值的与一些通用参数有问题的子系统进行深入分析。比如它的并发达不到你的要求，证明子系统性能有问题，或是数据库用户连接过高，程序没有释放用户连接等等。这个我们要对子系统进行详细测试，由于B/S 结构
20、下,图片的请求对性能的影响较大，所以我们对子系统测试时要分两个部分进行，一、非程序部分，即图片等等;二、应用程序本身。通过事务或函数的分离，可以把这两块实现单独的测试，具体做法参考各个工具的手册，我这里就不做说明。对子系统的测试参数的设置要求则更高，它有助你后面精确的定位问题，比如对异常，死锁，网络流量等等前面没有注意到的情况的增加，同时你要注意增加测试参数的收集对系统的性能影响比较大，所以一般不要超过10个，刚刚介绍的整体的性能测试指标也不要增加很多，这样影响会小一点。最后在这一阶段要说明的是数据库的数据量会很大程度的影响性能，所以要根据前面的性能需求说明书向数据库中模拟相应的数据量，来进行
21、测试，这样才有更高的可信度。 上面所说的是对问题的发现，下面就是分析问题原因，这一步的要求比较高，一般由测试人员与程序员配合完成，当然如果你有相当的开发经验，再做这方面的测试，就更为难得。下面我们说说如何精确定位问题，出现问题的可能性可能有很多种，大致分以下几种，一、性能达不到目标；二、性能达到目标，但有一些其它的问题，比如异常，死锁，缓存命中过低，网络流量较大；三、服务器稳定性的问题，比如内存泄漏。要发现这些问题起马的要求要有一款使用的比较称心的性能分析与优化工具，比如微软的.NET下就有自己开发的工具，对Borland的Java开发工具中也有类似的工具，但我个人认为更好的工具是Rose下的
22、Purify与Quantify,主要是他对.net 与java ,C+都有支持，而且分析效果特别专业，我们先了解一下Rational Purify,Rational Purify 能自动找出Visual C/C+ 和Java 代码中与内存有关的错误，确保整个应用程序的质量和可靠性。在查找典型的Visual C/C+ 程序中的传统内存访问错误，以及Java，C# 代码中与垃圾内存收集相关的错误方面；Rational Quantity 则是一款针对函数级的性能分析利器，使用它你可以从图形化的界面中得到函数调用的时间，百分比与次数，以及子函数所占时间，使你可以更快的定位性能瓶颈。我们先说性能优化与异
23、常的处理，性能优化有一个原则，即用时间比例最大的进行优化，效果才最明显，比如有个函数它的执行时间为30秒，如果你优化了一百倍则执行时间为0.3秒,提升了29.7秒，而如果它的执行时间为0.3秒，优化后为0.003秒，实际提升了0.297秒，提升的效果并不明显，而且写过程序的人都知道，后者性能优化的代价更大。在性能优化的过程中，一般是先数据库，后程序，因为数据库的优化不需要修改程序，修改的风险很小。但如何才能确定是数据库的问题，这就需要技巧，在使用Quantity时，你一路分析下去，大多数最终会发现，是数据库查询函数占用时间比较大， 比如什么，SqlCmd.ExecuteNoQuery等等数据库
24、执行函数,这时你就需要分析数据库，呵呵。数据库的分析原则是先索引，后存储过程，最后表结构视图的优化，索引的优化是最简单也是通常最有效的方法，如果合理的使用会带来意想不到不到的效果。在这里我要给大家简单的介绍一下我的最爱，SQLProfile,SQL查询分析器，Precise,SQLProfile是一个SQL语句跟踪器，可以跟踪程序流程使用的SQL语句与存储过程，结合查询分析器对SQL的分析，可以对索引的优化做出很好的判断，但索引也不是万能的，在增删改较多的表，索引过多会引起这些操作的性能下降，所以判断还是需要一定的经验。 同时针对用户使用频度最高的SQL进行优化也是最行之有效的，这时我则需要P
25、recise，它可以观测某一个较长时间内的SQL语句的执行情况。数据库优化的潜能挖光后，如果还是达不到性能要求或是还有问题，则要从程序来进行优化，这是程序员做的事，测试人员要做的，就是告诉他们，哪个函数执行过多引起了性能下降，比如异常过多，某个循环过多，或是DCOM调用过多等等，但说服程序员也是一件不容易的事，你要在这一阶段做的出色一定要有几年的编程经验，并且要让程序员感到听你的性能会有提升，这是一件很不容易的事情哦。内存的分析，一般是一个长期分析的过程，要做好不容易，首先要有长期奋战的准备，其次内存泄漏的分析最好是放在单元测试之中同步进行，而不是要等到最后再去发现问题，当然出了问题也只好面对
26、，一般这类问题都是在服务器运行了很久才暴露出来，一旦发现问题后，则需要定位问题，分析的原则采用子系统相互独立运行，找到最小问题的系统集,或是借助内存分析工具观察内存对象情况，初步定位问题，再用Purify进行运行时分析，通常C+ 内存问题比较多，Java与.NET比较少，一般由GC不合理引起。C+的内存错误就比较多了，主要常见的有:1、 Array Bounds Read (ABR) ：数组越界读2、 Array Bounds Write (ABW)：数组越界写3、 Beyond stack Read (BSR)：堆栈越界读4、 Free Memory Read(FMR)：空闲内存读5、 In
27、valid pointer Read(IPR)：非法指针阅读6、 Null Pointer Read(NPR)：空指针阅读7、 Uninitialized Memory Read(UMR)：未初始化内存读写8、 Memory Leak：内存泄漏注：如果需要更多的信息，可以参见Purify的帮助信息。顺便提一句，为什么我要说单元测试时做这个比较好，由于单元测试针对的是单一功能，这时结合单元测试案例做内存分析会更快的定位问题，同时由于问题较早的发现，则后期的风险则会减少，当然如果结合代码覆盖工具PureCoverage 来做就更完美了，呵呵。 完成此文，已经是凌晨了，也算是回答了前一段时间提出要进行B/S结构测试又无从下手的朋友的要求，在这里要向大家表达一下歉意，由于工作比较忙，难免对大家的来信有所疏漏，请大家原谅。此文的要求的读者，对测试工具有所了解，希望进入更深测试的同仁，希望我的文章给大家带来帮助,同时也借此文表达一些曾经帮助过我的朋友与同事。 注：本篇只是对B/S应用的测试过程作一个整体的描述，对某一个阶段使用的工具只是作大概的介绍,你也可使用你比较熟悉的工具达到相同的目标