前不久，InfoQ 向大家推荐了几本有关软件架构的新书，引起了国内读者的广泛兴趣。其中一本是《开源应用架构（The Architecture of Open Source Applications）》，来自知名开源项目的各位作者对软件的设计进行了说明。通过对这些成功的系统架构进行概览，让软件工程师可以彻底了解最佳实践和陷阱。InfoQ 中文站响应读者的需求，整理了该书有关知名开源软件架构的精彩内容，供国内开发社区借鉴。本期介绍的是著名浏览器自动化工具Selenium WebDriver 的软件架构，第一部分主要分享了Selenium WebDriver 的演变历史和架构观点。
Selenium 是一个浏览器自动化工具，通常用来编写Web 应用的端到端测试。浏览器自动化工具准确执行你所期望的行为：自动化浏览器的某个控件，从而可以自动重复执行任务。这听起来像是一个很容易解决的问题，但是正如我们即将看到的那样，其实 Selenium 成功的背后凝聚了大量的工作。
介绍 Selenium WebDriver 软件架构的技术专家是来自 Google 的 Simon Stewart ，他是 Selenium 的核心贡献者和 Selenium WebDriver 的创建者。
Simon Stewart 首先谈起了 Selenium 的组成部分：
在介绍 Selenium 架构之前，最好先了解一下该项目的各个相关组成部分是如何结合在一起的。从较高的层次看，Selenium 由三种工具组成。第一个工具 Selenium IDE，是 Firefox 的扩展插件，支持用户录制和回访测试。录制 / 回访模式存在局限性，对许多用户来说并不适合，因此第二个工具——Selenium WebDriver 提供了各种语言环境的 API 来支持更多控制权和编写符合标准软件开发实践的应用程序。最后一个工具——Selenium Grid 帮助工程师使用 Selenium API 控制分布在一系列机器上的浏览器实例，支持并发运行更多测试。在项目内部，它们分别被称为“IDE”、“WebDriver”和“Grid”。
追根溯源，Selenium 和 WebDriver 最初是两个独立的项目，Simon Stewart解释了发展的历史：
Jason Huggins 在 2004 年发起了 Selenium 项目，当时他在 ThoughtWorks 公司开发内部的时间和费用（Time and Expenses）系统，该应用使用了大量的 JavaScript。虽然 Internet Explorer 在当时是主流浏览器，但是 ThoughtWorks 还使用一些其他浏览器（特别是 Mozilla 系列），当员工在自己的浏览器中无法正常运行 T&E 系统时就会提交 bug 报告。当时的开源测试工具要么关注单一浏览器（通常是 IE），要么是模拟浏览器（如 HttpUnit）。购买商业工具授权的成本会耗尽这个小型内部项目的有限预算，所以它们都不是可行的测试选项。
在自动化困难的情况下，通常会依靠手动测试。当开发团队规模很小或者构建发布非常频繁时，这种方式不太适用。同时，让人手动执行原本可以自动化的脚本也是一种对人力的浪费。沉闷重复的任务越无聊，人们工作就会越慢而且比机器犯更多错误。手动测试也不是一种选择。
幸运的是，所有被测试的浏览器都支持 Javascript。Jason 和他所在的团队有理由采用 Javascript 编写一种测试工具来验证应用的行为。他们受到 FIT（ Framework for Integrated Test ）的启发，使用基于表格的语法替代了原始的 Javascript，这种做法支持那些编程经验有限的人在 HTML 文件中使用关键字驱动的方式来编写测试。该工具，最初称为“Selenium”，后来称为“Selenium Core”，在 2004 年基于 Apache 2 授权发布。
Selenium 的表格格式类似于 FIT 的ActionFixture。表格的每一行分为三列。第一列给出了要执行的命令名称，第二列通常包含元素标记符，第三列包含一个可选值。例如，如下格式表示了如何在名称为“q”的元素中输入字符串“Selenium WebDriver”：
type name=q Selenium WebDriver
因为 Selenium 过去使用纯 JavaScript 编写，它的最初设计要求开发人员把准备测试的应用和 Selenium Core、测试脚本部署到同一台服务器上以避免触犯浏览器的安全规则和 JavaScript 沙箱策略。在实际开发中，这种要求并不总是可行。更糟的是，虽然开发人员的 IDE 能够帮助他们快速处理代码和浏览庞大的代码库，但是没有针对 HTML 的相关工具。人们很快意识到维护一个中等规模的测试集是笨拙而痛苦的过程。
为了解决这个问题和其他问题，我们编写了 HTTP 代理，这样所有的 HTTP 请求都会被 Selenium 截获。使用代理可以绕过“同源”规则（浏览器不支持 Javascript 调用任何当前页面所在服务器以外的其他任何东西）的许多限制，从而缓解了首要弱点。这种设计使得采用多种语言编写 Selenium 绑定成为可能：它们只需把 HTTP 请求发送到特定 URL。连接方法基于 Selenium Core 的表格语法严格建模，称之为“Selenese”。因为语言绑定在远程控制浏览器，所以该工具称为“Selenium Remote Control”或者“Selenium RC”。
就在 Selenium 处于开发阶段的同时，另一款浏览器自动化框架 WebDriver 也正在 ThoughtWorks 公司的酝酿之中。WebDriver 的最初代码在 2007 年初发布。WebDriver 项目的初衷是把端对端测试与底层测试工具隔离开。通常情况下，这种隔离手段通过适配器（Adapter）模式完成。WebDriver 正是来源于该方法在许多项目上的不断实践应用，最初是 HtmlUnit 的封装，工具发布后很快开始支持 Internet Explorer 和 Firefox。
在 WebDriver 最初发布时，与 Selenium RC 存在显著差异，尽管它们都属于浏览器自动化的 API 工具。对于用户来说，最明显的区别在于 Selenium RC 提供基于字典的 API，所有方法都在一个类中开放，而 WebDriver 的 API 更面向对象。此外，WebDriver 仅支持 Java，而 Selenium RC 提供广泛的语言支持。技术差异也很明显：Selenium Core（RC 的基础）基本上是 JavaScript 应用，运行在浏览器的安全沙箱之内。WebDriver 则尝试原生绑定到浏览器中，绕开了浏览器的安全模型，代价就是框架自身的开发投入显著增加。
在 2009 年 8 月，两个项目宣布合并，Selenium WebDriver 就是合并的成果。目前，WebDriver 支持的语言绑定包括 Java、C#、Python 和 Ruby。它支持 Chrome、Firefox、Opera 和 Android、iPhone 浏览器。此外，还有其他关联项目，不在同一源代码库中维护，但是和主项目（Selenium WebDriver）紧密合作，例如提供 Perl 绑定支持、BlackBerry 浏览器支持，以及“无头”WebKit——用于持续集成的测试其无法正常显示的情况。最初的 Selenium RC 机制仍然维持，帮助 WebDriver 在浏览器不受支持的情况下提供支持。
Simon Stewart 在介绍 Selenium WebDriver 软件架构之前，谈到了架构和项目开发的重要主题。概括如下：
- 保持成本低廉。
- 模拟用户。
- 证明 dirver 运行良好…
- …但是你无需了解一切细节
- 降低巴士因素（bus factor）。
- 偏爱 JavaScript 实现。
- 所有方法调用都是 RPC 调用。
- 我们是开源项目。
具体来说：
保持成本低廉
在 Y 平台上支持 X 浏览器本质上是一种昂贵的提议，无论是从开发还是维护角度考虑。如果我们能够找到办法维持产品的高品质而又不违背太多其他原则，那么就值得采纳。这种思想最明显的体现在我们尽可能得使用 JavaScript 编程，你稍后会看到。
模拟用户
WebDriver 的设计目的是为了准确模拟用户与 Web 应用交互的方式。模拟用户输入的常用办法是利用 Javascript 合并和触发一系列事件（如果真实用户执行相同交互操作，应用会处理同样的事件）。“合成事件”（synthesized events）方法在面对不同浏览器、有时相同浏览器的不同版本时存在不少困难，触发的事件和相关值略有不同。为了不让问题复杂化，大多数浏览器处于安全原因不允许用户通过这种方式与表单元素（如文件输入元素）交互。
WebDriver 总是尽可能的使用在操作系统层面触发事件的方法。因为这些“原生事件”不是由浏览器生成，所以这种方法避免了合成事件导致的安全限制，同时，因为它们是特定于具体操作系统的，一旦在某个平台上的浏览器运行良好，在另一种浏览器上重用代码相对容易些。困难的是，这种方法必须满足两点才可行：WebDriver 与浏览器紧密绑定，同时开发团队在无需浏览器窗口获得焦点的情况下发送原生事件（因为 Selenium 测试运行时间较长，最好能支持同时在机器上执行其他任务）。目前，原生事件可用于 Linux、Windows 平台，不包括 Mac OS X。
不管 WebDriver 如何模拟用户输入，我们都在努力尽可能地模仿用户行为。RC 刚好相反，它提供的 API 层次远低于用户操作。
证明 Driver 运行良好
想让事情十全十美（motherhood and apple pie）可能过于理想化了，但是我相信编写无法运行的代码是没有意义的。证明 driver（指的是 WebDriver API 的特定实现。例如，Firefox 和 Internet Explorer 各有自己的 driver 实现）在 Selenium 项目中运行良好的办法是我们拥有一套广泛的自动化测试用例。这些通常是“集成测试”，需要编译代码并使用浏览器与 Web 服务器交互，但是我们尽可能地编写“单元测试”，它不像集成测试，无需完全重新编译即可运行。目前，大约有 500 个集成测试和 250 个单元测试，涵盖所有浏览器。我们在修补缺陷和编写新代码时会增加测试，我们的重点正转移到编写更多的单元测试。
并非所有测试都要运行于每一个浏览器上。其中一些测试用于某些浏览器不支持的特定功能，或者在不同浏览器上处理方式不同的功能。例如，某些测试用于新的 HTML5 功能，这些功能并非所有浏览器都支持。尽管如此，每一个主流的浏览器都进行了充分的测试。可以想象，在不同平台上针对每种浏览器运行超过 500 个测试是一种极大的挑战，我们一直在努力面对。
你无需了解一切细节
很少有开发人员精通各种语言和技术。因此，我们的架构需要帮助开发人员把他们的才华用于最擅长的地方，而无需处理不适合他们的代码片段。
降低巴士因素
在软件开发领域存在一种（非正式的）概念，称为“巴士因素”。它指的是关键开发人员的数量，如果这些人遇到不幸——被大巴撞伤而离开项目，那么项目就无法继续进行。像浏览器自动化这样复杂的技术特别能够证明巴士因素的重要性，因此我们的许多架构决策都希望能够尽可能提高关键开发人员的数量。
偏爱 Javascript 实现
WebDiver 在没有其他方式控制浏览器的情况下会使用纯 Javascript 驱动浏览器。这意味着我们添加的所有 API 都应该倾向于偏爱 Javascript 实现。举一个具体的例子，HTML5 引入了 LocalStorage，这是在客户端存储结构化数据的 API。它通常在浏览器中使用 SQLite 实现。比较自然的实现方式是使用类似 JDBC 的技术为底层的数据存储提供数据库连接。最终，我们决定采用底层 Javascript 实现的 API，因为通常数据库访问 API 与 Javascript 实现不太兼容。
所有方法调用都是 RPC 调用
WebDriver 控制运行在其它进程中的浏览器。一个很容易忽视的事实是，这意味着所有 API 调用都是 RPC 调用，因此框架的性能在于网络延迟上。在正常操作中，这未必明显——大多数操作系统优化了到本机（localhost）的路由——但是随着浏览器和测试代码之间的网络延迟增加，对于 API 设计者和使用者来说，原本高效的调用会恶化。
这种情况给 API 的设计带来了一定压力。功能粗糙的较大规模的 API 可能会通过合并多个调用帮助减低延迟，但是这需要掌握平衡，时刻保持 API 的可读性和易用性。例如，有时候需要检测某个元素是不是对最终用户可见。我们不仅需要考虑各种 CSS 属性（可能需要通过查看父元素来推断），也应该检查元素的尺寸。最低限度情况下，API 应该分别执行所有这些检测。WebDriver 把这些功能都合并到一个方法 isDisplayed 中。
这是开源项目
虽然严格意义上说，这不是一种架构观点，但还是要强调 Selenium 是一个开源项目。上面提到的所有观点联系在一起，表达的意思是：我们希望尽可能的帮助新的开发人员易于参与项目。降低参与门槛的措施包括尽可能使所需知识浅显、使用的语言种类较少、依赖自动化测试验证。
最初该项目被划分成一系列模块，每一个模块代表了一种特定的浏览器，其他的模块是通用代码和支持代码。每一个绑定的代码树保存在这些模块下面。这种方法对于类似 Java 和 C#的语言来说非常有用，但是对于 Ruby 和 Python 的开发人员来说很痛苦。这种情况直接导致了有限的参与者，只有一小部分人参与 Python 和 Ruby 的绑定工作。为了解决这个问题，在 2010 年的十月和十一月，项目源代码被重新组织，Ruby 和 Python 代码存放在每种语言的独立顶级文件夹中。这种方式符合开源开发人员的期望，立刻吸引了社区的广泛参与。
本文的第二部分会详细介绍 Selenium WebDriver 的架构设计和实现，感兴趣的读者可以阅读本书的在线版本。
评论