最近因要写一些关于自动化测试及自动化框架方面的东西,所以需要学习和补充很多自动化工具和框架方面的知识,以期能获取第一手资料来完成自己的写作所需。因为之前常见的和使用的自动化工具只有QTP、selenuim,其它的测试工具都是听说名字,没有相对进一步去查看和学习其相关特性、原理及适用性。【因为之前是想着先学好一样工具后再学习其它工具就会更容易,且一次学习多个工具很容易混淆学习,降低效率】如今到了需要从更上的一个层次去理解自动化,并要考虑如何更好的去实施一个自动化的时候,如果还是只了解某一两个工具,可能知识的局限性就凸现出来了,所以需要从另一个方面去学习自动化方面的知识了。

话说自动化测试方面的工具还是非常的多的,不可能也没有必要查看了所有的测试工具;个人觉得当学习众多同类知识或相关主题时,分几步走:

1、学习所有同类知识的共同理论、原理部分【此为共性】

2、学习所有同类知识的独有特性、技巧部分【此为个性】

3、根据具体的实际场景,适当的运用所学知识的【即运用知识的个性部分去解决特定的问题】

学习自动化测试工具也是这样的,之前不愿意学习太多是怕混淆视听,现在对原有知识已有了一定的固化认识【即了解了基本原理】,也就可以从新学习个性化的东西了;而这一步正是为了以后能够适当运用所掌握的知识,顺利的进行自动化测试任务的开展和实施。其目标达矣!


这里只列出自己觉得有特性的自动化工具,对于原理完全相同的同类产品,只列出其中最出色者。此外,更多的工具列表见​​这里​​ 


商业工具:

1、QTP:

这个大家都知道的,支持录制,支持插件,支持部分插件扩展,目前只用过web插件、默认的windows功能。入门自然是很容易的事情,随便录制就可以有脚本出来,可以执行了,但是真正实施起来就不是那么回事;个人觉得qtp大量部署自动化测试不是其优势,其批量执行没有很好的管理框架,即使集成到qc也不是很爽,毕竟是一个工具调用另一个工具,效率和性能首先就是问题,貌似很不专业;其次其对象库文件,每次执行后都会有更新;测试结果都是分开的,没有一个统一的综合的结果评定;总的来说,QTP更像是一个脚本开发和调试工具,而在测试执行,脚本管理,规划这方面还是不足的。通常都是自己写执行框架,这里不得不说qtp提供的接口类型还是比较多的,如:工具本身提供dom接口,还支持dll调用,支持.net库函数调用,支持windows api调用,支持第三方的dom控件调用。

2、WinRunner:

号称企业级自动化工具,脚本语言较难用,也很贵,没有了解过,因为其貌似不在支持版本更新了

3、Rational Robot

同样号称企业级自动化测试工具,IBM相关的公司会使用,也很贵,也没有了解过,因为安装文件大,还要破解

4、SilkTest:

这个也是比较相对著名的工具,不过同样还是没有了解过,对于商业的工具,因为其占地面积大,还要破解等麻烦事,最关键的是使用的公司少,所以只使用过QTP,其它的一概未了解过


开源工具:

1、UIAutomation:

这个是微软提供的UI自动化框架,当然它的初衷并不仅仅是为自动化测试而产生的,它的任务是给更多的开发或者应用去调用windows的UI控件,不过还是可以用于自动化测试的;因为之前微软就有类似的工具,而这个是重新设计的ui操作类框架,其目的是为了兼容支持windows系列操作系统的UI自动化操作【xp,vista,server2003】,还有就是天然支持WPF。当然其设计与通常的自动化工具就不一样了,比如:没有把控件支持的方法绑定在控件对象本身,没有提供专门的鼠标/键盘事件,但是却提供了特定控件对象的事件响应监听及处理方法的定制。其工作流程大概是这样的:

a、先获取特定的元素对象,有多种方法。如:句柄,属性值

b、获取这个元素对象的模式。模式是这个框架的设计的独具之处,成就了它的灵活性,统一性

c、通过这个模式在进行具体的方法调用,属性值获取等

d、监听指定对象的特定事件,一旦发生则执行指定的事件处理函数

前提:安装.net 3.0

文档:http://msdn.microsoft.com/zh-cn/library/ms747327.aspx


2、EFT【easy function testing】:

这个是在.net3.0 的UIAutomatuon的基础上封装的一个dll文件,同样还封装了部分windows api以实现鼠标和键盘事件。所以这个只能叫测试类库,且仅支持windows程序,而且同样支持uiautomain所支持的WPF程序的测试。

