企业官网建设流程全解析

很多人第一次跑通 Appium 脚本的时候，都会觉得这玩意儿挺神奇：一个 Python 脚本发个请求，手机里的 App 就自动打开、自动点击、自动滑动，像是被远程操了盘。但等你真正多踩几次坑，你会发现 Appium 本质上不是什么高深莫测的黑魔法，它就是一个在 WebDriver 协议基础上扩展出来的移动端自动化框架。只是它的坑埋得比较深，尤其是从环境搭建到元素定位，每一步都有那种"明明是按教程来的，怎么到我这儿就报错"的经典剧情。

这篇东西我不想写成一板一眼的官方文档翻译，而是把我从零开始搭 Appium、写脚本、跑测试、处理各种诡异报错的完整经验拆给你看。适合刚入行测试、想转自动化测试，或者已经在用别的工具但想了解 Appium 的人。看这篇之前你最好有一点 Python 基础和一点 Android 基础知识，没有也没关系，我尽量把原理讲透，跟着做也能跑起来。

1. 先搞清楚Appium到底解决了什么问题

移动端自动化测试的选型，这几年翻来覆去就那么几个主流流派：iOS 上有 XCUITest，Android 上有 UIAutomator 和 Espresso，跨平台层面有 Appium、Airtest、Maestro、Kobiton 这类工具。之所以大家最后普遍绕不开 Appium，是因为它的核心设计确实踩对了点：用一套 API 同时驱动 iOS 和 Android。

1.1 为什么是Appium而不是别的框架

你写过 Selenium 的话，上手 Appium 会非常快，因为它们同源。Appium 本质上就是 Selenium 的移动端延伸，它把 WebDriver 协议拿过来，针对移动端的场景做了扩展，比如说滑动、多点触控、锁屏、网络切换、定位权限处理这些 Web 端没有的操作。这个设计的好处是：团队里已经有 Selenium 经验的人，几乎不用重新学一套交互模型，迁移成本极低。

另一个关键点是，Appium 不需要往被测 App 里注入任何代码。它走的是黑盒模式，以"外部驱动"的方式去操作 App，这在很多公司里是刚需。因为被测应用往往是其他团队开发的，你没法为了测试去改人家的源码。这一点也是 Appium 和 Espresso 这类白盒框架最大的区别。白盒框架虽然快，但耦合太重，黑盒框架虽然相对慢一点，但解耦、通用、不动业务代码，这是它在企业级测试体系里站稳脚跟的根本原因。

1.2 Appium能做什么，不能做什么

我把 Appium 的边界先给你划清楚，省得你抱有不切实际的期望：

• 能做：启动/关闭 App、点击/输入/滑动/长按/拖拽、获取控件属性、断言界面状态、处理 WebView 混合页面、执行 JS、模拟电话/短信（部分平台）、模拟 GPS、截屏、录屏、并行跑多设备。
• 不能做：OCR 级别的图像识别（它不是 Airtest 那种基于图像匹配的工具）、性能采集（N 个工具能做，但 Appium 不是专业的）、iOS 上私有 API 的操作。

这里要特别说一句，很多人误以为 Appium 能靠坐标硬点，这个想法很危险。基于坐标的点击脚本，换个分辨率就全军覆没。Appium 真正推荐的定位方式是找控件节点，也就是通过页面元素树里的属性来定位。整个 Appium 的稳定性，其实完全取决于你的定位策略是否合理。

1.3 一个典型的Appium运行链路

当你运行一个 Appium 脚本时，底层的通信链路是这样的：

Python脚本(Client) -> HTTP请求发送给Appium Server -> Appium Server按平台转发给对应Driver -> Android端调用UiAutomator2 / iOS端调用XCUITest -> 驱动框架去执行实际的操作并返回结果

理解了这条链路，你后面排查问题就能有一个基本的定位方向：脚本报错，先看是 Client 的问题还是 Server 的问题，再看是驱动的问题还是设备本身的问题。我把这条链路写得这么直白，是因为很多新手出错之后完全蒙了，不知道去哪个环节找原因，实际上责任边界就是这么清晰。

