51Testing软件测试论坛
标题:
结合 Docker-Selenium 镜像进行 Web 应用并发自动化测试
[打印本页]
作者:
悠悠小仙仙
时间:
2017-6-30 10:11
标题:
结合 Docker-Selenium 镜像进行 Web 应用并发自动化测试
一、前言
最近一直在还去年的技术债,去年我们测试团队投入一大堆测试技术,但没有多少个是做精的,那今年的目标就是做到极致,去年团队落地了Web和移动端的自动化测试,但随着用例的增加,执行自动化脚本的时间越来越长,我们还需要做快速迭代的,很多时候一天还可能发几个版来响应客户的需求,那面对频繁地发版。自动化测试的支撑就应更加高效,所以就想到落地并发自动化测试来提高自动化测试的执行效率,但对于web应用,一台机器上跑多个浏览器的时候,对于业务交互时也比较麻烦,而且一种浏览器在一台机器上一般只有一个,那要做并发就要多台机器,问题在没有那么多资源的情况下要怎么做,正好最近翻其他技术网站的时候翻到Docker-selenium,通过selenium gird+docker容器很好地把多台分布式容器利用起来,更充分的利用机器的资源,这样web的并发自动化测试就可以落地了,并解决了在多个浏览器跑兼容测试的难题
二、操作过程
先说明一下具体的并发架构
自动化具体执行的流程
第一步:docker-compose自动构建浏览器测试环境容器
首先还是先看一下前言中的链接如何使用selenium gird+docker,对于selenium gird的容器的启动,可以用docker-compose.yml做容器自动编排,这样就不用手工一步一步去启动容器和link了
具体的docker-compose.yml描述
docker-compose.yml
hub:
image: lunkrtech.rd.mt/wqzhou/selenium-hub
ports:
- 4444:4444
firefox:
image: lunkrtech.rd.mt/wqzhou/node-firefox-debug-zh
ports:
- 5901:5900
links:
- hub
chrome:
image: lunkrtech.rd.mt/wqzhou/node-chrome-debug-zh
ports:
- 5902:5900
links:
- hub
chrome2:
image: lunkrtech.rd.mt/wqzhou/node-chrome-debug-zh
ports:
- 5903:5900
links:
- hub
复制代码
其中hub就是selenium gird的容器,启动的时候使用4444端口,其他的是浏览器的镜像,而且这里也说明一下浏览器容器的5900端口,在docker.io获取浏览器镜像时,会有debug版,debug的话是可以通过VNC Viewer连接映射的端口来查看调试浏览器和用例的具体执行情况,一般也建议直接用debug版,上面分别用了2个chrome和1个firefox的容器集群构建成分布式的web自动化测试环境
启动完整之后打开selenium gird,就能看到具体浏览器容器的启动情况,当然,这一步也是要做到自动检查是否启动成功的
第二步:并发框架设计
并发的框架也是利用了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的命令来合并自动化测试报告
三、执行过程演示
具体的执行过程就是执行python脚本就好了,当然我们可以用jenkins来做自动构建触发自动化测试的执行
其实就是执行robot_mutil_dev.py webmutil.txt local,node1,node2,webmutil.txt是测试套件,后面的是刚才标记的tags
执行过程:
上面有2个浏览器就是通过VNC viewer来连接到容器中查看远程浏览器的情况的,在连接到selenium gird的时候,gird会自动判断哪个浏览器是空闲的,那gird就会把用例分配到对应空闲的浏览器中执行
大概并发的自动化测试就实现了,当然这里还有一个注意的地方,就是执行用例失败之后的截图,如果是多线程执行的话,截图也是多线程的,线程1产生的截图1命名为selenium-screen-1.png,线程2也会产生的截图1命名为selenium-screen-1.png,那这样线程2的截图就会把线程1的截图给覆盖了,那解决办法是,既然用到线程,那肯定有线程或进程id的,那就在图片命名中加一个线程id号就能解决问题了,具体的就是在selenium2library中的_screenshot.py:
def _get_screenshot_paths(self, filename):
if not filename:
self._screenshot_index += 1
pid=os.getpid()
filename = 'selenium-%s-screenshot-%d.png' % (pid,self._screenshot_index)
else:
filename = filename.replace('/', os.sep)
复制代码
那这样就万事大吉了,执行完测试之后具体生成的文件,在jenkins把对应路径配置好上传必须的文件就好了:
最后一步当然是执行完成以后看到的测试报告
也可以从测试报告的tags中看到,有多少个用来在对于的tags执行的,而且在具体的用例日志中也看到报告是通过合并得到的,大致的过程就是这样子啦
在我们自己产品的使用中,有具体的效率对比
提升的速度不多,原因是我分配到各节点的用例不均匀,但这个起码从本质上提高了自动化测试执行的效率,只要分配好执行的用例,效率肯定会很明显的提高的
四、最后说几句
还是回到那句,去年做了一大堆技术,今年就追求做到极致,其他还不仅是自动化测试,过几天有空的话可能也会继续分享一下我的mock服务器改良版,还有接口自动化测试的,以前一直是苦于环境,有很多测试数据是一次性的,那现在可以用docker对接口测试环境进行管理,执行测试或重现问题时可以自动构建环境,结合微服务的思想将数据和程序分离,然后,这样一次性的数据也可以多次使用了,所以今年就是要把去年的一大堆东西做到真正高效地解决测试的难题以既能保证质量,又能快速迭代地去响应客户需求,争得更多的市场,好吧,说那么多,希望大家也一起加油,把2017年做得极致,谢谢
作者:
巴黎的灯光下
时间:
2017-6-30 16:25
当然,除了用来做自动化测试,还可以用来做并发爬虫,有那么多个浏览器去做,当然会更高效,我自己最多还试过10个浏览器并发的,没毛病
作者:
草帽路飞UU
时间:
2017-6-30 16:25
随着docker的出现,使用 selenium 做浏览器云测试已经没有太多的成本了。
作者:
乐哈哈yoyo
时间:
2017-6-30 16:26
docker 趋势很牛叉,现在基本上都在往devops发展。
作者:
小皮球的故事
时间:
2017-6-30 16:26
这类框架的开发从来都不是问题,最终会出问题的地方就是维护。
欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)
Powered by Discuz! X3.2