UI 自动化稳定性用例实战经验分享！

前言：

大家常说 UI 自动化不稳定，那又如何提高稳定性呢？

操作界面非预期的弹框、广告、浮层

测试系统的 A/B 策略

总结：

前言：

稳定性测试是软件测试的一个重要方面，它旨在评估软件在不同负载和压力条件下的稳定性和可靠性。稳定性测试可以通过自动化测试来实现，其中 UI 自动化测试是一种常用的方法。

UI 自动化测试稳定性，最常见的就是同一套测试用例在同样的环境上，时而测试通过，时而测试不通过。这样的测试结果产生了很多无效的缺陷，特别是自动化测试已经与公司内部平台接入了相应缺陷系统，使用对于开发、产品以及 QA 常常说自动化测试做了很多无用功。

要提高 UI 测试稳定性，首先我们需要知道到底是什么原因引起的。尽可能的找出那些引起不稳定因素，然后找到相关不稳定因素对应的解决措施。

根据目前公司的项目实践经验以及遇到的场景，总结了以下几种原因：

系统层面、第三方软件一些意外弹框，例如第三方软件的广告、系统权限提示、系统更新提示
- 解决方案：
  - 关闭系统更新、浏览器更新
  - 尽量不要安装非必要的第三方软件，目前第三方软件常用推送广告
  - 保证测试机器干净，减少非必要的异常出现
测试软件本身弹框，例如详情页根据用户画像，自动推送一些广告弹框，这种一般很难知道在什么时候会出现，导致测试用例执行不成功
- 解决方案：
  - 增加黑名单机制，将遇见过得弹框都记录到黑名单里面，在元素定位封装时增加黑名单判断
  - 自动失败异常弹框算法
  - 增加用例失败重试机制，结合上面两种方案

页面元素发生了变化

页面增加新功能，导致页面元素发生改变
- 解决方案：
  - 尽量不要使用元素本身的 ID、name、class 定位，尽量使用 xpath 定位方式
  - 采用模糊匹配
  - 采用组合定位策略
开发修改了元素名称 (公司将前端改写成了 vue)
- 解决方案：
  - 使用不改变的值进行定位，例如控件的文本，例如不管怎么改，登录文案不会改变
  - 如果是页面改版，就需要修改定位
终极解决方案：
- 定时扫描页面元素是否发生改变，使用 page_source 获取页面元素分析，一旦改变是否影响用例执行，及时修改用例

测试数据原因

主要是用例执行的前置操作未完成，例如用例依赖前面用例执行产生数据或者已有历史数据被其他人删除
- 解决方案：
  - 可以通过 API 生成数据
  - 通过 数据库 生成数据
  - 通过 API 和 数据库 造数据效率比较高且准确，前提对于相应数据库结构和 api 需要比较熟悉

页面控件点击失效或者未加载出来

网络或者服务器偶尔响应比较慢
- 解决方案：
  - 脚本增加智能等待
  - 脚本增加重试机制
页面控件元素点击无效
- 解决方案
  - 增加异常处理，是否点击操作太快、元素是否可见、元素被遮挡等处理
  - 可以增加 1-2 次重复点击，例如第一次点击失败，再点击一次
  - 使用 js 定位操作

由于公司运营活动，每次选择不同的城市进行，导致同一个城市不同时间看见页面不一样，效果也不一样

解决方案
测试用例编写兼容处理，根据不同时期，拿到活动标识，调用不同逻辑进行处理

操作界面非预期的弹框、广告、浮层，主要采用方案：保证测试机器干净、关闭系统更新和增加黑名单机制、自动失败异常弹框算法、失败重试机制
页面元素发生了变化，主要采用方案：采用模糊匹配、使用 xpath 定位、采用组合定位策略、使用 page_source 获取页面元素分析元素是否发生改变
测试数据原因，主要采用方案：通过 API 和 数据库 造数据
页面控件点击失效或者未加载出来，主要采用方案：增加智能等待和重试机制、增加异常处理、使用 js 定位
测试系统的 A/B 策略，主要采用方案：测试用例编写兼容处理