Skill 2：会判断页面是否适合自动化不是所有 APP 页面都适合用同一种自动化方式处理。有些页面是 Native，可以直接通过 Appium 定位元素。 有些页面是 WebView，需要切换 Context。 有些页面是动态渲染，普通控件树可能看不到内部元素。 有些页面涉及支付、风控、验证码，不适合直接走真实链路。所以测试人员要先判断：这个页面能不能被识别？这个按钮有没有稳定定位属性？这个链路是否适合端到端自动化？是否需要接口辅助造数据？是否需要 mock、埋点、日志或图像识别兜底？自动化不是把所有手工操作都翻译成脚本。真正有效的自动化，是选择适合自动化的场景，把高频、稳定、重复的链路沉淀下来。比如电商 APP 里：首页搜索商品 ↓进入商品详情页 ↓点击立即购买 ↓进入订单确认页 ↓校验商品、价格、地址、运费等信息这类主链路就比较适合做自动化回归。但真实支付、真实退款、真实优惠券核销，就不能随便在生产环境跑自动化。测试人员要能判断：什么能自动化；什么不能自动化；什么需要换策略自动化；什么应该交给接口、日志或人工探索来覆盖。这一步判断做不好，后面脚本写得越多，风险反而越大。Skill 3：会设计元素定位策略APP 自动化里，元素定位不能只靠 XPath。更推荐的优先级是：resource-id ↓accessibility id / content-desc ↓稳定文本 text ↓组合定位 ↓XPath ↓坐标点击兜底为什么不建议一上来就用 XPath？因为 XPath 对页面层级非常敏感。页面结构稍微变化，XPath 就可能失效。坐标点击也一样，只适合作为兜底方案。不同分辨率、不同系统字体、不同机型适配，都可能导致坐标不稳定。测试开发同学真正要做的，不是“能点到就行”，而是设计一套稳定、可维护、可复用的定位策略。比如有稳定 ID 时，优先使用：driver.find_element(AppiumBy.ID, "com.xxx:id/search_box")如果没有稳定 ID，但有 content-desc，可以使用：
发布于 北京
分享
评论
赞
未登录
友善发言
评论
加载中
