Menu Close

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

本文我们来分享MeterSphere在UI测试中的分布式扩展部署方案,该方案将满足企业在大规模使用MeterSphere UI测试时的高并发和稳定性需求。

一、UI测试简介与使用场景

UI自动化测试简单地说是以自动化方式模拟用户操作UI界面的一种测试方式,分为Web端和App端两大类,这两大类所用的技术栈和技术框架也有着本质上的区别。

但无论是Web端还是App端,UI测试的目的是一致的:即确保用户界面向用户提供了适当的访问和浏览测试对象功能的操作。除此之外,UI 测试还要确保UI功能内部的对象符合预期要求,并遵循公司或行业的相关标准。

开展自动化测试的目的并不是在于发现更多的Bug,而是为了保证产品质量,以最快的速度验证功能的正确性,并以最低的成本定位问题代码。但UI自动化用例脚本的维护成本也比较高,所以每个企业应结合自身业务的属性,再决定是否要开展UI自动化测试,切忌盲目跟风。

一般具备以下场景的项目或者应用系统适合开展UI自动化测试:

1. 长期存在的项目,未来3~5年内确定一直在投入使用。此类项目采用UI自动化进行日常回归,回归次数越多、时间越长,收益越高;

2. 应用系统中相对稳定的功能。如果是专门为某个特定需求做的功能(比如特定节日的促销活动),或者是一次性使用的功能,就无需采用UI自动化测试。简单来说,相对稳定的界面功能适合采用UI自动化测试。

二、UI测试在MeterSphere中的定位

2022年5月5日,MeterSphere一站式开源持续测试平台正式发布v1.20 LTS版本。在这一版本中,MeterSphere继续深入践行“一站式持续测试平台”的设计理念,新增了UI测试模块,实现了对测试跟踪、接口测试、UI测试和性能测试的一站式覆盖。

注:目前MeterSphere的UI测试指的是Web UI测试,并非App测试。

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

从MeterSphere官网的架构图可以看出UI测试在MeterSphere的技术栈中具有以下两个定位:

1. UI测试作为MeterSphere的一大测试模块,充分融入到了MeterSphere产品的整个持续测试体系中,为企业提供平台级别的UI测试能力;

2. 基于现有的MeterSphere的架构体系,结合用户的团队管理、DevOps流程,企业借助MeterSphere平台能够将UI测试也融入到DevOps系统中,补全DevOps中关于UI自动化测试的短板。

三、MeterSphere UI测试模块的技术选择

