RFT的经典案例.doc

测试框架设计的几点原则 本系列从如何构建结构良好的测试框架、高效的对象缓存机制，以及测试 Windows 应用程序的技巧和方法等方面，介绍如何运用 RFT 测试 Windows/.NET 应用程序。 HYPERLINK /developerworks/cn/rational/r-cn-rftwindows2/ 一种高效的对象缓存机制在测试框架中的应用 HYPERLINK /developerworks/cn/rational/r-cn-rftwindows3/ 利用 Windows Domain 测试 Windows 控件 HYPERLINK /developerworks/cn/rational/r-cn-rftwindows4/ 对 TestObject.find() 方法的扩展与改进 一个好的测试框架需要具备哪些元素呢？虽然对不同的项目而言，答案可能有所不同。但总的来说，一个好的测试框架通常具有以下的共同特点： 分层结构 关注分离 代码重用 结构清晰 易于维护 方便调试 可扩展性好 除了以上所述的几点外，一个好的框架还应该提供相应的通用服务，以使得脚本开发者可以很容易而且快速地基于它来开发脚本。比如象错误处理，本地化版本支持，日志服务等。 HYPERLINK /developerworks/cn/rational/r-cn-rftwindows1/index.html \l ibm-pcon 回页首 定义良好的层次结构 如何定义一个良好的层次结构，是我们在构建测试框架首先需要考虑的问题。通常我们会把最基本的一些原子操作放在最底层，而在较上层封装这些操作，并开放相应的接口供最终的脚本开发者进行调用。这样往往会使得 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，其中包括对该控件的基本操作，以及一些在测试过程需要使用的验证方法，比如验证某个属性的值。 AppLib：所有与当前测试应用相关的方法及对象在这一层定义。它包括 2 部分： Dialogs：正如名称所示，在这一部分中，主要保存所有的对话框或其他窗口对象，以及对这些窗口上控件的操作方法。他们通过调用下一层的基本控件函数来实现。与 NetWidgets 不同，在这一层定义的方法，是与应用中具体的控件名称所绑定的，具有明确的含义，如 SetPassword()；而在 NetWidgets 层中，仅仅是某一类控件的一个通用的方法而已，如 SetText()。除了窗口对象外，一些其他的经常需要乃至的对象，如应用中的菜单，工具栏等，也在这一部分定义。 Wizards：在这一部分所定义的方法，他们包含是一些基本操作的组合，用来完成某项具体的功能，如 Login()。这些功能都是大部分 Cases 需要经常调用，或者是特定的测试步骤组合。通过将它们纳入这一层统一管理，可以很方便地起到代码重用的目的。通常这些 Wizard 是对同一个 Dialog 上的操作组合，但这并不是必须的。有时候跨多个 D