摘要 眾所周知，自動(dòng)化測(cè)試可以一定程度上減輕測(cè)試人員負(fù)擔(dān)，提高測(cè)試效率，并且通過(guò)自動(dòng)化還可以實(shí)現(xiàn)可靠性測(cè)試和性能測(cè)試。對(duì)于移動(dòng)客戶端測(cè)試而言，如果我們能夠讓手機(jī)自動(dòng)運(yùn)行應(yīng)用程序來(lái)幫助我們檢測(cè)功能的正確性，會(huì)不會(huì)很酷？有道測(cè)試組對(duì)一些熱門的手機(jī)自動(dòng)化工具進(jìn)行了調(diào)研，并選擇了一些工具進(jìn)行實(shí)際的使用。本文將會(huì)結(jié)合實(shí)際工作，對(duì)移動(dòng)客戶端（Android&iOS）GUI自動(dòng)化的工具調(diào)研和實(shí)現(xiàn)進(jìn)行介紹。
Android
工具
Android APIs提供的instrumentation類可以初始化Android應(yīng)用程序代碼，允許你監(jiān)控應(yīng)用程序的系統(tǒng)交互，配合KeyEvent、 MotionEvent類，發(fā)送用戶事件，進(jìn)而實(shí)現(xiàn)GUI 層的自動(dòng)化。測(cè)試程序需要繼承ActivityInstrumentationTestCase2來(lái)實(shí)現(xiàn)自動(dòng)化。
為了方便編寫自動(dòng)化測(cè) 試用例，我們需要對(duì)ActivityInstrumentationTestCase2進(jìn)行擴(kuò)展。業(yè)界也已經(jīng)有一些成熟的自動(dòng)化工具，諸如 Robotium、Athrun、NativeDriver、MonkeyRunner等。我們需要針對(duì)自身產(chǎn)品的需求，從中選取一款合適的工具來(lái)實(shí)現(xiàn)自 動(dòng)化。對(duì)于移動(dòng)客戶端GUI的自動(dòng)化而言，需要保證選取的工具有以下幾點(diǎn)特性：
1、工具開源，易于擴(kuò)展。
2、腳本編寫簡(jiǎn)潔，維護(hù)成本低。
3、滿足客戶端的自動(dòng)化需求。
4、便與校驗(yàn)結(jié)果的正確性。
5、可用于持續(xù)集成。
表1列出了這四款工具的區(qū)別：
表1 Android自動(dòng)化工具對(duì)比
MonkeyRunner通過(guò)編寫Python腳本來(lái)實(shí)現(xiàn)自動(dòng)化，結(jié)果的驗(yàn)證是通過(guò)截屏比對(duì)圖片來(lái)實(shí)現(xiàn)，驗(yàn)證方式不夠靈活，不建議采用。
NativeDriver 是WebDriver 接口的一種實(shí)現(xiàn)，使用移動(dòng)客戶端原生UI而不是瀏覽器UI（Selenium） 的自動(dòng)化測(cè)試工具。類似于selenium RC的方式來(lái)運(yùn)行測(cè)試程序，對(duì)于熟悉WebDriver的用戶，上手會(huì)很快。從表1可以看出該工具也可以滿足我們的自動(dòng)化需求，但在調(diào)研初期，該工具提供 的接口較少，沒(méi)法滿足測(cè)試需求，而今的完善程度也已經(jīng)很高了。沒(méi)有使用該工具可以認(rèn)為是歷史原因吧。
Robotium被大家所熟知，基于instrumentation實(shí)現(xiàn)，提供的接口可以滿足大部分自動(dòng)化需求。但不支持webview，而有道詞典的查詞結(jié)果展示恰好使用的是webview組件，該模塊就沒(méi)有辦法通過(guò)該工具來(lái)實(shí)現(xiàn)自動(dòng)化。
Athrun的實(shí)現(xiàn)和Robotium類似，提供的接口也很多，并且支持webview，也可實(shí)現(xiàn)持續(xù)集成。對(duì)于我們的產(chǎn)品而言，滿足自動(dòng)化的需求。由 于工具開源，在今后需求不滿足的時(shí)候我們也可以在該工具的基礎(chǔ)上做一些封裝。所以最終選擇了Athrun來(lái)實(shí)現(xiàn)筆記和詞典的GUI自動(dòng)化。
實(shí)例
和寫Android應(yīng)用類似，首先要建立一個(gè)Android Test Project ，指定被測(cè)試的Android Project。如果沒(méi)有應(yīng)用源代碼，也可以在測(cè)試程序的AndroidManifest.xml文件內(nèi)，修 改<instrumentation> 標(biāo)簽下targetPackage為我們要測(cè)試的應(yīng)用程序的package。之后導(dǎo)入framework.jar，就可以開始編寫自動(dòng)化腳本了。圖1是有 道云筆記Android端登錄模塊的自動(dòng)化用例：
圖1 Android 自動(dòng)化用例
我們需要繼承AthrunTestCase，指定package和想要開始的Activity 。每一個(gè)方法作為一個(gè)測(cè)試用例，最后以Android JUnit Test的方式運(yùn)行測(cè)試用例。這里需要注意的一點(diǎn)，要先在設(shè)備上安裝被測(cè)試的應(yīng)用。如果這個(gè)應(yīng)用是簽名過(guò)的，那么我們的測(cè)試應(yīng)用也需要用一樣的簽名。
從代碼可以看出，尋找組件的接口很簡(jiǎn)單，可以通過(guò)組件的id、value等屬性來(lái)尋找。如果組件沒(méi)有相對(duì)獨(dú)立的屬性，也可以通過(guò)該組件的父節(jié)點(diǎn) 一層層來(lái)尋找。Android SDK提供的hierarchyviewer工具將模擬器當(dāng)前Activity的 UI組件以樹狀形式展現(xiàn)，可以清晰的看到每個(gè)組件的詳細(xì)屬性。
驗(yàn)證一條測(cè)試用例是否通過(guò)的方式也有很多種，可以驗(yàn)證Activity的跳轉(zhuǎn)、組件的展示，當(dāng)然還有一些可能就需要通過(guò)截屏。圖1是通過(guò)驗(yàn)證執(zhí)行用例后Activity的跳轉(zhuǎn)來(lái)判斷測(cè)試用例是否通過(guò)。
以上我們就完成了一條測(cè)試用例的自動(dòng)化。顯然基于Athrun的框架，使得我們的自動(dòng)化用例編寫方便了很多，成本也大大降低了。
為了完成各種自動(dòng)化測(cè)試用例，我們有必要對(duì)Athrun有更詳細(xì)的了解，以便二次開發(fā)所需接口。感興趣的朋友可以通過(guò)http://code.taobao.org/svn/athrun/trunk/android/來(lái)下載工具源代碼。
iOS
工具
在介紹iOS自動(dòng)化之前，首先要介紹下Xcode 所提供的 instruments工具。該工具是一款用來(lái)動(dòng)態(tài)跟蹤和分析OS X和iOS代碼的實(shí)用工具。這是一個(gè)靈活而強(qiáng)大的工具，它讓你可以跟蹤一個(gè)或多個(gè)進(jìn)程，并檢查收集的數(shù)據(jù)。這樣，Instruments可以幫你更好的理 解應(yīng)用程序和操作系統(tǒng)的行為。
instruments除了提供自動(dòng)化工具automation外，還有諸如leaks、allocations等用來(lái)檢測(cè)和分析程序性能的工 具。對(duì)于iOS測(cè)試和開發(fā)而言，追蹤和定位缺陷，instruments是非常實(shí)用的。圖2是instruments的主界面：
圖2 instruments 主界面
關(guān)于instruments所提供的各種工具的使用，感興趣的朋友可以在iOS Developer Library中了解。
接下來(lái)就要介紹一下UI Automation，它可以用在真實(shí)設(shè)備或模擬器來(lái)執(zhí)行自動(dòng)化測(cè)試。
使用JavaScript編寫測(cè)試用例，調(diào)用UI Automation的接口模擬用戶交互操作。該工具會(huì)將自動(dòng)化運(yùn)行的日志信息返回到instruments 信息欄。
實(shí)例
在Xcode通過(guò) profile的方式來(lái)啟動(dòng)instruments。或者直接雙擊啟動(dòng)instruments，在instruments主界面中選擇設(shè)備上被測(cè)試的應(yīng)用 程序。然后在Automation Script欄編寫自動(dòng)化腳本。使用iOS設(shè)備需要注意的一點(diǎn)是確保Developer profile設(shè)置是Release模式。圖3是有道云筆記iPhone版登錄模塊的自動(dòng)化用例：
圖3 iOS 自動(dòng)化用例
完成自動(dòng)化腳本后，可以通過(guò)點(diǎn)擊Instruments 的Record按鈕來(lái)運(yùn)行，也可以通過(guò)instruments相關(guān)命令來(lái)運(yùn)行。前者適合于調(diào)試，后者適合于持續(xù)集成。
從圖3可以看出，對(duì)應(yīng)的UI 組件需要逐層指定。定位這些組件有兩種方式。對(duì)于iOS 5以上的系統(tǒng)可以通過(guò)錄制生成腳本，但錄制的方式可能會(huì)記錄錯(cuò)誤。所以為了定位準(zhǔn)確的組件位置，就需要調(diào)用logElementTree ，將當(dāng)前屏幕組件的層次樹狀結(jié)構(gòu)打印到日志中，通過(guò)日志定位組件。
從上圖也可以看出UI Automation 所提供的驗(yàn)證機(jī)制有些繁瑣，驗(yàn)證每一個(gè)組件是否存在都需要去做判斷。這僅僅是冰山一角，UI Automation會(huì)對(duì)捕獲到彈出窗口（alert）點(diǎn)擊默認(rèn)操作按鈕，提供的日志文件也不便于分析，所以我們有必要對(duì)UI Automation的接口進(jìn)行二次封裝，更方便去編寫自動(dòng)化用例。
Athrun也提供了iOS的自動(dòng)化框架，有三種實(shí)現(xiàn)方式。第一種AppFramWork是代碼注入型，需要在源碼中插入測(cè)試代 碼，Objective-C編寫測(cè)試用例，自動(dòng)化成本較高，不建議使用。第二種instrument Athrun就是對(duì)UI Automation的接口進(jìn)行擴(kuò)展，提高了原有接口運(yùn)行的穩(wěn)定性。第三種instrumentDriver基于instrument JS框架來(lái)開發(fā)InstrumentDriver服務(wù)端，在java上實(shí)現(xiàn)客戶端，使用java腳本控制iOS自動(dòng)化執(zhí)行。該框架還實(shí)現(xiàn)了單步運(yùn)行，調(diào)試 等UI Automation沒(méi)有的功能。圖4為instrumentDriver的架構(gòu)圖：
圖4 instrumentDriver 架構(gòu)圖
從instrumentDriver的介紹可以看出，相比蘋果所提供的UI Automation是有不少優(yōu)點(diǎn)的。目前由于我們需要通過(guò)自動(dòng)化腳本配合instruments 其他性能檢測(cè)工具來(lái)實(shí)現(xiàn)對(duì)應(yīng)用程序的性能測(cè)試，所以依舊采用instruments 原生工具配合擴(kuò)展的JS腳本的方式。后續(xù)如果可以找到更好的獲取性能數(shù)據(jù)的辦法，會(huì)逐漸轉(zhuǎn)向instrumentDriver的方式來(lái)實(shí)現(xiàn)iOS的自動(dòng) 化。
對(duì)比
從表2可以簡(jiǎn)單看一下目前我們選擇的iOS和Android自動(dòng)化工具的區(qū)別：
表2 iOS和Android自動(dòng)化工具對(duì)比
結(jié)語(yǔ)
自動(dòng)化的實(shí)現(xiàn)一定程度上提升了我們的測(cè)試效率，由于互聯(lián)網(wǎng)產(chǎn)品迭代速度較快，這里建議大家自動(dòng)化從冒煙測(cè)試做起，用 例設(shè)計(jì)要盡可能簡(jiǎn)潔，多做封裝，以便降低維護(hù)成本。同時(shí)實(shí)現(xiàn)自動(dòng)化的持續(xù)集成，更早介入測(cè)試，更早發(fā)現(xiàn)問(wèn)題。在此基礎(chǔ)之上，我們還可以通過(guò)自動(dòng)化配合獲取 性能數(shù)據(jù)的腳本來(lái)實(shí)現(xiàn)對(duì)應(yīng)用程序的性能測(cè)試。這些工作可以使得我們的測(cè)試覆蓋更廣，測(cè)試力度更深，更好的檢測(cè)和監(jiān)控產(chǎn)品質(zhì)量。
原文：http://techblog.youdao.com/?p=571