自动化框架总结-2（转）

前言：

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

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

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

常见的自动化框架开发语言有：　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就可以了。调试使用基本的脚本语言调试出错功能就可以了。

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

 

从这个角度来说，一个自动化测试框架的设计的成功，应该是重执行和测试结果的收获的生产效率，而不是偏重开发环境的好坏和脚本开发的生产效率。

是分布式测试框架还是统一的测试框架好？

这是自动化测试框架设计中面临了又一个测试抉择。

分布式的测试框架，有点像早期的软件开发，微软的方式，就是每个人一套软件。每个人一个测试框架。这个测试框架是由测试人员独享的。他在这个测试框架上执行测试用例，收获测试结果。

统一的测试框架，有点类似于当今Web2.0 的概念，是以提供服务，而不是软件为主的。整个公司的测试人员都同意到一个服务器上去提交测试任务，这个统一的测试框架会有自己的任务调度功能，优先级处理功能等来统一执行提交的测试任务，并把测试结果返回给提交相应测试任务的测试人员。 通常，是有一个Web界面的人机接口。

那么，是一人一套框架好呢？还是大家共用一个框架好呢？在设计原则上，并没有优劣之分。虽然有人说，Web2.0的方式是大势所趋，云计算已经成为了趋势。一个统一的基于客户端服务器架构的自动化测试框架会便于管理，便于跟踪，但是，统一的框架需要复杂的进度调度和测试环境的协调(共用使用物理测试环境所造成的冲突)。 相对来说，一个人一套自动化测试框架的设计方法直接，实现简单，部署容易，管理花费少。可以让大家很快的用起来，能够早的看到测试结果。而对自动化测试框架来说，越快看到结果（测试结果）越能得到管理层的支持和投资。

所以，在项目初期的时候，建议可以使用一个测试工程师一套框架的方法，在大家等候使用起来以后，在把这套框架移植到统一的服务器上去。做一个渐进式的，逐步演化的测试框架，而不是在项目一开始就设计一个一个高，大，全的自动化测试框架，让大家等的望眼欲穿。

自动化测试框架中ＡＰＩ设计原则有哪些？

API的封装的好坏涉及到脚本的开发效率和可维护性。有经验显示，相对于设计水平一般的API，一套好的自动化测试API可以提高自动化脚本的开发效率2-3倍，一般来讲，需要进行三层封装：

 

总的来说，自动化框架中设计的好的API有两个原则要把握：

隐藏测试设备的复杂性，针对测试逻辑提供统一的接口。 熟悉软件测试的工程师都知道，测试当中，是需要使用很多辅助测试设备的，这些设备，有可能是PC上的运行的测试软件，有可能是专用的测试设备。而很多时候，不同的测试设备往往都是做同样的测试活动。如简单的Web页面自动化就可以使用QTP，Winrunner，Selenium等。封装的好的API，应该能够隐藏底层使用的测试工具。而对测试人员提供统一的编程接口。测试人员只需要下达操作动作，而具体这个动作使用了那些测试工具来实现，是API内部的事情，不需要测试人员分心。

关键字驱动：关键字驱动的意思是API的封装的程度要和测试用例描述的程度相同。如测试用例中描述：“注册（接口）是一个新用户(变量)，并验证生效（返回值）”，那么相应的ＡＰＩ的设计的关键字就需要有“Register $user_name”这个关键字，并能够根据返回值来验证动作是否成功。测试人员不需要去担心在那个页面，如何输入等具体的细节。