批量控件校验的挑战

        [问题 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 全面地对比了两种不同的校验方法的差异。