2. 环境搭建：最容易劝退的一关

Appium 的环境搭建，是劝退率最高的环节。很多人就是卡在这一步，连 Hello World 都没跑通就放弃了。其实整理清楚思路，其实就是装齐"四件套"：移动开发环境、Appium Server、移动端 Driver、客户端库。

2.1 逐项安装和验证

我先给出一份能跑通的基准配置，都以当前稳定版本为例：

这里我说个老生常谈但非常致命的问题：很多人的 path 环境变量配得稀碎。JDK 装好了，但是adb命令在命令行里根本敲不出来；Appium 装好了，但是appium命令找不到。建议把 Android SDK 的platform-tools和emulator目录加到系统 PATH 里，这会省掉后面 90% 的"命令不存在"报错。

2.2 关于Appium 1.x和2.x的差异

网上搜到的大量教程还是基于 Appium 1.x 的，这里必须提醒你一下。1.x 时代，强大的定位引擎、iOS/Android 的所有驱动都是内置的；2.x 做了大瘦身，把各种 driver 拆成了独立安装的插件。这意味着你 1.x 的脚本"开箱即跑"，但 2.x 里如果你没装对应平台的 driver，运行时直接报错。好在 2.x 的驱动安装并不复杂，在命令行执行即可：

appium driver install uiautomator2 appium driver install xcuitest

安装完成后用appium driver list查看，能看到已安装的驱动列表，确认没问题再继续。

2.3 模拟器还是真机

这个问题我直接给结论：初学阶段一定优先用模拟器。模拟器的好处不仅是快，更关键的是你可以随时打开开发者选项里的"指针位置"来看坐标、可以方便地调整分辨率、可以快速重置系统。真机的坑就多了，各种厂商 ROM 对 UiAutomator2 的支持程度不一，华为、小米、OPPO 各种"省电优化""后台清理"能把你的自动化进程杀死。当然，最终上线前还是要跑真机的，但那应该是已经掌握基础之后的阶段。

模拟器我推荐用 Android Studio 自带的 AVD，创建的时候选一个 API 30 左右的镜像，不需要 Google Play 版本（带 Play 的镜像有些系统分区不让写）。创建好之后用emulator -avd 你的设备名启动，或者直接在 Android Studio 里点绿色播放按钮。

2.4 环境验证脚本

装完之后别急着往下学，先做一个环境自检：新建一个最简脚本，什么都不干，只启动一个 App，看看链路通不通。

from appium import webdriver from appium.options.android import UiAutomator2Options options = UiAutomator2Options() options.platform_name = "Android" options.device_name = "emulator-5554" options.app_package = "com.android.settings" options.app_activity = ".Settings" driver = webdriver.Remote("http://127.0.0.1:4723", options=options) print(driver.current_package) driver.quit()

如果你能看到设置 App 被拉起，并且打印出com.android.settings，恭喜，你的环境彻底通了。这一步看着简单，但很多人倒在这一步之前。

3. 懂了这个原理，才算真正会用Appium

很多人用 Appium 停留在"会调 API"的层面，一遇到奇怪的问题就抓瞎。我怀疑是因为他们没搞懂 Appium 的行为逻辑。这一章我把几个核心运行机制拆开讲明白，你后面写脚本、排错会轻松一大截。

3.1 Session机制到底是什么

Appium 里最核心的概念是 Session（会话）。你可以把它理解成"一次测试任务的容器"：Session 启动时，Appium Server 会根据你传入的 Desired Capabilities（期望能力）去创建驱动实例，并建立和设备的连接。Session 的存活期间，所有操作都通过这个 Session 来路由。

Session 的创建，就是你脚本里webdriver.Remote()的那一行。这一行执行成功，意味着 Appium Server 和手机之间已经打通；执行失败，说明你的环境或者能力参数有毛病。后面所有操作如果报"Session 失效"，通常就是你的 Session 超时了或者设备断连了，而不是你的脚本语法错了。

