摘要: 本文首先列举了 Dojo 应用 UI 自动化测试所面临的挑战，进而引出设计 Dojo 应用 UI 自动化测试的框架时应考虑的一些原则。对于正从事 Web UI 自动化测试工作的读者（即便所测试的应用不是 Dojo 应用）或者对这方 ...
测试运行时的网络环境：如果测试时的网速较慢，等待时间会增加。 测试服务器的负载：测试服务器可能是独占也可能是共享的。如果自动化测试执行时的服务器负载较大，也会导致等待时间增加。 对于上述硬编码等待时间的问题，Web UI 自动化测试开发人员一般有如下对策。 尽量将等待时间设置的大一些。这样做存在一些问题。一来未必能保证在任何情况下该值都足够大；二来它意味着无论服务器在本地还是远程浏览器是快是慢，执行时间都一样，这对于服务器在本地以及浏览器比较快的测试环境是很大的时间成本浪费。 设置放大因子。这种方法是在编码的时候给等待时间乘上一个因子。这个因子或者是硬编码的，比如定义在一个参数文件中。当测试环境比较好的时候，设置小一点；测试环境比较差的时候，设置大一点。 高级一些的，可以动态地设置这个因子。比如，可以把某一个操作的执行时间作为计算该因子数值的参照。这个方法使情况得到了部分改善，但是仍然不能保持其执行的稳定性。 基于条件的等待： 由于硬编码等待时间方式的不稳定性，Web UI 自动化测试框架开始支持“基于条件的等待”。这种方式是采用“轮询”的机制判断是否可以开始执行一个操作。假设，当前要执行的操作是一个按钮点击动作。这个按钮默认是被禁用的，当页面从服务器端加载了数据之后这个按钮才被启用。因此，如果要保证这个操作成功，就需要“轮询”这个按钮的状态 ? 直到发现它被启用了，才执行点击操作。 如果由于存在 bug 按钮一直不启用怎么办？所以，基于条件的等待的方法需要设置“超时时间”。如果超过这个时间按钮还没有启用，就认为这个测试用例失败了。所以，大家发现了，这个超时时间的设置其实还是个“硬编码等待时间”，所以某种程度上，这种方式仍存在硬编码等待时间方式的弊端。这种方式的另外一弊端是它带来了额外的编码成本，并且自动化测试代码中可能充斥了许多条件判断代码，而它们本身不完成我们的“业务”目标，仅是辅助代码。 B. 元素定位 一般的 Web UI 自动化测试编码无非包含这样几个步骤：定位及获取元素，执行操作以及验证结果。而且，通常 Web UI 自动化测试开发人员在元素定位和获取这个步骤上花费相当多的时间。大多数 Web UI 自动化测试开发人员希望所需获得的元素能有一个静态 id 属性。根据规范，id 属性的值在 DOM 树中必须是唯一的，因此通过 id 属性就可以很简单并且准确地定位元素。但是，这样的需求常常不是产品的需求，而只是为了满足 Web UI 自动化测试代码开发的简便。所以，对于产品开发人员来说，给每个需要在 Web UI 自动化测试中使用到的元素增加静态 id 属性不是高优先级的工作。而且，从技术角度上讲，有些 Dojo 应用中的元素也无法设置静态 id 属性。 对于 Dojo 应用，情况又复杂了一些。图 1 展示的是一个 Dojo 按钮小部件在 Firebug 中呈现的 DOM 结构。最外层的 SPAN 元素上有一个 widgetid 属性，内部的 SPAN 元素上定义了 id 属性，共同点是它们都是由一个前缀和一个动态的数字构成的。这个数字是由运行时该 Dojo 小部件在整个 DOM 树上的位置决定的，索引从 0 开始。因此可知，图 1 中的按钮小部件是整个 DOM 树上的第二个按钮。Widgetid 是每个 Dojo 小部件都有的属性，如没有特别指定的话，它就是如图中所示的动态结构。 所以，如何通过这种动态格式的 id 和 widgetid 定位获取页面中的元素成为另一个 Dojo 应用 UI 自动化测试开发的挑战。 图 1. Dojo 按钮小部件 C. Dojo 复杂性 读者不要误会，这里说的“Dojo 复杂性”不是说 Dojo 使用起来很复杂，而是说 Dojo 应用最后生成的页面 DOM 结构比较复杂。如图 1 所示，原本用一个 INPUT 元素实现的按钮，现在嵌套了四层 SPAN 元素。 所以，Dojo 小部件已不再是一个简单的 HTML 元素，而是由诸多 HTML 元素组合而成的。Dojo 按钮小部件只是一个简单的例子，对于像表格、日历之类的 Dojo 小部件，它们的结构更加复杂。针对某个 Dojo 小部件的操作也不再像操作普通的 HMTL 元素那样简单（调用某个 JavaScript 方法就可以实现），而是要具体定位响应事件（比如点击事件）的 Dojo 小部件的内部对应元素，然后触发具体的事件。 多数的 Web UI 自动化测试框架只能处理基本的 HTML 元素。这是合理的，因为框架开发者不知道最终的自动化测试开发者使用什么样的前段框架，因而只能提供最基本的“小砖块”。如果具体应用的自动化测试开发者有任何需求，可以在其之上进行二次开发。 对于 Dojo 应用的 UI 自动化测试开发者来说，可以选择直接定位和操作 Dojo 小部件内部元素的方法。但是，这样做的弊端很明显 ? 缺乏重用性。 因此，应该将 Dojo 小部件作为最小操作单元。如何将 Dojo 小部件模块化成为了又一个挑战。 D. 产品复杂性 产品复杂性包含两层意思。 一是指产品本身页面层次多，界面元素多以及功能逻辑复杂。Web UI 自动化测试开发过程中，编写定位元素的代码通常占据很大一部分时间，编写这部分代码的工作量直接受页面元素多少的影响。功能复杂度一般不太会直线性增加编码工作量，但是有可能会增加调试的工作量。 二是指产品页面 DOM 结构复杂。Web 2.0 应用的开发模式与传统 Web 应用的开发模式有很大的不同。传统 Web 应用开发基本上是一个页面对应一个物理的程序文件（比如，.jsp 文件）。而 Web 2.0 应用的开发通常是整个应用只有少数几个物理的程序文件，页面的跳转和呈现通过 JavaScript 更新 DOM 树结构完成。所以，在浏览器中的跳转页面实际上往往只是 DOM 树结构被更新了。这样，就有可能带来这样一个问题：DOM 树上同时存在多个页面的 DOM 子节点。如果其他页面有与当前要定位的元素类似的元素，就很容易出现“错误定位”。 如何能在产品变得越来越复杂的同时，尽可能的减少开发工作量，也是一个 Dojo 应用 UI 自动化测试开发者要解决的问题。 E. 频繁的 UI 更改 频繁的 UI 更改在“敏捷开发”大行其道之后成为了又一个让 Web UI 自动化测试开发者头痛的问题。迭代中的产品 UI 经常随着客户的反馈不断地修改，于是自动化测试代码需要跟着更新。由此带来的 Web UI 自动化测试脚本巨大的维护工作量也成为了很多人反对进行 Web UI 自动化测试的重要原因之一。 难道，因此就放弃 Web UI 自动化测试吗？我认为，作为 Web UI 自动化测试开发者需要考虑的应该是：在这样的现实之下，如何能够最小化频繁的 UI 更改带来的代码维护工作量。从经验来看，并非 Web UI 上的任何一点点更改都会导致自动化测试代码的修改。这个问题的解决极大程度上依赖于测试框架适应 DOM 结构变化的能力以及元素定位时所使用的方法。 F. Dojo 升级 Dojo 升级有可能会引发 Dojo 小部件 DOM 结构的变化，继而带来自动化测试代码的维护工作量增加。尽管根据经验，这一点的影响不是很显著，因为目前一些常见的 Dojo 小部件（比如按钮输入框之类）都已经十分成熟，但是还是需要考虑。如果一个小部件的 DOM 结构发生了变化，如何能够最小化对自动化测试代码的影响？这是 Dojo 应用 UI 自动化测试开发者要考虑的问题。 |
