在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个测试是一种极大的挑战，我们一直在努力面对。