Desired Capabilities 是启动 Session 的"配置清单"，你可以把它理解成告诉 Appium：我要测什么平台、什么设备、什么 App、以什么方式启动。常见的几个选项：

启动 App 有两种方式：一种是直接指向 Apk 安装包路径，Appium 会帮你安装再启动；另一种是指定appPackage和appActivity，只在已安装的应用上启动。日常测试建议第二种，省去了每次重装的时间消耗。

3.2 控件树和定位的关系

网页有 DOM 树，移动端原生界面也有类似的控件层级结构。Appium 通过驱动框架 UIAutomator2/XCUITest 去获取当前界面的"控件树"，然后你再通过 CSS 选择器式的方式（id、xpath、class 等）去匹配想要的元素。这也是 Appium 能跨平台的根本原因：它把不同平台的"原生控件树"统一成了一层抽象结构。

举个例子，界面上的一个"登录"按钮，在 Android 原生里可能叫android.widget.Button，在 iOS 里可能叫XCUIElementTypeButton。Appium 把两边都映射成统一的"Button"类型。你在自动化里用的定位策略，其实都是针对这颗抽象控件树在写查询条件。所以 Appium Inspector 这类工具存在的意义，就是帮你"看到"这颗控件树长什么样、每个节点有哪些属性可以用来定位。

3.3 为什么有时候定位"看不见"的元素会失败

这是新手最容易懵的一个问题。网页里元素没显示出来，你照样可以通过 DOM 操作到它；但移动端不一样，很多控件是"懒加载"的，界面没渲染出来的时候，控件树里压根没有这个节点。所以脚本里经常会看到"等待元素出现"的逻辑。Appium 本身不会帮你处理这种时序问题，你得靠显式等待来手动控制。

后面我会专门讲等待策略，这里先建立这个意识：移动端自动化里，绝大多数 flaky（不稳定）问题都是时序问题，而不是定位表达式写错了。

4. 第一个完整用例：从启动应用到拿到测试结果

纸上谈兵谈完了，接下来走一个真实的用例。我选一个最容易复现的场景：打开系统计算器，做一次加法运算，然后断言结果正确。这个用例不用安装任何额外的第三方 App，只要是 Android 模拟器就自带计算器，环境门槛最低。

4.1 获取包名和Activity

计算器的包名和 Activity 在不同的系统版本里有差异，最常见的路径是这两个：

• 包名：com.android.calculator2
• Activity：.Calculator

你如果不确定，可以用这个命令在真机/模拟器上查：

adb shell "cmd package resolve-activity --brief com.android.calculator2"

或者先手动打开计算器，再执行adb shell "dumpsys window | grep mCurrentFocus"看当前焦点窗口，也能拿到包名和 Activity 的信息。

4.2 核心脚本拆解

下面这段代码是一个完整的运行链路，我逐步拆开讲解。

import time from appium import webdriver from appium.options.android import UiAutomator2Options from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC options = UiAutomator2Options() options.platform_name = "Android" options.device_name = "emulator-5554" options.app_package = "com.android.calculator2" options.app_activity = ".Calculator" options.no_reset = True driver = webdriver.Remote("http://127.0.0.1:4723", options=options) wait = WebDriverWait(driver, 10) try: # 等待并点击数字 7 btn_7 = wait.until(EC.presence_of_element_located((By.ID, "com.android.calculator2:id/digit_7"))) btn_7.click() # 点击加号 btn_plus = wait.until(EC.presence_of_element_located((By.ID, "com.android.calculator2:id/op_add"))) btn_plus.click() # 点击数字 5 btn_5 = wait.until(EC.presence_of_element_located((By.ID, "com.android.calculator2:id/digit_5"))) btn_5.click() # 点击等号 btn_eq = wait.until(EC.presence_of_element_located((By.ID, "com.android.calculator2:id/eq"))) btn_eq.click() time.sleep(1) # 读取结果文本 result_view = driver.find_element(By.ID, "com.android.calculator2:id/result") result_text = result_view.text print("计算结果: ", result_text) assert result_text == "12", f"期望得到12，实际得到{result_text}" print("用例通过") finally: driver.quit()

