摘要

眾所周知，自動化測試可以一定程度上減輕測試人員負擔，提高測試效率，並且通過自動化還可以實現可靠性測試和效能測試。對於移動客戶端測試而言，如果我們能夠讓手機自動執行應用程式來幫助我們檢測功能的正確性，會不會很酷？有道測試組對一些熱門的手機自動化工具進行了調研，並選擇了一些工具進行實際的使用。本文將會結合實際工作，對移動客戶端（Android&iOS）GUI自動化的工具調研和實現進行介紹。

Android

工具

Android APIs ^[1] 提供的instrumentation類可以初始化Android應用程式程式碼，允許你監控應用程式的系統互動，配合KeyEvent、MotionEvent類，傳送使用者事件，進而實現GUI 層的自動化。測試程式需要繼承ActivityInstrumentationTestCase2來實現自動化。

為了方便編寫自動化測試用例，我們需要對ActivityInstrumentationTestCase2進行擴充套件。業界也已經有一些成熟的自動化工具，諸如Robotium、Athrun、NativeDriver、MonkeyRunner等。我們需要針對自身產品的需求，從中選取一款合適的工具來實現自動化。對於移動客戶端GUI的自動化而言，需要保證選取的工具有以下幾點特性：

1. 工具開源，易於擴充套件。
2. 指令碼編寫簡潔，維護成本低。
3. 滿足客戶端的自動化需求。
4. 便與校驗結果的正確性。
5. 可用於持續整合。

表1列出了這四款工具的區別：

表1  Android自動化工具對比

MonkeyRunner通過編寫Python指令碼來實現自動化，結果的驗證是通過截圖比對圖片來實現，驗證方式不夠靈活，不建議採用。

NativeDriver ^[2] 是WebDriver 介面的一種實現，使用移動客戶端原生UI而不是瀏覽器UI（Selenium）的自動化測試工具。類似於selenium RC的方式來執行測試程式，對於熟悉WebDriver的使用者，上手會很快。從表1可以看出該工具也可以滿足我們的自動化需求，但在調研初期，該工具提供的介面較少，沒法滿足測試需求，而今的完善程度也已經很高了。沒有使用該工具可以認為是歷史原因吧。

Robotium ^[3] 被大家所熟知，基於instrumentation實現，提供的介面可以滿足大部分自動化需求。但不支援webview，而有道詞典的查詞結果展示恰好使用的是webview元件，該模組就沒有辦法通過該工具來實現自動化。

Athrun ^[4] 的實現和Robotium類似，提供的介面也很多，並且支援webview，也可實現持續整合。對於我們的產品而言，滿足自動化的需求。由於工具開源，在今後需求不滿足的時候我們也可以在該工具的基礎上做一些封裝。所以最終選擇了Athrun來實現筆記和詞典的GUI自動化。

例項

和寫Android應用類似，首先要建立一個Android Test Project ，指定被測試的Android Project。如果沒有應用原始碼，也可以在測試程式的AndroidManifest.xml檔案內，修改<instrumentation> 標籤下targetPackage為我們要測試的應用程式的package。之後匯入framework.jar，就可以開始編寫自動化指令碼了。圖1是有道雲筆記Android端登入模組的自動化用例： 

圖1  Android 自動化用例

我們需要繼承AthrunTestCase，指定package和想要開始的Activity 。每一個方法作為一個測試用例，最後以Android JUnit Test的方式執行測試用例。這裡需要注意的一點，要先在裝置上安裝被測試的應用。如果這個應用是簽名過的，那麼我們的測試應用也需要用一樣的簽名。

從程式碼可以看出，尋找元件的介面很簡單，可以通過元件的id、value等屬性來尋找。如果元件沒有相對獨立的屬性，也可以通過該元件的父節點一層層來尋找。Android SDK提供的hierarchyviewer工具將模擬器當前Activity的 UI元件以樹狀形式展現，可以清晰的看到每個元件的詳細屬性。

驗證一條測試用例是否通過的方式也有很多種，可以驗證Activity的跳轉、元件的展示，當然還有一些可能就需要通過截圖。圖1是通過驗證執行用例後Activity的跳轉來判斷測試用例是否通過。

