Rational Functional Tester (RFT) 是一款支持 Java 和具备强大对象识别机制的功能测试工具。在使用 RFT 测试基于 Eclipse 的程序时,测试人员经常会遇到校验一个 view 中的一大批控件的情况。使用传统的方法会产生大量的硬编码,升级和维护的成本比较高。本文将借助RFT的对象识别机制,实现一种低耦合可配置的校验方法。该方法将预期结果和被测试的控件配置在两个独立的文件中,只需要维护一个控件容器,而被测试的控件在运行时被动态识别出来并进行校验。维护阶段,测试人员可以通过修改配置文件达到动态调整预期值、增加或者减少被测试控件的目的,而不需要修改任何的 RFT 脚本。该方法可以大大地减少代码的耦合和需要维护的被测试对象的数量,在基于 Eclipse 的程序测试中有广泛的应用前景。
静态的校验点测试
Rational Functional Test(RFT)是一款基于Java的自动化功能测试工具。作为Rational Software Development Platform(RSDP)软件家族中的一员,它为java/eclipse/html/.net等各种被测试程序提供了一个自动化测试平台。其中对基于eclipse的程序的支持更是RFT的特色之一,这使得它在eclipse得到广泛应用的背景下前景广阔。
在功能测试中,用RFT完成一个校验点的测试是非常容易的,只需要很少的代码。下面我们首先给出一个静态校验点测试的例子。本文中被测试程序是Rational Data Architect 6.1。RFT的版本是6.1.1.1。
[问题 1]给定了当前如图 1 所示的Properties View,请校验Name字段的值是否是预期的“DB_LARGE1”。
图 1: 被测试的面板
为了解答这个简单的问题,首先需要抓取Name文本框对应的测试对象,我们把它命名为testDb,如图2的Script Explorer所示。然后可以通过如下代码进行校验。之所以称这种校验的方法为静态校验点测试,是因为校验的代码是被硬编码到源文件中的,如果要增加或者修改任何一个被校验的对象,都需要大幅度修改源程序的对应位置和维护script Explorer,并且还需要重新编译才能得到结果。
图 2: 抓取测试对象testDb()

public void testMain(Object[] args) {
String expect="TESTDB";
boolean result=expect.equals(testDb().getProperty("text").toString());//判断字符串是否等于预期值
String context="The value of textfield ="+expect;
RationalTestScript.logTestResult(context,result);//输出测试的结果
}
批量控件校验的挑战
[问题 2]请校验图1的面板中的连续8个文本控件的值是否都等于预期值,它们的预期值依次 为"DB_LARGE1","","LARGE","DATABASE_MANAGED","32","32","12.67","0.18"。
毫无疑问,问题 2 也完全可以使用静态的方法予以实现。但是,要注意到在上面的静态校验点测试中,预期值、被测试对象、和校验过程都同时出现在代码中。如果继续用传统的方法来处理问题 2,那么很有可能面临至少两方面的问题。首先,传统方法无法管理较多的预期值,预期值只能硬编码在文件中,而且只能编译前进行修改;其次,所有的被测试控件都必须提前被抓取到Script Explorer中,维护的成本是比较高的,一旦被测试对象有所改变,Script Explorer就需要重新维护。
这两点的局限性实际上就是代码的耦合太强的表现,当不同功能的代码都混在一个类中,类的功能界限会趋于模糊。这样的编写思路不管是从功能还是逻辑上来讲,都不能称之为好的设计和实现。所以我们尝试用一个全新的动态的方法来解答问题 2。
动态实现校验点测试的基本思路
为了实现一个比较好的动态的校验点测试,首先测试人员可以将被测试控件和预期结果分别配置在两个文件中。因为几乎每个被测试的控件通常都和某些特征标签文本相邻,我们只需要在文件中清楚地配置出这种相对位置关系即可。在运行的时候,主程序会读取这两个配置文件,并在测试对象树上面搜索被测试控件。一旦搜索到该控件,则从该控件的属性集合中取出对应的属性值,和配置文件中的预期结果进行比对,最终得以判断该校验点是否通过。这个思路的流程图如图 3 所示。
图 3: 动态校验点测试流程图

这里我们引入“控件容器”的概念,所谓控件容器,指的是内部包含其他控件的一个容器式的控件。图1中红色矩形所表示的就是一个控件容器,它对应于SWT编程中的一个composite对象。控件容器的重要性在于,如果得到了一个控件容器的TestObject引用,就有可能通过编程的方法遍历并操作其内部的所有控件。控件容器就是那个唯一需要抓取和维护的对象。
根据以上的思路,被测试的控件不再通过script explorer一一维护,而是只需要维护一个总体的容器。这样就是在牺牲一定性能的情况下提高了系统的灵活性和可维护性。主程序从配置文件读取控件列表,一次就可以全部校验完成,也同时进一步减少了维护的成本。表 1 全面地对比了两种不同的校验方法的差异。
| 静态测试方法 | 动态测试方法 | |
|---|---|---|
| 预期值 | 硬编码于源程序中 | 配置在一个单独的文件中 |
| 被测试控件 | 需要一个个的抓取到script explorer中 | 配置在一个单独的文件中 |
| 校验代码 | 非常冗长,代码行和校验点数量成正比 | 非常简短,而且随着校验点增加而不变 |
| 维护性 | 需要在编译前修改源程序,而且经常需要维护script explorer | 只需要修改两个配置文件,不需要重新编译,几乎不需要维护script explorer |
| 重用性 | 几乎没有重用性,对于新增加的校验点,需要添加新的程序段 | 重用性非常高,不需要对新增的校验点不需要编写任何新的代码 |
| 性能 | 性能非常好 | 性能中等,因为遍历需要消耗时间 |