这段脚本的逻辑就是模拟人操作计算器：点 7，点加号，点 5，点等号，最后读取结果区的文本，断言它等于 12。

这里我用了WebDriverWait来做显式等待，而不是一上来就直接 find。为什么？因为计算器启动过程也是异步的，界面没加载完之前就去找元素，大概率会直接报NoSuchElementException。用显式等待，相当于告诉程序"最多等 10 秒，直到这个元素出现再往下走"，这是移动端自动化里最基础的稳定性保障。

4.3 这个用例里藏着的通用模式

别小看这个"点按钮-断言结果-收尾"的用例，它里面其实涵盖了一套可复用的标准结构：

• 准备阶段：构建 Capabilities，连接到 Appium Server，启动目标 App。
• 操作阶段：等待元素出现，执行点击、输入、滑动等动作。
• 断言阶段：获取界面状态（文本、属性、可见性），与预期值做比对。
• 收尾阶段：清理资源，关闭 Session。

任何一个 App 的功能用例，基本都能套进这个框架里。后面你写几十个用例后回头看，会发现全是这个骨架的变体。

4.4 计算器用例可能出现的坑

• noReset=True很关键：如果你之前手动打开过计算器，App 可能停留在某个历史界面，或者缓存了上一次的计算结果。设置noReset可以避免 App 因为数据残留而进入非预期状态。
• 结果控件的 ID 在不同系统上不同：com.android.calculator2:id/result在 API 30 上验证过，API 33 某些模拟器上可能改成别的 ID。找不到元素时先别怀疑脚本，打开 Appium Inspector 看一眼实际控件树。
• 启动的时候要先清后台：如果你手动开了计算器然后直接跑脚本，App 可能只是从后台切到前台，不会重新走初始化流程。建议测试前先adb shell am force-stop com.android.calculator2，保证 App 是从冷启动开始。

5. 元素定位与等待策略：脚本稳定性的分水岭

如果你已经能跑通上面的用例，那么恭喜你跨过了最基础的门槛。接下来你的主要矛盾，从"怎么跑起来"变成"怎么稳定地跑"。这一章是整篇教程里我最想让你认真看的部分，因为大部分人的自动化脚本死在了定位和等待上。

5.1 各种定位策略的优先级

Appium 支持多种定位方式，不同方式的优先级和稳定性完全不同。我按推荐程度排个序：

这个优先级不是凭空排的。resource-id和content-desc是控件自带的"身份标识"，天然稳定；XPath 虽然灵活，但一碰到界面层级调整就失效，而且解析控件树有性能开销，用多了脚本会明显变慢。

5.2 直接给出一套定位写法的参考

• 优先用By.ID和By.ACCESSIBILITY_ID，这是你 80% 场景的解法。
• class 定位适合批量操作场景，比如"把所有列表项里的文本都取出来"。
• Android 上可以用 UIAutomator 的UiSelector，它能做到"文本包含""后代节点"这类更复杂的关系查询，而且语法比 XPath 简洁。
• iOS 和 Android 的差异要注意：By.ID在 iOS 上没有对应的resource-id，通常得用By.IOS_CLASS_CHAIN或 accessibility id 来兼容跨平台逻辑。

5.3 隐式等待和显式等待到底怎么选

这是一个面试高频题，也是实际脚本里的"稳定性分水岭"。

• 隐式等待（implicitly_wait）：设置一个固定的全局轮询时间。每次 find 元素时，如果没找到，会自动重试直到超时。这个机制看似方便，但它会影响所有 find 操作，而且如果一个元素真的要在第 8 秒才出现，其他不该等的操作也会被拖慢。
• 显式等待（WebDriverWait）：针对特定元素设置最长等待时间和轮询间隔，等待某个条件成立。比如"等按钮可点击"和"等文本出现"，都可以用不同的条件去精确控制。

