我做过自动化测试好多年，也用过不少的测试工具，对自动化的测试理论也了解不少，研究生的论文是写的自动化测试。现在看来那个论文真是的很稚嫩。

　　为了更好的提高重用性，需要引入自动化测试框架，让测试能更节省人力，让测试更加可靠。

　　先介绍我接触的第一个自动化测试框架，是一个测试界面的框架：
　　被测产品是一个C/S结构的程序，采用Rational Robot来做产品的自动化。
　　由于Robot对某些窗口支持不好，测试框架还采用了SAS的自动化前辈Carl Nagle的部分代码
　　整个ProductA有76个窗口，有800个Case。
　　整个架构是这样子的：

　　我来简单介绍一下子：ProductA是被测试的产品，ProductB是有时候和ProductA做集成的产品。
　　第一层是底层：包括CommonFunction以及产品给到的Property文件或者XML文件，这里面只有ProductSpecificListViewUtilities和ProductRelatedPropertiesFile是和被测产品相关的，是为产品而定制的或者是被测产品开发的人提供的文件。

　　第二层是中间层：按照窗口来划分，每个Checkbook，每个EditBox，每个RadioButton都是一个独立的Item，每个Item都封装一个方法，我们叫Task。不同窗口的OKButton的点击被封装到不同的窗体的文件中，作为各自独立的Task。Task有时间需要调用CommonFunction里面读取Property文件的方法，总的来说，Task和被测产品关系不算大。

　　中间层还有一个叫做Wizard，是调用一系列的Task，每个Wizard都是和被测产品的业务相关系的。
　　如何区分Task和Wizard我举个例子：
　　QQ登陆界面：
　　点击UserNmae，输入UserName，清空UserName，点击密码，输入密码，清空密码，点击登陆这是7个Task。
　　而一个Wizard是
　　1输入用户名，2输入密码，3点击登陆，这是一个Wizard。Wizard不做验证，只是调用各个小的Task。Wizard调用后验证的结果在TaskCase里面调用。

　　第三层是TestCase，调用Wizard，然后用CommonFunction的Verify系列方法去验证，PassOrNot。

　　分为三层架构后，有有点也有缺点：
　　优点是：
　　1对产品进行了隔离，一般Case写好后不需要修改，只是去调整底层的Task和Wizard。想想Case有800个，而Task和Wizard写在一起才76个文件，每个窗体一个。
　　2Task和Wizard起名有规范，直接读Case能够读懂，写Case的工作交给只会手工的人也能写，调试交给专职自动化的人来。
　　3产品小规模调整的时候，只需要调整Task，甚至不动Wizard和Task。
　　4便于做本地化，只修改properties文件行。缺点也是蛮明显的：1产品不能大改动，界面如果是可配置的，我们必须固定某种配置或者并行集中不同界面的配置，增加了复杂度。
　　5先期写CommonFunction和Wizard比较耗时。
　　6不熟悉CommonFunction的人调试得花费较长时间。