摘要: 本文首先列举了 Dojo 应用 UI 自动化测试所面临的挑战，进而引出设计 Dojo 应用 UI 自动化测试的框架时应考虑的一些原则。对于正从事 Web UI 自动化测试工作的读者（即便所测试的应用不是 Dojo 应用）或者对这方 ...
| 本文首先列举了 Dojo 应用 UI 自动化测试所面临的挑战，进而引出设计 Dojo 应用 UI 自动化测试的框架时应考虑的一些原则。对于正从事 Web UI 自动化测试工作的读者（即便所测试的应用不是 Dojo 应用）或者对这方面感兴趣的读者，本文都有一定的参考价值。 随着富 Internet 应用（RIA）的不断兴起，各种 JavaScript 开发工具包的功能也在不断增强，Dojo 正是其中的佼佼者。Dojo 提供了一套完整的开发解决方案，包括核心的 JavaScript 库、简单易用的小部件（Widget）等。当越来越多的企业 Web 应用选择 Dojo 作为前端技术框架的时候，作为测试人员，我们便需要考虑如何有效地进行自动化测试开发与实施。Dojo 是一个 Web 前端技术框架，所以这里所说的自动化测试，具体是指 Web UI 自动化测试，更进一步说是 Web 2.0 UI 自动化测试。 考虑到 Web UI 的特性以及 Web UI 自动化测试的投入产出比（ROI），关于是否应该进行 Web UI 自动化测试，测试领域存在不同的观点。我个人认为还是有必要的。不过这不是本文要讨论的重点。决定 Web UI 自动化测试成败（或者说收效）的因素有很多，技术框架的选取和设计是其中之一，个人认为也是比较重要的一个因素。本文将从 Dojo 应用 UI 自动化测试面临的诸多挑战谈起，进而讨论针对 Dojo 应用 UI 自动化测试的框架适用的设计原则。 虽然本文探讨的主题是 Dojo 应用的 UI 自动化测试，但不少内容也适合其他的 Web 2.0 应用。希望读者朋友或多或少都能从中获益。 Dojo 是什么？ Dojo 是一个 JavaScript 实现的开源 DHTML 工具包。它是在几个项目捐助基础上建立起来的(nWidgets，f(m)，Burstlib) 。 Dojo 的最初目标是解决开发 DHTML 应用程序遇到的一些长期存在的历史问题，现在，Dojo 已经成为了开发 RIA 应用程序的利器： Dojo 让您更容易地为 Web 页面添加动态能力，您也可以在其它支持 JavaScript 的环境中使用 Dojo ； 利用 Dojo 提供的组件，您可以提升 Web 应用程序的可用性和交互能力； Dojo 很大程度上屏蔽了浏览器之间的差异性，因此，您可以不用担心 Web 页面是否在某些浏览器中可用； 通过 Dojo 提供的工具，您还可以为代码编写命令行式的单元测试代码。 Dojo 的打包工具可以帮助您优化 JavaScript 代码，并且只生成部署应用程序所需的最小 Dojo 包集合。 Dojo 应用 UI 自动化测试面临的挑战 Dojo 应用 UI 自动化测试面临的挑战可以归为两类：开发阶段的挑战和维护阶段的挑战。 开发阶段的挑战： 异步请求的处理 元素定位 Dojo 复杂性 产品复杂性 维护阶段的挑战： 频繁的 UI 更改 Dojo 升级 下面，我们具体讲解每一种挑战。为了后文讲解设计原则时能方便的对应到这些挑战，我们用英文字母标记每个挑战。 A. 异步请求的处理 在传统的 Web 应用中，用户每点击页面上的超链，浏览器就会向服务器发出一个请求，等待服务器做出响应，然后返回一个完整新网页，但在大多数情况下用户不得不忍受页面闪烁和长时间的等待。为了解决传统的 Web 应用中出现的问题，出现了 Ajax。通过使用 Ajax 页面和应用向服务器请求它们真正需要的东西，也就是页面中需要修改的部分，服务器就提供哪部分，这使得通信量更少，更新更少，用户等待页面刷新更短，用户更加满意。 但是，Ajax 的到来对 Web UI 自动化测试却未必是好消息。Web UI 自动化测试框架的执行方式类似于一个“队列”:用户定义了一系列的页面操作和验证，之后 Web UI 自动测试框架把它们按顺序一一执行。在传统 Web 应用中，由于每次向服务器端发起请求都会导致页面跳转，Web UI 自动化测试框架能很容易地判断出合适该执行下一个动作。 但是，Ajax 的行为是异步的，也就是说，用户的操作跟服务器端的处理现可以是并行的，不存在严格的顺序。起初，这给 Web UI 自动化测试框架的开发者带来了困扰，而且很长一段时间里这个问题都没有被很好的解决。 起初，Web UI 自动化测试开发人员主要有两种解决方案：硬编码等待时间和基于条件的等待。 硬编码等待时间： 这种方式是指在代码中指定一个静态等待时间，比如指定等待 30 秒后执行下一个操作。通常，这种数值的设置来源于经验。可以想象，如果这个等待时间比实际等待时间小，自动化脚本执行就会失败。而且，不幸的是，这样情况的确经常发生。随着测试环境的变化，实际需要的等待时间事实上是一个变量。以下几个因素都有可能导致它发生变化： 测试服务器在远程还是本地：毫无以为，由于网络的影响，服务器如果在远程，等待时间就会增加。 使用的浏览器： 浏览器 JavaScript 引擎的执行速度对等待时间也有影响。根据经验， Firefox 和 Chrome 都比 IE 要快。因此，如果用的是 IE，等待时间也会增加。 |
