摘要: 本文首先列举了 Dojo 应用 UI 自动化测试所面临的挑战，进而引出设计 Dojo 应用 UI 自动化测试的框架时应考虑的一些原则。对于正从事 Web UI 自动化测试工作的读者（即便所测试的应用不是 Dojo 应用）或者对这方 ...
Dojo 应用 UI 自动化测试框架挑选（设计）原则 讲解完了所有的挑战，让我们来看看当我们要设计或者选取一个 Dojo 应用 UI 自动化测试框架时需要考虑的因素和原则。 概括起来，主要有以下八大原则。括号内是该原则所对应解决的挑战。 隐式等待（A） 位置关系操作（B，E） 封装 Dojo 小部件 （C，D，F） IBM 框架 （E） 代码生成（D） 测试数据的管理（D） 录制与编码 （D） 接下来，我们一一来讲解每一条原则。为了帮助读者理解，讲解过程中会引用内部自行开发的 Dojo 应用 UI 自动化测试框架 Water Bear 的部分内容。 隐式等待 挑战 A 提到了异步请求处理的问题也描述了几种解决方案，但都不甚理想。最理想的情况是自动化测试框架能够自己处理异步请求的问题，并且不需要开发者编写任何代码。这就是所谓的“隐式等待”机制。 目前，不少 Web UI 自动化测试框架都具备“隐式等待”功能，比如 Sahi 和 Selenium。Water Bear 使用的是 Sahi。当然，Sahi 同时也提供了对“硬编码等待时间”和“基于条件的等待”的 API 支持（因为，有些情况下还是不得不使用“硬编码等待时间”或“基于条件的等待”）。根据经验，超过 90%的情形是 Sahi 的“隐式等待”功能可以覆盖的，但是像“进度条”这样的功能就不得不用“基于条件的等待”。在进度条达到 100%之前，前端代码不断地向后台发起 Ajax 请求轮询进度状态。这种情形，Sahi 无法智能地得知哪一个 Ajax 请求的返回是“最后一个”，因此，就无法决定何时可以执行下一个动作。 清单 1. “进度条”代码示例 BrowserCondition cond = new BrowserCondition(getBrowser()) { public boolean test() throws ExecutionException { return getBrowser().isVisible(getBrowser().div("100%").in(es)); } }; getBrowser().waitFor(cond, waitTime); 清单 1 展示了 Water Bear 中部分实现进度条功能的代码，也就是 Sahi“基于条件的等待”的代码。在 test 方法返回“真”之前（也就是代码发现文本“100%”出现了），waitFor 方法一直处于轮询状态。waitTime 是一个超时时间。如果这个时间达到了，即便 test 方法仍然返回“假”，waitFor 还是返回。通常，这时已经可以认定 Web UI 的功能执行出现了问题。 只所以把“隐式等待”放在第一个来讲，是因为 Web UI 自动化测试框架是否具备该功能对于 Dojo 应用 UI 自动化测试实施成败是至关重要的。 位置关系操作 Dojo 应用 UI 自动化测试框架应当具备根据给定对象定位其他对象的功能。这种相对的位置关系通常包括：在里面、在附近、在左面（右面）以及在上面（下面）等等。目前，Sahi 支持所有这些位置关系查找，另外还支持“在上面或者下面”以及“在左面或者右面”。这当中，“在里面”使用的最为频繁。 为什么要使用位置关系操作？有以下几个原因： 准确定位页面对象。在挑战 D 中，我们提到了在一个 DOM 树中有可能存在与要查找的对象属性与 DOM 结构完全相同的对象。尤其对于“确定”或者“取消”按钮，这种情况很常见。这时，必须要通过限定父对象来缩小查找范围。一般来讲，只要限制到当前页面的边界元素能够阻止跨页面 DOM 节点查找就够了（因为，当前页面有哪些对象一目了然，但是其他页面的 DOM 节点是由运行时的操作控制的，无法预料）。 封装 Dojo 小部件。这一点会在下面具体讲解。 提供更丰富的查找方式，如根据“标签”查找 Dojo 小部件。通常，文本框的左侧会有一个文本，比如“名称：”。如果，该文本框没有任何其他合适的静态属性用来定位，就可以通过“在附近”查找的方法，先定位“名称：”所在的元素，再找到这个文本框。 当 DOM 树结构未发生“功能性”变化时，避免自动化测试代码改动。所谓“功能性”变化是指页面上增加、替换或者移除了控件，比如按钮或者输入框等。当发生这些变化时，自动化测试代码不得不修改。但，如果发生的仅仅是 DOM 树结构上的变化，比如增加了不可见的 DIV 或者 SPAN 元素，只要位置关系操作使用得当，自动化测试代码可以做到不需要修改。 我们来看一个例子。图 2 左边是所测应用现在的状态：一个 Dojo 按钮小部件被一个 DIV 元素包围。在代码中，我们用按钮的文本“OK”并限制在图示的 DIV 中来定位它。之后，DOM 树结构发生了变化，变成了图 2 右边的样子，在原有的 DIV 元素和按钮之间增加了两层 DIV 元素。此时，代码不需要更改，因为这个“OK”按钮仍然在之前的 DIV 元素里。但是，如果用 XPath 定位元素，这种情况就很有可能要修改了。 图 2. 位置关系操作示例 封装 Dojo 小部件 在挑战 C 中，提到了 Dojo 小部件 DOM 结构的复杂性。最好的方式是封装 Dojo 小部件，将每个 Dojo 小部件作为一个整体操作。 Water Bear 使用的编程语言是 Java。它将页面中的 Dojo 小部件映射成一个 Java 类，以此封装所有该 Dojo 小部件的行为。由于 Sahi 支持“在里面”的位置关系操作，使得封装更加容易 ? 只需要定位到 Dojo 小部件的最外层 HTMl 元素（一般是 DIV），其他的元素定位都限制在该元素之内。从而，即便页面上同时有两个同类型的 Dojo 小部件，也不会出现跨部件的错误操作。 图 3 展示了 Water Bear 中定义的与 Dojo 小部件对应的一些类。最上层父类 WebElement.java 代表一般的 HTML 元素，它封装了基本 HTML 元素的方法。DojoWidget.java 是所有 Dojo 小部件类的抽象。它定义了所有 Dojo 小部件类的通用方法，比如 getWidgetId()等。所有 Dojo 小部件类均继承自 DojoWidget.java 并定义自己的方法，比如 ComboBox.java 需要定义 selectByText 方法。  图 3. Water Bear 中与 Dojo 小部件对应的类 那么，页面上 Dojo 小部件如何和这些类对应关联起来呢？Water Bear 中通过.wdef 文件把两者关联起来。 |
