通用技术 UI 自动化稳定性用例实战经验分享!

king158 · 2021年07月03日 · 最后由 maomaokeen 回复于 2021年08月06日 · 1036 次阅读

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

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

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

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

  • 操作界面非预期的弹框、广告、浮层
  • 页面元素发生了变化
  • 测试数据原因
  • 页面控件点击失效或者未加载出来
  • 测试系统的 A/B 策略

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

  • 系统层面、第三方软件一些意外弹框,例如第三方软件的广告、系统权限提示、系统更新提示

    • 解决方案:
      • 关闭系统更新、浏览器更新
      • 尽量不要安装非必要的第三方软件,目前第三方软件常用推送广告
      • 保证测试机器干净,减少非必要的异常出现
  • 测试软件本身弹框,例如详情页根据用户画像,自动推送一些广告弹框,这种一般很难知道在什么时候会出现,导致测试用例执行不成功

    • 解决方案:
      • 增加黑名单机制,将遇见过得弹框都记录到黑名单里面,在元素定位封装时增加黑名单判断
      • 自动失败异常弹框算法
      • 增加用例失败重试机制,结合上面两种方案

页面元素发生了变化

  • 页面增加新功能,导致页面元素发生改变
    • 解决方案:
      • 尽量不要使用元素本身的 ID、name、class 定位,尽量使用 xpath 定位方式
      • 采用模糊匹配
      • 采用组合定位策略
  • 开发修改了元素名称 (公司将前端改写成了 vue)

    • 解决方案:
      • 使用不改变的值进行定位,例如控件的文本,例如不管怎么改,登录 文案不会改变
      • 如果是页面改版,就需要修改定位
  • 终极解决方案

    • 定时扫描页面元素是否发生改变,使用 page_source 获取页面元素分析,一旦改变是否影响用例执行,及时修改用例

测试数据原因

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

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

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

测试系统的 A/B 策略

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

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

总结:

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

以上为内容纯属个人理解,如有不足,欢迎各位大神指正,转载请注明出处!

共收到 12 条回复 时间 点赞

xpath 说实话,如果设置不好,比 id 等其他属性更不稳定。

因为 xpath 自身带结构的,页面上其他元素发生变化也可能导致 xpath 结构变化,并且在不同的手机和系统版本,结构也很可能不一样,导致生成的 xpath 不一样

想请教几个问题:

  • 什么叫自动失败异常弹框算法?
  • 如果脚本增加智能等待和重试机制后,仍然没有用怎么办?

头一回看到要求写 xpath 的。。。。

页面增加新功能,导致页面元素发生改变
解决方案:
尽量不要使用元素本身的 ID、name、class 定位,尽量使用 xpath 定位方式

这个和我的认知不大一样。可以分享下具体什么场景下, xpath 定位比 id、name 要好?

陈恒捷 回复

是这样的,我猜他认为的 xpath,大概是类似于正则匹配的那种,包含某个关键词,这样去搜索,

提个方案:一个元素设置多个定位方法,哪个方法定位到元素就用哪个

陈恒捷 回复

这样做的场景

  • 这个可能是我目前公司适用的特例,我们目前 web 前端目前都是采用 Vue 写的,大部分元素没有对应的 ID、name,其中 class 又都是一样的,所以大部分定位都是采用 xpath 的模糊规则、组合规则匹配进行的定位这种要求。 目前页面HTML源码
  • 由于历史原因,前端有些代码不规范 (有些是历史久远外包做的),导致很多 id、name 那些命令重复
  • 什么叫自动失败异常弹框算法?
    • 主要是针对一些弹框的自动识别操作的功能封装,这里面对于弹框、广告、浮层这些异常处理,里面包含黑名单、自动识别并处理,如在 web 界面,HTML 界面弹框的层级是最高,通过这个来进行一些处理。
  • 如果脚本增加智能等待和重试机制后,仍然没有用怎么办?
    • 这种情况下载,我们就得分析我们的重试机制里面是否完善,一般来说定位不到,总会有原因。
king158 回复

哦哦,明白。如果是 web 前端 +vue,确实得用 xpath ,因为 template 里一个组件,实际对应 html 好几层结构了。

king158 回复

谢谢~

1.您的意思是 封装这样子的功能“如果用例失败,首先检查是否有在黑名单中的弹窗,如果存在,则优先处理弹窗” 吗?

2.重试机制是等所有用例运行完之后,重新运行所有失败用例,但是下一次仍然存在网络的原因,导致定位不到,还有就是当一个用例失败,马上重新运行,这个我也试过了,也是网络的原因会导致定位不到

  • 定位失败了,才会去走其他逻辑,只要成功就直接会跳出定位逻辑代码
  • 用例运行失败,一般不会立即重新执行,这种大概率会失败,可以延时再去重试执行或者执行完成之后在执行一次失败的用例,这个前面都有人实现了

使用 page_source 获取页面元素分析元素是否发生改变,即使发现了元素改变了,也无法自动生成新的定位啊,何必去特意检查,运行的时候不久能发现么

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册