测试数据的管理最好能够将测试数据和测试用例代码分离，这样同样一份测试用例代码可以搭配 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 自动化测试实施成功的可能性。 |
