1-selenium-core.png
Selenium是一套javascript开发[1]的类库，用于对浏览器执行一些行为， 例如点击网页上的一个按钮。为了避开浏览器的同源策略，selenium类库和web application必须绑定在一起。 同源策略(Same-origin policy) 是web application 中重要的安全模型[2]，在这个模型中，浏览器只允许一个网页访问拥有相同“origin”的网页。这里“origin”指的是URI scheme，host name 和port number的组合。在这一阶段，测试脚本是一些表格式的符号脚本，这些符号脚本由selenium core 类库进行解析成javascript。
2-selenium-via-proxy.png
和web application 绑定在一起的Selenium显然不是一个好的架构。想象一下，在这种模式下，对于每个web application的每一次测试，都要重复同样的步骤，即绑定一个selenium上去，很容易出错而且效率低下。因此，人们引入了代理服务器，用来将selenium类库解析好的测试指令注入（inject）网页的head section。不好意思，本人知识有限，暂时只能把它理解为类似CORS[3][4]的机制。如果有朋友看到这段话并且给予肯定或指正，鄙人不胜感激。
3-selenium-rc.png
然而proxy的模式仍然让人们难以忍受，而这个时候许多高级的通用性语言开始在自动化测试领域广泛发挥起了作用。Selenium的开发者为这些高级语言分别开发了客户端的API，通过调用这些API，命令以wire protocol[5]的形式被高级语言发送到selenium server。这里的wire protocol指的是运行在传输层之上的应用层protocol。我猜，很久之前，第一次被大家广泛使用的就应该是这一模式下的selenium（哎，暴露了我的年龄）。但是这些API的设计难称完美，并广为诟病
4-selenium-webdriver.png
相信大家最熟悉的应该是这一模式，它集成了selenium和webdriver，有人叫他selenium 2，甚至有人直呼其为WebDriver （可怜的selenium）。可以说这个版本的selenium已经算的上是一个非常出色的工具了。API被重新设计成JSON形式，简洁而优雅，而且大多数主流高级语言都支持JSON。同时，浏览器以原生的模式启动，WebDriver作为浏览器上的extensions同Selenium Webdriver进行交互，同真实的场景更加接近。这种模式很美，但是并不完美。首先它能否很好的发挥作用，取决于作为extension部署在浏览器上driver对API的支持程度。说到这里，很多朋友可能已经知道我在指谁了，不错，就是IE。用Webdriver做过测试的人都应该体会过在IE上跑case的痛苦，简直“欲仙欲死”。另一个问题在于selenium server，driver和浏览器版本的兼容性很难控制。例如，selenium server 2.53能很好的支持firefox45，但是如果需要把firefox45升级到47+，就需要把selenium server 升级到3.X。这不是一个轻松的过程，因为selenium的许多API发生了较大的变动。
5-w3c-webdriver.png
好消息是目前，JSON wire protocol已经成为了Web 领域的标准，称之为WebDriver protocol。所有的浏览器都同意对其进行支持，并将driver集成到自己的产品里。也就是说driver不再以extension的形式同浏览器交互，而是以所谓的“Native call”。Selenium革了浏览器开发商的命的同时，也革了自己的命。
[1] https://github.com/SeleniumHQ/selenium/blob/master/javascript/node/selenium-webdriver/index.js#L23
[2] https://en.wikipedia.org/wiki/Same-origin_policy
[3] https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
[4] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
[5] https://en.wikipedia.org/wiki/Wire_protocol
网友评论