本文以HP公司的Quick Test Professional为例。仅为个人的一些实践中的看法，如有不对或者不同的意见，尽请指正
1. 引言
1.1 关于Automation Testing
自动化测试的作用体现在可以让自动化工具帮助测试人员执行case从而提高测试效率，降低成本。但从实践的经验来看，自动化的使用并不像想象中那么的完美，特别对一些稍具规模的项目来说，甚至可以说令人失望和无奈。
撇开开发成本不谈，就现在的常见的系统开发模式上来看，一个需求的变更，甚至于说IT开发一个变量名的变更都有可能导致刚刚开发好或者是还在开发阶段的脚本无法使用，不得不重新修改维护。待到好不容易修改完成了之后，猛然间又发现需求又变了，代码又更新了，只好继续，待到好不容易一个版本稳定了，抓紧把脚本搞定，运行了一，两遍之后。新版本上，于是脚本又跟不上了，继续改，周而复始，其维护成本可想而知了。
解决这个局面的一个最好的办法就是提高脚本复用型，即不管系统如何修改，需求如何变更，系统如何更新，能以最少的代价完成脚本的更新。故而搭建一个合适的framework是非常重要的。同时一个规范化的framework可以使整个脚本开发团队开发出的脚本井然有序，提高脚本的质量
1.2 关于Framework
没有一个Framework可以说是完美万能可以适用于任何项目系统，没有最好只有最合适，这是千年不变的真理。对于那些比较经典或者之前使用的比较成功的framework，可以拿来借鉴修改使他能够适合自己使用，最忌生搬硬套，不分青红皂白拿来就用，结果工作量骤增不谈，还不一定有好的效果。我们需要具备的是拿来精髓而不是鸡肋。
2. Framework的搭建
2.1 Framework的目的
在选择搭建何种framework前，首先要明确这个framework是准备为何种目的而搭建的，仅仅为这个版本？这个项目？或者是公司的产品线？或者是更加common的目的，不同的目的所搭建的framework的成本是不同的，而如果可以从一开始就确认framework的目的，那么就可以从搭建framework一开始设计时就注意更多的细节从而减少之后更多的rework。不过这种仅仅是一种理想的情况，IT本来就是一个一切都会变化的领域，所以不可能从一开始便有很全面的意识，这里提到只是希望提醒自己注意，在搭建framework初始就要使自己养成一种稍微长远一点的思想，在设计的一些细节上，要考虑将来可能产生的复用性。
现在的一般，我们都是以一个当前项目为目的进行搭建，如果这个项目比较成功的话，那么这个framework就会被其他的项目修改下进行使用。对公司来说，特别是项目型公司来说，这种更为经济实用。
2.2 Framework的组成
以Quick Test Professional为例，一般的Framework由以下几部分组成
2.2.1 Object Repository: QTP特有的，放置对象的用，对于对象的处理方法一般有2种，
- 使用Shared类型对象库。即所有的脚本只能使用一个或几个对象库，由特定人员统一维护，这样可以有效减少对象的冗余，加快运行的速度。同时对于QTP来说使用对象库编写脚本更加快速方便。不过就需要依赖于对象库，一旦对象库发生变化，就需要修改相应的脚本
- 不使用对象库，完全使用描述型编程的话可以不使用对象库，脚本就更加独立，系统对象变化也不会对脚本产生很大影响。但势必会有大量的外部测试数据作为支持（至少要存储对象名），同时开发脚本的速度和执行速度维护成本会相应增大。
一旦确认了对象的处理方法，就要完全统一，避免两者交错，对象的处理应该尽量一致性。
2.2.2 Reusable Action：编写的复用的脚本，可以看作是一个function ,某些时候也给被library function代替
Library Function:放置一些基本的操作函数，比如对excel, oracle,QC操作，当然也可以放置复用脚本
无论是Reusable Action还是Library Function，都需要注意代码的规范，命名规范，以及相应的注释。
各脚本之间应该尽可能相对独立，以便整合时减少错误的发生。
2.2.3 Test Data：所有的测试数据，搭建framework中尽量脚本和测试数据分离，一般建议完全独立，达到data-driven，这对维护和管理会带来极大的便利。
测试数据的放置也需要根据不同情况而定，一般采取的方法有2种
a. 一个test case一套测试数据
b. 所有的test case一套数据
c. 两者结合
2.2.4 Document：团队合作中，文档的重要性毋庸置疑。
2.2.5 Driver：调用执行test case的主脚本，应该具备以下一些东西
- 全局参数
- 所要test case的地集合，包括测试需要用的测试数据，参数
- 能够判断测试结果，并且决定是否调用其它的测试用例，或者停止测试
- 自动生成测试报告。以及需要输出的路径
- 每个测试脚本的初始设置路径
2.3 Framework的灵魂-----划分粒度
Framework的关键作用在于可以复用，这就要求对系统各种操作的有个合适的划分才能达到既能够充分复用，又不会因为过分划分而导致脚本零零碎碎，维护起来困难重重。
颗粒的划分最基本的还是适合原则：这个framework是给谁用的？不同的系统，不同项目对颗粒度的划分要求也是不同的。总结一下对颗粒度的划分有几个层次
· 不划分:将所有的操作及其业务路径放在一个function里，执行起来只需要执行这一个function，通过改变测试数据或者来控制执行什么路径的test case。
Eg.测试Login，user name和password为空，username不正确，password不正确，以各种不同权限用户登陆成功，都会分别进入不同的页面。这样一个功能就可以不用划分而将所有的可能路径写入同一个Function中
· 按照业务流程划分：将所有操作按照一定的业务进行划分，把这个业务中所有可能路径都包含在一起，每个业务操作可能会经历多个页面。但这种划分对设计者的业务要求比较高
Eg.测试网上购物流程，最终收银结账包括各种信息确认或者重写可写入同一个function中
· 按照页面划分：将每个页面上的任何操作，比如输入，点击，都放在一起。这是一种比较common的做法，划分设计起来简单
· 按照实际操作划分：相当于重写keywords,即将所有的输入，click ,select等动作重新封装，一般这些封装里会包括对象的检查，各种validation,然后通过参数来控制应该对哪个对象进行操作。这个划分更确切的说是作为辅助其他划分方法的一种工具
Eg.需要click一个image,首先check这个image是否存在，然后再click，最后check是否到了其他页面，这三步操作可重新封装成一个image click的function
最近比较流行的saffron framework就是这类的典型
以上只是几种比较典型的做法，不能说哪种一定好，哪种一定不好，根据具体情况实际操作而已。很多情况也会同时使用。
3. 选择自动化test case
所有的test case都可以做成自动化，但不是所有的test case都适合作自动化，自动化的高成本势必带来希望高回报，但一般来说一个脚本运行
