Appium 與現代行動框架：了解自動化挑戰

過去十年，行動自動化技術取得了顯著進步，這主要得益於 Appium 等框架的出現，它們使團隊能夠使用熟悉的語言和工具來實現應用程式的自動化。同時，React Native、Flutter 和 Jetpack Compose 等現代 UI 框架透過抽象化大部分原生 UI 層，徹底改變了行動應用程式的建置方式。

雖然這些框架可以加快開發速度，但它們也可能為測試自動化帶來意想不到的挑戰——尤其是在 UI 元素是動態產生或缺乏穩定標識符的情況下。

了解現代框架如何向自動化工具公開 UI 元素，可以幫助團隊設計出既對開發者友善又對自動化友善的應用程式。

行動自動化工具如何識別使用者介面元素

自動化框架，例如 鴉片 透過作業系統提供的原生自動化框架與行動應用程式互動。

例如：

• AndroidUIAutomator2
• iOS：XCUITest

這些原生框架將應用程式的 UI 層級結構揭露給自動化工具。測試腳本使用定位器（例如）與此層級結構中的元素進行互動：

• 輔助使用 ID
• 資源 ID
• XPath表達式
• 類名

其中，輔助功能標識符被廣泛推薦，因為它們在版本建置和使用者介面變更中往往保持穩定。

對於 Appium 的新手讀者，您可以瀏覽概述。 Appium架構在此.

現代 UI 框架和定位器穩定性

React Native、Flutter 和 Jetpack Compose 等框架提供了抽象層，使開發人員能夠更有效率地編寫 UI 程式碼。然而，這些框架通常會在執行時間動態產生原生 UI 元件。

結果是：

• UI層級結構可能會在不同的版本中發生變化。
• 某些元素可能不會公開穩定的識別碼。
• 自動產生的視圖結構可能會影響定位器的可靠性。

這並不意味著這些框架難以自動化。相反，它凸顯了以下幾個方面的重要性： 明確定義 UI 元素的穩定標識符 自動化測試所依賴的。

這也對諸如基於人工智慧的自癒等新功能產生了影響。這些系統依賴應用程式結構一定程度的穩定性來識別定位器何時真正發生了變化。如果標識符和使用者介面層級在不同版本之間發生顯著變化，則每次執行都可能需要“修復”，從而降低自動恢復機制的有效性。

不同版本間的識別符不穩定

自動化不穩定的一個常見原因是 UI 元素依賴在不同版本之間發生變化的標識符。

譬如：

• 未定義輔助功能標識符的元素
• 動態產生的視圖結構
• 源自內部元件層次結構的識別符

在這種情況下，自動化測試可能在一個版本中通過，但在另一個版本中失敗，因為底層 UI 結構發生了變化。

這在現代 UI 框架中尤其常見，因為渲染的原生元件可能會根據佈局更新或框架優化而有所不同。

範例：React Native 中的穩定標識符

React Native 等框架提供了一些屬性，讓開發人員公開穩定的識別碼以進行自動化操作。

例如：

<Button 
  testID="login_button" 
  title="Login" 
/>

此標識符可供自動化框架訪問，並允許測試可靠地定位元素。

使用這種明確的標識符可以確保即使 UI 佈局隨著時間的推移而演變，測試也能保持穩定。

可訪問性和可測試性往往相輔相成

使用輔助使用標識符不僅有利於自動化，還能提高依賴螢幕閱讀器等輔助技術的使用者的使用體驗。

任何一種 Apple 以及 Google 建議在以下位置公開有意義的輔助使用標籤和識別碼： 行動應用程式可訪問性提升.

在實踐中，這意味著在設計使用者介面元素時考慮到可訪問性通常會有所改進。 同時提高自動化可靠性.

實用調試技巧：檢查使用者介面層級結構

當定位器在不同版本中的行為不一致時，檢查 UI 層次結構可以揭示元素是如何暴露給自動化工具的。

有助於實現這一目標的工具包括：

• Appium 檢查器
• Xcode 輔助使用檢查器
• Android UIAutomator Viewer
• Android Studio 佈局檢查器

這些工具可讓測試人員檢查 UI 樹並進行驗證：

• 元素是否公開穩定的輔助使用標識符
• 標識符是否會在不同版本之間發生變化
• UI 層級結構是否包含動態產生的元件

通常情況下，只要檢查使用者介面層次結構，就能更容易辨識出定位器不穩定的根本原因。

品質保證工程師的最佳實踐

品質保證工程師可以透過遵循以下幾個關鍵實踐來提高自動化可靠性：

• 比較喜歡 輔助使用標識符 超越 XPath 定位器
• 驗證定位器在多個版本中的穩定性
• 與開發人員協作，定義穩定的標識符
• 使用 UI 檢查工具驗證定位器策略

自動化框架功能強大，但它們很大程度上依賴應用程式如何公開 UI 元素。

行動開發者的最佳實踐

開發人員可以透過在 UI 開發過程中考慮自動化來顯著提高可測試性。

有益的做法包括：

• 為重要的使用者介面元素定義明確的可訪問性標識符
• 避免動態產生標識符
• 保持不同版本之間的識別符一致
• 記錄自動化測試中使用的標識符

當開發人員將可測試性視為 UI 設計流程的一部分時，自動化將變得更加穩定且易於維護。

自動化作為其中的一部分 Continuous Testing

在現代交付流程中，行動自動化通常是更廣泛的持續測試策略的一部分，其中自動化測試貫穿整個開發生命週期。

希望在大規模設備叢集上擴展自動化測試的團隊通常會將 Appium 等框架與支援大規模行動自動化執行的裝置叢集平台結合使用。這樣就可以跨多個裝置和作業系統版本進行測試。

進一步了解 Digital.ai 測試平台在此： https://docs.digital.ai/continuous-testing/

結語

諸如 React Native、Flutter 和 Jetpack Compose 等現代移動框架大大提高了開發人員的效率。然而，如果在開發過程中沒有考慮可測試性，它們的抽象層有時會為自動化帶來挑戰。

為了實現可靠的自動化，品質保證工程師和開發人員都能從處理中受益。 測試標識符是使用者介面設計的核心組成部分而不是事後考慮的。

穩定的輔助使用識別碼可以提高 Appium 等工具的自動化可靠性，同時也能為真實使用者提供更好的輔助功能。

當團隊在早期階段就協作進行可測試性測試時——透過公開穩定的標識符、避免動態定位器和驗證 UI 層次結構——行動自動化在各個建置版本中變得更加可預測和可維護。

在許多情況下，脆弱的自動化和可靠的自動化之間的差異不在於測試工具本身，而是應用程式 UI 的設計是否便於測試。