自动化测试框架的设计原则

前言：

使用脚本语言来设计自动化测试开发框架，是很多大型ＩＴ企业在进行自动化测试中所采用的方法，一

个好的自动化测试框架，可以大幅度提高测试人员自动化脚本开发的效率，可以提高自动化脚本开发的并行性和可靠性。自动化测试框架设计的好与坏，直接关系到整个公司的测试水平，也关系到公司产品的发布周期和发布质量。那么在设计一个自动化测试框架的时候，会面临哪些问题？对这些问题，有什么解决方法，每一种解决方法的优劣又如何呢？

我们在脚本开发长期的经验中，看到了美国，中国；大型，小型等不同ＩＴ公司对于自动化测试框架设计上的面临的挑战和相应的不同解决方法，这里结合我们的观点，和大家一起探讨一下。

要选择什么样的开发语言？

常见的自动化框架开发语言有：C，C++，Java, TCL, Perl, Ruby, Python。

使用C或者C++，对于整个自动化测试框架的执行效率而言会有所提高。但是由于常见的测试流程对设

计到对大量字符串的处理能力，C或者C++ 在这些方面的支持并不完备。会导致整个开发流程的延长，更重

要的是，使用C或者C++，不能够实现跨平台。如果自动化框架只是在公司内部使用，不是商用产品的话，

不建议使用。

Java的自动化测试框架主要还是面向对使用Java开发的产品的测试，并且主要使用在单元测试阶段。对于用其他语言开发并编译的软件产品，在测试方面提供的支持力度一般。如果是对于嵌入式系统的测试，就

更欠缺。在Web界面的测试方面，Java提供一定的支持。

TCL是老牌的自动化测试语言。在80年代开始就在Motorola使用，后来被思科采纳，并在自动化测试

领域得到了广泛的应用。对于基于命令行来远程控制的设备如路由器，交换机等的自动化测试领域应用非常成熟。美中不足的是：TCL在设计之初是不支持面向对象的设计方法的，虽然后来出现了iTCL来弥补不足，但

是常见的基于TCL的测试脚本开发还不是基于面向对象的。对脚本的可维护性和可复用性带来了一些挑战。

Perl语言在设计之初也不支持面向对象，在网络管理员的圈子里应用的很广，被称作是the duct tape of the Internet。在自动化测试领域应用的范围不是很广泛。有一些IT厂家由于历史的原因在使用Perl进行自动

化测试，但是也在慢慢向其他脚本开发语言转型。

Python作为一个脚本开发语言，它的使用者社区的技术水平比较高。相对来说，它的支持库的代码水平

也比较高。对于软件开发的各个方面的第三方库（如图像处理，网络通信，Web技术等）都有非常好的支持。Python本质上就是面向对象的脚本语言。90年代以后成立的硅谷高科技公司，很多都使用Python作为他们

自动化测试的官方语言。在美国的群众基础非常好。社区也非常活跃。它的创始人还因此被Google招募旗下。

Ruby是日本人发明的完全面向对象的脚本语言。它的使用者社区起初主要在日本和台湾的一些IT公司。在2006年左右，当Web的综合开发框架Ruby on Rails出现后，在网站的开发社区中也开始流行开来。

Ruby语言也受到了大型IT公司的测试团队的关注。在自动化测试领域得到了越来越广泛的应用。有一些大型公司正在由其他的脚本语言向Ruby转换。

作为一个自动化测试框架，一个设计原则就是快速成形，快速推广，增量开发。框架的基本功能要马上可用，并能迅速找到使用者，得到成功推广的案例，形成自己的使用社区。并在此基础上，按照社区使用人的需求，进行增量开发，逐步扩大社区的用户基数，并丰富框架的功能。在这个要求上，对编程语言的选择有如下两点：

1、Fast Prototype （马上就可以用）

2、可扩展

第一点，对于解释执行的脚本语言来说，是非常适合的，解释执行的脚本语言可以再有限的代码量内开发出尽可能丰富的功能，而不用担心内存分配与释放等其他编译执行语言需要考虑的问题。而面向对象有可以满足第二点的要求。所以，如果选择自动化框架的脚本语言，推荐Python和Ruby。

