Appium 和 Selenium 以外的自動化框架 

一個團隊在同一個迭代周期內發布了一個 React Native 應用程式和一個行銷網站。行動端應用程式套件基於 Espresso 和 XCUITest 建置；Web 端應用程式套件基於 Playwright 建置。兩個團隊都沒有編寫任何 Appium 或 Selenium 程式碼——並非因為這些工具有缺陷，而是因為兩個團隊一開始都不需要跨平台橋接。 

如果你對自動化測試的認知仍然停留在“移動端用 Appium，W​​eb 端用 Selenium”，那也沒錯——只是你忽略了大多數 QA 團隊如今都在默默運行的其他技術棧。本文將帶你了解當團隊的應用程式組合超越基礎階段後，除了 Appium 和 Selenium 之外還會出現的其他框架，以及它們各自發揮作用的場景。 

為什麼雙框架思維模型會走到盡頭 

Appium 和 Selenium 之所以聲名鵲起，自有其道理：一個基於 WebDriver 的單一協議就能驅動幾乎所有行動應用程式或瀏覽器，這在早期階段確實非常實用。但隨著應用程式組合的成熟，問題就顯現出來了——原生 iOS 和 Android 建置版本差異增大，Web 前端轉向元件密集型框架（這些框架假定自動化速度快、穩定性高），測試套件規模龐大，以至於「運行測試」和「組織測試」變成了兩個獨立的問題。所有這些問題都無法透過尋找更好的 WebDriver 用戶端來解決，而需要將框架與應用層相符。 

Playwright：專為現代 Web 應用的實際行為而設計 

Playwright 直接針對瀏覽器引擎進行自動化操作 ——Chromium、Firefox 和 WebKit——無需將所有操作都路由到 WebDriver 伺服器，這正是它成為單頁應用測試團隊預設推薦方案的重要原因之一。自動等待元素、每個測試使用獨立的瀏覽器上下文以及內建的網路攔截功能，完美解決了以往需要在 Selenium 之上添加自訂重試邏輯才能解決的不穩定問題。 Digital.ai Playwright 專案可在目前框架版本上原生運行測試，因此從 Selenium 遷移過來的團隊無需重新建立平台即可實現目標—參見 劇作家執行文件 用於設置。 

Cypress：前端優先的替代方案 

Cypress犧牲了Playwright的部分跨瀏覽器相容性，換取了更精簡的開發者體驗。 即時重載、可讓您在每一步檢查 DOM 的時間旅行偵錯器，以及前端工程師通常比傳統 WebDriver 腳本更容易上手的測試編寫模型。對於編寫測試的人員與編寫被測 React 或 Angular 元件的人員是同一團隊來說，它非常合適。 Cypress 支援以下平台： Digital.ai 測試所使用的瀏覽器與其他所有測試都相同—詳情請見此處。 Cypress 文檔. 

WebdriverIO：一個 API，兩種協議 

WebdriverIO 很容易被忽視，因為它與其說是取代 Selenium 或 Appium，不如說是建立在兩者之上。 它為團隊提供了一個單一的、現代化的 JavaScript API，可以針對瀏覽器運行 Selenium 會話，或者針對行動應用程式運行 Appium 會話，這對於那些在 Web 和行動端使用單一語言和測試運行器，而不是為每個協議維護單獨的程式碼庫的組織來說，意義重大。 Digital.ai 測試支援 WebdriverIO 針對 Selenium 和 Appium 執行路徑的測試—參見 WebdriverIO 整合文檔 針對每項設定。 

XCUITest 與 Espresso：原生應用程式何時勝過跨平台應用 

