跳至內容

Appium 如何運作？

正如在主頁所提到的，Appium 是個開放原始碼專案和相關軟體的生態系統，旨在促進許多應用程式平台的 UI 自動化。隨著 Appium 2 的釋出，Appium 有以下主要目標：1

  • 在跨平台、標準 API 下提供特定於平台的自動化功能
  • 允許從任何程式語言輕鬆存取此 API
  • 提供工具以利社群方便開發 Appium 擴充功能

因此，採用您所知道的任何應用程式平台，例如 iOS 或 Android。Appium 希望開發人員和測試人員能夠根據單一統一的 API 為該平台撰寫 UI 自動化程式碼。根據 Appium 的目標，我們有許多問題需要回答才能讓一切順利運作

  • 「單一統一」的 API 應該是哪個 API？
  • 我們如何將該 API 對應到特定平台的自動化行為？
  • 我們如何透過多種熱門程式語言讓該 API 可以存取？

這裡還潛藏著另一個更大的問題，因為除了 iOS 和 Android 之外，還有更多應用程式平台

  • 我們如何為所有平台啟用自動化？

探討 Appium 對這些問題的解答可能不是了解 Appium 的最快方法，但絕對是個好方法！讓我們深入探討。

Appium 選擇的 API

Appium 很幸運，因為在它之前，有一項技術在 UI 自動化領域中長期以來一直是先驅，那就是 Selenium。Selenium 專案的目標是支援網頁瀏覽器的 UI 自動化，因此我們可以將它視為涵蓋 Appium 目標的子集。在這過程中，Selenium（以及在它們合併後，另一個名為 WebDriver 的專案）開發了一個相對穩定的瀏覽器自動化 API。

多年來，Selenium 與各種網頁瀏覽器供應商和 W3C 標準組織合作，將其 API 轉變為官方網頁瀏覽器標準，稱為 WebDriver 規範。現在所有主要瀏覽器都實作與 WebDriver 規範一致的自動化功能，而 Selenium 團隊不必維護執行實際自動化的任何軟體；標準萬歲！

Appium 的最初目標是為行動應用程式（iOS 和 Android）開發自動化標準。我們可以創造一些新的東西，但本著團結力量和維持標準的精神，我們決定採用 WebDriver 規範作為 Appium 的 API。2雖然網站和行動原生應用程式的使用者互動並不完全相同（例如，當我們開始考慮由簡單遙控器控制的電視平台時，差異更大），但事實上，大多數軟體 UI 幾乎都是相同的。這表示 WebDriver 規範提供自動化 API 原語（尋找元素、與元素互動、載入網頁或畫面等），這些原語或多或少對應到任何平台。

當然，Appium 希望支援使用者互動確實從網頁到行動裝置或網頁到電視有所不同的情況，因此 Appium 也利用 WebDriver 規範內建的可擴充性。結果是，無論您想要自動化哪個平台，當您使用 Appium 時，您將使用標準 WebDriver 規範，但有兩個但書

  • 我們可能無法在特定平台上支援任何 WebDriver API 命令，因此有些命令可能不受支援（例如，在原生行動應用程式自動化的領域中，無法取得或設定 Cookie）。
  • 我們可能支援超越 WebDriver API 命令清單中可用功能的自動化行為，儘管任何此類命令都將是有效的且符合規範的 WebDriver API 擴充功能。

你實際上如何使用 WebDriver API，特別是在 Appium 的情況下？我們將在以下章節中介紹 Appium 如何提供通用程式語言存取權。你現在只需要知道 Appium 透過實作 WebDriver 協定來引入通用 UI 自動化介面的方式。

平台自動化行為

接下來的問題是，Appium 如何將此協定對應到各種平台上的自動化行為？訣竅在於，嚴格來說，Appium 沒有這麼做！它將此責任留給一種稱為 Appium 驅動程式的軟體模組。有一個完整的驅動程式簡介，你可以接著閱讀，因此我們現在不會深入探討它們如何運作。

目前重要的是要了解，驅動程式有點像是 Appium 的可插入模組，它賦予 Appium 自動化特定平台（或一組平台，視驅動程式的目標而定）的能力。最終，驅動程式的責任只是實作表示 WebDriver 協定的 Appium 內部介面。它如何實作此介面完全取決於驅動程式，基於它在特定平台上進行自動化的策略。通常，驅動程式會透過依賴特定於平台的自動化技術來執行此操作，而且在細節上會更複雜且困難。例如，Apple 維護一種稱為XCUITest的 iOS 自動化技術。支援 iOS 應用程式自動化的 Appium 驅動程式稱為XCUITest 驅動程式，因為它最終所做的就是將 WebDriver 協定轉換為 XCUITest 函式庫呼叫。

