Rational Functional Tester实现测试

期结果分别配置在两个文件中。因为几乎每个被测试的控件通常都和某些特征标签文本相邻，我们只需要在文件中清楚地配置出这种相对位置关系即可。在运行的时候，主程序会读取这两个配置文件，并在测试对象树上面搜索被测试控件。一旦搜索到该控件，则从该控件的属性集合中取出对应的属性值，和配置文件中的预期结果进行比对，最终得以判断该校验点是否通过。这个思路的流程图如图 3 所示。

　　图 3： 动态校验点测试流程图

　　

　　这里我们引入“控件容器”的概念，所谓控件容器，指的是内部包含其他控件的一个容器式的控件。图1中红色矩形所表示的就是一个控件容器，它对应于SWT编程中的一个composite对象。控件容器的重要性在于,如果得到了一个控件容器的TestObject引用，就有可能通过编程的方法遍历并操作其内部的所有控件。控件容器就是那个唯一需要抓取和维护的对象。

　　根据以上的思路,被测试的控件不再通过script explorer一一维护,而是只需要维护一个总体的容器。这样就是在牺牲一定性能的情况下提高了系统的灵活性和可维护性。主程序从配置文件读取控件列表,一次就可以全部校验完成,也同时进一步减少了维护的成本。表 1 全面地对比了两种不同的校验方法的差异。

表 1：静态方法和动态方法对比

	静态测试方法	动态测试方法
预期值	硬编码于源程序中	配置在一个单独的文件中
被测试控件	需要一个个的抓取到script explorer中	配置在一个单独的文件中
校验代码	非常冗长，代码行和校验点数量成正比	非常简短,而且随着校验点增加而不变
维护性	需要在编译前修改源程序,而且经常需要维护script explorer	只需要修改两个配置文件，不需要重新编译,几乎不需要维护script explorer
重用性	几乎没有重用性，对于新增加的校验点，需要添加新的程序段	重用性非常高，不需要对新增的校验点不需要编写任何新的代码
性能	性能非常好	性能中等,因为遍历需要消耗时间

　　动态校验点测试的思想能够被实现的前提是RFT能够提供强有力的支持。而RFT本身一些优秀的特性恰恰证明了这种动态校验的可行性，下面我们通过两方面来展示RFT的相关特性。

　　首先这种可行性是因为RFT的对象识别体系，它提供了把所有被测试控件映射成为一个树形结构的能力，这使得通过程序来动态遍历所有被测试控件成为可能。因此,测试人员可以不用静态地一个个的抓取和维护被测试控件，而采用配置加遍历的方法来进行动态查找，这就大大减少了代码的耦合性。

　　在RFT对象识别体系中，每个被测试的对象都被映射成为TestObject的子类实现。这些TestObject通过树形结构组织在一起，用以映射被测试对象中物件相互包含的关系。一个典型的例子如图 4 所示。在这个例子中，整个eclipse的Properties View都映射成为一个TestObject的树形结构。

　　图 4： 对象映射机制

　　

　　其次这种可行性来自于RFT的TestObject类提供的丰富的对象属性。正是因为有这些属性的存在,测试人员才可能在动态遍历寻找目标时,精确地判断相对位置关系和文字特征。RFT中每个TestObject对象都可以使用getProperties和getPrope