我的实践建议是弃疗隐式等待，全部用显式等待。虽然代码会多写几行，但它能让你的脚本行为完全可控。你想想：登录按钮在登录请求没有完成之前是不可点击的，用显式等待element_to_be_clickable可以精确表达业务状态，让脚本等得更合理，不容易出现"明明界面还没准备好，脚本就硬点了一下"的尴尬。

5.4 动态内容的处理技巧

App 里永远有一些"会变"的元素：比如带时间的文本、随机生成的订单号、从服务器拉取的列表。这类元素不建议直接用精确文本定位，而是用"包含匹配"或者"父子关系定位"。比如你要点某个订单，可以先找到父容器，再在父容器范围里去匹配子元素，这样就算订单号变了，定位逻辑依然成立。

另外提一句：能用 XPath 解决的，不一定非要用 XPath 解决。在 Android 上，UiSelector 经常会给你惊喜，.textContains("登录")这种写法在可读性和性能上都优于 XPath 的contains(@text, '登录')。

6. 排查问题的思路而非背答案

实际用 Appium 的过程中，你一定会遇到报错。我之前也有一段时间被各种奇怪的报错折腾得头皮发麻，后来总结出一个经验：报错信息是最诚实的路标。它直接告诉你问题出在哪一层，只是很多人看报错只看最后一行，而真正的线索在中间或前面。

6.1 最常见的5类报错和定位链路

第一类：连不上 Appium Server。报错多为Connection refused或ECONNREFUSED。排查链路：Appium Server 是否真的在运行？端口是不是 4723？如果改了端口，脚本里对应地址改了吗？用curl http://127.0.0.1:4723/status可以快速确认 Server 是否活着。

第二类：Capabilities 无效。报错多为The desired capabilities were not recognized。大概率是某个 capability 名字写错了，比如把platformName写成了platform，或者把appPackage写成了package。去和官方文档对一遍拼写就好。

第三类：元素找不到。报错多为NoSuchElementException。排查链路：打开 Appium Inspector，看当前界面是不是你以为的那个界面；确认元素是否在当前屏幕上（没滑下去就找不到是正常的）；确认控件树里这个元素是否存在，而不是被content-desc或text属性伪装成了别的样子；最后再看是不是时序问题——元素还没加载出来，等待时间不够。

第四类：Click 没反应或者报空指针。这大概率是元素被遮挡或者不可点击。比如一个按钮上方悬浮了一层透明的 View，元素是找到了，但点击事件被拦截了。可以用坐标偏移或者等待遮罩消失来解决。

第五类：Session 卡死或闪退。常见于设备断连（模拟器被手动关闭、USB 松动）或者 Appium 服务端因内存问题崩溃。先重启 Server，再检查adb devices里设备是否还在线。

6.2 Appium服务端日志的读法

很多人忽略 Appium Server 的控制台日志，其实这是最强大的排错工具。你跑脚本的时候保持终端开着，出问题时服务端会在日志里打出执行到哪一步、哪个 driver 报了错、底层框架返回了什么原始错误。

拿 Android 驱动的底部日志来说，它会打印类似这样的信息：

[UiAutomator2] Starting 'com.android.calculator2/.Calculator' and waiting for 'com.android.calculator2/.Calculator' to be focused [WD Proxy] Matched '/element' to command name 'findElement' [WD Proxy] Got data with status 200: ...

看到Matched说明请求已经被路由到指定驱动；看到status 200说明底层操作执行成功。如果某一步status非 200，后面通常会跟一个 JSON 格式的错误描述，那里面的信息比你在 Python 里看到的报错更接近根因。

6.3 一个真实的排错过程

我演示一个典型的"元素找不到"排查过程。某次我的脚本点击"登录"按钮时总是报错，用 Appium Inspector 一看，发现界面上确实有"登录"两个字，但它是 TextView 而不是 Button，而我的定位条件写的是class=android.widget.Button。

