深入解析 Appium 的工作原理从 W3C WebDriver 协议到跨平台自动化生态【免费下载链接】appiumCross-platform automation framework for all kinds of apps, built on top of the W3C WebDriver protocol项目地址: https://gitcode.com/GitHub_Trending/ap/appiumAppium 是一个开源项目与相关软件生态系统的统称其核心使命是让测试开发者能够用一套统一的 API为 iOS、Android、浏览器、桌面乃至电视等多种应用平台编写 UI 自动化代码。本篇基于官方文档《Appium 如何工作》展开系统梳理 Appium 2 的三大目标、WebDriver 协议选型、驱动程序Driver与插件Plugin扩展机制并结合当前仓库源码给出实现层面的印证读完你将对Appium 到底如何工作建立完整、可追溯的认知并掌握驱动/插件 CLI 管理、客户端选型等实战要点。Appium 2 的核心目标与方法论原则正如仓库 中文首页 所述Appium 旨在促进多种应用平台的 UI 自动化包括移动端iOS、Android、Tizen、浏览器端Chrome、Firefox、Safari、桌面端macOS、Windows、电视端Roku、tvOS、Android TV、三星等。随着 Appium 2 的发布项目确立了三个主要目标在跨平台标准 API 之下提供特定于平台的自动化能力允许从任何编程语言轻松访问这一 API提供工具方便社区开发 Appium 扩展。围绕这三个主要目标项目还遵循一套次要目标方法论原则官方同样鼓励 Appium 扩展开发者遵循尽可能依赖并贡献于开源技术尽可能依赖给定平台的供应商提供的工具尽可能依赖不修改应用即可实现自动化的工具最好不要求用户构建额外的 SDK 或软件从而避免测试版应用与生产版应用之间产生差异尽可能依赖现有标准而不是创造新标准。这些原则直接塑造了 Appium 的整体架构不发明新协议而是采用 WebDriver 标准不重复造轮子而是封装平台厂商工具如 Apple 的 XCUITest、Google 的 UiAutomator2不给应用打补丁而是运行原生应用本身。Appium 的 API 选择为什么是 W3C WebDriver要回答单一统一 API 应该是什么Appium 站在了 Selenium 的肩膀上。Selenium 项目长期深耕浏览器 UI 自动化领域可视为 Appium 目标的一个子集在演化过程中Selenium 与后来合并的 WebDriver 项目一起将浏览器自动化 API 逐步标准化为 W3C 官方标准 ——WebDriver 规范。如今所有主流浏览器都原生实现了符合该规范的自动化能力无需 Selenium 团队维护任何执行实际自动化的软件。Appium 的初衷是为移动应用iOS 与 Android制定自动化标准。它本可以发明新协议但为了团结力量、保持标准的一致性最终决定采用 WebDriver 规范作为 Appium 的 API。虽然网站与移动原生应用的用户交互并不完全相同考虑到电视这类由简单遥控器操控的平台时差异更大但绝大多数软件 UI 都高度相似因此 WebDriver 规范提供的自动化原语——查找元素、与元素交互、加载页面或屏幕等——可以或多或少地映射到任何平台。这里有一个重要的历史细节Appium 最初编写时实际使用的是比 WebDriver 规范更古老的JSON Wire ProtocolJWP此后 Appium 一直与 W3C 规范共同演化现已完全符合 W3C 规范。对应地当前仓库中 base-driver 的协议路由 目录下的实现即是这一演化的产物。当然Appium 也清楚Web 到移动Web 到电视之间确实存在交互差异因此它充分利用了 WebDriver 规范内置的可扩展性。结果是无论自动化哪个平台使用 Appium 都遵循标准 WebDriver 规范但存在两个注意事项某些 WebDriver API 命令可能在特定平台上不受支持例如在原生移动应用自动化中获取或设置 cookie 是不可能的Appium 可能支持超出 WebDriver API 命令列表的自动化行为但任何此类命令都会是合法、符合规范的 WebDriver API 扩展。平台自动化行为驱动程序的职责下一个问题是Appium 如何把 WebDriver 协议映射到广泛平台的自动化行为严格来说Appium 本身不做这件事——它将这一职责交给一种称为 Appium驱动程序Driver的软件模块。驱动程序就像是 Appium 的可插拔模块赋予 Appium 自动化特定平台或平台集合的能力。其终极职责只是实现一个代表 WebDriver 协议的 Appium 内部接口至于如何实现完全由驱动程序根据其在特定平台上的自动化策略决定。通常驱动程序的实现要依赖平台特有的自动化技术例如Apple 维护着名为 XCUITest 的 iOS 自动化技术支持 iOS 应用自动化的 Appium 驱动程序XCUITest 驱动本质上就是把 WebDriver 协议转换成 XCUITest 库调用Google 的 UiAutomator2 技术、只能通过 ADB 获得的能力以及辅助应用内 Android SDK 提供的能力共同支撑着 Android 自动化。驱动程序彼此独立、可插拔是因为不同平台驱动程序的构建工具与使用要求完全不同。因此 Appium 让你只安装自动化任务所需的驱动程序并且提供了专门的 扩展管理 CLIappium driver/appium plugin子命令来管理它们。从源码看驱动程序的本质在仓库中这一设计有清晰的源码印证。Appium 服务器本身的核心类是 AppiumDriver它继承自DriverCore而驱动程序的基类则位于 base-driver 包。任何驱动只需继承BaseDriver并实现对应的命令方法即可工作import BaseDriver from appium/base-driver class MyNewDriver extends BaseDriver { }这个空驱动程序本身不会做任何事但你可以把它打包为 Node.js 模块在package.json中添加 Appium 相关字段如driverName、automationName、platformNames、mainClass再通过appium driver install安装。WebDriver 协议命令到驱动方法名的映射定义在 base-driver 包的协议路由文件中——例如实现Navigate To命令只需在驱动类中定义async setUrl(url)方法。仓库中的 fake-driver 就是一个几乎什么都不做、仅用于展示驱动编写方式的示例驱动是学习驱动开发的最佳起点。驱动程序的自动化映射与多层架构驱动程序作者真正面临的挑战不是如何使用 WebDriver 协议BaseDriver已封装好这一切而是如何在目标平台上实现真实自动化。以 iOS 为例XCUITest 框架要求调用代码使用 Objective-C 或 Swift 编写且只能在由 Xcode 触发的特殊模式下运行因此无法直接从 Node.js 函数跳到 XCUITest API。XCUITest 驱动把自身拆成两部分——Node.js 部分整合进 Appium、处理 WebDriver 命令和 Objective-C 部分在 iOS 设备上执行 XCUITest 调用——而两部分之间的通信方式竟然也是 WebDriver 协议Objective-C 端本身就是一个名为 WebDriverAgent 的 WebDriver 实现。这意味着一条真实的 iOS 自动化链路可能涉及十余个环节测试代码 → Appium 客户端库 → Selenium 客户端库 → 网络 → Appium 服务器 → XCUITest 驱动 → WebDriverAgent → Xcode → XCUITest → iOS → macOS。理解这一点对排查测试问题至关重要当测试失败时问题可能出在这条深栈的任意一环。代理模式不重复实现已有的 WebDriver上述两端都用 WebDriver 协议的架构还带来了一个额外好处代理Proxy模式。当 XCUITest 驱动需要实现Click Element命令时其内部代码本质上只是构造一个指向 WebDriverAgent 的 HTTP 请求——等于重建了客户端对 Appium 的原始调用。因此驱动可以让 Appium 知道该命令应直接代理到其他 WebDriver 服务器驱动程序本身完全不参与处理响应也原样回传。这也意味着 Appium 可以为任何现有 WebDriver 实现轻松创建包装驱动。当你查阅某个开源驱动的源码却找不到某条命令的实现时很可能它正被代理到别处。通用编程语言访问HTTP 客户端-服务器架构Appium 本质上是一个 Node.js 程序理论上可以做成把 Appium 及其驱动作为库导入 Node.js 程序的形态但这样无法满足任何流行编程语言都能使用的目标。幸运的是WebDriver 规范本身就是一个基于 HTTP 的协议设计上就面向网络而非单进程内存调用。这种客户端-服务器架构的核心好处是自动化实现者服务器即执行自动化的部分与自动化运行者客户端即定义自动化步骤的部分完全分离。所有困难的部分如何在特定平台实现自动化由服务器端统一处理而瘦客户端库可以在任何语言中编写——只需用该语言向服务器发起 HTTP 请求即可。只要该语言存在高级 HTTP 库就能相对容易地为新语言带来基本的 Appium/WebDriver 能力。给 Appium 用户的三点结论Appium 是一个 HTTP 服务器只要想使用它进行自动化它就必须作为进程运行在某台计算机上并通过网络供执行自动化的机器访问无论同一台机器还是地球另一端。使用 Appium 客户端而非裸 HTTP除非你想手写原始 HTTP 调用或使用 cURL否则应使用所选语言的 Appium 客户端。每个客户端的目标都是封装 WebDriver 协议让你使用符合该语言习惯的对象和方法。服务器与客户端不必在同一台机器上只需保证客户端能通过网络向服务器发送 HTTP 请求。这极大便利了云服务商对 Appium 的使用——他们托管 Appium 服务器、相关驱动与设备你只需把客户端脚本指向其安全端点。客户端视角同一命令集的五种语言实现客户端简介 给出了同一组操作在五种语言中的等价实现底层调用的都是同一组 WebDriver 命令Find Element→Click Element→Get Element Text→Get Page Sourceelement driver.find_element(byBy.XPATH, value//*[textFoo]) element.click() print(element.text) print(driver.page_source)WebElement element driver.findElement(By.Xpath(//*[textFoo])) element.click() System.out.println(element.getText()) System.out.println(driver.getPageSource())// Webdriver.io const element await driver.$(//*[textFoo]); await element.click(); console.log(await element.getText()) console.log(await driver.getPageSource())element driver.find_element :xpath, //*[textFoo] element.click puts element.text puts driver.page_sourceAppiumElement element driver.FindElement(MobileBy.AccessibilityId(Views)); element.click(); System.Console.WriteLine(element.Text); System.Console.WriteLine(driver.PageSource);选择客户端时需注意每个客户端都是独立维护的某一客户端具备的功能不代表另一客户端也有尽管所有客户端至少支持标准 W3C 协议与常见 Appium 扩展优先考虑你想用的语言其次才是该库的功能完善程度与维护活跃度。许多语言的 Appium 客户端构建在该语言的 Selenium 客户端之上因此某些客户端文档只记录其在 Selenium 基础上新增的功能完整参考需要同时查阅 Appium 与 Selenium 两份文档。另外要强调的是这些都不直接等于测试。Appium 与客户端库只负责自动化本身如果你要做测试通常还需要测试运行器、测试框架等工具它们与 Appium 无绑定关系——这正是 Appium通用可访问性的好处之一它可以与你认为最合适的任何工具集配合。Appium 的巨大范围平台化生态与插件系统在单一 API 下自动化一切的愿景远超核心维护团队的能力范围因此 Appium 的路径是授权社区在 Appium 之上作为平台开发功能——这就是所谓的 Appium 生态系统。Appium 团队官方维护少数驱动程序如前述 XCUITest 驱动但不可能拥有维护众多平台驱动的专业能力。从 Appium 2 开始项目提供了工具来赋能社区任何人都可以创建驱动程序只需创建一个符合适当约定、实现 WebDriver 协议任意子/超集的 Node.js 模块。创建驱动通常只需极少量代码因为 WebDriver 协议细节被抽象化且存在大量辅助库正是支撑 Appium 官方驱动的那批库。分享驱动很容易且没有中央权威使用 Appium 驱动 CLI 即可分享公开或私下、免费或收费均可驱动可以是开源或闭源的官方自然更欣赏开源。生态的边界不止于平台自动化。Appium 2 还发布了插件系统让任何人都能构建并分享改变 Appium 工作方式的模块。与驱动类似插件通过 插件 CLI 发布与消费几乎没有功能限制。仓库中的 images-plugin 就是一个官方示例它给 Appium 增加了基于模板图像查找并交互屏幕区域的能力此外仓库还维护着 execute-driver-plugin、universal-xml-plugin、relaxed-caps-plugin、storage-plugin 等多个官方插件以及展示插件编写方式的 fake-plugin 示例。插件的基类是 BasePlugin其核心能力是通过与命令同名的方法拦截、包装或替换驱动原本的命令处理。扩展管理 CLI 实战速查驱动与插件共用同一套管理 CLIappium driver/appium plugin支持完全相同的子命令常用操作如下子命令用途示例install安装扩展支持npm/git/github/local四种来源appium driver install xcuitest、appium driver install xcuitest9.0.0、appium plugin install /path/to/my/plugin --sourcelocallist列出已安装扩展及官方未安装扩展可用--installed、--updates、--verbose、--jsonappium driver list --installed --updatesupdate更新扩展默认仅更新 minor/patch--unsafe允许主版本升级appium driver update uiautomator2 --unsafe、appium plugin update installeduninstall卸载扩展appium plugin uninstall imagesrun运行扩展自带脚本如预构建不传脚本名则列出可用脚本appium driver run uiautomator2 resetdoctor对已安装扩展执行环境检查并非所有扩展都提供appium driver doctor uiautomator2总结一个可扩展的通用 UI 自动化接口回到开篇的四个问题Appium 的答案环环相扣统一 API采用 W3C WebDriver 标准附带合法的扩展命令平台映射交由可插拔的驱动程序实现本质是继承BaseDriver、实现协议命令方法的 Node.js 模块必要时可代理到其他 WebDriver 实现多语言访问借助 WebDriver 的 HTTP 客户端-服务器架构由各语言的客户端库封装覆盖所有平台则通过开放生态——任何人可构建并分享驱动与插件没有中央权威。这就是 Appium一个可扩展的、潜在覆盖一切的 UI 自动化通用接口。若想继续深入推荐按序阅读 驱动程序介绍 与 客户端简介 理解两大角色阅读 扩展管理 CLI 掌握日常操作并通过 构建驱动程序 与 构建插件 加入生态开发仓库中的 fake-driver、fake-plugin 及 base-driver 协议路由 则是随时可查阅的源码级参考。【免费下载链接】appiumCross-platform automation framework for all kinds of apps, built on top of the W3C WebDriver protocol项目地址: https://gitcode.com/GitHub_Trending/ap/appium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 深入解析 Appium 的工作原理：从 W3C WebDriver 协议到跨平台自动化生态
深入解析 Appium 的工作原理从 W3C WebDriver 协议到跨平台自动化生态【免费下载链接】appiumCross-platform automation framework for all kinds of apps, built on top of the W3C WebDriver protocol项目地址: https://gitcode.com/GitHub_Trending/ap/appiumAppium 是一个开源项目与相关软件生态系统的统称其核心使命是让测试开发者能够用一套统一的 API为 iOS、Android、浏览器、桌面乃至电视等多种应用平台编写 UI 自动化代码。本篇基于官方文档《Appium 如何工作》展开系统梳理 Appium 2 的三大目标、WebDriver 协议选型、驱动程序Driver与插件Plugin扩展机制并结合当前仓库源码给出实现层面的印证读完你将对Appium 到底如何工作建立完整、可追溯的认知并掌握驱动/插件 CLI 管理、客户端选型等实战要点。Appium 2 的核心目标与方法论原则正如仓库 中文首页 所述Appium 旨在促进多种应用平台的 UI 自动化包括移动端iOS、Android、Tizen、浏览器端Chrome、Firefox、Safari、桌面端macOS、Windows、电视端Roku、tvOS、Android TV、三星等。随着 Appium 2 的发布项目确立了三个主要目标在跨平台标准 API 之下提供特定于平台的自动化能力允许从任何编程语言轻松访问这一 API提供工具方便社区开发 Appium 扩展。围绕这三个主要目标项目还遵循一套次要目标方法论原则官方同样鼓励 Appium 扩展开发者遵循尽可能依赖并贡献于开源技术尽可能依赖给定平台的供应商提供的工具尽可能依赖不修改应用即可实现自动化的工具最好不要求用户构建额外的 SDK 或软件从而避免测试版应用与生产版应用之间产生差异尽可能依赖现有标准而不是创造新标准。这些原则直接塑造了 Appium 的整体架构不发明新协议而是采用 WebDriver 标准不重复造轮子而是封装平台厂商工具如 Apple 的 XCUITest、Google 的 UiAutomator2不给应用打补丁而是运行原生应用本身。Appium 的 API 选择为什么是 W3C WebDriver要回答单一统一 API 应该是什么Appium 站在了 Selenium 的肩膀上。Selenium 项目长期深耕浏览器 UI 自动化领域可视为 Appium 目标的一个子集在演化过程中Selenium 与后来合并的 WebDriver 项目一起将浏览器自动化 API 逐步标准化为 W3C 官方标准 ——WebDriver 规范。如今所有主流浏览器都原生实现了符合该规范的自动化能力无需 Selenium 团队维护任何执行实际自动化的软件。Appium 的初衷是为移动应用iOS 与 Android制定自动化标准。它本可以发明新协议但为了团结力量、保持标准的一致性最终决定采用 WebDriver 规范作为 Appium 的 API。虽然网站与移动原生应用的用户交互并不完全相同考虑到电视这类由简单遥控器操控的平台时差异更大但绝大多数软件 UI 都高度相似因此 WebDriver 规范提供的自动化原语——查找元素、与元素交互、加载页面或屏幕等——可以或多或少地映射到任何平台。这里有一个重要的历史细节Appium 最初编写时实际使用的是比 WebDriver 规范更古老的JSON Wire ProtocolJWP此后 Appium 一直与 W3C 规范共同演化现已完全符合 W3C 规范。对应地当前仓库中 base-driver 的协议路由 目录下的实现即是这一演化的产物。当然Appium 也清楚Web 到移动Web 到电视之间确实存在交互差异因此它充分利用了 WebDriver 规范内置的可扩展性。结果是无论自动化哪个平台使用 Appium 都遵循标准 WebDriver 规范但存在两个注意事项某些 WebDriver API 命令可能在特定平台上不受支持例如在原生移动应用自动化中获取或设置 cookie 是不可能的Appium 可能支持超出 WebDriver API 命令列表的自动化行为但任何此类命令都会是合法、符合规范的 WebDriver API 扩展。平台自动化行为驱动程序的职责下一个问题是Appium 如何把 WebDriver 协议映射到广泛平台的自动化行为严格来说Appium 本身不做这件事——它将这一职责交给一种称为 Appium驱动程序Driver的软件模块。驱动程序就像是 Appium 的可插拔模块赋予 Appium 自动化特定平台或平台集合的能力。其终极职责只是实现一个代表 WebDriver 协议的 Appium 内部接口至于如何实现完全由驱动程序根据其在特定平台上的自动化策略决定。通常驱动程序的实现要依赖平台特有的自动化技术例如Apple 维护着名为 XCUITest 的 iOS 自动化技术支持 iOS 应用自动化的 Appium 驱动程序XCUITest 驱动本质上就是把 WebDriver 协议转换成 XCUITest 库调用Google 的 UiAutomator2 技术、只能通过 ADB 获得的能力以及辅助应用内 Android SDK 提供的能力共同支撑着 Android 自动化。驱动程序彼此独立、可插拔是因为不同平台驱动程序的构建工具与使用要求完全不同。因此 Appium 让你只安装自动化任务所需的驱动程序并且提供了专门的 扩展管理 CLIappium driver/appium plugin子命令来管理它们。从源码看驱动程序的本质在仓库中这一设计有清晰的源码印证。Appium 服务器本身的核心类是 AppiumDriver它继承自DriverCore而驱动程序的基类则位于 base-driver 包。任何驱动只需继承BaseDriver并实现对应的命令方法即可工作import BaseDriver from appium/base-driver class MyNewDriver extends BaseDriver { }这个空驱动程序本身不会做任何事但你可以把它打包为 Node.js 模块在package.json中添加 Appium 相关字段如driverName、automationName、platformNames、mainClass再通过appium driver install安装。WebDriver 协议命令到驱动方法名的映射定义在 base-driver 包的协议路由文件中——例如实现Navigate To命令只需在驱动类中定义async setUrl(url)方法。仓库中的 fake-driver 就是一个几乎什么都不做、仅用于展示驱动编写方式的示例驱动是学习驱动开发的最佳起点。驱动程序的自动化映射与多层架构驱动程序作者真正面临的挑战不是如何使用 WebDriver 协议BaseDriver已封装好这一切而是如何在目标平台上实现真实自动化。以 iOS 为例XCUITest 框架要求调用代码使用 Objective-C 或 Swift 编写且只能在由 Xcode 触发的特殊模式下运行因此无法直接从 Node.js 函数跳到 XCUITest API。XCUITest 驱动把自身拆成两部分——Node.js 部分整合进 Appium、处理 WebDriver 命令和 Objective-C 部分在 iOS 设备上执行 XCUITest 调用——而两部分之间的通信方式竟然也是 WebDriver 协议Objective-C 端本身就是一个名为 WebDriverAgent 的 WebDriver 实现。这意味着一条真实的 iOS 自动化链路可能涉及十余个环节测试代码 → Appium 客户端库 → Selenium 客户端库 → 网络 → Appium 服务器 → XCUITest 驱动 → WebDriverAgent → Xcode → XCUITest → iOS → macOS。理解这一点对排查测试问题至关重要当测试失败时问题可能出在这条深栈的任意一环。代理模式不重复实现已有的 WebDriver上述两端都用 WebDriver 协议的架构还带来了一个额外好处代理Proxy模式。当 XCUITest 驱动需要实现Click Element命令时其内部代码本质上只是构造一个指向 WebDriverAgent 的 HTTP 请求——等于重建了客户端对 Appium 的原始调用。因此驱动可以让 Appium 知道该命令应直接代理到其他 WebDriver 服务器驱动程序本身完全不参与处理响应也原样回传。这也意味着 Appium 可以为任何现有 WebDriver 实现轻松创建包装驱动。当你查阅某个开源驱动的源码却找不到某条命令的实现时很可能它正被代理到别处。通用编程语言访问HTTP 客户端-服务器架构Appium 本质上是一个 Node.js 程序理论上可以做成把 Appium 及其驱动作为库导入 Node.js 程序的形态但这样无法满足任何流行编程语言都能使用的目标。幸运的是WebDriver 规范本身就是一个基于 HTTP 的协议设计上就面向网络而非单进程内存调用。这种客户端-服务器架构的核心好处是自动化实现者服务器即执行自动化的部分与自动化运行者客户端即定义自动化步骤的部分完全分离。所有困难的部分如何在特定平台实现自动化由服务器端统一处理而瘦客户端库可以在任何语言中编写——只需用该语言向服务器发起 HTTP 请求即可。只要该语言存在高级 HTTP 库就能相对容易地为新语言带来基本的 Appium/WebDriver 能力。给 Appium 用户的三点结论Appium 是一个 HTTP 服务器只要想使用它进行自动化它就必须作为进程运行在某台计算机上并通过网络供执行自动化的机器访问无论同一台机器还是地球另一端。使用 Appium 客户端而非裸 HTTP除非你想手写原始 HTTP 调用或使用 cURL否则应使用所选语言的 Appium 客户端。每个客户端的目标都是封装 WebDriver 协议让你使用符合该语言习惯的对象和方法。服务器与客户端不必在同一台机器上只需保证客户端能通过网络向服务器发送 HTTP 请求。这极大便利了云服务商对 Appium 的使用——他们托管 Appium 服务器、相关驱动与设备你只需把客户端脚本指向其安全端点。客户端视角同一命令集的五种语言实现客户端简介 给出了同一组操作在五种语言中的等价实现底层调用的都是同一组 WebDriver 命令Find Element→Click Element→Get Element Text→Get Page Sourceelement driver.find_element(byBy.XPATH, value//*[textFoo]) element.click() print(element.text) print(driver.page_source)WebElement element driver.findElement(By.Xpath(//*[textFoo])) element.click() System.out.println(element.getText()) System.out.println(driver.getPageSource())// Webdriver.io const element await driver.$(//*[textFoo]); await element.click(); console.log(await element.getText()) console.log(await driver.getPageSource())element driver.find_element :xpath, //*[textFoo] element.click puts element.text puts driver.page_sourceAppiumElement element driver.FindElement(MobileBy.AccessibilityId(Views)); element.click(); System.Console.WriteLine(element.Text); System.Console.WriteLine(driver.PageSource);选择客户端时需注意每个客户端都是独立维护的某一客户端具备的功能不代表另一客户端也有尽管所有客户端至少支持标准 W3C 协议与常见 Appium 扩展优先考虑你想用的语言其次才是该库的功能完善程度与维护活跃度。许多语言的 Appium 客户端构建在该语言的 Selenium 客户端之上因此某些客户端文档只记录其在 Selenium 基础上新增的功能完整参考需要同时查阅 Appium 与 Selenium 两份文档。另外要强调的是这些都不直接等于测试。Appium 与客户端库只负责自动化本身如果你要做测试通常还需要测试运行器、测试框架等工具它们与 Appium 无绑定关系——这正是 Appium通用可访问性的好处之一它可以与你认为最合适的任何工具集配合。Appium 的巨大范围平台化生态与插件系统在单一 API 下自动化一切的愿景远超核心维护团队的能力范围因此 Appium 的路径是授权社区在 Appium 之上作为平台开发功能——这就是所谓的 Appium 生态系统。Appium 团队官方维护少数驱动程序如前述 XCUITest 驱动但不可能拥有维护众多平台驱动的专业能力。从 Appium 2 开始项目提供了工具来赋能社区任何人都可以创建驱动程序只需创建一个符合适当约定、实现 WebDriver 协议任意子/超集的 Node.js 模块。创建驱动通常只需极少量代码因为 WebDriver 协议细节被抽象化且存在大量辅助库正是支撑 Appium 官方驱动的那批库。分享驱动很容易且没有中央权威使用 Appium 驱动 CLI 即可分享公开或私下、免费或收费均可驱动可以是开源或闭源的官方自然更欣赏开源。生态的边界不止于平台自动化。Appium 2 还发布了插件系统让任何人都能构建并分享改变 Appium 工作方式的模块。与驱动类似插件通过 插件 CLI 发布与消费几乎没有功能限制。仓库中的 images-plugin 就是一个官方示例它给 Appium 增加了基于模板图像查找并交互屏幕区域的能力此外仓库还维护着 execute-driver-plugin、universal-xml-plugin、relaxed-caps-plugin、storage-plugin 等多个官方插件以及展示插件编写方式的 fake-plugin 示例。插件的基类是 BasePlugin其核心能力是通过与命令同名的方法拦截、包装或替换驱动原本的命令处理。扩展管理 CLI 实战速查驱动与插件共用同一套管理 CLIappium driver/appium plugin支持完全相同的子命令常用操作如下子命令用途示例install安装扩展支持npm/git/github/local四种来源appium driver install xcuitest、appium driver install xcuitest9.0.0、appium plugin install /path/to/my/plugin --sourcelocallist列出已安装扩展及官方未安装扩展可用--installed、--updates、--verbose、--jsonappium driver list --installed --updatesupdate更新扩展默认仅更新 minor/patch--unsafe允许主版本升级appium driver update uiautomator2 --unsafe、appium plugin update installeduninstall卸载扩展appium plugin uninstall imagesrun运行扩展自带脚本如预构建不传脚本名则列出可用脚本appium driver run uiautomator2 resetdoctor对已安装扩展执行环境检查并非所有扩展都提供appium driver doctor uiautomator2总结一个可扩展的通用 UI 自动化接口回到开篇的四个问题Appium 的答案环环相扣统一 API采用 W3C WebDriver 标准附带合法的扩展命令平台映射交由可插拔的驱动程序实现本质是继承BaseDriver、实现协议命令方法的 Node.js 模块必要时可代理到其他 WebDriver 实现多语言访问借助 WebDriver 的 HTTP 客户端-服务器架构由各语言的客户端库封装覆盖所有平台则通过开放生态——任何人可构建并分享驱动与插件没有中央权威。这就是 Appium一个可扩展的、潜在覆盖一切的 UI 自动化通用接口。若想继续深入推荐按序阅读 驱动程序介绍 与 客户端简介 理解两大角色阅读 扩展管理 CLI 掌握日常操作并通过 构建驱动程序 与 构建插件 加入生态开发仓库中的 fake-driver、fake-plugin 及 base-driver 协议路由 则是随时可查阅的源码级参考。【免费下载链接】appiumCross-platform automation framework for all kinds of apps, built on top of the W3C WebDriver protocol项目地址: https://gitcode.com/GitHub_Trending/ap/appium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考