前提:安装了.net3.0

使用:引入该文件,uiautomation 相关dll,VS环境下编写测试用例

下载地址:​​http://www.softpedia.com/get/Programming/Other-Programming-Files/Eft.shtml​

google code:​​http://​​​​code.google.com/p/eft/​


3、Selenium:

这个应该大多数人都知道的,现在也是大多数互联网公司在使用的测试框架;selenium仅支持web的UI级别测试,但是其优点在于:

a、支持多种语言编写测试脚本,比如:java、python、ruby、perl等;同时也就意味着其后的支持类库也是很多的

b、支持多浏览器,如:ie,ff,safari、chrome等

c、支持多平台,如:windows、linux、MAC、android、iphone等

d、支持分布式执行,一套测试用例可以同时分布到不同的测试机上执行,而且还可以进行任务细化,比如:针对liunx执行系统只分配linux下需要执行的用例

此外还有录制工具支持,简单也说,web类测试基本上是首选,不过对flash的支持好像不是太好

其主要分2个版本,1.X版本是以js驱动来进行自动化实现的;2.X重新开发了webdriver来代替js驱动,直接调用浏览器底层接口来完成自动化实现的

前提:如果使用remote或者RC功能,需安装jre

下载地址:http://seleniumhq.org/download/


4、watir【web automation testing in ruby】

5、STAF【software testing automation frame】


WebDriver

waitN

Canoo WebTest

TestCompele

AdvenNet QEngine

QARun

TestPartner





总结:

原理总结

所有的测试工具均可分为基于windows,基于web的,也有个别特殊的。但原理大概就分为这几类情况,在理解了这些原理后,如果有需要,有时间,有精力时可以参考现有工具的优缺点来开发适应性、针对性更强的测试工具;而最捷径的方法就是把这些现有工具适当的集成到一起,时间和难度上都有大大降低。

分类总结:

按提供功能的方式其中部分叫工具,另外的部分叫框架;按用途分有的提供自动化功能,有的支持自动化用例的执行,有提供测试环境的部署;按针对被测试对象分有web、windows;按产品的开发语言分有针对不同语言的,如.net,java等

应用总结

最后才是干货,掌握和了解这么工具为嘛使,不能总是为了好玩,而是为了能在以后的自动化实施过程中用于支持策略的制定;比如新接收了一个测试项目需要进行自动化实施,那么需要考虑哪些点?使用哪个工具,有哪些工具可以作为备选?那么自然就要对常用自动化工具有一个初步的了解,同时对影响自动化过程的其它元素也要有一定的掌握,不过这里可以跳过,这里只是说与工具相关的因素的抉择。大体可以分为如下来考虑:

1、考虑被测试产品的类型,B/S,,C/S,web service,SOAP,SDK或者API;过滤支持某类功能测试的工具

2、考虑是否支持录制,可以录制就相对于说开发效率有较大的提高

3、考虑工具的价格,通常首选开源或免费产品

4、考虑工具扩展性,可能某类工具可以支持现在的业务需求,但日后需求有变化的话,是否有很好的扩展性,支持被测产品的新特性,如flex,flash,wpf等

5、考虑工具的支持性,即后期的升级及版本更新的特性,不要选用即将不再支持的工具

6、考虑工具的广泛性,即这个工具在外部的流行程度,这样以后招人容易,有问题也有较活跃的社区可以求助

7、考虑工具的成熟性,即这个工具不能还在beta版本,需要有一个较稳定的版本,而且估计较长时间内不会有大版本的更迭

8、考虑工具的可开发性,即工具是否提供插件接口,用于可以自定义自己的基础类库和识别机制

9、考虑工具的易用性,即是否有强大的后台支持,如windows、.net、java类库支持

10、考虑工具的适应性,即是否容易被封装,可以很容易被嵌入或引入到其它的框架中,比如:功能框架被引入到执行框架中

11、考虑工具的针对性,即如果有专门的针对性工具可选,自然比那些综合性很强的工具其适用性要高的多了


最后,自动化是任重而道远的,真正难解决的还是那些实际的应用和实施,不同的项目有不同的测试需求、场景需求、环境需求,需要进行综合考虑;最终的结果是要提交一个可交付的,易维护的,高效率的,较稳定的测试构建,就不是仅仅了解测试工具就能办到的,所以还有很长的路需要去实践。