基于docker的UI自动化测试实践
作者:strayhrt 发布时间:[ 2016/7/26 11:27:42 ] 推荐标签:测试用例
安装配置docker
公司的测试机是centos系统,如果想玩docker过程中不出幺蛾子,建议保证系统到centos7,内核3.10以上。。。
一开始的时候,我是并不信邪的,在centos6的系统风风火火的搞了起来,结果脸被打肿了,各种血泪不说了。
docker安装很简单,官网文档看看行
安装好docker后,首先从官方库中下载centos6.6的镜像。
然后以此为基础分别配置3个镜像,分别是安装了behave的镜像,pg/redis的镜像和安装了application以及其他组件的镜像。
启动app,pg容器,其中pg容器以container的形式附在app的容器内,这样做的目的是为了让两个容器的ip一致,这样app的配置文件中关于pg,redis的配置可以用127.0.0.1指定。并且这两个容器又相对独立,用例执行结束后可以stop掉pg容器,并新建一个容器附在app容器中。
这么做的效果跟所有组件布在同一个容器中是一样的,好处在于重启pg,redis比重启app要快,快很多~
docker run -d -v /opt/data/remote:/opt/share 172.16.154.92:5000/centos:6-cfp-apps-2.6.1
docker run -d --net=container:{上一步产生容器的ID} 172.16.154.92:5000/centos:6-cfp-env-2.6.1
集成celery
到上一步为止,我们大体的结构已经有了,但是我们想让它更快,更好用一点。于是我们加上了celery。
celery是一个比较常用的python异步框架,分别在docker机器以及behave容器中安装上。
我们希望自动化控制脚本通过docker机器中的celery去新建n个behave以及app,env的容器,并在case完成后重新新建env容器。
然后我们希望behave容器中的celery接受用例id和app容器的ip,从而去指定的app页面中执行用例
behave容器中使用supervisor启动celery并监听behave消息队列
[supervisord]
nodaemon=true
[program:celery]
command=bash -c "cd /root/ && celery worker -A tasks -Q behave -l info -c 1 -f /opt/share/celery%(ENV_celery)s.log"
startretries=0
docker机器中celery监听main队列。
celery worker -A tasks -Q main -c 10 -l info
celery的task脚本tasks.py中指定队列
from celery import Celery,platforms
import subprocess
import os,sys
import time
platforms.C_FORCE_ROOT = True
app = Celery()
app.conf.update(
CELERY_IMPORTS = ("tasks", ),
BROKER_URL = 'redis://172.16.154.92:9852/0',
CELERY_RESULT_BACKEND = 'redis://172.16.154.92:9852/1',
CELERY_ROUTES = {
'tasks.cfp_start': {'queue': 'main'},
'tasks.behave_init': {'queue': 'main'},
'tasks.get_ip': {'queue': 'main'},
'tasks.behave': {'queue': 'behave'},
'tasks.rm_docker': {'queue': 'main'},
'tasks.stop_docker': {'queue': 'main'},
},
...
)
这样我们通过控制脚本得到需要测试的caseid,然后启动配置个数的app,pg,behave容器,在检查到app容器ready后发送caseid和容器ip到celery队列。
然后监控case执行过程,在某个case完成后,重启该case对应容器的pg容器,完成后发送下个caseid和ip到celery。这样分布式的测试保证了单个用例的执行环境。
运行速度也有一定的保障。
毕竟我的测试机可是24核 24g的机器。。。 运行过程中整机的cpu有时突破90%,也算是资源没有浪费了~~
结果处理
因为每次behave都只是执行一个case,因此生成的junit报告也只有一个case的信息。因此需要做报告合并。
不想重复造轮子搜索了下, 通过两个现有的模块 xunitparser,junit_xml愉快搞定。生成一个大的junit报告
然后是放在jenkins,用插件展示了。
用例调试
之所以用例调试要专门拿来说下,是因为使用docker容器创建的容器都是私有ip,不能直接访问。
docker倒是可以将容器中的端口映射一个实体机的端口,但这个并不十分好用,因为我们app的配置文件里面需要配置一些跳转的url,而这些跳转的urlip又是私有的或者干脆是127.0.0.1的。。。 于是我们新建了一个squid的容器跟app容器在一个网段,然后暴露代理端口给我们,这样浏览器设下代理ok了。
然后是用例运行中的截图,phantom本来是没有界面的嘛,而且又是多个用例异步的执行,这要怎么调试呢。
也很简单,behave中通过after_step() 方法在每个用例每个步骤执行后都可以screenshot,保存在用例的目录。该目录mount在docker机器中。
然后启动一个nginx容器,设置好截图目录,可以直接查看啦~~
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11