我们的自动化测试为什么这么难？(2)

　　页面测试工具的选择有什么规律

　　首先要赞扬Selenium和WebDriver这些开源WEB自动化测试工具的灵活性(注：WebDriver就是基于Selenium的一个自动化测试类库，但它不再是运行在浏览器内的JS程序，而是自己可以控制浏览器)，这些工具在与大多数测试平台的整合以及其所支持的脚本语言种类上都有很大优势(Java、dotNET、Perl、Python、Ruby、C#等)。由于它们是专一的WEB自动化测试工具，它们在处理WEB应用的问题上显得非常专业，结合一些Hook程序的使用，使得它们的运行速度明显快于QTP。而同QTP一样，他们在处理一些第三方插件的时候都需要借助另外的插件和程序，这一点也正好印证了开源工具的特征：为了解决我们需要的需求，可以采取一些额外的手段来协助。不过商业工具也不是就甘心这样让出他们的市场的，HP为QTP10.0及以上的版本增加了ExtensibilityAccelerator组件，专门用来为测试人员自定义开发与发布插件类库。该组件在其易用性在还没有被广泛验证之前一直显得比较低调，通过对QTP11的简单试用，笔者觉得这是开源的冲击终于让像HP这样的厂商不得不放低姿态，开放一些核心的、更有价值的东西给大家使用，其一直鼓吹的傻瓜式关键字驱动不再成为其宣传的核心卖点。总的来说在易用性和扩展性上，最新版本的商业工具(QTP)和这里提到的两种开源工具其实是旗鼓相当的;只不过在平台整合和所支持的脚本语言上，QTP还是显得比较单纯，虽然厂商在不断地丰富着它所提供的AOM接口方法。

　　其次，单就WEB自动化测试来说，我们选择任何工具，只要能进行WEB测试，那么它几乎可以全部应付我们绝大多数的自动化需求;只不过为了自动化实施的更加便利，我们对WEB应用类型还是可以再细分一下。由于Selenium和WebDriver这些开源是基于浏览器的测试工具，它们在快速响应UI交互请求和流程性、逻辑较为简单的应用程序的测试上优势巨大。但是对于业务逻辑复杂和流程性很强的软件来说，要是使用他们就必须有足够强大的测试框架：要处理不同的第三方插件程序，要完成类型众多的参数Mapping解析和文件操作、数据库操作等，要处理调度管理和大规模执行的种种条件依赖，要完成复杂的断言分析设定，定义出错之后的处理方法……即便是为其专门定制的测试管理工具Bromine也无法很好的满足我们日常这些复杂的需求。虽然这些组件开发完成之后组装起来的框架通用性比一般的QTP自动化测试框架要高一些，但是其开发的技术难度显然比后者高很多，必须要考虑员工技能现状，这就需要我们仔细地考虑清楚其开发成本是否有足够的优势。相较之下，虽然QTP这些商业工具入门简单，但随着测试人员不断地学习和深入，我们会发现它也能够满足一些更复杂的逻辑和流程验证。因为QTP的起点很低，即便起初没有测试框架，使用QTP+QC提供的一套原始的框架也可以替代管理，完全没有技术难度可言，用于处理大部分流程性比较复杂的系统来说都足够了，后续框架建立起自己所需要的框架之后也可以把离散的脚本程序纳入新的框架中去管理，其核心问题是对执行环境和测试数据等方面因素要求非常高。而QTP脱离QC的框架也有很多，不过大同小异，开发难度也不高，笔者认为这是在B/S结构的金融软件UI自动化测试中使用得最多、最为成熟的一种形态。有了这种应用系统特征的区分意识，我们就能够理解Google和百度这样的门户网站为何很少去使用QTP测试，因为这种应用要使用QTP测试实在是让被测程序委屈(操作慢)、让测试工具委屈(综合实力无法体现)，更让测试人员委屈(得不偿失)——如果他们能够熟练运用Selenium和WebDriver这类开源工具和框架的话。

　　总之，工具的选择一方面要看被测应用的特征，一方面要看组织内部人员技能水平现状。如果要追求技术上的行业领先地位，充分利用现有的强大的技术优势，那么使用开源工具和框架无疑是一种不错的选择;而且开源的思想使得工具更加能够区分体现不同的社会产业领域的软件在自动化测试上的不同特征，为更加全面的认识自动化测试铺下坚实的基础。但是由于开源的自动化测试实施在一开始就要把调度平台、测试框架相关的内容全部准备好，就从根本上决定了它们不适合在探索性的测试自动化建设中大规模使用。同时我们知道，QTP这种商业工具在初级到中高级水平的自动化测试实施过程中还是比较有优势的，只不过在实施的过程中所遇到的问题远远要比这些开源工具更加闹心，随时有让人想放弃这种工具的感觉。但是在达到一定规模和水平之后，无论任何工具，在界面测试自动化实施上，我们回头看的时候就将会发现，选择开源测试工具还是商业测试工具无非是郁闷在起点还是郁闷在过程中的问题，其本质上都是一样的，没有什么卓越到让傻瓜都能变得无比强大的测试工具。通常，互联网应用和门户网站的UI测试更推荐使用Selenium和WebDriver这些开源工具;而对于有着复杂业务逻辑和业务流程的B/S结构的企业ERP应用来说，如果自动化测试实施的规模较大、测试人员技能水平一般的话，那么最好还是先使用QTP这种类似的商业工具。

　　我们不妨扪心自问：我们追求的是什么?我们的现状又是怎么样的?我们是否已经把我们当前这个自动化测试的建设做到出现瓶颈了?在遇到瓶颈的时候我们还有没有继续进行深入的研究呢?如果再三思考之后还是想到可能会有可改进的地方，觉得有可能越过某个点之后就会得到新的效应，那么请不妨回头继续把当下的建设做完。就像围着5米宽的圆环型跑道寻找遗失的物品，无论单次走的是内圈还是外圈，都应该走到头，否则达成你的目标就只能靠碰运气了。如果你们在开展大规模的自动化建设，并且你们发现根本无法在跨越目前的瓶颈了，那么可能真的需要尝试一些新的工具或者框架了。

　　大规模自动化实施也有流程定势

　　笔者理解，一般的小型项目和系统在快速的测试过程中对测试框架的需求不是很明显，因为三五十个测试用例的管理对与我们来说不是什么问题。但是如果用例多到几百上千乃至上万的话，没有科学的组织管理方式将会是个灾难。我们这里先看看大型项目和系统或者系统群的自动化实施，它们在自动化实现从无到有、由浅入深的过程中都需要关注哪些方面。

　　首先是人员的技能，这是最基本的条件，缺少这个条件，一切后续的工作都没有办法继续下去。所以一个公司要进行自动化实施，在这个实施周期的最初阶段就需要解决的是人员技能的问题，一般有人才引进、引入培训或者聘请顾问咨询等办法。自动化测试框架与平台不能单靠“求同存异”这四个字就能定义的，因为它们需要全部兼容绝大多数类型的系统、解决绝大多数问题。所以调研分析虽说用不着细致入微，但还是应该把所有系统的设计特征和业务流程都了解清楚。所以这对负责人的技能要求非常高，否则会带来频繁且不必要的框架、平台的变更，给测试管理带来很大不便。就像做接口测试自动化，我们公司的产险业务系统中的业务规则多依赖于JAVA程序，但是养老险则基本都依赖数据库PACKAGE，拿其中一个做所谓的DEMO去向另一个去推行，阻力就会大到基本不可行的程度。这就是负责人对系统特征理解单一、对整个公司的应用系统的架构特点不了解所导致的。

原文转自：http://www.ltesting.net