Appium

定义

Appium 是一套开源工具，用于对原生应用、移动 Web 应用和混合应用做 UI 自动化。原生应用指使用 iOS、Android 或 Windows 软件开发工具包编写的应用；移动 Web 应用指通过移动端浏览器访问的网页应用，Appium 支持 iOS 上的 Safari 以及 Android 上的 Chrome 和内置浏览器；混合应用则在原生容器中嵌入用于展示网页内容的控件。^[2]

它的核心特征是跨平台：同一套测试脚本可以在 iOS、Android 和 Windows 平台之间复用，而不必为每个平台单独改写。^[2] 严格来说，Appium 及其客户端库属于自动化程序库而非测试框架，测试的运行方式与断言工具可由使用者自行搭配。^[4]

原理

Appium 采用客户端—服务器架构。服务端用 Node.js 编写，对外暴露 REST 接口，接收客户端发来的 HTTP 请求，在设备上执行相应命令，再以 HTTP 响应返回执行结果。^[4] 由于通信基于 HTTP，任何具备 HTTP 客户端能力的编程语言都可以构造测试脚本，官方与社区为 Java、Python、Ruby、JavaScript、PHP、C# 等语言提供了客户端库。^[5]

Appium 的接口沿用了 Selenium 项目发展出的 WebDriver 规范。该规范原本面向浏览器自动化，其后被 W3C 标准化，Appium 采用它作为统一 API，并针对移动场景做了扩展。^[1] 早期这一协议以 JSON Wire Protocol 的形式实现，请求体多为键值对形式的 JSON；Appium 继承并扩展了移动版的 JSON Wire Protocol，使其能够控制安装应用、卸载应用、旋转屏幕等移动设备行为。^[6]

自动化过程以会话为单位。客户端向服务端发送 $POST /session$ 请求，请求中携带一组称为预期能力（Desired Capabilities）的键值对，用于说明目标平台、设备名称、待测应用等信息；服务端据此建立会话并返回会话标识，后续命令都在该会话下执行。^[4]

Appium 自身并不直接实现各平台的自动化，而是把这一职责交给驱动。驱动是可插拔模块，负责把 WebDriver 协议转换为具体平台自动化框架的调用。例如 iOS 端由 XCUITest 驱动把协议请求转成苹果 XCUITest 库的调用，Android 端则通过 UiAutomator2 驱动对接谷歌的 UiAutomator2 接口。^[1][7]

发展历程

Appium 的前身是 2011 年出现的 iOSAuto。当时丹·奎利亚尔（Dan Cuellar）在 Zoosk 担任测试经理，iOS 产品的回归测试耗时不断增长，而苹果官方工具 UIAutomation 要求用 JavaScript 编写测试、不支持实时调试，必须在 Xcode 的 Instruments 中运行；第三方工具又依赖私有 API 并把服务端嵌入应用。他于是尝试让 UIAutomation 以类似解释器的方式实时运行，由此做出 iOSAuto。^[3]

2012 年，丹·奎利亚尔在伦敦 Selenium 大会上用 Selenium 语法演示了 iOS 自动化。会后 Selenium 的共同创建者贾森·哈金斯（Jason Huggins）与他联系，鼓励其以开源许可发布代码。同年 8 月，C# 版源码发布到 GitHub；随后又出现 Python 版本，并加入 Web 服务器、通过 HTTP 实现 WebDriver 协议，使任何语言的 Selenium 客户端都能驱动 iOS 自动化。^[8] 项目原拟取名 AppleCart，因与苹果商标示例冲突而改名 Appium。^[3]

2013 年 1 月，Sauce Labs 决定支持该项目并投入开发力量，团队决定以 Node.js 重写，此后 Appium 定型为一个专门的 Web 服务器。同年，新版本在谷歌测试自动化大会上首次亮相，并发布 Android 与 Selendroid 支持，成为跨平台自动化框架。^[7] 2014 年 5 月，Appium 1.0 发布，稳定性与功能得到明显改善。^[9]

2016 年底，Sauce Labs 把 Appium 捐赠给 JS 基金会，以表明项目持续开源的承诺；该基金会后来并入 OpenJS 基金会，Appium 成为其影响力项目。^[9][10] Appium 2 于 2023 年发布，架构改为以生态系统为中心，核心模块只保留与平台无关的能力，各平台自动化被移入独立驱动，改变或扩展行为的代码被移入独立插件。^[9] 此后发布的 Appium 3 变更幅度较小，主要是删除已废弃代码并适配更新的运行环境。^[9]

应用

Appium 主要用于软件自动化测试，验证被测应用的功能是否符合预期。与一般的软件测试不同，UI 自动化会尽量在真实界面上模拟用户场景，同时获得执行速度、可扩展性和一致性上的收益。^[11] 它既可以在真机上执行，也可以在模拟器或仿真器上执行。^[12]

在工程实践中，Appium 常被接入持续集成与持续交付流程，在代码变更后自动运行回归用例；测试还可并行执行以缩短整体耗时，并使用显式等待等方式处理偶发失败。^[13] 服务端既能部署在本地，也能部署在云端，云端部署可通过为每个会话分配独立环境来实现并行测试。^[14]

除移动端外，Appium 的驱动机制也被扩展到桌面与电视等平台，Windows 桌面应用自动化由微软提供的驱动支持，另有面向 macOS、tvOS、Chrome、Firefox 等目标的驱动。^[2][11]

局限

Appium 的能力受底层平台自动化技术的约束。在原生移动应用的自动化场景中，浏览器环境下的部分 WebDriver 命令并不适用，例如读写 Cookie 无法实现；某些平台上部分命令也可能不被支持。^[1] 例如 iOS 真机上的 Safari 原生部分无法自动化，早期版本也无法在同一会话中自动化多个应用，且不支持多设备同时执行。^[12]

执行速度与稳定性是常被提及的短板。相比部分专用框架，Appium 的测试执行可能更慢，混合应用的测试难度较高，测试过程中还可能出现元素定位失败、会话创建失败等典型错误。^[15][13]

引入 Appium 2 的模块化架构后，驱动与插件需要单独安装和更新，默认安装只包含核心服务端，不再自带任何驱动，这增加了使用者的配置与版本管理成本。^[16] 其服务器默认地址和默认基础路径也在该版本中发生变化。^[16]

参见

• Selenium —— Appium 采用其发展出的 WebDriver 规范作为统一接口。

• WebDriver —— Appium 与客户端通信所遵循的 W3C 浏览器自动化标准。

• UiAutomator —— Android 平台自带的 UI 自动化框架，被 UiAutomator2 驱动调用。

• XCUITest —— 苹果提供的 iOS 自动化技术，被 XCUITest 驱动调用。

• OpenJS Foundation —— Appium 所属的开源基金会，Appium 为其影响力项目。

• 移动应用测试 —— Appium 所服务的主要应用场景。