UiAutomator 1.0 與 UiAutomator 2.0 差異

Google Android Developers 在 2015 年 3 月 13 日時公開發表了 UiAutomator 2.0,v2.0 相較於 v1.0 最明顯的優勢在於其 在 v1.0 的基礎上增加了許多實用性高的 API 。包含:

另外還有一最主要的差異為 UiAutomator 2.0 測試產出由 Java Base 更改為 Android Base ,讓 UiAutomator 2.0 可以完整的在 Android Instrumentation 上運行,這是個優勢能讓此框架更完善的被終端使用者運用。

輸出從 .jar or .zip 變更為 .apk

差異

因為前言所提及的主要更新以及其他基礎的更新,讓 UiAutomator 2.0 運作架構與 UiAutomator 1.0 大不相同,因此在 UI Testing 上有些顯著的實用改善,如:

  • 支援中文輸入
  • v2.0 可直接對 Application 輸入中文
  • v1.0 需借助 utf 才能輸入中文

  • 支援更準確的 Element 判定

  • v2.0 必須明確定位位置才能對 EditText 送文字
  • v1.0 即使定位在父類別也會對子類別 EditText 送文字

  • 支援 Android OS Unique Elements

  • Android Toast 識別

  • 修正 v1.0 大多數的 Bugs

  • 將框架的更新與 Android OS 切分

  • 相較 v1.0 更快速更有效率

  • Element Finding
  • Android Activities

因上述差異,UiAutomator 2.0 相對於 UiAutomator 1.0 來說,可說是一大有感升級,也因為 UiAutomator 2.0 額外支援了 Android OS 的特殊 elements 判定,讓自動化測試在更新的 OS 版本上(如 Android 7.0)更加完善,也因此隨著欲執行自動化測試的裝置越新,也會建議轉換成 UiAutomator 2.0 框架來執行自動化測試,可以避免掉許多框架上的瑕疵而導致的錯誤。

上述簡單介紹了 UiAutomator 1.0 與 UiAutomator 2.0 之間的差異,接下來將介紹使用 Google UiAutomator 2.0 的自動化測試框架 Appium 運作兩種框架的實際差異。


Appium With UiAutomator 2.0

自從 UiAutomator 2.0 發表後,其實官方本身的文件並不多,在業界也並沒有很廣泛的被使用,而且甚至在 UiAutomator 2.0 仍然有些原生的 Issue 待解,所以各個測試框架也只能在這好與壞的尷尬之間努力著墨,提供使用者完善的測試框架,而在此處我們使用的自動化測試框架為 Appium。

Appium 在 Google 推出 UiAutomator 1.0 時就有發表出運用 UiAutomator 1.0 的相對應測試框架,[GitHub] appium-android-bootstrap 是使用 Google UiAutomator 1.0 API 來實作 Devices 動作,而 [GitHub] appium-uiautomator2-server 則是使用 Google UiAutomator 2.0 API 將 appium-android-bootstrap 的 Bootstrap Module 重新實作(re-implement)。

差異

Item appium-android-bootstrap appium-uiautomator2-server
Package AppiumBootstrap.jar appium-uiautomator2-server-vX.X.X.apk
Automation Google UiAutomator 1.0 Google UiAutomator 2.0
Controller Server Socket Netty Server

由上表可以發現 appium-uiautomator2-server 使用的自動化框架為 UiAutomator 2.0,也因為 UiAutomator 2.0 本身已經修正了許多 UiAutomator 1.0 的 Bugs,能讓 UiAutomator 本身所產生的 Flaky 下降許多。

再來是 requests 的溝通橋樑差異,appium-android-bootstrap 是使用 Appium Server 本身的 Server Socket 來處理 Client 端的 WebDriver Script 與 devices/emulators 的 Action,而 appium-uiautomator2-server 則是使用透過 appium-uiautomator2-driver 所驅動的 Netty Server 來運行 requests,使用 Netty Server 比起使用 Server Socket 能擁有更好的 Performance 以及耗費更少的記憶體。

P.S. Netty 在 client-server 間是個 non-blocking I/O 的框架,意即所有的 I/O actions 不會出現反向干擾,展現出其高性能。 from Netty (software) – Wikipedia

實際升級經驗談

在我們的 Android 自動化測試上,使用 Appium With UiAutomator 1.0 已經好一陣子了,長期使用此自動化測試框架其實可以很明顯的感受到因為 UiAutomator 1.0 本身不穩定的狀況而導致測試失敗的無奈感,實際舉出幾個我們實際升級成 UiAutomator 2.0 後的有感改善例子來說:

  • 元件定位
  • v1.0 判斷過慢且不穩定,容易出現 NoSuchElementException 卻可以肉眼看得到元件的狀況,或是頁面載入完成後需要 1~2 秒才能定位出元件。
  • v2.0 判斷元件迅速,等待頁面載入完成後,幾乎可以在 1 秒內定位出元件,因此偶爾會出現頁面還沒載入完成卻已經執行完判斷的有趣現象。

實際經驗:v2.0 若妥善的搭配 Explicit Wait 可以大幅的降低 Test Script Error。

  • 指令執行間距
  • v1.0 因為僅用同一 Server 在做動作,因此下一步驟容易因為上一步驟不穩定性而延遲,進而導致步驟與步驟間距差異大。
  • v2.0 因為本身動作會由 Netty Server 分別處理,接收 Requests 與執行 Action 並不會由同 Server 處理,所以步驟間距時間相對穩定。

實際經驗:從肉眼就可以觀察到 v2.0 跑測試時穩定的節奏性,若 Test Code 有誤也能很直覺的瞭解錯誤點。

  • 測試時間過長
  • v1.0 跑複雜性高的測試時,因為同一 Server 序列處理 Requests 和執行 Action,堆疊下來的測試時間會非常可觀。
  • v2.0 因其測試步驟間距穩定,動作執行俐落,並列處理 Requests 和執行 Action 能省下不少時間。

實際經驗:根據多次測試計算,在 v1.0 平均一條跑 2 分鐘的測試,在 v2.0 運作平均一條降低 6.3 秒左右(會因為不同動作而有不同的加速幅度)

  • 系統支援限制
  • v1.0 因為不支援 Android Nougat 以上的 OS 原生架構,所以測試裝置僅能只用 Android 6.0 或更低階的裝置。
  • v2.0 已向上相容支援 Android Nougat 以上的 OS 原生架構,測試裝置也因此能升級至 Android 7.0 的高階裝置。

實際經驗:使用低階裝置容易出現網路異常、效能低落的現象,高階且穩定的裝置能減少許多 Flaky。

UiAutomator 2.0 除了提供給我們更穩定的測試輸出外,「測試時間」對於測試來說也是一大重點,UiAutomator 2.0 除了本身速度穩定且較快的優勢外,因為其支援度提高,能讓自動化測試運行在更高階更高效能的裝置,的確大幅的縮減了測試可能出現的外在影響,綜觀以上幾點實際的例子來說,這就是我們實際從 UiAutomator 1.0 升級至 UiAutomator 2.0 後會推薦使用此自動化框架的原因,以上的升級歷程及升級經驗提供給大家參考。

參考資料

廣告

發表迴響

Please log in using one of these methods to post your comment:

WordPress.com Logo

您的留言將使用 WordPress.com 帳號。 登出 / 變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 / 變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 / 變更 )

Google+ photo

您的留言將使用 Google+ 帳號。 登出 / 變更 )

連結到 %s