业界常用的控制库的设计方法和工具有哪些？

既然是自动化测试，就涉及到对远程的被测试对象进行无人值守的自动化控制与测试。需要自动化复现测试人员的手动操作步骤和结果判断步骤。而对于远程被测对象的控制，可以分为

1、命令行（CLI）控制

2、图形用户界面（GUI）控制

CLI的控制主要是使用Expect的远程控制库。Expect库在TCL上最先开发，后来也被移植到了Perl，Ruby和Python上。

控制图像界面的工具分为控制Web浏览器的工具和控制窗口的工具。具体应用的时候又可以分为开源和商用工具两个方面：

常用Web浏览器自动化控制商用工具：

● Winrunner

● QTP

● Silktest

● IBM Rational Robot

常用的Web浏览器自动化控制开源工具：

● Selenium

● AutoIT

● IE Automate

● Ruby Waitr

推荐使用工具的原则是无论使用商用还是开源的自动化测试工具，都需要可以支持标准的脚本编程语言：TCL, Perl, Ruby, Python。这样，可以保证自动化测试体系不会锁定在某一个测试工具上。

一个测试框架最基本功能是什么？

既然是一个测试框架，很多设计人员喜欢把一大堆的东西都塞在里面，为测试框架增添很多的功能。实际上，一个测试框架应该在两个核心功能上做好文章，其他的都是次要的辅助功能：

1、强力的执行引擎：真正做到无人值守

2、良好的报表生成和管理功能

所谓强力的执行引擎，是指一个自动化测试框架在批量执行脚本的情况下，不论遇到什么情况，如脚本运行错误，脚本质量错误，测试环境异常，被测设备死机或者挂起等，都要有能力重新清理测试环境，使测试环境恢复到最初始的状态，并执行接下来需要执行的脚本。也就是说，一个好的测试引擎，能够做到24小时7

天的无人值守的运行，而不会中途因为任何的非物理异常而退出。

良好的报表生成功能是指一个测试框架要有分布式的对脚本的结果的收获和呈现的能力。很多情况下，脚本是并发执行的，就像一下子种了一大块田，而当脚本执行完毕，也就是庄稼成熟的时候，如何对脚本执行的结果进行快速收割，并捆绑好，整齐划一，让人对结果一目了然。更重要的是，要需要能够提供针对不同版本的相同自动化脚本执行日志的比较。并能够对这些报表进行搜索和排序，这些都需要一个很好的报表生成和

管理功能。

要不要ＩＤＥ开发环境？

很多人问，一个自动化测试框架，如果没有一个集成开发环境，开进行脚本的开发和调试，那还叫做自动化测试框架么？实际上，这里面有一个对自动化测试框架理解的误区。而这个误区，在没有真正做过完整的软件测试发布流程之前，是一个脚本开发人员不会了解的。

一个自动化测试框架的目的到底是什么？很多人一下子回答不上来。而在多年的实践中，我们了解到，一个自动化测试的最重要的目的，或者说它存在的理由是：缩短产品的测试周期。企业之所以愿意在自动化测试框架上投入人力和物力，主要原因还是因为自动化框架可以大规模的驱动自动化测试脚本的并行执行，并能够在短时间之内获取到测试结果。并根据测试结果生成完整的测试报告。而这个测试报告时一个软件版本能否发布的重要的质量依据。越早拿到整个测试报告，产品的发布周期就会缩短。Time to Market的时间就会缩短，企业就会早一点占领市场。

从这个角度看，一个集成的开发环境并不能够满足企业的这方面的需求。一个集成开发环境会加快脚本的开发速度和调试速度，但是并不能够加快脚本的执行速度。所以，在一些业界比较优秀的自动化测试框架里面，并没有提供集成开发环境和调试环境。如果想开发脚本，使用UltraEdit, Vim或者Emacs就可以了。调试使

用基本的脚本语言调试出错功能就可以了。

所以我们说，自动化测试框架的开发，也涉及到整个自动化测试活动的开展的绩效评估有冰山效应。如果不能得到最终的测试报告，ＩＤＥ环境设计的再好，也看不到绩效：