Python+Appium 搞定移动端 Web UI 自动化测试实战

用 Python 操作 Appium 去跑 Web 项目的 UI 测试自动化，很多人听到第一反应是：Appium 不是做手机 App 的吗？这话对了一半。Appium 确实主要服务移动端，但它执行的是 WebDriver 协议，所以当你要自动化的 Web 页面跑在移动端 Chrome、Safari，或者是内嵌在 App 里的 WebView 组件时，Python + Appium 反而是最顺手的组合之一。我最近半年一直负责一套 H5 商城的回归测试，登录、加购、下单、订单列表是主要回归路径，用的技术栈就是标题里这套。这篇文章不搞框架选型表演，只讲我从零开始搭这套自动化、又把用例稳定跑起来的过程，以及踩过的不少坑。

1. 为什么用 Appium 跑 Web 的 UI 自动化

1.1 纯桌面 Web 和移动端 Web 是两种不同的“Web”

先把边界说清楚：不是所有 Web 项目都适合 Appium。如果被测对象是公司管理后台、官网、PC 端的商城页面，老老实实用 Selenium + Chrome 会省心很多，Appium 在这里没有任何优势。可一旦 Web 产品的主要入口变成手机浏览器里的 H5 页面，或者 App 内用 WebView 加载的活动页、支付页、订单详情页，情况就变了。

这些页面看不起来就是普通网页，但实际运行时会牵扯大量移动端能力：定位权限、摄像头唤起、移动端软键盘、App 与网页之间的 scheme 跳转、下拉刷新手势、以及各种原生弹窗和 Web 元素混在一起的情况。Selenium 设计时没有重点考虑这些手机系统级交互，它适合的是桌面浏览器里相对“干净”的 DOM。Appium 则天然把 WebDriver 协议和移动端系统能力打通了，所以我个人会这样划分：纯桌面 PC Web 提自动化，选 Selenium；移动端 H5 或 App 内嵌 WebView 提自动化，选 Python + Appium。

1.2 纯网页自动化为什么会不够用

我在不少团队里看到过一种做法：把手机浏览器 App 当成一个普通的应用，用 Selenium 去连 Chrome 的远程调试端口，或者用 uiautomator 去点击屏幕坐标。短时间能跑通，但长期维护非常痛苦。

先说远程调试端口方案，它的问题在于每次启动 Chrome 都要带--remote-debugging-port参数，真机上需要先用 adb 设置端口映射，中间断开一次就要重新连接。坐标点击方案就更脆弱，不同分辨率下同一个按钮的位置完全不一样，换台手机脚本就废。Appium 对这些做了抽象，它启动 session 之后，你面对的是一个符合 Selenium API 的 driver 对象，元素定位是 ID、CSS、XPath，不用关心底层驱动是 ChromeDriver 还是 XCUITest。也就是说，我可以用同一套 Python 写法，跑 Android 端浏览器网页，也能切到 iOS 或混合 App。

1.3 哪些场景值得用 Appium

我整理过适合这套技术栈的场景，大致有三类：

• 移动端浏览器里的 H5 页面，要求在多台 Android/iOS 真机上验证 UI 和业务主流程。
• App 内嵌 WebView 的页面，比如 App 里的活动页、客服 H5、第三方登录页。此时 Appium 可以在原生部分和 WebView 部分之间切换。
• 需要同时验证原生壳和页面内容的用例，比如要从原生按钮进入 H5 页面，再走完页面里的完整流程。

如果你只是要给一个已经足够稳定的 PC 网站写几个冒烟用例，那不需要 Appium。但如果是“手机端用户会打开的网页”，我建议把 Appium 纳入方案池里。它补的正是 Selenium 最不擅长、而移动端 Web 测试又绕不开的那部分能力。

2. 环境搭建：先别急着写代码，把驱动匹配这一关过好

2.1 Python 和 Appium Server 的基础安装

环境搭建的坑往往不在 Python 本身，而在下面几个组件之间的版本关系。先装 Python 3.8 以上版本，Windows 安装时一定要记得勾选 Add Python to PATH，装完打开命令行验证：

python --version pip --version

如果是在 Linux 服务器上跑调度任务，也别用系统自带的旧版 Python，建议通过 pyenv 或者官方源码包安装到一个独立目录，避免和系统默认 Python 冲突。开发机上用 VSCode 的话，装好 Python 插件后，记得在右下角选择解释器，否则后续跑 pytest 时可能直接用了全局环境，导致ModuleNotFoundError。

Appium Server 是 Node.js 应用，需要先装 Node.js LTS，然后用 npm 全局安装：

