开源应用架构之SeleniumWebDriver(上)

开源应用架构之SeleniumWebDriver（上）前不久，InfoQ向大家推荐了几本有关软件架构的新书，引起了国内读者的广泛兴趣。其中一本是《开源应用架构（TheArchitectureofOpenSourceApplications）》，来自知名开源项目的各位作者对软件的设计进行了说明。通过对这些成功的系统架构进行概览，让软件工程师可以彻底了解最佳实践和陷阱。InfoQ中文站响应读者的需求，整理了该书有关知名开源软件架构的精彩内容，供国内开发社区借鉴。本期介绍的是著名浏览器自动化工具SeleniumWebDriver的软件架构，第一部分主要分享了SeleniumWebDriver的演变历史和架构观点。Selenium是一个浏览器自动化工具，通常用来编写Web应用的端到端测试。浏览器自动化工具准确执行你所期望的行为：自动化浏览器的某个控件，从而可以自动重复执行任务。这听起来像是一个很容易解决的问题，但是正如我们即将看到的那样，其实Selenium成功的背后凝聚了大量的工作。介绍SeleniumWebDriver软件架构的技术专家是来自Google的SimonStewart，他是Selenium的核心贡献者和SeleniumWebDriver的创建者。SimonStewart首先谈起了Selenium的组成部分：在介绍Selenium架构之前，最好先了解一下该项目的各个相关组成部分是如何结合在一起的。从较高的层次看，Selenium由三种工具组成。第一个工具SeleniumIDE，是Firefox的扩展插件，支持用户录制和回访测试。录制/回访模式存在局限性，对许多用户来说并不适合，因此第二个工具——SeleniumWebDriver提供了各种语言环境的API来支持更多控制权和编写符合标准软件开发实践的应用程序。最后一个工具——SeleniumGrid帮助工程师使用SeleniumAPI控制分布在一系列机器上的浏览器实例，支持并发运行更多测试。在项目内部，它们分别被称为“IDE”、“WebDriver”和“Grid”。追根溯源，Selenium和WebDriver最初是两个独立的项目，SimonStewart解释了发展的历史：JasonHuggins在2004年发起了Selenium项目，当时他在ThoughtWorks公司开发内部的时间和费用（TimeandExpenses）系统，该应用使用了大量的JavaScript。虽然InternetExplorer在当时是主流浏览器，但是ThoughtWorks还使用一些其他浏览器（特别是Mozilla系列），当员工在自己的浏览器中无法正常运行T&E系统时就会提交bug报告。当时的开源测试工具要么关注单一浏览器（通常是IE），要么是模拟浏览器（如HttpUnit）。购买商业工具授权的成本会耗尽这个小型内部项目的有限预算，所以它们都不是可行的测试选项。在自动化困难的情况下，通常会依靠手动测试。当开发团队规模很小或者构建发布非常频繁时，这种方式不太适用。同时，让人手动执行原本可以自动化的脚本也是一种对人力的浪费。沉闷重复的任务越无聊，人们工作就会越慢而且比机器犯更多错误。手动测试也不是一种选择。幸运的是，所有被测试的浏览器都支持Javascript。Jason和他所在的团队有理由采用Javascript编写一种测试工具来验证应用的行为。他们受到FIT（FrameworkforIntegratedTest）的启发，使用基于表格的语法替代了原始的Javascript，这种做法支持那些编程经验有限的人在HTML文件中使用关键字驱动的方式来编写测试。该工具，最初称为“Selenium”，后来称为“SeleniumCore”，在2004年基于Apache2授权发布。Selenium的表格格式类似于FIT的ActionFixture。表格的每一行分为三列。第一列给出了要执行的命令名称，第二列通常包含元素标记符，第三列包含一个可选值。例如，如下格式表示了如何在名称为“q”的元素中输入字符串“SeleniumWebDriver”：typename=qSeleniumWebDriver因为Selenium过去使用纯JavaScript编写，它的最初设计要求开发人员把准备测试的应用和SeleniumCore、测试脚本部署到同一台服务器上以避免触犯浏览器的安全规则和JavaScript沙箱策略。在实际开发中，这种要求并不总是可行。更糟的是，虽然开发人员的IDE能够帮助他们快速处理代码和浏览庞大的代码库，但是没有针对HTML的相关工具。人们很快意识到维护一个中等规模的测试集是笨拙而痛苦的过程。为了解决这个问题和其他问题，我们编写了HTTP代理，这样所有的HTTP请求都会被Selenium截获。使用代理可以绕过“同源”规则（浏览器不支持Javascript调用任何当前页面所在服务器以外的其他任何东西）的许多限制，从而缓解了首要弱点。这种设计使得采用多种语言编写Selenium绑定成为可能：它们只需把HTTP请求发送到特定URL。连接方法基于SeleniumCore的表格语法严格建模，称之为“Selenese”。因为语言绑定在远程控制浏览器，所以该工具称为“SeleniumRemoteControl”或者“SeleniumRC”。就在Selenium处于开发阶段的同时，另一款浏览器自动化框架WebDriver也正在ThoughtWorks公司的酝酿之中。WebDriver的最初代码在2007年初发布。WebDriver项目的初衷是把端对端测试与底层测试工具隔离开。通常情况下，这种隔离手段通过适配器（Adapter）模式完成。WebDriver正是来源于该方法在许多项目上的不断实践应用，最初是HtmlUnit的封装，工具发布后很快开始支持InternetExplorer和Firefox。在WebDriver最初发布时，与SeleniumRC存在显著差异，尽管它们都属于浏览器自动化的API工具。对于用户来说，最明显的区别在于SeleniumRC提供基于字典的API，所有方法都在一个类中开放，而WebDriver的API更面向对象。此外，WebDriver仅支持Java，而SeleniumRC提供广泛的语言支持。技术差异也很明显：SeleniumCore（RC的基础）基本上是JavaScript应用，运行在浏览器的安全沙箱之内。WebDriver则尝试原生绑定到浏览器中，绕开了浏览器的安全模型，代价就是框架自身的开发投入显著增加。在2009年8月，两个项目宣布合并，SeleniumWebDriver就是合并的成果。目前，WebDriver支持的语言绑定包括Java、C#、Python和Ruby。它支持Chrome、Firefox、Opera和Android、iPhone浏览器。此外，还有其他关联项目，不在同一源代码库中维护，但是和主项目（SeleniumWebDriver）紧密合作，例如提供Perl绑定支持、BlackBerry浏览器支持，以及“无头”WebKit——用于持续集成的测试其无法正常显示的情况。最初的SeleniumRC机制仍然维持，帮助WebDriver在浏览器不受支持的情况下提供支持。SimonStewart在介绍SeleniumWebDriver软件架构之前，谈到了架构和项目开发的重要主题。概括如下：保持成本低廉。模拟用户。证明dirver运行良好............但是你无需了解一切细节降低巴士因素（busfactor）。偏爱JavaScript实现。所有方法调用都是RPC调用。我们是开源项目。具体来说：保持成本低廉在Y平台上支持X浏览器本质上是一种昂贵的提议，无论是从开发还是维护角度考虑。如果我们能够找到办法维持产品的高品质而又不违背太多其他原则，那么就值得采纳。这种思想最明显的体现在我们尽可能得使用JavaScript编程，你稍后会看到。模拟用户WebDriver的设计目的是为了准确模拟用户与Web应用交互的方式。模拟用户输入的常用办法是利用Javascript合并和触发一系列事件（如果真实用户执行相同交互操作，应用会处理同样的事件）。“合成事件”（synthesizedevents）方法在面对不同浏览器、有时相同浏览器的不同版本时存在不少困难，触发的事件和相关值略有不同。为了不让问题复杂化，大多数浏览器处于安全原因不允许用户通过这种方式与表单元素（如文件输入元素）交互。WebDriver总是尽可能的使用在操作系统层面触发事件的方法。因为这些“原生事件”不是由浏览器生成，所以这种方法避免了合成事件导致的安全限制，同时，因为它们是特定于具体操作系统的，一旦在某个平台上的浏览器运行良好，在另一种浏览器上重用代码相对容易些。困难的是，这种方法必须满足两点才可行：WebDriver与浏览器紧密绑定，同时开发团队在无需浏览器窗口获得焦点的情况下发送原生事件（因为Selenium测试运行时间较长，最好能支持同时在机器上执行其他任务）。目前，原生事件可用于Linux、Windows平台，不包括MacOSX。不管WebDriver如何模拟用户输入，我们都在努力尽可能地模仿用户行为。RC刚好相反，它提供的API层次远低于用户操作。证明Driver运行良好想让事情十全十美（motherhoodandapplepie）可能过于理想化了，但是我相信编写无法运行的代码是没有意义的。证明driver（指的是WebDriverAPI的特定实现。例如，Firefox和InternetExplorer各有自己的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的设计带