摘要 眾所周知，自動化測試可以一定程度上減輕測試人員負擔，提高測試效率，并且通過自動化還可以實現可靠性測試和性能測試。對于移動客戶端測試而言，如果我們能夠讓手機自動運行應用程序來幫助我們檢測功能的正確性，會不會很酷？有道測試組對一些熱門的手機自動化工具進行了調研，并選擇了一些工具進行實際的使用。本文將會結合實際工作，對移動客戶端（Android&iOS）GUI自動化的工具調研和實現進行介紹。
Android
工具
Android APIs提供的instrumentation類可以初始化Android應用程序代碼，允許你監控應用程序的系統交互，配合KeyEvent、 MotionEvent類，發送用戶事件，進而實現GUI 層的自動化。測試程序需要繼承ActivityInstrumentationTestCase2來實現自動化。
為了方便編寫自動化測 試用例，我們需要對ActivityInstrumentationTestCase2進行擴展。業界也已經有一些成熟的自動化工具，諸如 Robotium、Athrun、NativeDriver、MonkeyRunner等。我們需要針對自身產品的需求，從中選取一款合適的工具來實現自 動化。對于移動客戶端GUI的自動化而言，需要保證選取的工具有以下幾點特性：
1、工具開源，易于擴展。
2、腳本編寫簡潔，維護成本低。
3、滿足客戶端的自動化需求。
4、便與校驗結果的正確性。
5、可用于持續集成。
表1列出了這四款工具的區別：
表1 Android自動化工具對比
MonkeyRunner通過編寫Python腳本來實現自動化，結果的驗證是通過截屏比對圖片來實現，驗證方式不夠靈活，不建議采用。
NativeDriver 是WebDriver 接口的一種實現，使用移動客戶端原生UI而不是瀏覽器UI（Selenium） 的自動化測試工具。類似于selenium RC的方式來運行測試程序，對于熟悉WebDriver的用戶，上手會很快。從表1可以看出該工具也可以滿足我們的自動化需求，但在調研初期，該工具提供 的接口較少，沒法滿足測試需求，而今的完善程度也已經很高了。沒有使用該工具可以認為是歷史原因吧。
Robotium被大家所熟知，基于instrumentation實現，提供的接口可以滿足大部分自動化需求。但不支持webview，而有道詞典的查詞結果展示恰好使用的是webview組件，該模塊就沒有辦法通過該工具來實現自動化。
Athrun的實現和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的框架，使得我們的自動化用例編寫方便了很多，成本也大大降低了。
為了完成各種自動化測試用例，我們有必要對Athrun有更詳細的了解，以便二次開發所需接口。感興趣的朋友可以通過http://code.taobao.org/svn/athrun/trunk/android/來下載工具源代碼。
iOS
工具
在介紹iOS自動化之前，首先要介紹下Xcode 所提供的 instruments工具。該工具是一款用來動態跟蹤和分析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自動化工具對比
結語
自動化的實現一定程度上提升了我們的測試效率，由于互聯網產品迭代速度較快，這里建議大家自動化從冒煙測試做起，用 例設計要盡可能簡潔，多做封裝，以便降低維護成本。同時實現自動化的持續集成，更早介入測試，更早發現問題。在此基礎之上，我們還可以通過自動化配合獲取 性能數據的腳本來實現對應用程序的性能測試。這些工作可以使得我們的測試覆蓋更廣，測試力度更深，更好的檢測和監控產品質量。
原文：http://techblog.youdao.com/?p=571