关于MeterSphere中UI测试的技术选择,可以阅读我们此前发布的文章《技术选型丨MeterSphere为什么选择Selenium作为UI自动化框架?》 ;对于主流的UI测试工具的优缺点,MeterSphere社区在《MeterSphere UI测试功能模块设计与实现》直播中也进行了详细的介绍(直播回放地址:
https://live.vhall.com/v3/lives/watch/101779389),这里不过多赘述。

总的来说,Selenium在脚本语⾔、浏览器⽀持、并发、分布式以及插件录制视频录制⽅⾯都有完整的⽅案,并且与JMeter(WebDriver Sampler)有深度集成。无论是从最⼴⼤⽤户群体的⻆度来说,还是从最为⼴泛的最佳实践⻆度来说, Selenium都是最符合MeterSphere中UI测试模块需求的。在设计时,MeterSphere对Selenium框架进行了简化和封装,做到了开箱即用,操作更加简单和方便,并且提供平台化能力。

概括成一句话就是:MeterSphere充分兼容了Selenium的特性,以测试平台方式提供了UI测试能力。

四、MeterSphere UI测试模块的架构设计

在聊MeterSphere UI测试架构的设计之前,我们先了解下MeterSphere的整体架构。

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

从整体架构不难看出MeterSphere是以Docker Engine的方式运行Selenium进行UI测试的,同时支持直接导入已有Selenium IDE插件已经录制的自动化脚本,也支持通过Selenium Gird的方式提高UI自动化的并发能力。MeterSphere UI自动化执行的过程如下:

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

1. 用户在MeterSphere UI测试模块直接编写测试脚本,或者导入Selenium IDE Side脚本(后续支持MeterSphere自研的插件);

2. 用户界面选择或者API触发UI自动化测试,MeterSphere自动化调用Selenium Grid进行UI自动化测试,并反馈测试结果。

五、MeterSphere UI测试的开箱即用的部署方式

从上述的MeterSphere UI自动化架构可以看出,MeterSphere支持Selenium Gird进行自动化测试。单机部署MeterSphere企业版,通过msctl status查看底层服务,多了local-selenium-grid服务:

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

进入此容器服务内,同时运行了Chrome、Firefox两种Node进程:

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

所以,单机MeterSphere中默认采用All-in-One的UI测试部署方案。此方案能够快速搭建UI测试所需要的组件,无需额外的配置,方便企业快速投入使用。但是弊端也很明显,资源配置有限,只适合进行少量UI自动化场景运行和日常回归,不适合大规模进行使用。

六、MeterSphere UI测试模块的分布式扩展部署

为了保证MeterSphere中UI测试在大规模使用时的高并发和稳定性,建议部署原生的Selenium Gird方案,并与MeterSphere进行集成。

主要原因有两方面,一方面是Selenium Grid可以按照执行时指定的浏览器,并自动寻找符合测试要求的节点运行测试任务;另一方面,Selenium Grid的架构特点,天生就能很好地支持测试用例的并发执行。Selenium Gird的架构如下:

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

Selenium Hub用来管理各个Selenium Node的注册信息和状态信息,并且接收远程客户端代码的测试调用请求,并把请求命令转发给符合要求的Selenium Node执行。查看Selenium GitHub上关于Docker Hub的部署方式(
https://gitHub.com/SeleniumHQ/docker-selenium),可支持多种部署方案:

1. 独立主机部署方案

2. 独立单台主机,Docker部署方案

3. 独立多台主机,Docker部署方案

4. Kubernetes部署方案

MeterSphere社区推荐采用“独立多台主机,Docker部署方案”或者“Kubernetes部署方案”。推荐的理由是,后续扩展方便且简单,当然企业根据需求也可以选择其他部署方案。下面我们重点展示这两种部署方案详细的操作部署过程。

■ 独立单台主机,Docker部署方案

1. 独立主机上部署Docker运行环境,部署完成后检查Docker是否运行;

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

2. 执行以下命令,部署安装Selenium Gird。

$ docker network create grid
$ docker run -d -p 4442-4444:4442-4444 --net grid --name selenium-Hub selenium/Hub:4.3.0-20220628
$ docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-Hub \
    --shm-size="2g" \
    -e TZ=Asia/Shanghai \
    -e SE_EVENT_BUS_PUBLISH_PORT=4442 \
    -e SE_EVENT_BUS_SUBSCRIBE_PORT=4443 \
    -e SE_NODE_MAX_SESSIONS=30 \    #配置支持的最大启动Session数量
    -e SE_NODE_OVERRIDE_MAX_SESSIONS= true
    selenium/Node-chrome:4.3.0-20220628
$ docker run -d --net grid -e SE_EVENT_BUS_HOST=selenium-Hub \
    --shm-size="2g" \
    -e TZ=Asia/Shanghai \
    -e SE_EVENT_BUS_PUBLISH_PORT=4442 \
    -e SE_EVENT_BUS_SUBSCRIBE_PORT=4443 \
    -e SE_NODE_MAX_SESSIONS=30 \    #配置支持的最大启动Session数量
    -e SE_NODE_OVERRIDE_MAX_SESSIONS= true
    selenium/Node-firefox:4.3.0-20220628

■ 独立多台主机,Docker部署方案

需要准备至少2台主机,其中一台用于部署Hub,其他主机用户部署不同浏览器的Node,所有的主机都需要提前安装Docker服务。

1. 第一台主机(Machine-1)部署Hub操作;

$ docker run -d -p 4442-4444:4442-4444 --name selenium-Hub selenium/Hub:4.3.0-20220628

2. 第二台主机(Machine-2)部署Chrome Node;

$ docker run -d -p 5555:5555 \
--shm-size="2g" \
-e TZ=Asia/Shanghai \
-e SE_EVENT_BUS_HOST=<ip-from-machine-1> \
-e SE_EVENT_BUS_PUBLISH_PORT=4442 \
-e SE_EVENT_BUS_SUBSCRIBE_PORT=4443
-e SE_NODE_MAX_SESSIONS=30 \    #配置支持的最大启动Session数量
-e SE_NODE_OVERRIDE_MAX_SESSIONS= true
-e SE_NODE_HOST=<ip-from-machine-2> \
selenium/Node-chrome:4.3.0-20220628

3.第三台主机(Machine-3)部署Firefox Node。

$ docker run -d -p 5555:5555 \
--shm-size="2g" \
-e TZ=Asia/Shanghai \
-e SE_EVENT_BUS_HOST=<ip-from-machine-1> \
-e SE_EVENT_BUS_PUBLISH_PORT=4442 \
-e SE_EVENT_BUS_SUBSCRIBE_PORT=4443 \
-e SE_NODE_MAX_SESSIONS=30 \    #配置支持的最大启动Session数量
-e SE_NODE_OVERRIDE_MAX_SESSIONS= true
-e SE_NODE_HOST=<ip-from-machine-3> \
selenium/Node-firefox:4.3.0-20220628

■ Kubernetes部署方案

Selenium Gird部署至Kubernetes采用了Helm Chart部署方式。具体部署方式如下:

#创建Namespace
kubectl create namespace selenium-grid
#第一步添加Helm仓库
helm repo add docker-selenium https://www.selenium.dev/docker-selenium
# 第二步更新
helm repo update
# 查询Selenium Grid的版本
helm search repo docker-selenium --versions
#安装最新版本Selenium Grid
helm install selenium-grid docker-selenium/selenium-grid -n selenium-grid

1. 部署完成后,kubectl get all -n selenium-grid查看运行如下:

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

2. 由于此Kubernetes集群没有配置Ingress,所以开启NodePort模式的SVC。命令为:kubectl edit -n selenium-grid svc selenium-Hub

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

3. 查看修改后的NodePort端口地址:kubectl get svc -n selenium-grid selenium-Hub。如下图所示,NodePort端口为32340(后续MeterSphere界面配置和访问Hub界面需要使用);

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

4. Helm默认部署的Node会话Session为1个,这样远远无法满足并发需求。需要修改会话限制,添加参数:

SE_NODE_MAX_SESSIONS: “30” #这边调整为30,具体可以按照不同Kubernetes配置进行修改

SE_NODE_OVERRIDE_MAX_SESSIONS: “true”

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

5. 删除不同浏览器Node的POD加载最新的ConfigMap配置文件,快速删除POD命令如下:

kubectl get pod -n selenium-grid |grep Node|awk ‘{print $1}’|xargs kubectl delete pod -n selenium-grid

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

6. 如果Kubernetes集群配置较大,我们还可以添加不同浏览器Node的副本数来提高不同Node的数量,从而满足更大的并发需求。例如添加Chrome Node副本数:

kubectl scale deployment -n selenium-grid –replicas=3 selenium-chrome-Node

7. 上述操作完成后,打开Hub界面进行确认部署是否完成,打开方式为:
http://k8s-worker:Nodeport。

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

七、MeterSphere界面配置与测试验证

■ 界面配置

使用管理权限登录MeterSphere平台,选择“系统设置”→“系统参数设置”,在界面中配置Hub地址:

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

■ 测试效果

打开UI测试界面,同时运行多个UI自动化测试,并且关闭性能模式,观察Hub状态界面,显示已经同时运行多个Session。

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

MeterSphere平台中UI测试报告如下,可以看到所有功能都在正常运行:

产品解读丨MeterSphere UI测试模块的设计与分布式扩展

八、总结

MeterSphere一站式开源持续测试平台完全兼容了Selenium的UI自动化测试体系,对Selenium框架进行了简化和封装,实现了开箱即用,操作也更加简单方便。

可以说,MeterSphere的UI测试功能模块成功将Selenium从工具转变为了平台,满足企业在学习、管理UI测试方面的实际需求。同时,MeterSphere还支持原生的Selenium Gird分布式方案,并且满足企业对UI自动化的高并发需求。

Posted in 持续测试, 观点