在进行 IBM Rational Functional Tester（RFT）自动化测试脚本开发时，我们往往需要首先创建一个测试框架，然后基于此进行测试脚本的开发。一个设计良好的测试框架会给以后的脚本开发带来很多便利。在这篇文章里，我们结合一个实际的项目来介绍一下如何使用 RFT 构建一个结构合理、可扩展的，用于测试 Windows .Net 应用程序的测试框架。

　　测试框架设计的几点原则

　　一个好的测试框架需要具备哪些元素呢？虽然对不同的项目而言，答案可能有所不同。但总的来说，一个好的测试框架通常具有以下的共同特点：

　　● 分层结构

　　● 关注分离

　　● 代码重用

　　● 结构清晰

　　● 易于维护

　　● 方便调试

　　● 可扩展性好

　　除了以上所述的几点外，一个好的框架还应该提供相应的通用服务，以使得脚本开发者可以很容易而且快速地基于它来开发脚本。比如象错误处理，本地化版本支持，日志服务等。

　　定义良好的层次结构

　　如何定义一个良好的层次结构，是我们在构建测试框架首先需要考虑的问题。通常我们会把最基本的一些原子操作放在最底层，而在较上层封装这些操作，并开放相应的接口供最终的脚本开发者进行调用。这样往往会使得 Case 更加简洁易读。

　　根据面向对象基本理论，我们首先要定义一些基础的控件类，用来代表那些需要在测试中进行操作的基本界面元素，象按钮，输入框等。如果你使用 RFT 测试 Java 或 Web 应用，那么你可以直接使用 IBM Package，在这个包里封装了所有的在 Java 和 Web 这两个 Domain 下的基本控件。通过在你的脚本中调用这些类，你就可以很方便地实现对被测应用的操纵。但是，我们所测试的应用是基于 Windows .Net 的，在这个包里没有对应的控件类可以利用，因此，第一步，我们要开发自己的控件类。

　　其实，我们也可以不定义基础类，而直接使用 GUITestObject 来操纵每一个界面对象，但这样做的代价是显而易见的，会有很多重复且不易读的代码充斥在我们的脚本中。这显然不是我们所想要的。好在虽然各种控件的种类繁多，但对于每一个控件而言，需要封装的主要是一些我们在测试中经常需要调用的简单方法，比如说 Click()，或 SetText()，因此工作量并不太大。

　　在实现了这一层之后，理论上说，我们可以直接在 Case 脚本里调用这些方法来实现对测试对象的操作。但这样做也有一个问题是，如果以后你对这些方法的名称进行了修改，或者因为程序实现的改变，原来的 A 类控件被 B 类代替，这时，势必会对所有已经编写好的 Case 脚本造成很大的影响，带来很大的代码维护量。因此为了隔离下层代码对上层 Case 的影响，我们在其中又加入了新的一层。最后的层次结构如下：

图 1. 层次结构

　　以下是对每一层的具体解释：

　　NetWidgets：这一层封装了所有的基本 Windows 控件，它与具体的应用无关，可以看作是测试 .Net 应用的基础类库。对应于 Windows 的每一个控件，在这一层里，都有一个对应的 Class，其中包括对该控件的基本操作，以及一些在测试过程需要使用的验证方法，比如验证某个属性的值。