驅動程式為獨立、可插入模組的原因之一，在於它們彼此運作的方式完全不同。建置和使用不同平台驅動程式的工具和需求完全不同。因此，Appium 讓您僅使用自動化任務所需的驅動程式。選擇驅動程式並安裝它們，以便您可以將它們與您的 Appium 執行個體搭配使用，這非常重要，因此 Appium 擁有自己的 用於管理驅動程式的 CLI。

因此，要回答我們最初的問題，Appium 提供存取特定平台自動化功能的方式是 Appium 團隊（或其他任何人3）為該平台撰寫一個驅動程式，實作 WebDriver 協定的任意多或少功能。然後，任何使用 Appium 的人都可以安裝該驅動程式。

通用程式語言存取

不過，使用 Appium 到底是什麼意思，或看起來像什麼？由於 Appium 最終是一個 Node.js 程式，它可能看起來像將 Appium 及其驅動程式匯入到您自己的 Node.js 程式中作為函式庫。但這無法達成 Appium 的目標，也就是為使用任何流行程式語言的人們提供自動化功能。

幸運的是，Appium 搭著 Selenium 的順風車，這表示我們從第一天就有了解決這個問題的方案。您會發現，WebDriver 規格實際上是一個基於 HTTP 的協定，表示它設計為在網路中使用，而不是在單一程式的記憶體中使用。

此「客戶端-伺服器」架構的主要好處之一，在於它允許自動化實作程式（在本案例中進行自動化的程式，即「伺服器」）與自動化執行程式（在本案例中定義自動化應如何執行、執行步驟等事項的程式，即「客戶端」）完全區分。基本上，所有「困難的工作」（實際找出如何在特定平台上執行自動化）都可以在一個地方由伺服器處理，而「精簡」的客戶端程式庫可以用任何程式語言撰寫，這些程式庫只需以符合語言的方式對傳送至伺服器的 HTTP 要求進行編碼。換句話說，只要存在高階 HTTP 程式庫，就可以相對輕鬆地將基本的 Appium / WebDriver 功能帶入新的程式語言，只需用該語言編寫基本的 HTTP 客戶端即可。

對於身為 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 開始，就是提供工具來賦予社群加入我們願景的能力

  • 任何人只要建立一個符合適當慣例並實作任何 WebDriver 協定的（子|超）集合的 Node.js 模組，就能建立一個驅動程式。建立驅動程式通常只需要最少的程式碼，因為 WebDriver 協定細節已被抽象化，而且有許多輔助函式庫可用---這些函式庫與驅動 Appium 團隊自己驅動程式的函式庫相同。
  • 使用 Appium 驅動程式 CLI 可以輕鬆地與他人分享驅動程式。沒有中央權威。任何人都可以公開或私下分享驅動程式，免費或販售。驅動程式可以是開放或封閉原始碼（儘管我們顯然欣賞開放原始碼！）。

Appium 作為開發平台的願景超越了對所有應用程式平台自動化的支援。作為一個熱門的自動化工具，Appium 有許多機會與各種其他工具和服務整合。此外，Appium 有許多功能構想，無論是作為核心伺服器或在各種驅動程式中體現，而核心團隊永遠沒有時間建立。因此，Appium 2 發布了一個外掛程式系統，讓任何人都可以建立和分享改變 Appium 運作方式的模組！

與驅動程式透過 Appium 驅動程式 CLI 輕鬆分享和使用的方式相同，外掛程式也可以透過平行 外掛程式 CLI 發布和使用。外掛程式可以執行各種類型的操作，例如新增 Appium 根據範本影像尋找和與螢幕區域互動的能力（就像 images 外掛程式）。外掛程式的功能限制非常少，因此您可能也有興趣瞭解如何在 Node.js 中 建立外掛程式 以與 Appium 搭配使用。

這就是 Appium：一個可擴充的通用介面，可自動化所有可能的 UI！請繼續閱讀一些特定簡介文件以取得更多詳細資料，或查看各種指南深入了解 Appium 的一些更通用的概念和功能。

  1. 為了達成這些主要目標，我們也使用一組次要目標或方法原則，我們也鼓勵 Appium 外掛程式開發人員使用

    • 盡可能依賴（並貢獻）開源技術
    • 盡可能依賴特定平台供應商提供的工具
    • 盡可能依賴允許自動化未修改應用程式的自動化工具（最好不要要求使用者內建其他 SDK 或軟體，這些 SDK 或軟體會在應用程式的測試版本和生產版本之間造成差異）
    • 盡可能依賴現有標準，而不是建立新的標準

    ↩

  2. 技術上來說，當 Appium 最初撰寫時，我們處理的是比 WebDriver 規格更舊的東西，稱為 JSON Wire Protocol。從那時起，Appium 持續與 W3C 規格一同進化，並完全符合 W3C 規範。 ↩

  3. 您可以建立並分享自己的驅動程式！請查看 建立驅動程式 以進一步瞭解如何在 Node.js 中開發可與 Appium 搭配使用的驅動程式。 ↩