一、APP 自动化为什么比 Web 自动化更容易劝退？做 Web 自动化时，很多人习惯了打开浏览器开发者工具。看 DOM、看 id、看 class、看文本，定位路径相对清晰。但 APP 不一样。APP 页面里的元素结构，需要通过 Android 调试工具、UiAutomator、Appium Inspector 等方式去获取。真实项目里，常见问题非常多。1. 控件层级复杂你在页面上看到的是一个按钮。但底层结构可能是这样：FrameLayout LinearLayout FrameLayout ViewGroup View肉眼看是“搜索按钮”，控件树里可能只是一个普通 View。没有明确的 text。 没有稳定的 resource-id。 content-desc 也不一定有。最后很多同学只能写一堆又长又脆弱的 XPath。这种脚本不是不能跑，而是非常不稳定。页面稍微一改，脚本就挂。2. 元素属性不稳定很多 APP 的 resource-id 并不稳定。今天是这个 ID。 明天发版以后就变了。 测试环境一个样，生产环境又是另一个样。如果自动化脚本强依赖这些不稳定属性，维护成本会非常高。结果就是：写脚本 1 小时，维护脚本 3 小时。最后团队对自动化越来越没信心。3. 混合渲染页面不好识别现在很多 APP 都不是纯 Native 页面。电商、金融、内容、外卖、企业内部 APP，经常会用到：WebView；Weex；Flutter；React Native；自研动态化框架。这类页面最大的问题是：页面上明明有按钮，但 UiAutomator 可能看不到内部元素。也就是说，不一定是你代码写错了，而是底层识别方式就拿不到完整页面结构。如果不先判断页面技术实现，就盲目写 Appium 脚本，很容易越写越崩溃。4. 自动化资产很难沉淀很多团队做 APP 自动化，是“项目制”的。这个 APP 写一套。 换个 APP 再写一套。 这个页面重新找元素。 那个页面重新写脚本。时间久了，脚本越来越多，但真正可复用的方法很少。这也是为什么很多测试团队做了几年自动化，最后还是靠人肉回归。
发布于 北京
分享
评论
赞
未登录
友善发言
评论
加载中
