Selenium-Grid版本

selenium-grid分为版本1和版本2，其实它的2个版本并不是和selenium的版本1和2相对应发布的[即selenium-grid2的发布比selenium2要晚一点]。不过幸运的是现在的selenium-grid2基本能支持selenium2的所有功能了。

selenium虽然分1和2，但其实原理和基本工作方式都是一样的。只是版本2同时支持selenium1和selenium2两种协议，并且在一些小的功能和易用性上进行了优化。比如：指定测试平台的方式；以下未作特殊说明的Selenium-Grid均为通用。

Selenium1工作原理

selenium1中除了使用selenium-core以外，进行自动化测试时都需要使用selenium-RC来作为代理[不管是本机还是远程]，目的是为了解决同源问题；而造成同源问题的原因是因为selenium1中是使用Javascript来驱动测试执行的【浏览器由于安全问题不允许不同域之间的JS调用，即非同源不可调用；而selenium1中的工作方式就是在宿主页面注入JS并且通过调用JS来执行测试操作的，所以就设计到同源问题】。所以为了达成目的，其解决方案就有2种：

1、使用selenium-core：

selenium-core是一组js库，用来驱动浏览器操作的所有库文件都在这里，整个selenium1可以认为核心组件就是这个selenium-core；而使用selenium-core的方式就是在被测试站点程序的源码里把selenium-core中的所有js库直接添加到页面里，这样页面正常加载的同时也会把selenium-core加载下来，并且天生就是同源的。
2、使用selenium-RC：

RC是一个http代理程序，用来注入到浏览器和被测web程序之间，这样浏览器所有的请求和接收的内容都会通过RC；RC会把浏览器的请求发送给真实的web程序，而在接收到web程序的响应内容时，并没有把内容原原本本的返回给浏览器客户端，而是把包含selenium-core的内容注入到响应内容中去，然后才发送响应内容给浏览器，这样就通过欺骗的方式让浏览器认为selenium1的驱动类库同样是同源的。

Selenium2工作原理

selenium2中因为使用的webdriver，这个技术不是靠js驱动的，而是直接调用浏览器的原生态接口驱动的。所以就没有同源问题，也就不需要使用RC来执行本地脚本了【当然缺点就是并不是所有的浏览器都有提供很好的驱动支持，但JS却是所有浏览器都通用的】。所以selenium2中执行本地脚本的方式是：通过本地webdriver驱动直接调用本地浏览器接口就完事了。在本地调用本地的代码是这样的：

但有时候并总是只执行本地测试的脚本，有时候可能需要在本地调用远程的环境来执行测试，【比如：因为测试环境覆盖原因】此时就需要一个类似selenium1中的RC来承担这个任务，也就是selenium2中的selenium-server。selenium-server支持接收远程脚本的调用命令，然后操作其宿主机上的浏览器来到远程执行测试的任务。当然selenium-server为了兼容selenium1的脚本，它同样也支持selniumRC所支持的功能【即能接收selenium1的调用命令】。在本地调用远程机器执行测试的代码是这样的：

但是在运行这段代码之前，要先启动Selenium-Server；启动命令为：

调用selenium-server对应的结构图：

Selenium-Grid工作原理

到此为止，其实还没有提到selenium-grid，因为到目前为止我们还没有需求说同时覆盖多个平台和浏览器，而selenium-grid在这种情况下就会体现出其作用来。selenium-grid是用于设计帮助我们进行分布式测试的工具，其整个结构是由一个hub节点和若干个代理节点组成。hub用来管理各个代理节点的注册和状态信息，并且接受远程客户端代码的请求调用，然后把请求的命令再转发给代理节点来执行。使用selenium-grid远程执行测试的代码与直接调用Selenium-Server是一样的[只是环境启动的方式不一样，需要同时启动一个hub和至少一个node]：

上面是启动一个hub和一个node，若是同一台机器要启动多个node则要注意端口分配问题，可以这样来启动多个node：

调用Selenium-Grid的基本结构图如下：

上面是使用selenium-grid的一种普通方式，仅仅使用了其支持的分布式执行的功能，即当你同时需要测试用例比较多时，可以平行的执行这些用例进而缩短测试总耗时；除此之外，selenium-grid还支持一种更友好的功能，即可以根据你用例中启动测试的类型来相应的把用例转发给符合匹配要求的测试代理。例如你的用例中指定了要在Liunux上FF的3.6版本进行测试，那么selenium-grid会自动匹配注册信息为Linux、且安装了FF3.6的代理节点，如果匹配成功则转发测试请求，如果失败则拒绝请求。使用selenium-grid的远程兼容性测试的代码同上。其调用的基本结构图如下：

了解了selenium-grid的基本结构，再来看看selenium-grid通信的原理。假设现在我们有这样一个场景：[一个测试请求客户端、一个hub节点、一个Windows+ie代理、一个linux+FF代理、一个Mac+Safari代理、一个任意平台下的Chrome代理]。其分布图如下：

测试的代码如下：

那么整个测试执行的过程大概是这样的。首先我们在测试请求机上执行测试代码，代码中测试启动方式为远程调用；

此时测试脚本就会根据启动参数连接hub节点，这里的连接信息为

连接到hub成功后，会在hub上注册一个session信息；[后面再与hub通信时就会带上这个session信息，告诉hub我之前来过，并且之前是被分配到哪个代理节点上执行过测试]

hub在接受初始化请求时会根据请求的类型来匹配所有代理，并确定是否有符合规则的代理；

如果匹配失败了就会拒绝该初始请求；如果匹配成功则通知对应代理节点进行对应的初始化操作，这里是启动XX，并记录浏览器的注册session，最后发回给hub端；

hub端接收到代理端起的完成后的session信息后，在hub中同样要记录session并返回给测试请求端，[session中会保存匹配到的代理信息]

在初始化请求成功之后，测试请求端会继续发送下一条测试命令，这里的命令是：

此命令会同样被发送给hub，当然是带上session信息的；

hub接收到带有session的请求命令时，会查询session的信息，得知session中对应的代理后就把请求的命令给转发给该代理；

代理在接收到hub发送过来的测试命令后，同样查询其session信息，并根据session信息操作与之对应的浏览器以执行测试；

测试完成后会通知hub执行结果，hub再转发给测试请求端，测试请求端根据的返回信息来决定接下来的执行流程；

最后测试结束后，通知hub关闭浏览器进程，同时清除对应的session信息。

由selenium-grid的原理可以得知

通过selenium-grid执行远程操作时，并不需要远程机器上有测试脚本；但是远程机器上必须安装了对应的webdriver程序[可以直接放在环境变量的目录里即可]，当然了，还得需要正确的启动了代理程序。[具体可以参考：如何搭建Selenium-Grid环境]