定制的Java 控件（或者没有包含于标准 Java 库中的控件）正在挑战 GUI 自动化测试过程。本文解释了如何通过 IBM Rational Functional Tester 所提供的两种方法使用这些控件类，用以创建自动化的处理过程： getProperty 和 invoke。 
        IBM® Rational Functional Tester 提供了标准接口，便于操作标准 Java®控件。例如，在 Rational TextGuiTestObject 接口中，您可以很方便的使用getText 和 setText 方法获取/设置Swing文本框。另一方面，任何GUI自动化工具都很难实现非标准的或定制控件的自动化，包括 Rational Functional Tester。 定制控件 并不存在于标准部件之中（例如，AWT 或 Swing），但它们是应用程序开发者不断积累所创造的。 Rational Functional Tester 开发者并不知道这些控件，不能预料到您所需要的方法，因而他们不可能提供包含所有方法的接口。为了测试这些接口，您需要直接从控件本身获取控件如何工作的信息。幸运的是， Rational Functional Tester为我们提供了一条途径，那就是使用 getProperty 和 invoke方法。

        Java applet 就是一个定制控件的实例，如图 1所示。 这是 Lotus Notes中包含的 Editor applet 。

                                    图 1. Lotus Notes Editor applet

        这个 applet 显示了用户输入富文本（可设置文本为粗体、斜体、文本颜色等等）的区域。用户通过使用顶部 applet 的按钮和列表框控制文本的显示。 这些按钮并不是标准控件。就是说，它们不属于 Swing 或 AWT 按钮，而属于 Lotus的开发者。它们的包和类名，com.lotus.app.MultiImageButton，表现出了这一点。很明显，这个包中的类不是一种标准控件，因此 Rational Functional Tester 不能提供包含您需要的一切接口。

        但是，即使这些按钮不是标准控件，Rational Functional Tester 仍然可以使用最普遍的类来识别它们，即 GuiTestObject。但在大部分情况下，这样做还不能满足要求。问题在于，对比直接提供的 GuiTestObject 类，您需要更多有关控件的信息，更多操作它们的方法。例如，虽然 GuiTestObject提供了点击按钮的方法，但是它没有提供获取按钮名称（例如，用来区别粗体按钮和斜体按钮）的方法 getText ，而且它没有提供 isSelected 方法以确定是否某个特殊按钮已被选择。但这些正是彻底测试 applet 所必需的信息。因此，您不得不使用 Rational Functional Tester 的 getProperty 和 invoke 方法直接从控件中获取信息。

        本文为您展示了如何使用 Rational Functional Tester 测试定制的Java控件。本文中我们主要使用 Lotus 创建的 Editor applet 实例，但您可以将此原则应用于任何定制的 Java 类中，无论其是否嵌入 Web 页面内。

对象图（Object Map）

        当您实现自动化 Editor applet 时，首先要做的就是映射它的对象。步骤如下：

        创建一个 new script。 
        打开 Object Map。 
        选择 Insert Test Object。 
        在页面中突出显示 control 。 
        选定 Include All Objects on Selected Page。 
        点击 Finish。 
        这步为 My Object Map 增加了页面中的所有对象，如 图 2所示。

                           图 2. 来自于 Editot applet 的对象图

注意： 
        由于在本例中您测试的是一个 applet，因此当您增加这些对象时不得不选择 Java 域。否则，将会只有一个对应 applet的对象，而不是许多个对应 applet 中 Java 控件的对象。如果您仅仅是测试单机 Java 应用程序，那么这些都是不必要的。

        正如您所见的，Rational Functional Tester 能够辩识出 applet 中的任何控件都是独立的 GUI 对象。但是，定制的控件往往并不由 Rational Functional Tester 所能辩识为独立对象的控件组成。例如，Lotus Notes 具有另外一种称为 Action Bar 的包含许多 Action 按钮的 applet，如 图 3所示。

                                       图 3. Action Bar applet　　

            
        在映射过程中，这些 applet 仅仅产生一个单独的测试对象，如图 4所示。

                                      图 4. Action Bar applet 的对象图

        仅有一个单一测试对象的原因是 applet 中的按钮并不是真实的按钮，因为并没有独立的 GUI 对象。取而代之的是，Action Bar applet 在 Action Bar 上“绘制了”每个对象。Action Bar applet 追踪每个按钮的边界。当用户在 Action Bar 中点击时， applet 拦截此响应并指出用户点击了哪个按钮，给出它的边界。由于其具有此种特性，因而更适宜自动化，这就是为什么我在大部分文章中都关注更简单的 Editor applet 的原因。 但是，由于自绘制控件的问题具有普遍性，在文章的结尾我将回到 Action Bar applet，用它来展示如何使用 Rational invoke 方法作为替换一解决这个问题。

        由于 Rational Functional Tester 能够辩识出 Editor 控件中的单个按钮，因此对它的测试变的非常容易。这些按钮在对象图中注册为 GUI 测试对象，并且分配了索引以对应于它们在 applet中的位置。因此，您可以与索引结合，使用 GuiTestObject 方法点击任何特殊按钮。例如，为了点击 Bold 按钮，您可以在对象图中找到索引为 1 的按钮，将此对象转移为脚本，然后调用点击方法。

        但是，很可能通过特殊名称的查找而不依靠索引将获得更好的效果，例如开发者改变了这些按钮的顺序。但是这些信息并不能通过任何 GuiTestObject 方法（例如，在 GuiTestObject 中不存在提供按钮名称的 getText 方法）直接获得。 因此，您必须直接查询按钮以获取相关信息。 存在两种使用 Rational Functional Tester 的方式获取这部分信息：查询按钮的属性或调用一个方法。让我们先来举例说明第一个。