基于luckyframe二开大规模UI自动化实践

czx758

已于 2024-08-21 16:12:33 修改

阅读量1k

点赞数 12

文章标签： ui 自动化

于 2024-01-31 12:00:04 首次发布

本文链接：https://blog.csdn.net/qq_34418450/article/details/135946304

版权

项目背景

公司的老项目，toB项目，已经运维有十个年头，客户数量规模一百多家，目前大版本有三个主要的对外发布代码分支，加上trunk主干的分支，还有大大小小的客户个性化定制的若干版本。整个测试团队总共才十五个人左右，要想靠人工回归版本工作量巨大，所以领导决定引入UI自动化测试进行版本回归测试。

第一个UI自动化测试版本

UI自动化测试第一个版本是基于testng和selenium框架做的，UI测试用例是用java代码写的，每个测试用例对应了一个class。随着UI用例数量越来越多，当时UI用例已经有一千多个class类了，用例难以管理。虽然使用了多线程，但是随着用例数量规则越来越大自动化执行速度还是越来越慢。在应对多个代码分支的时候也束手无策。基于上面的痛点，决定引入平台化的自动化测试，调研了市面上的自动化UI测试，最终选择了luckyframe，在luckyframe基础上进行二次开发，废弃了testng的老的那一套。

平台化

用例执行速度问题优化
uckyframe自身支持执行机横向扩展，基本解决了用例执行速度问题，但是随着测试计划增多，目前有七十多个测试计划，单个代码分支版本的UI用例有1000+的数量，在测试资源不够充足的情况下，当前有四台执行机，想要执行完一次调度七十多个计划，那么每台执行机需要同时运行十几个任务计划，这会导致执行机卡死。同时，四台机器怎么分配任务计划也是个大问题，因为每个测试计划包含的用例数量不一，执行时间也不一样，怎么平均分配到每个执行机器上，理想情况是每个执行机都分配均衡。基于以上痛点，在参数管理增加一个参数，控制每个执行机同时可执行的任务数量。增加任务调度管理功能，所有的测试任务执行都通过任务调度来管理执行，如果超出客户端可执行的任务数量或者执行机不通，就排队等待执行，这样在执行一个版本回归测试的时候可以直接运行全部测试任务调度。为了解决计划执行机分配不均问题，在任务调度管理增加备选客户端IP的选择，支持多选，在主选择的客户端没有空闲的时候，选择有空闲的其他备选客户端。改造完成后，原本需要八个小时左右的运行时间，压缩到了两个小时内。
```
![!\[调度管理\](https://img-blog.csdnimg.cn/direct/554faf9899cf4b819d76b93d585c1342.png](https://img-blog.csdnimg.cn/direct/ea6311a40dc7465b8928c0ce4bdf5d68.png)
```

在这里插入图片描述

用例写作

引入了page object设计模式，即PO。需要规范元素命名规则，在导入页面元素或者新增页面元素后，在用例写作时候可以直接引用，这样可以很大提高用例的复用性，同时元素有变动后修改起来也很方便，只需要修改PO就行，不需要在所有涉及到的用例，这也是PO的优点所在。

在这里插入图片描述

不同代码分支问题

增加了一个项目复制的功能，在项目添加的时候可以选择复制项目选项，复制选择的项目的全部相关的，如测试步骤，测试计划，任务调度，PO等等，然后在此基础上就行微调就行，解决多个代码分支有些许不同的差异问题。
在这里插入图片描述

踩过的坑

在大批量测试用例执行时，selenium3.x的版本会出现socket通讯超时然后卡死的问题，需要升级到4版本，之前有在
luckyframe提过issue: https://gitee.com/seagull1985/LuckyFrameWeb/issues/I521S8，目前官方还未升级需要自己动手升级。
大批量用例执行时候可能会出现的这个问题，百度了下是端口满了，调大了待观察效果。

后续看情况再更新。