Appium 是如何工作的？

如主页所述，Appium 是一个开源项目，以及相关软件的生态系统，旨在促进许多应用程序平台的 UI 自动化。随着 Appium 2 的发布，Appium 具有以下主要目标：¹

• 使平台特定的自动化功能在跨平台的标准 API 下可用
• 允许从任何编程语言轻松访问此 API
• 提供工具来方便社区开发 Appium 扩展

因此，无论您知道什么应用程序平台，例如 iOS 或 Android。Appium 希望开发人员和测试人员能够根据单个统一的 API 为该平台编写 UI 自动化代码。基于 Appium 的目标，我们有很多问题需要回答才能使这一切成为可能

• 哪个 API 应该是那个“单个统一”的 API？
• 我们如何将该 API 映射到特定平台的自动化行为？
• 我们如何通过多种流行的编程语言访问该 API？

鉴于除了 iOS 和 Android 之外还有更多应用程序平台，这里还有一个更大的问题潜伏在后台

• 我们如何为所有平台启用自动化？

探索 Appium 对这些问题的答案可能不是学习 Appium 是什么的最快方法，但它肯定是一个好方法！所以让我们深入研究。

Appium 选择的 API

Appium 很幸运地先于一项技术，该技术在 UI 自动化领域一直是长期领先者，即 Selenium。Selenium 项目的目标是支持 Web 浏览器的 UI 自动化，从这个意义上说，我们可以认为它占据了 Appium 目标的一个子集。在此过程中，Selenium（以及他们合并后的另一个项目 WebDriver）开发了一个相对稳定的 API 用于浏览器自动化。

多年来，Selenium 与各种 Web 浏览器供应商和 W3C 标准组织合作，将其 API 变成一个官方的 Web 浏览器标准，称为 WebDriver 规范。所有主要浏览器现在都根据 WebDriver 规范实施了内联自动化功能，而无需 Selenium 团队维护任何执行实际自动化的软件；标准获胜！

Appium 的最初目标是为移动应用程序（iOS 和 Android）开发一个自动化标准。我们本可以发明一些新的东西，但本着团结一致、保持标准的原则，我们决定采用 WebDriver 规范作为 Appium 的 API。² 虽然网站和移动原生应用程序上的用户交互并不完全相同（当我们开始考虑例如由简单遥控器控制的电视平台时，差异更大），但事实是大多数软件 UI 几乎相同。这意味着 WebDriver 规范提供了自动化 API 原语（查找元素、与元素交互、加载页面或屏幕等...），这些原语或多或少地映射到任何平台。

当然，Appium 希望支持用户交互与 Web 到移动或 Web 到电视不同的情况，因此 Appium 还利用了 WebDriver 规范的内置可扩展性。结果是，无论您想自动化什么平台，当您使用 Appium 时，您都将使用标准的 WebDriver 规范，有两个注意事项

• 我们可能没有办法在给定平台上支持特定的 WebDriver API 命令，因此某些命令可能不受支持（例如，在原生移动应用程序自动化的世界中，获取或设置 cookie 是不可能的）。
• 我们可能支持超出 WebDriver API 命令列表范围的自动化行为，尽管任何此类命令都将是 WebDriver API 的有效且符合规范的扩展。

您实际上如何使用 WebDriver API，特别是在 Appium 的上下文中？我们将在 下面的部分 中介绍 Appium 如何提供通用编程语言访问。您现在需要知道的是，Appium 引入通用 UI 自动化接口的方式是通过实现 WebDriver 协议。

平台自动化行为

下一个问题是，Appium 如何将此协议映射到各种平台上的自动化行为？诀窍是，严格来说，Appium 不会！它将此责任留给一种称为 Appium 驱动程序的软件模块。有一个完整的 驱动程序介绍，您可以继续阅读，因此我们现在不会详细介绍它们的工作原理。

目前重要的是要了解，驱动程序就像 Appium 的一个可插拔模块，它赋予 Appium 自动化特定平台（或一组平台，具体取决于驱动程序的目标）的能力。最终，驱动程序的责任只是实现一个 Appium 内部接口，该接口表示 WebDriver 协议。它如何实现此接口完全取决于驱动程序，基于其在特定平台上实现自动化的策略。通常，并且在细节上更加复杂和困难，驱动程序通过依赖平台特定的自动化技术来做到这一点。例如，Apple 维护着一个名为 XCUITest 的 iOS 自动化技术。支持 iOS 应用程序自动化的 Appium 驱动程序称为 XCUITest 驱动程序，因为它最终所做的是将 WebDriver 协议转换为 XCUITest 库调用。

驱动程序是独立的可插拔模块的原因之一是它们彼此之间完全不同。为不同平台构建和使用驱动程序的工具和要求完全不同。因此，Appium 允许您仅使用自动化任务所需的驱动程序。选择驱动程序并安装它们以便您可以在 Appium 实例中使用它们非常重要，以至于 Appium 有自己的 用于管理驱动程序的 CLI。

因此，为了回答我们最初的问题，Appium 为给定平台提供对自动化功能的访问的方式是，Appium 团队（或任何其他人³）为该平台编写一个驱动程序，实现尽可能多或尽可能少的 WebDriver 协议。然后，任何使用 Appium 的人都可以安装该驱动程序。

通用编程语言访问

但是，无论如何，使用 Appium 意味着什么，或者看起来像什么？由于 Appium 最终是一个 Node.js 程序，它可能看起来像将 Appium 及其驱动程序作为库导入到您自己的 Node.js 程序中。但这不符合 Appium 为使用任何流行编程语言的人提供自动化功能的目标。

