设计：想在jenkins服务器(linux)上执行pybot命令实现在不同的系统和浏览器上跑测试案例。
好处：只需在jenkins服务器一台机器上安装配置RF环境即可，而不需要在每个Jenkins的节点机重复搭建RF环境，当然用虚拟机的话可以搭建一套然后进行克隆。
实现：
1.在节点机上启动主节点：
在命令中打入命令 java -jar selenium-server-standlone-XXXX.jar -role hub
默认启动默认端口为4444，当然，你不喜欢4444也可以换个端口，加上 -port XXXX即可
启动完后，你可以用浏览器打开 http://localhost:4444/grid/console 这个网址查看主节点的状态
2.在同一节点机上启动子节点
打开命令 java -jar selenium-server-standalone-XXXX.jar -role node -hub http://192.168.XX.XXX:4444/grid/register
其中192.168.XX.XXX为主节点机子的ip地址，可以使用ipconfig命令在命令行查看得到。上面命令默认启动5555端口，可使用-port 更改。其他参数设置请自己看 吧https://code.google.com/p/selenium/wiki/Grid2
然后你可以在主节点机子上 ，输入http://localhost:4444/grid/console网址查看到这个子节点状态。
3.测试用例中调用（测试用例在jenkins服务器上）
Open Browser http://www.baidu.com remote_url=http://子节点ip:5555/wd/hub
4.在jenkins服务器上执行pybot
添加构建shell: pybot 冒烟测试.txt
添加Publish Robot Framework test results构建，输入output.xml所在的目录即可，默认是和用例同一目录。
5.其他要注意的：
重试用例
-R : 表示要重试错误用例 -d : 本次执行log存放路径 参数一 : 需要执行重试的output.xml文件路径 参数二 : suite路径
示例：
pybot -R D:\logs\2014-09-05-18-40-42\remote_1\tag__batch_0\output.xml -d D:\logs\2014-09-05-18-40-42\remote_2\tag__batch_0 D:\自动化测试111\成本系统
合并报告(使用rebot指令，详细说明可以通过 rebot --help 查看)
-N : 重命名报告 -d ：产生的新log的存放路径 参数一 ： 需要合并的log路径(支持通配符)
示例：
rebot -N 第1次执行 -d D:\logs\2014-09-05-18-40-42\1 D:\logs\2014-09-05-18-40-42\remote_1\*
需要优化的：
执行环境不稳定、挂死
在实际执行case的过程中，经常会出现一些莫名其妙的问题，比如：
1. 跑着跑着IEDriverServer.exe这个进程不起作用了，僵死了
2. 模态对话框很讨厌，特别是无法预知的模态框，如果不调用confirm action把它消掉的话，即使你在test teardown里面调close all browsers，也是关不掉IE窗口的，这极有可能会导致case结束了，但IE进程和IEDriverServer.exe进程都还在的情形。
不管怎么样，总是会出现case结束了，但IEDriverServer.exe进程还在的情况。对于本地执行方式来说，一旦有两个IEDriverServer.exe进程同时存在的话，那么执行环境就很不稳定了，什么奇怪的事情都可能发生；而对于selenium grid环境来说，如果一个case结束了，但IEDriverServer.exe进程还活着的话，会被hub认为该节点处于繁忙状态，hub就不会给它分发下一个case，那么当前批次一直被阻塞，其他批次也要等待这个批次(线程同步)，进而整个执行流程都会被阻塞，后果相当严重。
如果是在本地执行的话，我可以在case setup里面调用OperationSystem.Run关键字去杀 IEDriverServer.exe进程和IE进程；但是，如果是利用selenium grid分布式执行的话，这种操作系统级别的关键字，是无法通过hub转发到节点机器上执行的，因为hub只会转发webdriver支持的指令，其他指令都是在本地执行的。
所有，必须要想办法保证每个case执行完毕后，IEDriverServer.exe进程和IE进程都必须被清理掉，否则整个Selenium Grid体系就玩不转了，这点很重要。
解决办法：我也没想到一个比较优雅的办法来解决Selenium Grid稳定性的问题，用的一个比较偏门的办法：
1. 开发一个WCF服务部署到节点机器，它暴露的URL为：http://localhost:8732/gridservice/action/killprocess，其作用就是杀IE进程和IEDriverServer进程。
2. 定义一个关键字，叫“安全退出case”，内容如下：
3. 在case的teardown里面调用“安全退出case”关键字
这样做，为什么能达到目的呢？
1. 首先调用“close all browsers”是为了杀IEDriverServer进程的(但是有可能IE进程杀不掉，不过没关系)，保证hub会开一个新的session执行后续的那个”open browser“命令。
2. ”open browser“是selenium库支持的命令，所有是可以分发到hub的。
3. 不管请求分发到哪个节点，localhost都是指的是节点本机，所以调的是节点本机的服务，当然杀的也是节点自己的进程。
4. 调用“open browser”访问WCF服务的URL，类似于自杀式袭击。因为这个调用会报错，但是可以不用管，所有用“Run Keyword And Ignore Error”关键字保护起来。袭击完毕，各种残余都被清理的干干净净(包括IE进程和IEDriverServer进程)。
这个方案经过测试之后，发现有一个问题：正常情况下，IEDriverServer.exe进程是在webdriver调用quit方法之后自动退出的，hub与节点之间也是正常的交换信息；而采用自杀式袭击，来的比较突然，hub根本不知道节点发生什么事情，好像变的有点无所适从了，不停的试图与节点建立联系(但是节点又不会正确的通知自己的信息给hub，因为它的进程是非正常终止)，直到超时时间到了，才重新和节点建立一个新的session，然后开始后续的执行。hub的默认超时时间是300秒，要等的时间有点久，那么只好把这个时间设短一点吧，希望它早点超时，早点建立新session。可以在启动hub的时候，通过 -timeout 选项设置超时时间。
java -jar selenium-server-standalone-2.39.0.jar -role hub -timeout 20经过上述优化之后，实际跑下来效果还可以，后续还要经过大规模的实际运行来考察这个方案是否成熟稳定。
