一直想仔细研究框架，写个流水账似的测试程序不难，写个低维护成本的测试框架就很难了，所以研究多种测试框架还是很有必要的，知道孰优孰劣，才能在开始编写框架的时候打好基础，今天读到了KiKi Zhao的翻译文章，觉得很是不错，写了一点学习心得，有不正确之处，请指出。
中文原文地址：http://www.cnblogs.com/nckiki/articles/244202.html
英文原文地址：http://www.ibm.com/developerworks/rational/library/591.html
原文对自动化测试架构做了如下四种分类：
- 数据驱动测试框架（The Data-Driven Testing Framework）
说明：
仅仅是将测试数据从测试脚本中分离出来，开始了非混沌状态的第一步，这也是所有测试架构中最简单的一种
优点：
至少测试数据可以单独维护了
缺点：
任何被测试程序的变更所导致的工作量是所有架构中最多的，因此维护成本非常高
- 测试脚本模块化框架（The Test Script Modularity Framework）
说明：
l 箭头方向代表的是被调用和调用关系
l 测试脚本中包含了各功能点中涉及到的控件识别和业务逻辑操作，其中包含了外部测试数据的调用
l 测试脚本的维护由自动化测试开发工程师负责，要求必须懂自动化编程和业务逻辑
l 测试数据的维护由测试工程师负责
优点：
控件和业务逻辑一旦发生变化，要进行修改和维护的是底层的测试脚本（比无任何抽象封装的自动化测试程序稍好一些）
缺点：
l 几乎所有大的变更引起的工作量都由自动化测试开发工程师完成
l 控件识别和业务逻辑本身属于不同的领域，没有很好进行抽象封装
- 测试库构架框架（The Test Library Architecture Framework）
说明：
l 箭头方向代表的是被调用和调用关系
l 将所有的针对测试系统本身的控件识别和控件支持的操作封装在测试库中
l 测试脚本调用测试库的同时传递外部的测试数据
l 测试库的编写由自动化测试开发工程编写（可以不懂业务），负责控件的变更和维护
l 测试脚本的编写可由对业务比较掌握的自动化测试开发工程编写，负责业务逻辑的变更和维护
l 测试数据由测试工程师维护（可以不懂自动化开发）
优点：
l 被测试系统无论是哪层发生变化，只需要相应的人员进行变更维护即可
l 完成了控件识别操作和业务逻辑的抽象分离
缺点：
变更引起的工作量还是附加在自动化测试开发工程师身上
- 关键字驱动或表驱动测试框架（The Keyword-Driven or Table-Driven Testing Framework）
说明：
l 说到关键字驱动，当然得说QTP。确实当对象库（很类似测试库架构中的测试库）添加完成后，测试case步骤的组织就相当于是在关键字试图中选择控件对象（Control），动作（Action），参数（Parameters）。
l 仔细想想，当QTP在完成对被测试程序的录制后，完成了对象库的记录，关键字驱动测试case的步骤设置，如果再在table中存放一些测试数据，在测试步骤中进行调用的话，似乎以上三种架构所涉及的内容都得到了很好的运用，但再仔细一想，就QTP录制的测试程序来讲，其实什么架构都没有做，因为录制下来的脚本的维护成本是非常高昂的，因为从测试数据的维护，对象库的维护，业务逻辑的维护等等都必须要求维护者懂的QTP的使用，而且是具备一定水平的。这违背了架构的本身理念。所以得基于QTP做更上层次的对象抽象，最终QTP仅仅是个识别对象和运行VBScript脚本的工具，这一层次的架构设计就体现在VBScript的脚本组织上了。
l 换个角度，框架到底用来做什么，最终的目的无非是将不同层次的对象和逻辑进行抽象和分离封装，从而使得被测试程序的变更所导致的测试脚本框架的变更维护工作量减少到最少，更进一步，如果不懂自动化编程的普通测试工程师能不需要了解测试工具和框架本身的知识就能维护控件对象和业务逻辑，这样就可以将自动化测试工程的工作量进行很好的分摊。具体实施就是将控件对象，动作，参数等等从框架或工具本身剥离出来放在普通Excel表格中，组织成如下形式：
|
Window |
Control |
Action |
Arguments |
|
Calculator |
Menu |
View, Standard |
|
|
Calculator |
Pushbutton |
Click |
1 |
|
Calculator |
Pushbutton |
Click |
+ |
|
Calculator |
Pushbutton |
Click |
3 |
|
Calculator |
Pushbutton |
Click |
= |
|
Calculator |
Verify Result |
4 |
|
|
Calculator |
Clear |
||
|
Calculator |
Pushbutton |
Click |
6 |
|
Calculator |
Pushbutton |
Click |
- |
|
Calculator |
Pushbutton |
Click |
3 |
|
Calculator |
Pushbutton |
Click |
= |
|
Calculator |
Verify Result |
3 |
框架本身所要做的就是识别Excel表格中的这些控件对象以及Action
注：以上表格中还可以将数据剥离出去，以单独的数据Excel表格进行维护
优点：
极大的减少了自动化开发工程师维护量，毕竟在测试团队中，自动化开发工程师占的比较少
普通测试工程师，可以很好的维护自身负责的模块中涉及的测试case和测试数据
缺点：
框架的抽象程度比较高，对自动化测试工程师的开发能力比较高
总结：个人认为以上的四种架构是存在递进关系的，至少前三个是肯定的，原文中最后总结的图认为还是需要多种框架特点组合在一起的，还是有很好的借鉴意义的，这里一并附上
