很多测试同学不是不想做 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 等方式去获取。
真实项目里，常见问题非常多。
- 控件层级复杂
你在页面上看到的是一个按钮。
但底层结构可能是这样：
FrameLayout
LinearLayout
FrameLayout
ViewGroup
View
肉眼看是“搜索按钮”，控件树里可能只是一个普通 View。
没有明确的 text。 没有稳定的 resource-id。 content-desc 也不一定有。
最后很多同学只能写一堆又长又脆弱的 XPath。
这种脚本不是不能跑，而是非常不稳定。
页面稍微一改，脚本就挂。
- 元素属性不稳定
很多 APP 的 resource-id 并不稳定。
今天是这个 ID。 明天发版以后就变了。 测试环境一个样，生产环境又是另一个样。
如果自动化脚本强依赖这些不稳定属性，维护成本会非常高。
结果就是：
写脚本 1 小时，维护脚本 3 小时。
最后团队对自动化越来越没信心。
- 混合渲染页面不好识别
现在很多 APP 都不是纯 Native 页面。
电商、金融、内容、外卖、企业内部 APP，经常会用到：
WebView；
Weex；
Flutter；
React Native；
自研动态化框架。
这类页面最大的问题是：
页面上明明有按钮，但 UiAutomator 可能看不到内部元素。
也就是说，不一定是你代码写错了，而是底层识别方式就拿不到完整页面结构。
如果不先判断页面技术实现，就盲目写 Appium 脚本，很容易越写越崩溃。
- 自动化资产很难沉淀
很多团队做 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-id；
content-desc 是否可用；
页面是否是 WebView / Flutter / Weex 这类混合渲染；
是否只能通过坐标、图像识别或接口辅助处理；
这个场景是否值得做端到端自动化。
只有先把页面结构看明白，后面的 Appium 脚本、pytest 用例、CI 回归才有稳定基础。
举个例子，一个搜索入口，如果能拿到类似这样的信息：
那就可以优先考虑用 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 自动化才真正从个人脚本变成团队质量保障能力。
很多测试同学以为自动化就是写脚本。
但在企业里，真正有价值的是：
脚本能不能稳定跑，失败能不能定位，结果能不能被团队使用。
五、实操示例：从页面分析到用例执行
下面用一个简化版链路说明思路。
假设我们要测：
首页搜索商品 → 进入商品详情页 → 点击立即购买 → 进入订单确认页
注意，这里只是演示自动化链路设计思路。
真实项目中，不建议直接在生产环境触发真实下单和真实支付。
- 连接设备
先确认手机开启 USB 调试，然后执行：
adb devices
正常情况下会看到：
List of devices attached
8E3NXXXXX device
如果显示 unauthorized，需要在手机上确认调试授权。
- 启动 Appium 服务
安装 Appium：
npm install -g appium
安装 UiAutomator2 驱动：
npx appium driver install uiautomator2
启动服务：
npx appium
默认地址通常是：
安装 Python 依赖
pip install appium-python-client selenium pytest
建议使用独立虚拟环境，避免和其他项目依赖冲突。编写 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",
options=options
)
return driver
这里需要根据实际 APP 修改：
app_package
app_activity
device_name
- 编写核心链路用例
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 自动化里最容易踩的坑
- 购物车页面识别不到元素
很多电商 APP 的购物车页面不是纯 Native。
你可能看到页面上有“结算”按钮，但控件树里识别不到。
这时不要一直死磕 XPath。
更合理的做法是：
先判断页面是否可识别；
如果不可识别，考虑换链路；
比如从详情页直接走“立即购买”；
或者用接口辅助构造购物车数据；
再进入订单确认页做校验。
自动化不是必须完全复制手工路径。
只要能验证核心风险点，就可以选择更稳定的实现方式。
- 坐标点击用得太多
坐标点击确实简单。
但它最大的问题是不稳定。
不同机型、不同分辨率、不同状态栏高度、不同系统字体，都可能影响坐标位置。
所以坐标点击只能作为兜底，不要作为主定位方式。
- 只校验页面跳转，不校验业务结果
很多自动化脚本看起来跑通了，但其实没有有效断言。
比如只判断进入了订单确认页，却没有校验：
商品名称是否正确；
商品价格是否正确；
收货地址是否正确；
优惠是否生效；
支付方式是否正确；
运费是否正确。
这种自动化只能证明“页面能打开”，不能证明“业务是对的”。
真正有价值的自动化，一定要有业务断言。
- 在生产环境跑危险链路
涉及真实支付、真实下单、真实退款、真实优惠券、真实账户权益的链路，一定要谨慎。
更推荐：
测试环境执行；
沙箱支付；
测试账号；
测试商品；
可回滚数据；
接口辅助清理数据。
不要为了自动化，给线上业务制造风险。
- 只写脚本，不做封装
很多 APP 自动化刚开始能跑，后面跑不动，问题就出在这里。
所有逻辑都写在一个测试文件里。 所有定位都散落在用例里。 页面变化一次，要改十几个地方。
这种脚本跑得越多，维护越痛苦。
更合理的方式是逐步做封装：
页面对象封装
公共操作封装
等待方法封装
断言方法封装
截图日志封装
测试数据封装
自动化不是把手工步骤硬翻译成代码，而是把测试流程工程化。
七、AI 时代，APP 测试人的能力要怎么升级？
以前做 APP 测试，重点是：
会写用例
会执行测试
会提 Bug
会做回归
现在只会这些，已经不够了。
AI 时代的测试人，需要把能力往三个方向升级。
- 从执行测试升级到测试设计
AI 可以帮你生成用例初稿，但判断用例有没有价值，还是要靠测试人员。
你要能判断：
哪些链路是高风险链路；
哪些场景必须自动化；
哪些场景适合手工探索；
哪些页面不适合自动化；
哪些断言才是真正有价值的断言。
测试设计能力会越来越重要。
- 从手工回归升级到自动化回归
重复性的主流程回归，不应该长期靠人肉点击。
测试人员应该逐步把稳定链路沉淀成自动化资产。
比如：
登录链路
搜索链路
下单链路
支付前校验链路
订单查询链路
个人中心链路
这些链路不一定一开始就做得很完美。
但只要能稳定跑起来，就能慢慢迭代。
- 从单点脚本升级到测试平台能力
测试开发真正的价值，不是写几条脚本。
而是把脚本背后的能力平台化：
用例管理
设备管理
任务调度
执行记录
失败截图
日志采集
报告分析
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 测试开发，都能迁移复用。