发现问题后，我不去改 class，而是去给这个 TextView 加text属性定位，或者直接找它的父容器，用父容器 id 来点击。选择后者的原因是，这个 App 的"登录"文案在后续版本可能会被换成"Sign In"，但容器 id 一般不会变。

这种例子很典型：排错的核心不是把报错查一遍，而是搞清楚"界面真实结构"和"你的代码假设"之间的差异。每次报错，先承认代码对界面有某种假设，然后去验证这个假设是否成立，就是最快的排错路径。

6.4 把日志/截图作为标准做法

我强烈建议你在每个用例的关键节点上加上截图逻辑。Appium 截图能力很成熟，一行代码就能拿到当前屏幕的 PNG。当用例失败时，把截图和当时的页面控件树一并保存到测试报告里。这样以后排查问题时，你有的是"现场证据"，而不是空想"当时可能是这个原因"。

import os def save_screenshot(driver, name): screenshot_dir = "screenshots" os.makedirs(screenshot_dir, exist_ok=True) path = os.path.join(screenshot_dir, f"{name}.png") driver.save_screenshot(path) print(f"截图已保存: {path}")

7. 规模化落地要解决的几个问题

当你已经从"跑通一个用例"进化到"能写几十个用例"的阶段后，下一个瓶颈必然是如何规模化、如何维护、如何并行、如何进 CI。这可能是最真实的场景，因为你不可能只写一条脚本就当它是一个"自动化测试项目"了。

7.1 用Page Object模式组织代码

移动端和 Web 端的 PO 模式几乎一致：每个页面封装成一个类，页面上的元素定位和操作方法都收敛在类内部，测试用例只关心业务流程，不直接碰定位表达式。比如登录页可以封装成这样：

class LoginPage: def __init__(self, driver): self.driver = driver def input_username(self, text): self.driver.find_element(By.ID, "username_input").send_keys(text) def input_password(self, text): self.driver.find_element(By.ID, "password_input").send_keys(text) def click_login(self): self.driver.find_element(By.ID, "login_btn").click()

这样做的最大好处是：当某个页面的控件 ID 发生变更，你只需要改一个类，而不需要满项目搜索所有引用。测试用例里一行login_page.click_login()根本不用动。自动化测试项目的最大成本在维护，PO 模式是降低维护成本最有效的手段。

7.2 并行和多设备执行

Appium 天然支持多设备并行。你可以启动多个 Appium Server 实例（不同端口），也可以使用同一个 Server 但每个设备占用一个 Session。并行执行的时候，要注意脚本里不能有硬编码的端口和路径，而是通过配置文件或参数去区分设备。

我这里给一个 Python 层面简单的并行思路：使用concurrent.futures.ThreadPoolExecutor，一个线程跑一台设备，设备 ID 和对应的 Capabilities 从配置里读取。

from concurrent.futures import ThreadPoolExecutor def run_case(device_config): # 每个设备创建一个独立driver执行用例 driver = webdriver.Remote(device_config["server"], options=device_config["options"]) # ...执行用例... driver.quit() devices = [ {"server": "http://127.0.0.1:4723", "options": cfg1}, {"server": "http://127.0.0.1:4724", "options": cfg2}, ] with ThreadPoolExecutor(max_workers=2) as executor: executor.map(run_case, devices)

并行不是免费的午餐。设备越多，Appium Server 的压力越大，资源竞争问题会逐渐暴露。建议先把用例在单机上跑通，再去考虑并行，不要一上来就搞多设备，容易把问题复杂化。

7.3 测试数据管理

移动端自动化里，数据管理比 Web 端更难受。因为 App 安装在设备上，每次跑完用例之后，App 的数据可能会残留，影响下一次运行。解决思路有几个：