幸运的是，Appium 搭乘 Selenium 的便车这一事实意味着我们从一开始就有了解决这个问题的方案。您会发现，WebDriver 规范实际上是一个基于 HTTP 的协议，这意味着它被设计为在网络上使用，而不是在单个程序的内存中使用。

这种“客户端-服务器”架构的主要优势之一是它允许自动化实施者（执行自动化的东西，在本例中是“服务器”）与自动化运行器（定义应执行什么自动化，以什么步骤等...，在本例中是“客户端”）完全分离。基本上，所有“困难的事情”（实际上弄清楚如何在给定平台上实现自动化）都可以在服务器上的一个地方处理，并且可以在任何编程语言中编写“瘦”客户端库，这些库只是以语言适当的方式对服务器进行 HTTP 请求编码。换句话说，假设存在高级 HTTP 库，只需在该语言中编写一个基本的 HTTP 客户端，就可以相对容易地将基本的 Appium/WebDriver 功能引入新的编程语言。

这里有两个重要的要点供您，Appium 用户

• Appium 是一个 HTTP 服务器。只要您想使用它进行自动化，它就必须作为某个计算机上的一个进程运行。它必须在网络上可访问，以便您想从中运行自动化的任何计算机（无论是在同一台机器上还是在世界另一端）。
• 除非您想编写原始 HTTP 调用或使用 cURL，否则使用 Appium 进行自动化需要使用您选择的语言的 Appium 客户端。这些客户端的目标是封装 WebDriver 协议，以便您可以使用对象和方法来处理您的语言，而无需担心协议本身。
• Appium 服务器和 Appium 客户端不需要在同一台计算机上运行。您只需要能够通过网络从客户端向服务器发送 HTTP 请求。这极大地促进了使用 Appium 的云提供商，因为它们可以托管 Appium 服务器和任何相关的驱动程序和设备，您只需要将您的客户端脚本指向它们的安全的端点。

当然，这与“测试”本身无关，纯粹是关于使用 Appium 及其客户端库进行自动化。如果您想出于“测试”目的进行自动化，您可能需要借助测试运行器、测试框架等，这些都不需要与 Appium 相关；Appium 的“通用可访问性”的优势之一是它可以很好地与您在特定情况下发现的最有益的工具集配合使用。

Appium 的巨大范围

Appium 的愿景（在单个 API 下自动化所有内容）是巨大的！当然，比开源项目的核心维护团队要大得多。那么 Appium 如何希望实现这一目标呢？基本上，通过赋予社区在 Appium 作为平台的基础上开发功能。这就是我们所说的 Appium “生态系统”。

Appium 团队确实自己维护了一些驱动程序（例如，我们之前提到的 XCUITest 驱动程序）。但它无法希望拥有平台特定的专业知识或维护许多不同平台的驱动程序的能力。但是我们所做的是，特别是从 Appium 2 开始，提供工具来赋予社区加入我们的愿景

• 任何人都可以通过创建一个符合适当约定的 Node.js 模块并实现 WebDriver 协议的任何（子|超）集来创建驱动程序。创建驱动程序通常涉及最少的代码量，因为 WebDriver 协议细节被抽象化，并且许多辅助库可用——这些库与 Appium 团队自己的驱动程序使用的库相同。
• 使用 Appium 驱动程序 CLI 与他人共享驱动程序很容易。没有中央机构。任何人都可以公开或私下共享驱动程序，免费或付费。驱动程序可以是开源或闭源的（尽管我们显然赞赏开源！）。

Appium 的成为所有应用程序平台自动化平台的愿景超越了对所有应用程序平台自动化的支持。作为一个流行的自动化工具，有很多机会将 Appium 与各种其他工具和服务集成。此外，Appium 有很多功能想法，无论是作为核心服务器还是在跨各种驱动程序的化身中，核心团队永远没有时间构建。因此，随着 Appium 2 的发布，Appium 发布了一个插件系统，使任何人都可以构建和共享模块来改变 Appium 的工作方式！

与驱动程序可以通过 Appium 驱动程序 CLI 轻松共享和使用的方式相同，插件可以通过并行的 插件 CLI 发布和使用。插件可以做各种事情，例如为 Appium 添加根据模板图像查找和交互屏幕区域的能力（如 images 插件）。您可以使用插件做的事情几乎没有限制，因此您可能也有兴趣学习如何使用 Node.js 构建插件，这些插件可以与 Appium 一起使用。

这就是 Appium：一个可扩展的、通用的界面，用于可能所有内容的 UI 自动化！继续阅读一些特定的介绍文档以了解更多详细信息，或者查看各种指南以深入了解 Appium 的一些更一般的概念和功能。

---

1. 为了实现这些主要目标，我们还使用一组次要目标或方法论原则，我们也鼓励 Appium 扩展开发人员使用这些原则

   • 尽可能依赖（并贡献）开源技术
   • 尽可能依赖特定平台的供应商提供的工具
   • 尽可能依赖允许自动化未修改应用程序的自动化工具（最好不要要求用户构建额外的 SDK 或软件，这些 SDK 或软件会在应用程序的测试版本和生产版本之间引入差异）
   • 尽可能依赖现有标准，而不是创建新的标准

   ↩

2. 从技术上讲，当 Appium 首次编写时，我们正在处理比 WebDriver 规范更旧的东西，称为 JSON Wire 协议。从那时起，Appium 继续随着 W3C 规范的演变而演变，并且完全符合 W3C 规范。 ↩

3. 您可以构建和共享自己的驱动程序！查看 构建驱动程序 以了解有关如何使用 Node.js 开发可与 Appium 一起使用的驱动程序的更多信息。 ↩