长期困扰 Rational Functional Tester (RFT) 自动化测试的一个问题就是如何有效地识别 GUI 元素，以适应 GUI 的不断变化，这在敏捷开发日益成为主流开发模式的情况下显得更加重要。本文通过大量的实例向您介绍了针对不同的 GUI 元素，选择不同的对象识别技术，以提高 RFT 自动化测试的效率。
RFT 对象概述
RFT 对象
从开发的角度看，GUI 通常都是基于某一 GUI 开发库（SWT/SWING/AWT），这些库通常是按照面向对象的方式进行建模的，它将每一个 GUI 元素映射成该库中某一个类的对象。
从测试的角度看，所有的 GUI 元素，无论基于何种 GUI 库，都被 RFT 映射成对象，RFT 提供一个对象模型框架管理各种 GUI 元素。
图 1 是一个典型的基于 SWT 开发的 GUI，对于其中的一个按钮，在开发者看来，它就是 SWT 库中 Button 类的一个对象；但是 RFT 并不区分这是 SWT 库中的按钮，或者是其他 GUI 库的按钮，它都被映射成 RFT 对象模型中 GuiTestObject 对象。
在用 RFT 提供的 Inspector 工具获取 GUI 元素时，需要用到开发模型。而进行 RFT 脚本开发时，又需要用到 RFT 对象模型。熟练掌握两种对象模型，对提高 RFT 自动化测试效率非常有帮助。
图 1. RFT 对象模型示例
RFT 对象识别
基于 RFT 的自动化测试，都会采用 IBM 推荐的 ITCL 框架。在这个框架下，所有的脚本被划分为三个层次：对象层，任务层，用例层。对象识别就是在 RFT 的对象模型框架下，得到被测程序的 GUI 对象。它是对象层开发中最核心的任务。
常用的 RFT 的对象识别技术可以分为两大类：静态识别与动态识别。动态和静态方法各有优缺点，静态方法识别效率高、开发成本比较低，但是脚本的可维护性比较差；而动态方法刚好相反。
扩展 RFT 对象识别技术
采用常用的对象识别技术，可以识别出大部分的 GUI 元素，但有时也会遇到 RFT 无法识别的 GUI 元素，事实上识别这类用常用对象识别技术无法识别的 GUI 元素占用了 RFT 脚本开发的大部分时间。
RFT 中一个非常重要的根接口是 IGraphical 接口，它定义了针对 GUI 元素的所有标准操作（click,doubleclick,drag 等）。另外一个非常重要的根类是 GuiTestObject，它继承自 TestObject 并实现了 IGraphical 接口。常用对象识别技术中 GUI 元素都是被映射为 GuiTestObject 对象。它们在 RFT 对象模型中的位置如图 2 所示。灵活运用这些类、接口及其方法，能够极大地扩展 RFT 对象识别的功能。
图 2. RFT 对象模型类图
问题描述
使用 RFT 经常听到的一个谬论就是 RFT 只能测试基于 java 的 GUI 程序，对于 C/C++ 或者 windows 标准控件，RFT 无法识别。事实上，RFT 提供了 IWindow 接口用于识别平台相关的控件。
IWindow 接口介绍
从图 2 中可以看出，IWindow 接口也继承自 IGraphical 接口，从这点看，IWindow 接口具有与 GuiTestObject 类似的功能。
使用 IWindow 接口能够识别平台相关的 GUI 控件，但是其接口函数的具体实现与平台相关，windows 与 linux 上的实现就不一样，可以通过下述方法判断具体的平台，本文将主要分析 windows 上的应用。
清单 1