• 每条用例尽量构造独立数据目标，比如注册一个新的临时账号，跑完即弃。
• 通过adb shell pm clear 包名在用例前清理 App 数据，保证冷启动。
• 实在不能清理的，就在用例开头先做"回到初始状态"的逻辑，比如退出登录、重置开关。

我见过很多团队，脚本写得挺顺，但一接入持续集成就开始大量报错，最后排查下来 80% 都是脏数据问题。测试数据管理，是自动化从"demo"到"产能"之间的隐形门槛，越早重视越省心。

7.4 接入持续集成（CI）

脚本本地跑得再溜，不接入 CI 都不算完整落地。Appium 在 CI 里跑的难点通常不在脚本本身，而在环境准备。比如在 Jenkins 或者 GitLab CI 里，你需要保证：构建机上有 Android SDK、安装了对应的 driver、有可用的模拟器或者连接了真机。

模拟器在 CI 里最大的痛点是启动速度，通常一个模拟器从启动到完全就绪需要 1-2 分钟。可以尝试在 CI 里用"先启动模拟器再跑脚本"的阶段式流水线，并且设置合理的等待超时。如果用的是真机，还要处理 USB 连接不稳定、设备锁屏、充电策略这些问题。

我个人的经验是：CI 里先只跑"冒烟集"（happy path 的用例），因为冒烟集覆盖的是核心链路，跑得快，失败后反馈成本低；全量回归可以放到 nightly 或者按需触发。很多团队犯的错误是一上来就把几百条用例全扔进 CI，结果每次流水线跑一个小时，失败一堆，维护的人索性不看报告了，自动化也就废了。

8. 一些容易忽略但实际很重要的建议

最后这部分，我把自己这几年用 Appium 的一些零散经验整理成建议，虽然分散，每一条都是我掏过学费换来的。

关于 Inspector 的使用时机：很多人用 Appium Inspector 只是为了看控件树，但它其实还能直接录制脚本、验证定位表达式、查当前界面的层级关系。新版本 Inspector 已经支持在 Appium 2.x 上直接连接到运行中的 session，这个功能在调试阶段非常省时间。

关于 XPath 的性能：当页面层级很深、控件很多的时候，XPath 解析会很慢。一个聪明的做法是先用 id 定位到靠近目标的容器，再在容器内用相对 XPath 去找目标元素。缩小搜索范围是提高速度的有效手段，而不是把希望寄托在整棵树的绝对路径上。

关于手机性能对脚本的影响：同样的脚本，在高端旗舰机和低端机上跑，点击之后的响应时间差异可能达到几秒。如果你在 CI 环境里混合了不同档位的真机，等待时间必须预留足够余量，或者按设备类型做不同的超时配置。模拟器和真机的性能差异更是天壤之别，脚本在中低端机上如果频繁报超时，先别慌着改逻辑，考虑一下设备性能因素。

关于 Appium 和 Airtest 的取舍：如果你以后遇到"图片验证码""滑块验证""游戏内按钮"这类没有标准控件树的对象，Appium 会吃力。这种情况，Airtest 这类基于图像识别的工具反而更好用。不是非此即彼，团队里两种工具共存也是常见操作。工具是用来解决问题的，而不是用来信仰的。

关于维护成本和收益的清醒认知：自动化测试在 UI 频繁变动的早期阶段，是很鸡肋的：界面改一次，脚本坏一片。我个人建议的节奏是：功能趋于稳定后，再开始补 UI 自动化；功能还在快速迭代时，优先把手动回归和接口自动化做好。Appium 的价值在"回归"，而不是"探索"。

回头看看，Appium 这套东西从我最初接触到现在，整体框架没怎么大变，变的都是新驱动、新能力、新工具链。但只要你把"客户端-服务端-驱动-设备"这条链路的运转逻辑吃透了，不管以后工具怎么演进，你都能快速迁移。这也是我喜欢它的原因：看似复杂，但底层规律不多，落实到最后就是"稳定的定位 + 合理的等待 + 干净的数据"这三件事。把这三件事做好，你的自动化测试之路就已经赢过了大多数人。