以上我們就完成了一條測試用例的自動化。顯然基於Athrun的框架，使得我們的自動化用例編寫方便了很多，成本也大大降低了。

iOS

工具

在介紹iOS自動化之前，首先要介紹下Xcode 所提供的 instruments ^[5] 工具。該工具是一款用來動態跟蹤和分析OS X和iOS程式碼的實用工具。這是一個靈活而強大的工具，它讓你可以跟蹤一個或多個程序，並檢查收集的資料。這樣，Instruments可以幫你更好的理解應用程式和作業系統的行為。

instruments除了提供自動化工具automation外，還有諸如leaks、allocations等用來檢測和分析程式效能的工具。對於iOS測試和開發而言，追蹤和定位缺陷，instruments是非常實用的。圖2是instruments的主介面： 

圖2  instruments 主介面

關於instruments所提供的各種工具的使用，感興趣的朋友可以在 iOS Developer Library 中瞭解。

接下來就要介紹一下UI Automation，它可以用在真實裝置或模擬器來執行自動化測試。

使用JavaScript編寫測試用例，呼叫UI Automation的介面模擬使用者互動操作。該工具會將自動化執行的日誌資訊返回到instruments 資訊欄。

例項

在Xcode通過 profile的方式來啟動instruments。或者直接雙擊啟動instruments，在instruments主介面中選擇裝置上被測試的應用程式。然後在Automation Script欄編寫自動化指令碼。使用iOS裝置需要注意的一點是確保Developer profile設定是Release模式。圖3是有道雲筆記iPhone版登入模組的自動化用例：

圖3  iOS 自動化用例

完成自動化指令碼後，可以通過點選Instruments 的Record按鈕來執行，也可以通過instruments相關命令來執行。前者適合於除錯，後者適合於持續整合。

從圖3可以看出，對應的UI 元件需要逐層指定。定位這些元件有兩種方式。對於iOS 5以上的系統可以通過錄制生成指令碼，但錄製的方式可能會記錄錯誤。所以為了定位準確的元件位置，就需要呼叫logElementTree ，將當前螢幕元件的層次樹狀結構列印到日誌中，通過日誌定位元件。

從上圖也可以看出UI Automation 所提供的驗證機制有些繁瑣，驗證每一個元件是否存在都需要去做判斷。這僅僅是冰山一角，UI Automation會對捕獲到彈出視窗（alert）點選預設操作按鈕，提供的日誌檔案也不便於分析，所以我們有必要對UI Automation的介面進行二次封裝，更方便去編寫自動化用例。

Athrun也提供了iOS的自動化框架，有三種實現方式。第一種AppFramWork是程式碼注入型，需要在原始碼中插入測試程式碼，Objective-C編寫測試用例，自動化成本較高，不建議使用。第二種instrument Athrun就是對UI Automation的介面進行擴充套件，提高了原有介面執行的穩定性。第三種instrumentDriver基於instrument JS框架來開發InstrumentDriver服務端，在java上實現客戶端，使用java指令碼控制iOS自動化執行。該框架還實現了單步執行，除錯等UI Automation沒有的功能。圖4為instrumentDriver的架構圖： 

圖4  instrumentDriver 架構圖

從instrumentDriver的介紹可以看出，相比蘋果所提供的UI Automation是有不少優點的。目前由於我們需要通過自動化指令碼配合instruments 其他效能檢測工具來實現對應用程式的效能測試，所以依舊採用instruments 原生工具配合擴充套件的JS指令碼的方式。後續如果可以找到更好的獲取效能資料的辦法，會逐漸轉向instrumentDriver的方式來實現iOS的自動化。

對比

從表2可以簡單看一下目前我們選擇的iOS和Android自動化工具的區別：

表2  iOS和Android自動化工具對比

結語

自動化的實現一定程度上提升了我們的測試效率，由於網際網路產品迭代速度較快，這裡建議大家自動化從冒煙測試做起，用例設計要儘可能簡潔，多做封裝，以便降低維護成本。同時實現自動化的持續整合，更早介入測試，更早發現問題。在此基礎之上，我們還可以通過自動化配合獲取效能資料的指令碼來實現對應用程式的效能測試。這些工作可以使得我們的測試覆蓋更廣，測試力度更深，更好的檢測和監控產品質量。

參考資料