移動(dòng)APP的UI自動(dòng)化測(cè)試長(zhǎng)久以來(lái)一直是一個(gè)難點(diǎn),難點(diǎn)在于UI的”變”, 變化導(dǎo)致自動(dòng)化用例的大量維護(hù)。從分層測(cè)試的角度,自動(dòng)化測(cè)試應(yīng)該逐層進(jìn)行。最大量實(shí)現(xiàn)自動(dòng)化測(cè)試的應(yīng)該是單元測(cè)試,最容易實(shí)現(xiàn)也最容易在早期發(fā)現(xiàn)問(wèn)題;其次是接口級(jí)測(cè)試,以驗(yàn)證邏輯為目的進(jìn)行自動(dòng)化,由于接口的相對(duì)穩(wěn)定,自動(dòng)化測(cè)試成本相對(duì)也可以接受;自動(dòng)化成本最大的便是UI級(jí)自動(dòng)化測(cè)試,然而UI界面是直接反饋給用戶的效果展示,適度的尤其是BVT級(jí)的自動(dòng)化測(cè)試也是非常必要的。本文通過(guò)分析幾種自動(dòng)化框架的異同,使測(cè)試人員在選擇自動(dòng)化框架時(shí)有所參考。
https://developer./reference/android/app/Instrumentation.htmlInstrumentaion 是Android自帶的一個(gè)測(cè)試框架,是很多其它測(cè)試框架的基礎(chǔ),可以在同進(jìn)程中加載被測(cè)組件。它有很多豐富的高層封裝,使用者可以使用基于instrumentation的其他框架,避免過(guò)多二次開(kāi)發(fā)量。但I(xiàn)nstrumentation不支持跨應(yīng)用,導(dǎo)致基于instrumentation的框架都繼承了這個(gè)缺點(diǎn)。 https://github.com/robotiumtech/robotium Robotium是基于Instrumentation框架開(kāi)發(fā)的一個(gè)更強(qiáng)的框架. 對(duì)常用的操作進(jìn)行了易用性的封裝. 用于開(kāi)發(fā)功能性、系統(tǒng)和驗(yàn)收測(cè)試場(chǎng)景。它運(yùn)行時(shí)綁定到GUI組件。它安裝了一個(gè)測(cè)試用例套件作為在Android設(shè)備或仿真器上的應(yīng)用程序,并提供用于執(zhí)行測(cè)試的真實(shí)環(huán)境。 優(yōu)點(diǎn): 容易在最短的時(shí)間內(nèi)編寫測(cè)試腳本,易用性高。自動(dòng)跟隨當(dāng)前activity。 由于運(yùn)行時(shí)綁定到GUI組件,所以相比Appium,它的測(cè)試執(zhí)行更快,更強(qiáng)大。 不訪問(wèn)代碼或不了解app實(shí)現(xiàn),也可以工作。 支持Activities、Dialogs、Toasts、Menus、Context Menus和其他Android SDK控件。 缺點(diǎn): 不能處理flash和web組件。在舊設(shè)備上會(huì)變得很慢。 由于不支持iOS設(shè)備,當(dāng)自動(dòng)化測(cè)試同時(shí)覆蓋 android與iOS的情況時(shí),測(cè)試會(huì)被中斷。沒(méi)有內(nèi)置的記錄和回放功能.,使用記錄功能需要 TestDroid 和 Robotium Recorder 這樣的收費(fèi)工具。 https://google./android-testing-support-library/docs/uiautomator/ UIAutomator是由谷歌提供的測(cè)試框架,它提供了原生Android app和游戲的高級(jí)UI測(cè)試。這是一個(gè)包含API的Java庫(kù),用來(lái)創(chuàng)建功能性UI測(cè)試,還有運(yùn)行測(cè)試的執(zhí)行引擎。該庫(kù)自帶Android SDK。 優(yōu)點(diǎn):它在運(yùn)行訪問(wèn)不同的進(jìn)程時(shí),會(huì)給JUnit測(cè)試案例特權(quán)。庫(kù)由谷歌社區(qū)支持和維護(hù)。 缺點(diǎn):僅支持android4.1(API level 16)及以上。 不支持腳本記錄。 支持的重點(diǎn)是Java。 你不能獲得當(dāng)前活動(dòng)或儀表化。目前不支持web視圖。 庫(kù)僅支持使用Java,因此很難和使用Ruby的cucumber混合。如想支持BDD框架,建議使用Java自己的BDD框架,例如Jbehave。 https://google./android-testing-support-library/docs/espresso/index.html Espresso是Google的開(kāi)源自動(dòng)化測(cè)試框架。相對(duì)于Robotium和UIAutomator,它的特點(diǎn)是規(guī)模更小、更簡(jiǎn)潔、API更加精確、編寫測(cè)試代碼簡(jiǎn)單、容易快速上手。因?yàn)槭腔贗nstrumentation的,所以不能跨App。 Calabash是一個(gè)適用于iOS和Android開(kāi)發(fā)者的跨平臺(tái)app測(cè)試框架,可用來(lái)測(cè)試屏幕截圖、手勢(shì)和實(shí)際功能代碼。Calabash開(kāi)源免費(fèi)并支持Cucumber語(yǔ)言,Cucumber能讓你用自然的英語(yǔ)語(yǔ)言表述app的行為,實(shí)現(xiàn)BDD(Behavior Driven Development,行為驅(qū)動(dòng)開(kāi)發(fā))。 Cucumber中的所有語(yǔ)句使用Ruby定義。 優(yōu)點(diǎn): 有大型社區(qū)支持。列表項(xiàng) 簡(jiǎn)單,類似英語(yǔ)表述的測(cè)試語(yǔ)句支持在屏幕上的所有動(dòng)作,如滑動(dòng),縮放,旋轉(zhuǎn),敲擊等。 跨平臺(tái)開(kāi)發(fā)支持(同樣的代碼在Android和iOS設(shè)備中都適用)。 缺點(diǎn):測(cè)試步驟失敗后,將跳過(guò)所有的后續(xù)步驟,這可能會(huì)導(dǎo)致錯(cuò)過(guò)更嚴(yán)重的產(chǎn)品問(wèn)題。測(cè)試耗費(fèi)時(shí)間,因?yàn)樗偸悄J(rèn)先安裝app。 需要Calabash框架安裝在ios的ipa文件中, 因此測(cè)試人員必須要有iOS的app源碼。 除了Ruby,對(duì)其他語(yǔ)言不友好。 Appium是一個(gè)開(kāi)源的、跨平臺(tái)的自動(dòng)化測(cè)試工具,支持IOS、Android和FirefoxOS平臺(tái)。 通過(guò)Appium,開(kāi)發(fā)者無(wú)需重新編譯app或者做任何調(diào)整,就可以測(cè)試移動(dòng)應(yīng)用,可以使測(cè)試代碼訪問(wèn)后端API和數(shù)據(jù)庫(kù)。它是通過(guò)驅(qū)動(dòng)蘋果的UIAutomation和Android的UiAutomator框架來(lái)實(shí)現(xiàn)的雙平臺(tái)支持,同時(shí)綁定了Selenium WebDriver用于老的Android平臺(tái)測(cè)試。開(kāi)發(fā)者可以使用WebDriver兼容的任何語(yǔ)言編寫測(cè)試腳本,如Java, OC, JS, PHP,Python, Ruby, C#,Clojure 和Perl語(yǔ)言。 https://www./book/lihuazhang/selendroid/details Selendroid 是一個(gè)基于Instrumentation的一個(gè)框架. 完全兼容Webdriver協(xié)議。 Selendroid 可以在模擬器和實(shí)際設(shè)備上使用,也可以集成網(wǎng)格節(jié)點(diǎn)作為縮放和并行測(cè)試。 Robolectric 是一款A(yù)ndroid單元測(cè)試框架,但它并不依賴于Android提供的測(cè)試功能,它通過(guò)實(shí)現(xiàn)一套JVM能運(yùn)行的Android代碼,然后在unit test運(yùn)行的時(shí)候去截取android相關(guān)的代碼調(diào)用,然后轉(zhuǎn)到Robolectric實(shí)現(xiàn)的代碼(shadow objects)去執(zhí)行這個(gè)調(diào)用的過(guò)程。因此它不像模擬器或設(shè)備需要dexing(Android dex編譯器將類文件編譯成Android設(shè)備上的Dalvik VM使用的格式)、打包、部署和運(yùn)行的過(guò)程,大大減少了測(cè)試執(zhí)行的時(shí)間。Pivotal實(shí)驗(yàn)室聲稱使用Robolectric可以在28秒內(nèi)運(yùn)行1047個(gè)測(cè)試。 除了實(shí)現(xiàn)Android里面的類的現(xiàn)有接口,Robolectric還給每個(gè)Shadow類額外增加了很多接口,可以讀取對(duì)應(yīng)的Android類的一些狀態(tài)。比如它為ImageView提供了getImageResourceId()方法,測(cè)試者可以通過(guò)getImageResourceId()接口來(lái)確定是不是正確顯示了期望的Image。 RoboSpock是一個(gè)開(kāi)源的Android測(cè)試框架,它提供了簡(jiǎn)單的編寫B(tài)DD行為驅(qū)動(dòng)開(kāi)發(fā)規(guī)范的方法,使用Groovy語(yǔ)言,支持Google Guice庫(kù)。RoboSpock合并了Robolectic和Spock的功能。 Cafe是百度出品的一個(gè)基于Robotium的測(cè)試框架,它提供了跨進(jìn)程的測(cè)試解決方案。 http://code./p/athrun/wiki/index/ Athrun 是taobao出的一個(gè)移動(dòng)測(cè)試框架,它支持Android和IOS。Android部分是基于Instrumentation,在Android原有的ActivityInstrumentationTestCase2類基礎(chǔ)上進(jìn)行了擴(kuò)展,提供了一整套面向?qū)ο蟮腁PI。 IOS上的自動(dòng)化測(cè)試包括注入式自動(dòng)化框架AppFramework,和基于錄制的自動(dòng)化框架Athrun_IOS, InstrumentDriver。 其他自動(dòng)化框架還有應(yīng)用于穩(wěn)定性測(cè)試的Monkey系列(Monkey, Monkeyrunner, MonkeyTalk), 其中MonkeyTalk 支持iOS 和 Android,它可以為應(yīng)用進(jìn)行真實(shí)的,功能性交互測(cè)試。MonkeyTalk 提供簡(jiǎn)單的 'smoke tests',復(fù)雜數(shù)據(jù)驅(qū)動(dòng)的測(cè)試套件。MonkeyTalk 支持原生,移動(dòng)和混合應(yīng)用,真實(shí)設(shè)備或者模擬器。MonkeyTalk 使得場(chǎng)景捕獲非常容易,可以記錄高級(jí)別,可讀的測(cè)試腳本。還有適用于瀏覽器自動(dòng)測(cè)試的Selenium WebDriver,可以真實(shí)測(cè)試用戶行為,用戶交互如觸摸、手指滾動(dòng)、長(zhǎng)按等,還支持HTML5的一些特性,比如本地存儲(chǔ)、session存儲(chǔ)、應(yīng)用緩存等。而CTS則是應(yīng)用于兼容性測(cè)試的自動(dòng)化工具, CTS大部分是基于Junit和儀表盤技術(shù)編寫的。還擴(kuò)展了自動(dòng)化測(cè)試過(guò)程,可以自動(dòng)執(zhí)行用例,自動(dòng)收集和匯總測(cè)試結(jié)果。CTS采用XML配置文件的方式將這些測(cè)試用例分組成多個(gè)測(cè)試計(jì)劃(plan),第三方也可以創(chuàng)建自己的plan。 總結(jié)(Android)各個(gè)測(cè)試框架的繼承關(guān)系如下,繼承關(guān)系決定了有些框架的先天優(yōu)勢(shì)或先天不足. 在實(shí)際應(yīng)用中可以集成多個(gè)框架。
XCTest是蘋果在iOS 7和Xcode5引入的一個(gè)簡(jiǎn)單而強(qiáng)大的測(cè)試框架,它的測(cè)試編寫起來(lái)非常簡(jiǎn)單,并且遵循xUnit風(fēng)格。XCTest的優(yōu)點(diǎn)是與Xcode深度集成,有專門的Test導(dǎo)航欄,但因?yàn)槭芟抻诠俜綔y(cè)試API,因此功能不是很豐富。 UIAutomation是蘋果提供的UI自動(dòng)化測(cè)試框架,使用Javascript編寫。基于UIAutomation有擴(kuò)展型的工具框架和驅(qū)動(dòng)型的框架。擴(kuò)展型框架以JavaScript擴(kuò)展庫(kù)方法提供了很多好用js工具,注入式的框架通常會(huì)提供一些Lib或者是Framework,要求測(cè)試人員在待測(cè)應(yīng)用的代碼工程中導(dǎo)入這些內(nèi)容,框架可以通過(guò)他們完成對(duì)app的驅(qū)動(dòng)。驅(qū)動(dòng)型UI Automation 在自動(dòng)化測(cè)試底層使用了UI Automation庫(kù),通過(guò)TCP通信的方式驅(qū)動(dòng)UI Automation來(lái)完成自動(dòng)化測(cè)試,通過(guò)這種方式,編輯腳本的語(yǔ)言不再局限于JavaScript。 Frank是iOS平臺(tái)一款非常受歡迎的app測(cè)試框架,它使用Cucumber語(yǔ)言來(lái)編寫測(cè)試用例, Frank包含一個(gè)強(qiáng)大的“app inspector”--Symbiote,可以用它來(lái)獲得運(yùn)行中app的詳細(xì)信息,便于開(kāi)發(fā)者將來(lái)進(jìn)行測(cè)試回顧。 它允許使用Cucumber編寫結(jié)構(gòu)化英語(yǔ)句子的測(cè)試場(chǎng)景。 Frank要求測(cè)試時(shí)在應(yīng)用程序內(nèi)部編譯,這意味著對(duì)源代碼的改變是強(qiáng)制性的。操作方式為使用Cucumber和JSON組合命令,將命令發(fā)送到在本地應(yīng)用程序內(nèi)部運(yùn)行的服務(wù)器上,并利用UISpec運(yùn)行命令。 優(yōu)點(diǎn): 測(cè)試場(chǎng)景是在Cucumber的幫助下,用可理解的英語(yǔ)句子寫的。強(qiáng)大的Symbiote實(shí)時(shí)檢查工具。 活躍的社區(qū)支持。 不斷擴(kuò)大中的庫(kù)。 缺點(diǎn):對(duì)手勢(shì)的支持有限。 在設(shè)備上運(yùn)行測(cè)試有點(diǎn)難。 修改配置文件需要在實(shí)際設(shè)備上運(yùn)行。 記錄功能不可用。 http://www.oschina.net/translate/ios-ui-testing-with-kif KIF是Keep It Functional項(xiàng)目的縮寫,是一款iOS app功能性測(cè)試框架,使用Objective-C語(yǔ)言編寫,對(duì)蘋果開(kāi)發(fā)者來(lái)說(shuō)非常容易上手,更是一款開(kāi)發(fā)者廣為推薦的測(cè)試工具。KIF tester使用私有API來(lái)了解App中的視圖層級(jí)。但缺點(diǎn)是運(yùn)行較慢。 詳見(jiàn)Calabash-android 描述。 Subliminal是另一款與XCTest集成的框架。與KIF不同的是,它基于UIAutomation編寫,旨在對(duì)開(kāi)發(fā)者隱藏UIAutomation中一些復(fù)雜的細(xì)節(jié)。 https://github.com/kiwi-bdd/Kiwi/wiki/Getting-Started-with-Kiwi-2.0 Kiwi是對(duì)XCTest的一個(gè)完整替代,使用xSpec風(fēng)格編寫測(cè)試。 Kiwi帶有自己的一套工具集,包括expectations、mocks、stubs,甚至還支持異步測(cè)試。它是一個(gè)適用于iOS 開(kāi)發(fā)的Behavior Driven Development(BDD)庫(kù),優(yōu)點(diǎn)在于其簡(jiǎn)潔的接口和可用性,易于設(shè)置和使用,非常適合新手開(kāi)發(fā)者。Kiwi使用Objective-C語(yǔ)言編寫,易于IOS開(kāi)發(fā)人員上手。 IOS自動(dòng)化測(cè)試框架繼承關(guān)系如下. XCTest與 Xcode 的 IDE 直接集成,使用簡(jiǎn)單, 但其不支持stub和mock, 所以單使用XCTest框架的較少. Kiwi是一個(gè)iOS平臺(tái)十分好用的行為驅(qū)動(dòng)開(kāi)發(fā)BDD的測(cè)試框架,有著非常漂亮的語(yǔ)法,可以寫出結(jié)構(gòu)性強(qiáng),非常容易讀懂的測(cè)試。UI Automation是Apple官方提供的UI自動(dòng)化測(cè)試的解決方法,但接口不夠豐富。
Sikuli 是由 MIT 的研究團(tuán)隊(duì)發(fā)布的新型圖形化編程技術(shù)。它以圖像檢索技術(shù)為基礎(chǔ),提供了一套基于Python 的腳本語(yǔ)言以及集成開(kāi)發(fā)環(huán)境。使用者可利用屏幕截圖直接引用 GUI 元素進(jìn)行編程,完成交互操作。Sikuli的腳本編寫遵循 Python語(yǔ)法規(guī)范。由于 Sikuli基于 Python,其核心代碼由 Java 編寫,可在用戶自定義的 Java 工程中將其作為 Java 標(biāo)準(zhǔn)類庫(kù)進(jìn)行引用。 它的腳本是這樣式的: Sikuli將 GUI 對(duì)象的屏幕截圖作為函數(shù)的參數(shù)直接引用,整個(gè)代碼的語(yǔ)義清晰明了,可讀性極強(qiáng)。腳本執(zhí)行過(guò)程中,利用圖像檢索算法分析匹配當(dāng)前屏幕中對(duì)應(yīng)的控件,并對(duì)其應(yīng)用相應(yīng)的鼠標(biāo)或鍵盤操作。這種方式使得我們?cè)谀_本編寫時(shí),既無(wú)需關(guān)心繁瑣的應(yīng)用程序相關(guān) API 亦不用獲取 Web 內(nèi)容對(duì)象。 缺點(diǎn): 1、僅支持windows, MACOSX,和Linux平臺(tái),還不支持移動(dòng)平臺(tái)。 2、依賴屏幕截圖,使得1)在不同平臺(tái),不同分辨率,不同操作系統(tǒng)上需要維護(hù)一套圖形源文件,不利于跨平臺(tái)移植;2)若出現(xiàn)程序邏輯外的界面遮擋,則影響程序執(zhí)行。 但作為現(xiàn)有自動(dòng)化測(cè)試工具的補(bǔ)充,尤其是對(duì)無(wú)法獲取API的工程,比如flash 動(dòng)畫, 是非常有效的。 https://www./articles/utest-launches-appgrader-for-android 雖然AppGrader不是一流的測(cè)試框架,但也有所長(zhǎng)。它可以幫開(kāi)發(fā)者將自己的應(yīng)用與其他眾多同類型應(yīng)用進(jìn)行多方面比較,比如圖形和功能。通過(guò)對(duì)比結(jié)果,開(kāi)發(fā)者可以更有針對(duì)性地提高和改進(jìn)自己的應(yīng)用。目前AppGrader僅支持Android平臺(tái)。 FlipTest是一個(gè)優(yōu)秀的iOS app A/B測(cè)試框架,可為app挑選最佳的UI。FlipTest會(huì)基于外觀和易用性等眾多因素返回測(cè)試結(jié)果,進(jìn)而幫開(kāi)發(fā)者解決UI問(wèn)題。用FlipTest進(jìn)行測(cè)試無(wú)需向App Store重新提交應(yīng)用或者大幅更改代碼,只需要在app中添加一行代碼,節(jié)省了不少時(shí)間。 你工作中采用的框架是哪個(gè)?為什么選用它? |
|
來(lái)自: 小胖魚(yú)與小松鼠 > 《待分類》