npm install -g appium appium --version

这里要特别提醒：Appium 2.x 的架构和 1.x 不一样。2.x 默认不带任何移动端驱动，必须手动安装。以 Android 为例：

appium driver install uiautomator2

如果还要测 iOS 的 Safari 和 WebView，就装 XCUITest：

appium driver install xcuitest

Python 侧只需要安装官方客户端库：

pip install Appium-Python-Client

这个库不是简单地向 Appium Server 发 HTTP 请求，它把 WebDriver 协议封装成了和 Selenium 非常接近的 Python API，等你调用find_element、click、send_keys时，底层会通过 JSON Wire Protocol 或 W3C WebDriver 协议发给 Appium Server，再转给 ChromeDriver、UiAutomator2 或 XCUITest。

装完环境后，先不要着急写第一个脚本。我习惯先启动一个空的 Appium Server：

appium --address 127.0.0.1 --port 4723

看到 "Appium ready" 之类的日志，说明基础服务没问题。接下来最重要的其实是驱动的版本匹配。

2.2 移动端浏览器背后真正的引擎：ChromeDriver

很多人在“Appium 跑 Web”这件事上死磕了好几天，最后发现不是定位问题，也不是等待问题，而是 ChromeDriver 根本没连上。Appium 驱动 Android 上的 Chrome，并不是直接把 Chrome 元素树拉出来，它需要借助一个 ChromeDriver。ChromeDriver 的版本必须和设备上 Chrome 的版本匹配，一旦不匹配，启动 session 时大概率报：

unknown error: cannot connect to ChromeDriver

这类报错有个特点：Appium Server 的日志看起来像是网络错误，其实只是版本协商失败。我见过不少同学在这里反复重启 Appium，浪费了很多时间。正确的排查链路是：

1. 先用 adb 确认设备上 Chrome 的版本。
2. 查看 Appium 日志里实际尝试拉起的是哪个 ChromeDriver。
3. 如果版本差太多，手动下载匹配版本的 ChromeDriver。

查看 Chrome 版本的命令：

adb shell dumpsys package com.android.chrome | grep versionName

如果 Appium 自动下载 ChromeDriver 超时或失败，可以在 capability 里直接指定本地路径：

"appium:chromedriverExecutable": "/usr/local/bin/chromedriver"

如果团队里有多台设备、多个 Chrome 版本，我建议用appium:chromedriverChromeMappingFile指向一个 JSON 映射文件，这样 Appium 能根据设备上的 Chrome 版本自动选对应驱动，省去很多人力维护成本。记住，驱动匹配这件事在移动 Web 自动化里不是“锦上添花”，而是“地基”。

2.3 Appium Inspector：定位元素前先验证 Capabilities

Appium Inspector 是官方提供的图形化调试工具。很多人拿它来“找元素”，但我觉得它更重要的价值是：在写任何脚本之前，先用它验证整条 Capabilities 配置能不能拉起一个完整 session。

Inspector 的启动方式很简单：打开工具后填上 Appium Server 地址，再填一份 capabilities，点击 Start Session。如果 session 启动正常，你就能看到真机或模拟器画面，左侧是 UI 层级树，右侧是可以输入命令的命令行面板。如果 session 启动失败，Inspector 会直接把 Appium Server 的原始报错展示出来，比脚本里只报一个WebDriverException清晰得多。

定位元素时，我建议不要一上来就抄 XPath。移动端 Chrome 渲染出来的页面里，class 名经常会被框架重写，过于依赖 class 会选择到一堆无关元素。优先看 HTML 里有没有稳定的 id 属性，其次是 CSS selector，最后才是 XPath。拿到目标元素后，可以在 Inspector 右侧执行一个driver.find_element验证，确认能定位到，再把这段代码粘回测试脚本。Inspector 里也提供了 send keys 的调试入口，方便你在写代码前确认输入顺序和是否需要 clear 已有内容。

3. 跑通第一个 H5 用例：从 Capabilities 到页面操作

3.1 一份能用的 Desired Capabilities 配置

先给一份最小可用的配置，我用的是 Appium Python Client 里推荐的新写法：

from appium import webdriver from appium.options.android import UiAutomator2Options caps = { "platformName": "Android", "appium:automationName": "UiAutomator2", "appium:deviceName": "emulator-5554", "browserName": "Chrome", "appium:noReset": True, } options = UiAutomator2Options().load_capabilities(caps) driver = webdriver.Remote( "http://127.0.0.1:4723/wd/hub", options=options ) driver.get("http://your-test-site.com/login")

这份配置里