前言
Rational Function tester
根据我的一些项目实践经验和个人心得，想分享一下利用IBM的Rational Function tester来进行一个企业级的GUI自动化测试平台的构建，当然这不是告诉你一定要用RFT去做你的自动化测试，个人认为如果有能力的话最好能自己去开发底层的控件识别，当然难度有一点大。所以这里主要去体会的是一种思想，一种如何去真的将自动化测试实现规模化、平台化与流程化，工具和技术是一个次要面，关键在于如何去与你的公司流程与产品联合起来去做好自动化测试。
软件产品一般会用到下面三种不同类别的接口：命令行接口（command line interfaces，缩写CLIs)、应用程序接口（API）、图形用户接口（GUI）。有些产品会用到所有三类接口，有些产品只用到一类或者两类接口，这些是测试中所需要的接口。从本质上看，API接口和命令行接口比GUI接口容易实现自动化，去找一找你的被测产品是否包括API接口或者命令行接口。有些时候，这两类接口隐藏在产品的内部，如果确实没有，需要鼓励开发人员在产品中提供命令行接口或者API接口，从而支持产品的可测试性。
而且为了让API与CLI接口测试更为容易，应该把接口与某种解释程序，例如Tcl、Perl或者Python绑定在一起。这使交互式测试成为可能，并且可以缩短自动化测试的开发周期，当然这里不是重点。
当你的项目是基于界面开发的，而且项目已经成型，并没有提供你API的接口可以进行调用，那么你就很难做到两层的开发，你要考虑的是如何去做基于GUI的自动化测试。
很多测试人员因为上级想要推广自动化测试或者本身对自动化测试的热情而去推广自动化测试，而很多公司没有很大的人力物力去开发自己的自动化测试工具，因此就需要借助于一些自动化测试的工具，例如QTP、winrunner以及RFT等。
实际上，很多测试人员对这些工具的掌握都是靠着自己的摸索来一点一滴的用到部门的自动化测试项目中去的，而在这个过程中，又有很大一部分测试人员仅仅浮在这个工具的表面，以为测试人员所做的只是去用这个工具罢了，孰不知，很多自动化测试项目失败的原因并不是这个工具的原因，而是自身对自动化测试平台和流程的掌握问题。
因此，这次，将从RFT入手，来一步一步讲述如何去搭建一个企业级的自动化测试平台，所谓平台不仅包括测试工具、更是包括了流程和框架的思想，通过流程化，则能更加的管理自动化测试项目，才能更加的监测自动化测试项目的实用性；通过框架化，则能更加的增加自动化测试的灵活性，降低其维护成本。请牢牢记住：一切皆平台，而且要达到的要求最好如下：
1、自动化测试平台是为较稳定后的版本服务的，永远不要用自动化测试替代第一轮人工测试（即一个新功能发布的版本测试），因为人工测试，因为一个产品的第一个版本的某些固定功能的BUG的85%是在手工发现的，而15%是在之后的版本回归中发现的。可以在需求设计的时候，即设计出用例，然后在进行第一次测试的时候，转换成自动化测试用例和脚本。这样可以用于到以后新版本时，将这些功能继续测试一遍。
2、根据人工发现的BUG分布率和人工测试的普遍率去定义好自动化测试项目选取范围，这样的话可以提高自动化测试的收益价值。
3、要达到的效果是建立一种平台机制，将测试人员当成用户，能够让一个不会自动化测试的人员来反复对这个平台产品进行反复使用和维护，并且稳定性较高。
接下来的四部曲，将分别介绍：
第一部曲:RFT基础篇—录制与回放的使用和实践分析；
将说明录制与回放这种方法的使用，然后根据实践说明这种方法的弊端，因此这种方法只能小范围使用，而且只能用在很单一的回归测试中。
第二部曲:RFT提高篇—RFT的高效技巧及应用分析；
将介绍RFT的一些高效技巧，包括脚本模块化、数据驱动、ScriptAssure、动态搜索方法等。不会片面的介绍这些原理，而是从实践例子出发介绍一下这些方法，只要将例子操作一遍即可，这些方法都是可以在后期框架和平台的搭建方面能够用上的。
第三部曲:RFT进阶篇—基于RFT的自动化测试框架的搭建
将介绍如何利用RFT进行框架的搭建，当然其思想不一定局限于RFT这个工具，其实自己开发一个也是基于这种思想的，就是尽量将UI层和逻辑层进行分开，搭建好框架，基本上，基于UI自动化测试就可以开始应用了。
第四部曲:RFT完全篇—基于RFT的自动化测试平台的搭建
搭建好自动化测试框架是不够的，为了追求GUI自动化测试的实用性与易用性，需要的是建立好一个平台，其实即使用swing或者VC编写一个界面，然后用界面进行测试流程的管理。
OK，接下来，将尽快具体介绍这四部曲，希望能凭着自己的一点领悟，对大家在自动化测试生涯上有所帮助，也希望能够对大家的自动化测试项目能够起到真正应用，希望能够有志之士交流。
