【转】自动化测试框架的原则

转自：http://wenku.baidu.com/view/829ba76aa98271fe910ef991.html

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

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

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

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

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

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

要不要ＩＤＥ开发环境？

一个自动化测试框架的目的到底是什么？很多人一下子回答不上来。而在多年的实践中，我们了解到，一个自动化测试的最重要的目的，或者说它存在的理由是：缩短产品的测试周期

从这个角度来说，一个自动化测试框架的设计的成功，应该是重执行和测试结果的收获的生产效率，而不是偏重开发环境的好坏和脚本开发的生产效率。如果不能得到最终的测试报告，ＩＤＥ环境设计的再好，也看不到绩效

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

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

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

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

而对自动化测试框架来说，越快看到结果（测试结果）越能得到管理层的支持和投资。   

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

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

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

Script. => API  => Control Library

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

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

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