初衷
RF是一款非常容易简单上手的框架，特别在UI自动化方面，基本上算是立下过汗马功劳。在单机使用RF来完成UI自动化基本上是不存在问题的，如果涉及到大量的用例，就可能需要考虑到并发。
参考
在浏览论坛的时候看别人做了一套，基于Docker的UI自动化，又此也可以扩展了自己的思路，基于Docker的原理很简单，就把Selenium Grid和各个版本的浏览器打包成Docker的镜像，把代码运行在Docker镜像中，到达并发的效果。
具体操作过程
Centos7处理环境问题
搜索docker
yum search docker
安装docker
yum install -y docker
启动docker
systemctl start docker
查看状态
systemctl status docker
查看版本
docker version
查看docker信息
docker info
下载selemiunUI测试需要的镜像
命令docker pull：从docker hub中下载镜像。
首先搜索需要pull的image
命令：docker search selenium
针对docker selenium ，这里需要pull的image分别是：
selenium/hub
selenium/node-chrome-debug
selenium/node-firefox-debug
查看镜像
docker images
说明：默认的tag是latest；dockerhub服务器在海外，所以网速时好时坏，有时还会timeout报错，多试几次一定能成功。
由于国内访问直接访问Docker hub网速比较慢，拉取镜像的时间就会比较长
启动主hub容器
"docker run -d -P --name selenium-hub selenium/hub"
-d 表示容器以守护态（Daemonized）形式运行。
-P 表示 Docker 会随机映射一个 49000~49900 的端口到内部容器开放的网络端口。。
启动分支node chrome 容器
"docker run -d -p 5901:5900 --name node1 --link selenium-hub:hub selenium/node-chrome"
--link 通过 link 关联 selenium-hub 容器，并为其设置了别名hub
查看容器
"docker ps -a"
vnc连接
VNC远程浏览器环境
debug结尾的镜像都带有VNC服务端，本机安装VNC客户端，即可远程连接。
下载地址：https://www.realvnc.com/en/connect/download/vnc/
输入192.168.99.100:5901-->回车-->输入密码：secret-->确认-->进入chrome：58容器桌面
输入192.168.99.100:5901-->回车-->输入密码：secret-->确认-->进入firefox：52容器桌面
vncserver的密码：12345678
设计方案
第一步：docker-compose自动构建浏览器测试环境容器
首先还是先看一下前言中的链接如何使用selenium gird+docker，对于selenium gird的容器的启动，可以用docker-compose.yml做容器自动编排(比上面单独启动方便很多)，这样就不用手工一步一步去启动容器和link了
具体的docker-compose.yml描述
docker-compose.yml
hub:
image: selenium/hub
ports:
- 4444:4444
firefox:
image: selenium/node-firefox-debug
ports:
- 5901:5900
links:
- hub
chrome:
image: selenium/node-chrome-debug
ports:
- 5902:5900
其中hub就是selenium gird的容器，启动的时候使用4444端口，其他的是浏览器的镜像，而且这里也说明一下浏览器容器的5900端口，在docker.io获取浏览器镜像时，会有debug版，debug的话是可以通过VNC Viewer连接映射的端口来查看调试浏览器和用例的具体执行情况，一般也建议直接用debug版，上面分别用了2个chrome和1个firefox的容器集群构建成分布式的web自动化测试环境
启动完整之后打开selenium gird，就能看到具体浏览器容器的启动情况，当然，这一步也是要做到自动检查是否启动成功的
至于Xvfb，VNC，noVNC的区别，建议观看这篇文章，已经讲的很详细了。
Testerhome文章链接
第二步：并发框架设计（借用大神的思路）
- 并发的框架也是利用了python多线程的方法去实现的，其实具体的思想可以参考简单入手移动端并发自动化测试,不过比起这个当然是有改良的，之前用了bat脚本，这样执行的时候一旦并发多了总是弹窗口，显然就不好用了，后面就结合robot的tag来改良了并发框架
- 首先是robot的测试用例或测试套件分别贴上tags,代表分布在不同的容器上执行，其中node1和node2在远程容器中执行，所以要加上remote_url，local是指在本地执行，本地执行还是必要的，像一些上传本地文件的操作，放到远程机器上是执行不了的，所以保留本地执行
*** Settings ***
Library Selenium2Library
*** Test Cases ***
open_baidu
[Tags] node1
Open Browser https://www.baidu.com firefox remote_url=http://lunkrtech.rd.mt:4444/wd/hub
sleep 6
[Teardown] Close Browser
open_lunkr
[Tags] local
Open Browser https://www.lunkr.cn chrome
sleep 3
Wait Until Page Contains Element id=setting 3
[Teardown] Close Browser
open_coremail
[Tags] node2
Open Browser http://www.coremail.cn chrome remote_url=http://lunkrtech.rd.mt:4444/wd/hub
sleep 6
[Teardown] Close Browser
tags标记好用例之后，那就是并发框架的设计了，核心代码如下：
def run(arg):
os.system(str(arg))
threads = []
testsuite=sys.argv[1]
tags=sys.argv[2]
taglist=tags.split(',')
for tag in taglist:
cmd='pybot -i {0} -o .\\resultDir\\output-{0}.xml -l .\\resultDir\\log-{0}.html -r .\\resultDir\\report-{0}.html {1}'.format(tag,sys.argv[1])
t= threading.Thread(target=run,args=(cmd,))
threads.append(t)
-------这里省略产生多线程的代码-----------
os.system(u"rebot --output .\\resultDir\\output.xml -l .\\resultDir\\log.html -r .\\resultDir\\report.html --merge .\\resultDir\\output-*.xml")
脚本robot_mutil_dev.py接收两个参数，第一个，执行的测试套件或文件夹，第二个,以逗号分隔的多个标签，然后有多少个标签，就启动多少个线程根据不同的标签执行 pybot -i tag的命令，至于怎么使用python的多线程这里就不用多说了，大家估计比我还熟悉，最后所有自动化测试的线程都结束之后执行rebot的命令来合并自动化测试报告
个人认为的第二方案
大神的方案很好，但是里面的技术细节可能相对于比较复杂，我更加倾向于有没有开源开源代替的方案。
确实原理都是一样的，是希望可以通过启动不同的进程，来分别执行不同的测试用例，根据测试机的CPU核数确定启动的进程数，实现真正的并行执行。这样最大化节约了机器资源。
这里我们主要用到了开源工具pabot来实现测试用例的并行执行。
而且此框架也在不断的持续维护中，贴切的满足我们的需求。
同样的也是采用执行rebot的命令来合并自动化测试报告，区别就是不需要自己维护一个并发框架。
Robot Framework集成了rebot工具，可以使用它来进行报告的整合。
例如：rebot output1.xml output2.xml 即可联合输出一份报告
rebot --merge output1.xml output2.xml 即可合并输出一份报告
以上两者的区别是前者是或的关系，后者是与的关系也可以指定name输出报告：rebot --name
还可以指定部分case或者排除部分case输出报告：
rebot --include或者rebot --exclude
三、执行过程演示
结合Jenkins+docker技术，我们可以很方便的基于上面的两套方案，打造分布式并行自动化测试集群。
上面有2个浏览器就是通过VNC viewer来连接到容器中查看远程浏览器的情况的，在连接到selenium gird的时候，gird会自动判断哪个浏览器是空闲的，那gird就会把用例分配到对应空闲的浏览器中执行
那这样就万事大吉了，执行完测试之后具体生成的文件，在jenkins把对应路径配置好上传必须的文件就好了：
-
也可以从测试报告的tags中看到，有多少个用来在对于的tags执行的，而且在具体的用例日志中也看到报告是通过合并得到的，大致的过程就是这样子啦
提升的速度不多，原因是我分配到各节点的用例不均匀，但这个起码从本质上提高了自动化测试执行的效率，只要分配好执行的用例，效率肯定会很明显的提高的
