前言废话：
本来我在这里想使用功能自动化(GUI自动化)框架作为标题，但又担心给人误解以为我在这里介绍一个框架，但实际再看的时候又发现我是在说些基础的认识，根本不是什么框架却拿了一个很吸引人眼球的标题，然后使劲拍砖、谩骂。
（这里要对网络上的现状说两点：一是大家好像对自动化框架这样的字眼格外关注。有一次一个腾讯的部门负责人打电话我，第一句话就问你怎么理解自动化框架，一声长叹；另外要说的一点是，正因为好多人多自动化框架格外关注，也不知道是不是被网络上各种各样鼓吹的东西所影响还是它真的认识到自动化框架的用处，所以对使用这个字眼而偏偏内容有偏差的文章格外的不能容忍，并加以苛责，其实每个人说的可能都是对自己当时的认识或者积累的知识的一种沉淀，不管全面还是片面，大家了解就行，可接收可认同就取其精华去其糟粕，不认同就一笑而过，也不用一定要在那拍块砖，留个脚印，好像必须要告诉别人孙大圣来过此地一样，当然我想每个发表自己观点的人应该愿意看到你发表自己的看法，但言辞不至于过于激烈得像口角，这里瞎啰嗦几句吧，说实话我在这里开始发布自己的日志博客其实也就是想总结沉淀自己不断的认识的过程，并督促自己不断地学习进步，纯属个人观点）。
转入正题：
可能大家平常最常听到的都是什么数据驱动自动化框架、关键字驱动框架等等这样的字眼，在网上大家都对框架等等字眼趋之若鹜，期望越大失望也就越大，呵呵……
这里我为什么想用功能自动化框架的标题呢，因为我在这里没有把单元测试框架以及性能测试等考虑在内，等等这些本身也是属于自动化的，构建他们的平台是什么样的呢，对它们更深入的去理解，以后我研究总结后再记录吧。
这里我想把功能自动化框架分成两个概念，功能自动化基础框架和功能自动化应用框架。
基础框架的作用主要是做对象的识别、对象的操作等，在此基础上，就是应用框架，我愿意把所谓的数据驱动、关键字驱动框架归为此类，但这还是不够的，后面再说为什么不够。
基础框架完成是事情其实是现在很多人学习或者使用的工具，开源的Selenium以及市场占有率很高的QTP，实惠工具Test Complete等。它们是更底层的一些处理与封装，多数关系到与操作系统、浏览器等一些底层的操作。在这里建议大家多看看开源的框架Watir,Watin,Selenium等，研究他们源代码会让你对自动化的基础、本质有更深入的认识，对自己以后思路或者疑难问题的扩展也大有裨益。其实现在很多公司都有自己的开发平台，很多这种个性化的东西，大家可能就发现经常出现一些工具识别支持上存在的问题。微软为什么没人听说它用了其它哪个公司的工具呢？其实所有这底层的一套它都是自己开发的，我曾经看到过微软关于Web自动化的一套组件，其实就是对操作系统的一些API，浏览器一些对象等等的封装。对于现在很多有自己独立开发平台、有独立知识产权的公司，最后要发展适合自己的自动化，可能更多的需要在这方面多发力，这样你才能真正构建适合自己的框架。
当然这个耗费是比较大的，需要根据实际情况进行评估了。
我为什么说把数据驱动、关键字驱动归为应用框架，而又说不够呢？其实这些数据驱动、关键字驱动只是你实现自动化的一种方式，为什么录制回放这种硬编码的方式有很多问题，可用、维护性差呢？而实际情况是复杂的，场景是变化多样的，系统越复杂，关联越多，你的用例组织、脚本组织、结果分析等等，就与你实际的应用有密不可分的关系。那如何应对这些问题呢，这就构成了你实现自动化应用的基础，，此时你不得不在此时对他们进行不同的扩展、进行一些个性化的改进，提高你的重用，减少你的维护，此时就构成了的整个应用的框架，当然这个跟你实际提炼的程度有关，你应用的框架可能直接与你的应用关联了起来；也有可能你针对你相似的应用进行进一步的提炼，构成了你应用的基础框架，有可能你分了更多层，但整体还是为应用服务的。
暂时我就把对功能自动化框架的认识先写到这吧，欢迎大家谈谈自己的观点，共同学习，拒绝不友好拍砖。
版权声明：本文出自JackieChan的51Testing软件测试博客：http://www.51testing.com/?192995
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
相关链接：
