APP 自动化第一步就卡住？测试人必须掌握的 5 个 APP 测试 Skills

很多测试同学不是不想做 APP 自动化。而是刚准备动手第一步就被劝退了。老板说这次发版前把购物车链路再回归一下。 首页搜索商品 → 进入详情页 → 加入购物车 → 确认下单跑一遍看看有没有问题。手工测很熟。打开 APP点搜索框输入商品进详情页加购物车去结算几分钟就结束。但问题是这条链路不是只跑一次。一次迭代跑一遍灰度前跑一遍发版前再跑一遍。 一个版本至少三轮一条链路可能就要花掉半小时以上。如果项目里有几十条核心链路测试时间基本就被这些重复点击吃掉了。于是很多测试同学都会想到一个方向要不把这些稳定的核心链路做成 APP 自动化想法很好。但真正动手时第一步就卡住了。不是 Python 不会写。 不是 pytest 不会用。 也不是 Appium 完全没接触过。而是一个非常现实的问题这个按钮到底怎么定位打开 UIAutomatorViewer截图加载失败。 换 Appium Inspector设备终于连上了但控件树里全是 FrameLayout、ViewGroup、View。一个“立即购买”按钮翻了半天找不到稳定的 resource-id。 随便写一个 XPath跑起来直接 NoSuchElementException。再找再试再失败。更扎心的是好不容易定位到了APP 一升级控件 ID 变了页面是 WebView、Weex、Flutter 渲染很多元素根本抓不到本地能跑换台手机就挂换一个 APP又要重新分析页面结构自动化还没开始半天时间已经耗在找元素上。所以很多 APP 自动化项目最后不是死在框架上而是死在第一步元素定位和页面结构分析。APP 自动化到底为什么容易跑不稳测试人做 APP 自动化前要先补哪些能力AI 时代APP 测试怎么从手工回归升级到自动化和智能化测试。这里说的APP 测试 Skills不是指某个现成脚本包也不是某个一键生成工具。它指的是测试工程师做 APP 自动化时必须掌握的一组核心能力。工具会变框架会变但这些能力不会过时。一、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经常会用到WebViewWeexFlutterReact Native自研动态化框架。这类页面最大的问题是页面上明明有按钮但 UiAutomator 可能看不到内部元素。也就是说不一定是你代码写错了而是底层识别方式就拿不到完整页面结构。如果不先判断页面技术实现就盲目写 Appium 脚本很容易越写越崩溃。4. 自动化资产很难沉淀很多团队做 APP 自动化是“项目制”的。这个 APP 写一套。 换个 APP 再写一套。 这个页面重新找元素。 那个页面重新写脚本。时间久了脚本越来越多但真正可复用的方法很少。这也是为什么很多测试团队做了几年自动化最后还是靠人肉回归。二、APP 自动化的正确起步不是上来就写脚本很多同学做 APP 自动化习惯一上来就问Appium 怎么写 Python 脚本怎么写 这个按钮怎么 click但成熟的 APP 自动化不应该直接从写脚本开始。更合理的路径应该是页面结构分析 ↓ 元素定位策略设计 ↓ 测试链路拆解 ↓ 自动化脚本实现 ↓ 执行报告沉淀 ↓ 失败分析与持续维护也就是说自动化真正的起点不是代码而是你能不能把页面结构看清楚。页面结构看不清楚后面写多少脚本都是在赌。所以测试工程师必须先补齐一个核心能力快速分析 APP 页面结构并判断这个页面是否适合自动化。三、测试人必须掌握的 5 个 APP 测试 Skills这里说的 Skills不是某个可以直接下载的开源工具包。它更像是一份能力清单。如果你想把 APP 自动化真正做起来而不是写几条跑不稳的脚本下面这 5 个能力一定要补上。Skill 1会分析 APP 页面结构APP 自动化的第一步不是直接写脚本而是先看清楚当前页面能暴露出哪些元素信息。常见信息包括信息作用resource-id常用的元素定位属性之一content-desc常用于 accessibility id 定位text可用于文本定位class判断元素类型clickable判断元素是否可点击bounds判断元素坐标范围enabled判断元素是否可操作selected判断元素是否被选中很多测试同学写 APP 自动化之所以痛苦不是不会写代码而是没有先把页面结构分析清楚。一个页面能不能自动化先要看关键按钮能不能被识别有没有稳定的 resource-idcontent-desc 是否可用页面是否是 WebView / Flutter / Weex 这类混合渲染是否只能通过坐标、图像识别或接口辅助处理这个场景是否值得做端到端自动化。只有先把页面结构看明白后面的 Appium 脚本、pytest 用例、CI 回归才有稳定基础。举个例子一个搜索入口如果能拿到类似这样的信息android.view.View content-desc搜索 clickabletrue bounds[32,128][680,190] /那就可以优先考虑用 accessibility id 定位driver.find_element(AppiumBy.ACCESSIBILITY_ID, 搜索).click()但如果页面里只有一堆 View没有可用 text、没有 content-desc也没有稳定 resource-id就要谨慎了。这类页面不是不能测而是要换策略。比如通过接口提前构造数据只覆盖 Native 可识别区域借助日志、埋点、接口断言做结果校验必要时用图像识别或坐标作为兜底对不稳定页面做风险标记而不是盲目自动化。这就是页面结构分析的价值。不是为了炫技而是为了让你在写脚本前先判断这条路能不能走。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可以使用driver.find_element(AppiumBy.ACCESSIBILITY_ID, 搜索)如果必须用 XPath也要尽量避免写过长、过深、强依赖层级的 XPath。比如这种 XPath 就很容易失效driver.find_element( AppiumBy.XPATH, /hierarchy/android.widget.FrameLayout/android.widget.LinearLayout/android.widget.FrameLayout/android.view.ViewGroup/android.view.View )一旦页面层级变化用例就挂了。更好的方式是尽量基于稳定属性定位或者做一层封装让定位变化时只改一个地方。自动化用例能不能长期维护很多时候就取决于定位策略是否合理。Skill 4会把手工链路拆成自动化链路手工测试时我们习惯这样描述搜索商品加购物车提交订单。但自动化不能只写这么一句。它需要拆成更细的步骤启动 APP ↓ 等待首页加载完成 ↓ 定位搜索入口 ↓ 输入搜索关键词 ↓ 触发搜索 ↓ 等待搜索结果页加载 ↓ 选择商品 ↓ 等待详情页加载 ↓ 点击立即购买 ↓ 进入订单确认页 ↓ 校验关键字段每一步都要考虑等待条件是什么元素定位是否稳定页面跳转如何判断失败后如何截图断言应该放在哪里数据如何准备和清理。这就是手工测试和自动化测试的差别。手工测试靠经验走流程。 自动化测试要把经验变成稳定的工程流程。很多人写 APP 自动化不稳定不是因为代码能力差而是链路拆得太粗。比如只写点击搜索 点击商品 点击购买 判断提交订单按钮存在看起来跑通了但其实没有验证核心业务。真正有价值的自动化至少要校验是否进入了正确页面商品名称是否一致商品价格是否正确地址信息是否存在运费是否展示优惠信息是否正确页面异常时是否有提示。自动化不是只证明“我点过去了”。而是要证明这个核心业务链路在关键数据和关键状态上是正确的。Skill 5会用 AI 辅助测试设计和脚本生成AI 时代测试人不应该只把 AI 当聊天工具。在 APP 自动化场景里AI 很适合辅助做几类事情根据业务流程生成测试点根据页面元素信息生成用例初稿根据接口文档补充数据构造思路根据报错日志分析失败原因根据页面截图补充异常场景根据已有脚本生成封装建议。比如你把页面结构、业务流程、关键断言告诉 AI它可以帮你初步生成冒烟用例 回归用例 异常用例 边界用例 端到端链路用例但这里要注意AI 生成的是初稿不是最终稿。测试人员必须审核业务逻辑是否正确断言是否有效数据是否可控是否会误触真实支付是否遗漏异常场景是否适合接入 CI。AI 能提升效率但不能替代测试设计能力。真正有价值的测试人不是只会问 AI而是能把 AI 生成的内容变成可执行、可维护、可落地的测试资产。比如 AI 给你生成了一段 Appium 脚本你不能直接复制就跑。你要继续判断定位方式是否稳定等待方式是否合理是否需要封装 Page Object是否需要截图日志是否需要失败重试是否需要接入报告是否适合团队复用。这才是 AI 测试开发真正应该做的事情。四、一个典型 APP 自动化链路应该怎么规划以电商 APP 为例。不要一上来就做全量自动化。很多团队做自动化失败就是因为一开始目标太大登录、搜索、购物车、下单、支付、售后、消息、个人中心全都自动化。听起来很完整落地时很容易崩。更稳妥的方式是分阶段建设。第一阶段先跑通冒烟链路优先覆盖启动 APP 首页加载 搜索商品 进入详情页 进入订单确认页这一阶段目标不是覆盖所有功能而是先把主流程跑通。只要能稳定跑起来就已经解决了从 0 到 1 的问题。很多测试团队最缺的不是“大而全”的自动化平台而是一条真正能稳定跑起来的核心链路。第二阶段扩展核心回归链路当冒烟链路稳定之后再继续扩展登录 搜索 商品详情 购物车 优惠券 地址选择 订单确认 订单列表这一阶段重点是提高覆盖率。但仍然要注意涉及真实支付、真实资金、真实权益的动作不建议在生产环境直接自动化执行。更合理的方式是使用测试环境沙箱支付测试账号测试商品可回滚测试数据接口辅助造数和清理数据。第三阶段补充异常和边界场景核心链路稳定后可以继续补充网络异常 空结果 库存不足 优惠券不可用 地址缺失 登录过期 接口超时 重复点击 页面返回这些场景靠手工测很容易漏。但如果能沉淀成自动化回归资产价值非常高。尤其是登录过期、网络异常、接口超时、重复点击这类问题经常会在版本迭代中反复出现。第四阶段接入持续集成和报告最后再接入pytest Allure 报告 Jenkins / GitLab CI 失败截图 日志采集 失败用例重跑 测试结果通知这个阶段APP 自动化才真正从个人脚本变成团队质量保障能力。很多测试同学以为自动化就是写脚本。但在企业里真正有价值的是脚本能不能稳定跑失败能不能定位结果能不能被团队使用。五、实操示例从页面分析到用例执行下面用一个简化版链路说明思路。假设我们要测首页搜索商品 → 进入商品详情页 → 点击立即购买 → 进入订单确认页注意这里只是演示自动化链路设计思路。真实项目中不建议直接在生产环境触发真实下单和真实支付。1. 连接设备先确认手机开启 USB 调试然后执行adb devices正常情况下会看到List of devices attached 8E3NXXXXX device如果显示 unauthorized需要在手机上确认调试授权。2. 启动 Appium 服务安装 Appiumnpm install -g appium安装 UiAutomator2 驱动npx appium driver install uiautomator2启动服务npx appium默认地址通常是http://127.0.0.1:47233. 安装 Python 依赖pip install appium-python-client selenium pytest建议使用独立虚拟环境避免和其他项目依赖冲突。4. 编写 Driver 配置新版 appium-python-client 推荐这样写from appium import webdriver from appium.options.android import UiAutomator2Options from appium.webdriver.common.appiumby import AppiumBy def create_driver(): options UiAutomator2Options() options.platform_name Android options.device_name Android Device options.app_package com.xxx.xxx options.app_activity .MainActivity options.no_reset True driver webdriver.Remote( http://127.0.0.1:4723, optionsoptions ) return driver这里需要根据实际 APP 修改app_package app_activity device_name5. 编写核心链路用例import time from appium.webdriver.common.appiumby import AppiumBy class TestAppShoppingFlow: def setup_method(self): self.driver create_driver() def teardown_method(self): self.driver.quit() def test_search_to_order_confirm(self): driver self.driver # 点击搜索入口 driver.find_element(AppiumBy.ACCESSIBILITY_ID, 搜索).click() time.sleep(1) # 输入搜索关键词 search_input driver.find_element(AppiumBy.CLASS_NAME, android.widget.EditText) search_input.send_keys(测试商品) time.sleep(1) # 点击搜索按钮 driver.find_element(AppiumBy.ACCESSIBILITY_ID, 搜索).click() time.sleep(2) # 点击搜索结果中的第一个商品 driver.find_elements(AppiumBy.CLASS_NAME, android.view.View)[0].click() time.sleep(2) # 点击立即购买 driver.find_element(AppiumBy.ACCESSIBILITY_ID, 立即购买).click() time.sleep(2) # 校验是否进入订单确认页 assert driver.find_element(AppiumBy.ACCESSIBILITY_ID, 提交订单)这只是一个简化示例。真实项目里不建议大量使用time.sleep()更推荐显式等待from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC WebDriverWait(driver, 10).until( EC.presence_of_element_located((AppiumBy.ACCESSIBILITY_ID, 立即购买)) )显式等待可以减少页面加载慢导致的偶发失败。六、APP 自动化里最容易踩的坑1. 购物车页面识别不到元素很多电商 APP 的购物车页面不是纯 Native。你可能看到页面上有“结算”按钮但控件树里识别不到。这时不要一直死磕 XPath。更合理的做法是先判断页面是否可识别如果不可识别考虑换链路比如从详情页直接走“立即购买”或者用接口辅助构造购物车数据再进入订单确认页做校验。自动化不是必须完全复制手工路径。只要能验证核心风险点就可以选择更稳定的实现方式。2. 坐标点击用得太多坐标点击确实简单。但它最大的问题是不稳定。不同机型、不同分辨率、不同状态栏高度、不同系统字体都可能影响坐标位置。所以坐标点击只能作为兜底不要作为主定位方式。3. 只校验页面跳转不校验业务结果很多自动化脚本看起来跑通了但其实没有有效断言。比如只判断进入了订单确认页却没有校验商品名称是否正确商品价格是否正确收货地址是否正确优惠是否生效支付方式是否正确运费是否正确。这种自动化只能证明“页面能打开”不能证明“业务是对的”。真正有价值的自动化一定要有业务断言。4. 在生产环境跑危险链路涉及真实支付、真实下单、真实退款、真实优惠券、真实账户权益的链路一定要谨慎。更推荐测试环境执行沙箱支付测试账号测试商品可回滚数据接口辅助清理数据。不要为了自动化给线上业务制造风险。5. 只写脚本不做封装很多 APP 自动化刚开始能跑后面跑不动问题就出在这里。所有逻辑都写在一个测试文件里。 所有定位都散落在用例里。 页面变化一次要改十几个地方。这种脚本跑得越多维护越痛苦。更合理的方式是逐步做封装页面对象封装 公共操作封装 等待方法封装 断言方法封装 截图日志封装 测试数据封装自动化不是把手工步骤硬翻译成代码而是把测试流程工程化。七、AI 时代APP 测试人的能力要怎么升级以前做 APP 测试重点是会写用例 会执行测试 会提 Bug 会做回归现在只会这些已经不够了。AI 时代的测试人需要把能力往三个方向升级。1. 从执行测试升级到测试设计AI 可以帮你生成用例初稿但判断用例有没有价值还是要靠测试人员。你要能判断哪些链路是高风险链路哪些场景必须自动化哪些场景适合手工探索哪些页面不适合自动化哪些断言才是真正有价值的断言。测试设计能力会越来越重要。2. 从手工回归升级到自动化回归重复性的主流程回归不应该长期靠人肉点击。测试人员应该逐步把稳定链路沉淀成自动化资产。比如登录链路 搜索链路 下单链路 支付前校验链路 订单查询链路 个人中心链路这些链路不一定一开始就做得很完美。但只要能稳定跑起来就能慢慢迭代。3. 从单点脚本升级到测试平台能力测试开发真正的价值不是写几条脚本。而是把脚本背后的能力平台化用例管理 设备管理 任务调度 执行记录 失败截图 日志采集 报告分析 CI/CD 集成 AI 辅助分析这才是企业真正需要的测试开发能力。八、霍格沃兹测试开发学社是怎么规划这块能力的我们不会把 APP 自动化简单讲成“写几行 Appium 脚本”。因为真实企业里APP 自动化从来不是孤立存在的。它至少涉及Android 调试基础 Appium 自动化框架 元素定位策略 pytest 用例组织 页面对象模型 测试数据准备 失败截图与日志 CI/CD 集成 AI 辅助用例生成 测试平台化建设所以在霍格沃兹测试开发学社的测试开发课程和 AI 测试开发方向里会把这块能力拆成几个层次来训练。第一层APP 自动化基础能力包括Android 设备连接ADB 常用命令Appium 环境搭建UiAutomator2 驱动配置元素定位方式APP 页面结构分析常见连接问题排查。这一层解决的是能不能把 APP 自动化先跑起来。第二层APP 自动化工程能力包括pytest 用例组织Page Object 模式显式等待封装公共操作封装日志与截图失败重跑测试报告生成多设备兼容执行。这一层解决的是能不能让自动化稳定、可维护。第三层APP 自动化场景设计能力包括冒烟链路设计回归链路设计异常场景设计数据构造策略接口辅助测试业务断言设计高风险链路识别。这一层解决的是自动化到底测什么怎么测才有价值。第四层AI 辅助测试能力包括AI 辅助测试点生成AI 辅助用例生成AI 辅助脚本骨架生成AI 辅助失败日志分析AI 辅助测试报告总结AI 与自动化测试结合。这一层解决的是怎么用 AI 提升测试效率而不是只停留在聊天问答。第五层测试平台化能力包括自动化任务管理测试设备管理执行结果管理报告统一展示失败原因归类测试资产沉淀自动化能力平台化。这一层解决的是怎么从个人脚本升级为团队质量平台。九、这篇文章真正想告诉测试人什么APP 自动化不是不会做。很多时候是起步方式错了。如果一上来就写脚本很容易被元素定位、页面识别、环境问题劝退。更合理的思路是先看页面结构 ↓ 再判断自动化可行性 ↓ 再设计定位策略 ↓ 再拆业务链路 ↓ 再写自动化脚本 ↓ 最后接入持续回归AI 工具也好自动化框架也好本质上都只是手段。测试人真正要提升的是测试设计能力自动化工程能力工具化思维AI 辅助提效能力质量平台建设能力。这些能力才是测试开发长期有价值的地方。十、适合哪些同学系统学习如果你现在还停留在每次发版都靠手工回归APP 自动化一直没真正跑起来Appium 环境搭建总是出问题元素定位经常找不到自动化脚本写了但不稳定不知道 AI 怎么结合测试工作想从功能测试往测试开发升级想把自动化做成真正可复用的能力。那就非常适合系统补一下 APP 自动化和 AI 测试开发这块能力。因为未来测试岗位的要求一定不是只会点点点。企业更需要的是能把重复测试流程自动化、工具化、平台化的人。十一、系统学习方式APP 自动化不是拿到一个脚本就能解决的问题。真正落地时测试人员需要系统掌握ADB 常用命令Android 页面结构分析Appium 环境搭建UiAutomator2 驱动配置元素定位策略pytest 用例组织页面对象模型封装APP 自动化常见异常处理失败截图、日志、报告生成AI 辅助测试用例设计自动化与 CI/CD 集成。这些内容我们会在测试开发课程和 AI 测试开发方向里结合真实项目进行讲解和实操。课程学员可以获得对应的学习资料、代码模板、实战案例和老师答疑支持。但我们更建议大家不要只追一个现成工具。因为工具会变框架会变APP 技术栈也会变。真正值得掌握的是这套方法页面怎么分析 元素怎么定位 链路怎么拆解 断言怎么设计 失败怎么排查 脚本怎么维护 AI 怎么辅助提效 自动化怎么平台化这些能力学会了不管以后是做 Appium、接口自动化、测试平台还是 AI 测试开发都能迁移复用。如果你也想系统补齐 APP 自动化、测试开发和 AI 测试开发能力可以关注霍格沃兹测试开发学社后续课程安排。