清单 2. .wdef 文件示例
org.waterbear.core.widgets.dijit.Textbox=div|textbox|labelnear|dijit_form_ValidationTextBox,\
evo_form_ObjectNameTextBox,dijit_form_NumberTextBox,dijit_form_TextBox,aspen_config_directory_DNTextBox
org.waterbear.core.widgets.dijit.Checkbox=div|checkbox|labelnear|dijit_form_CheckBox
org.waterbear.core.widgets.dijit.Select=table|table|labelnear|dijit_form_Select
org.waterbear.core.widgets.dijit.Button=span|span|labelinside|dijit_form_Button
org.waterbear.core.widgets.dijit.ComboBox=div|textbox|labelnear|dijit_form_ComboBox
清单 2 展示了.wdef 文件的部分内容。它是一纯文本文件，每一行定义了一组映射关系。等号左边是 Dojo 小部件映射的 Java 类名，等号右边是页面上 Dojo 小部件的属性描述。其中，起关键作用的是是最后一个属性，它是 widgetid 的前缀部分。一个 Dojo 小部件类可以关联到多种页面 Dojo 小部件，因为有些 Dojo 小部件虽然被扩展了，但是对 Web UI 自动化测试来说扩展的功能不会被涉及到，于是可以用同一个类表示。
IBM 框架
IBM 框架以前被称作为 ITCL 框架，由质量软件工程（Quality Software Engineering） 和 IBM 中有经验的自动化团队合作开发而成的。这个框架由三层架构组成，架构的实现贯穿了应用对象、任务和测试用例包（IBM 包）。
潜在于应用对象、任务和测试用例包之下的基本原理是：
层次化的体系架构
将“做什么”与“如何做”分离开来
代码重用
一致和清晰的组织结构
快速增强的能力
迅速的调试
有效地组织文件
启用协作
学习他人
下面是对应用对象、任务和测试用例的解释说明：
应用对象：储存有关你的应用程序中的 GUI 元素信息。同时在这里也可以编写你的 Getter 方法，这些 Getter 方法可以返回对象，使调用者能够对这些 GUI 元素进行查询和操作。一般情况下，这些方法在 Task 层中进行调用。
任务：在这里你将编写可重用的方法，这些方法在你的应用程序中执行通用功能。同时在这里，你将编写可以处理和查询复杂的特定应用程序控件的方法。在任务中的方法可以被测试用例调用。
测试用例：导航一个应用程序，验证其状态，并记录其结果的方法。
这个理念应用到 Java 编程就是用不同“包”组织应用对象、任务和测试用例的类。无论具体的底层 Web UI 自动化测试框架是什么，用 IBM 框架的理念来架构上层测试用例的类都是有帮助的。 采用 IBM 框架能够有效地应对挑战 E，因为高重用性能够将代码改动控制在局部范围，并且一处改动即可纠正所有引用的代码。除了采用 IBM 框架，实际上如何合理地规划任务方法的粒度也很关键。但，这与具体应用就十分相关了。
代码生成
一般来说，编写用来获取界面元素的代码（也就是应用对象层的代码）在整个开发工作量中占据很大的比例。通常，它需要开发者先借助一些能够显示 DOM 树结构的工具（比如 Firebug）观察元素的属性，然后决定用什么属性来定位元素比较合适。 另外，一些代码又是比较“机械”或者模式化的，例如给界面元素赋值的操作。这样的代码应尽可能的通过一些自动化的方式生成，就可大大节省开发的时间。
在 Water Bear 中，针对以上的两个问题，分别开发了两种代码生成工具。
一个工具叫 AppObjs CodeGen，它可以自动遍历当前的 DOM 树，从而生成应用对象层的代码。它用 Sahi 脚本实现，将结果输出在它的日志窗口中(如图 4)。 开发者将代码复制到自己的类文件中即可。尽管这些代码仍可能需要一些手工修改，比如重命名以增强方法的可读性，但较之完全用手工编码已节省很多时间。
图 4. AppObjs CodeGen 生成结果
第二个工具叫 Skeleton CodeGen。 它的输入是应用对象层的类，输出是任务和测试用例层的部分代码。对于符合特定模式的以及界面有很多 UI 控件的 Dojo 应用，这个工具比较有效。生成代码仍需要二次修改，因为有些逻辑无法自动生成。
测试数据的管理
最好能够将测试数据和测试用例代码分离，这样同样一份测试用例代码可以搭配 N 种不同的测试数据运行。另外，这种分离也可以轻松地做到为不同的测试环境定义不同的测试数据 – 有时候，一些测试数据是有环境依赖的。
Water Bear 利用开源软件 XStream 来实现测试数据与测试用例代码的分离。首先，测试数据被定义在一个 HashMap 中。测试用例在第一次运行时会将 HashMap 通过 XStream 自动序列化成一个.xml 文件。当自动化脚本再次运行时，如果.xml 文件已经存在，它就直接读取已有文件并借助 XStream 把文件内容反序列化成 HashMap。在之后的运行中，只要 HashMap 的数据结构没有变化，就无需重新生成.xml 文件。数据文件的存放目录可以通过配置文件指定，因此对于不同的环境只要修改配置文件指向不同的路径即可。
录制与编码
提高开发效率的另一个途径是提供录制功能。但是录制功能通常有如下一些问题：
录制生成的代码通常是“过程化”的。“过程化”的代码很难重用。即便是针对同一个页面功能模块录制的不同的测试用例代码也是孤立的。如果页面功能发生变化，所有测试用例需要重新录制。因此，表面上看录制功能似乎大大减少了开发时间，但是当页面发生变化的时候，它或许未必如我们想象的那么好。
录制的代码可读性通常比较差。一般来说，录制之后仍需要重命名变量以提高代码可读性。
所以，理想中的录制功能生成的代码应该是模块化的，也就是按照应用对象、任务和测试用例这三个层次生成。这样的代码即便于二次修改，也便于与已有代码集成。从使用的角度看，所有的测试用例代码完全用录制功能生成不太现实，较好的方式是只用录制功能辅助开发应用对象层和任务层代码。 当 UI 发生非功能性变化时，只需要重新录制受影响的任务方法并更新应用对象层。理论上，测试用例层不需要修改（除非测试用例的逻辑不得不修改）。
Water Bear 目前仅支持“过程化”录制功能。图 5 展示的就是 Water Bear Recorder 生成的代码。开发者把生成的代码复制黏贴到自己的测试类中即可在 Water Bear 中直接运行。
图 5. Water Bear Recorder
结束语
本文首先列举了 Dojo 应用 UI 自动化测试面临的诸多挑战，之后从这些挑战入手，结合个人的开发经验以及一个内部使用的 Dojo 应用 UI 自动化测试框架，提出了八个在选取和设计 Dojo 应用 UI 自动化测试框架时需要考虑的原则。当然，每一点的重要性不尽相同。比如“隐式等待”是必须的，而录制功能却没有那么重要。但是，若是这些原则都能符合，将大大提高 Dojo 应用 UI 自动化测试实施成功的可能性。