Appium 最大的優勢——一個協議即可覆蓋兩個行動平台——也是它最大的局限性，一旦一個套件需要在一個平台上進行深度開發，它就會面臨同樣的問題。 XCUITest（蘋果自家的框架，內建於 Xcode）和 Espresso（Google的框架，內建於 Android Studio）完全繞過了自動化橋接，直接從應用程式自身的進程中驅動應用程式運行。這省去了 Appium 無法避免的間接層，使得它們在處理平台特定的互動（例如深度手勢處理、動畫或作業系統層級的權限對話框）時運行速度更快、更穩定，而跨平台驅動程式則需要付出更多努力才能實現這些互動。大多數成熟的團隊不會在兩者之間做出選擇；他們會使用 Appium 進行跨平台的冒煙測試，而使用 XCUITest 或 Espresso 進行更深入的、平台特定的回歸測試。 Digital.ai 測試在真實設備和雲端同時進行—參見 XCUI測試 以及 表示 執行計劃文件。 

Maestro：YAML優先的方式 

Maestro 完全跳過了程式碼編寫——流程是用純 YAML 而不是 Java、Swift 或 JavaScript 編寫的，這使得非自動化工程師也能進行 UI 測試編寫。 這是一個開源框架，內建了對動畫和載入延遲的容忍度，從而減少了使 Appium 腳本變得脆弱的手動等待和重試邏輯。 Digital.ai 測試中增加了對 Maestro 的支持 26.7 發布在雲端的真實和模擬 Android 裝置上，無需任何改動即可運行現有的 Maestro 流程，同時還能運行 Appium、Espresso 和 XCUITest 測試套件，並與其他執行類型一樣，獲得相同的裝置預留、錄影和報告功能。請參閱 Maestro 整合文檔 用於捆綁包格式和設定。 

根據應用層選擇，而不是憑習慣選擇。 

這並非是要棄用 Appium 或 Selenium 的理由——對於那些只想使用一款跨平台移動工具或一款跨瀏覽器工具，而無需維護其他工具的團隊來說，它們仍然是合適的選擇。上述框架只有在遇到它們所解決的特定問題時才真正發揮作用：例如，當 Selenium 在現代單頁應用 (SPA) 上的不穩定性成為瓶頸時，可以使用 Playwright 或 Cypress；當需要跨平台使用同一 JS API 時，可以使用 WebdriverIO；當測試套件需要在一個平台上進行深度測試時，可以使用 XCUITs 進行測試套件， 

如果團隊決定執行多個測試框架——例如，使用 Playwright 進行 Web 測試，使用 XCUITest 進行 iOS 測試——這是一種深思熟慮的基礎設施決策，而不是免費升級。五個框架意味著五種語法、五種 CI 配置，以及五個版本更新可能導致測試套件悄無聲息地崩潰的地方。只有當平台之間確實存在顯著差異時，這種部署才值得考慮；僅僅為了追求最新版本而部署則毫無意義。 

Digital.ai Testing Cloud 支援以上所有框架，因此，如果團隊確實需要組合使用幾個框架，執行基礎架構就不會成為障礙。 

來源和參考文獻 

Digital.ai 測驗：劇作家 — https://docs.digital.ai/continuous-testing/docs/te/test-execution-home/web-desktop-browsers/playwright 

Digital.ai 測試：Cypress — https://docs.digital.ai/continuous-testing/docs/te/test-execution-home/web-desktop-browsers/cypress 

Digital.ai 測試：WebdriverIO — https://docs.digital.ai/continuous-testing/docs/te/test-execution-home/integrations/frameworks/webdriverio 

Digital.ai 測試：XCUITest 執行計劃 — https://docs.digital.ai/continuous-testing/docs/te/test-execution-home/mobile-android-and-ios/xcuitest-and-espresso/execution-plan-using-xcuitest 

Digital.ai 測試：濃縮咖啡執行計畫 — https://docs.digital.ai/continuous-testing/docs/te/test-execution-home/mobile-android-and-ios/xcuitest-and-espresso/execution-plan-using-espresso 

Digital.ai 測試：Maestro 整合 — https://docs.digital.ai/continuous-testing/docs/te/test-execution-home/integrations/third-party-integrations/maestro-integration