静态的校验点测试
Rational nal TestRFT是一款基于Java的自动化功能测试工具。作为RationalSoftwareDevelopmentPlatformRSDP软件家族中的一员,它为java/eclipse/html/.net等各种被测试程序提供了一个自动化测试平台。其中对基于eclipse的程序的支持更是RFT的特色之一,这使得它在eclipse得到广泛应用的背景下前景广阔。
在功能测试中,用RFT完成一个校验点的测试是非常容易的,只需要很少的代码。下面我们首先给出一个静态校验点测试的例子。本文中被测试程序是RationalDataArchitect 6.1。RFT的版本是6.1.1.1。
问题 1给定了当前如图 1 所示的PropertiesView,请校验Name字段的值是否是预期的“DB_LARGE1”。
图 1: 被测试的面板
为了解答这个简单的问题,首先需要抓取Name文本框对应的测试对象,我们把它命名为testDb,如图2的tExplorer所示。然后可以通过如下代码进行校验。之所以称这种校验的方法为静态校验点测试,是因为校验的代码是被硬编码到源文件中的,如果要增加或者修改任何一个被校验的对象,都需要大幅度修改源程序的对应位置和维护tExplorer,并且还需要重新编译才能得到结果。
图 2: 抓取测试对象testDb
public void testMaint args
String expect=TESTDB;
booleanresult=expect.equalstestDb.getPropertytext.toString;//判断字符串是否等于预期值
String context=The value of textfield =+expect;
RationalTestt.logTestResultcontext,result;//输出测试的结果
批量控件校验的挑战
问题2请校验图1的面板中的连续8个文本控件的值是否都等于预期值,它们的预期值依次为DB_LARGE1,,LARGE,DATABASE_MANAGED,32,32,12.67,0.18。
毫无疑问,问题2也完全可以使用静态的方法予以实现。但是,要注意到在上面的静态校验点测试中,预期值、被测试对象、和校验过程都同时出现在代码中。如果继续用传统的方法来处理问题2,那么很有可能面临至少两方面的问题。首先,传统方法无法管理较多的预期值,预期值只能硬编码在文件中,而且只能编译前进行修改;其次,所有的被测试控件都必须提前被抓取到tExplorer中,维护的成本是比较高的,一旦被测试对象有所改变,tExplorer就需要重新维护。
这两点的局限性实际上就是代码的耦合太强的表现,当不同功能的代码都混在一个类中,类的功能界限会趋于模糊。这样的编写思路不管是从功能还是逻辑上来讲,都不能称之为好的设计和实现。所以我们尝试用一个全新的动态的方法来解答问题2。