NO IMAGE

簡介

 移動APP的UI自動化測試長久以來一直是一個難點,難點在於UI的”變”, 變化導致自動化用例的大量維護。從分層測試的角度,自動化測試應該逐層進行。最大量實現自動化測試的應該是單元測試,最容易實現也最容易在早期發現問題;其次是介面級測試,以驗證邏輯為目的進行自動化,由於介面的相對穩定,自動化測試成本相對也可以接受;自動化成本最大的便是UI級自動化測試,然而UI介面是直接反饋給使用者的效果展示,適度的尤其是BVT級的自動化測試也是非常必要的。本文通過分析幾種自動化框架的異同,使測試人員在選擇自動化框架時有所參考。

Android自動化框架

1. Instrumentation 

https://developer.android.com/reference/android/app/Instrumentation.html

Instrumentaion 是Android自帶的一個測試框架,是很多其它測試框架的基礎,可以在同程序中載入被測元件。它有很多豐富的高層封裝,使用者可以使用基於instrumentation的其他框架,避免過多二次開發量。但Instrumentation不支援跨應用,導致基於instrumentation的框架都繼承了這個缺點。

2. Robotium 

https://github.com/robotiumtech/robotium

Robotium是基於Instrumentation框架開發的一個更強的框架. 對常用的操作進行了易用性的封裝. 用於開發功能性、系統和驗收測試場景。它執行時繫結到GUI元件。它安裝了一個測試用例套件作為在Android裝置或模擬器上的應用程式,並提供用於執行測試的真實環境。

優點: 容易在最短的時間內編寫測試指令碼,易用性高。自動跟隨當前activity。 由於執行時繫結到GUI元件,所以相比Appium,它的測試執行更快,更強大。 不訪問程式碼或不瞭解app實現,也可以工作。 支援Activities、Dialogs、Toasts、Menus、Context Menus和其他Android SDK控制元件。

缺點: 不能處理flash和web元件。在舊裝置上會變得很慢。 由於不支援iOS裝置,當自動化測試同時覆蓋 android與iOS的情況時,測試會被中斷。沒有內建的記錄和回放功能.,使用記錄功能需要 TestDroid 和 Robotium Recorder 這樣的收費工具。

3. UIAutomator

https://google.github.io/android-testing-support-library/docs/uiautomator/

UIAutomator是由谷歌提供的測試框架,它提供了原生Android app和遊戲的高階UI測試。這是一個包含API的Java庫,用來建立功能性UI測試,還有執行測試的執行引擎。該庫自帶Android SDK。

優點:它在執行訪問不同的程序時,會給JUnit測試案例特權。庫由谷歌社群支援和維護。

缺點:僅支援android4.1(API level 16)及以上。 不支援指令碼記錄。 支援的重點是Java。 你不能獲得當前活動或儀表化。目前不支援web檢視。 庫僅支援使用Java,因此很難和使用Ruby的cucumber混合。如想支援BDD框架,建議使用Java自己的BDD框架,例如Jbehave。

4. Espresso

https://google.github.io/android-testing-support-library/docs/espresso/index.html

Espresso是Google的開源自動化測試框架。相對於Robotium和UIAutomator,它的特點是規模更小、更簡潔、API更加精確、編寫測試程式碼簡單、容易快速上手。因為是基於Instrumentation的,所以不能跨App。

5. Calabash

https://github.com/calabash

Calabash是一個適用於iOS和Android開發者的跨平臺app測試框架,可用來測試螢幕截圖、手勢和實際功能程式碼。Calabash開源免費並支援Cucumber語言,Cucumber能讓你用自然的英語語言表述app的行為,實現BDD(Behavior Driven Development,行為驅動開發)。 Cucumber中的所有語句使用Ruby定義。

優點: 有大型社群支援。列表項 簡單,類似英語表述的測試語句支援在螢幕上的所有動作,如滑動,縮放,旋轉,敲擊等。 跨平臺開發支援(同樣的程式碼在Android和iOS裝置中都適用)。

缺點:測試步驟失敗後,將跳過所有的後續步驟,這可能會導致錯過更嚴重的產品問題。測試耗費時間,因為它總是預設先安裝app。 需要Calabash框架安裝在ios的ipa檔案中, 因此測試人員必須要有iOS的app原始碼。 除了Ruby,對其他語言不友好。

6. Appium

http://appium.io/

Appium是一個開源的、跨平臺的自動化測試工具,支援IOS、Android和FirefoxOS平臺。 通過Appium,開發者無需重新編譯app或者做任何調整,就可以測試移動應用,可以使測試程式碼訪問後端API和資料庫。它是通過驅動蘋果的UIAutomation和Android的UiAutomator框架來實現的雙平臺支援,同時繫結了Selenium WebDriver用於老的Android平臺測試。開發者可以使用WebDriver相容的任何語言編寫測試指令碼,如Java, OC, JS, PHP,Python,
Ruby, C#,Clojure 和Perl語言。

7. Selendroid

https://www.gitbook.com/book/lihuazhang/selendroid/details

Selendroid 是一個基於Instrumentation的一個框架. 完全相容Webdriver協議。 Selendroid 可以在模擬器和實際裝置上使用,也可以整合網格節點作為縮放和並行測試。

8. Robolectric

http://robolectric.org/

Robolectric 是一款Android單元測試框架,但它並不依賴於Android提供的測試功能,它通過實現一套JVM能執行的Android程式碼,然後在unit test執行的時候去擷取android相關的程式碼呼叫,然後轉到Robolectric實現的程式碼(shadow objects)去執行這個呼叫的過程。因此它不像模擬器或裝置需要dexing(Android dex編譯器將類檔案編譯成Android裝置上的Dalvik VM使用的格式)、打包、部署和執行的過程,大大減少了測試執行的時間。Pivotal實驗室聲稱使用Robolectric可以在28秒內執行1047個測試

除了實現Android裡面的類的現有介面,Robolectric還給每個Shadow類額外增加了很多介面,可以讀取對應的Android類的一些狀態。比如它為ImageView提供了getImageResourceId()方法,測試者可以通過getImageResourceId()介面來確定是不是正確顯示了期望的Image。

9. RoboSpock

http://robospock.org/

RoboSpock是一個開源的Android測試框架,它提供了簡單的編寫BDD行為驅動開發規範的方法,使用Groovy語言,支援Google Guice庫。RoboSpock合併了Robolectic和Spock的功能。

10. Cafe

http://cafe.baidu.com/#panel1

Cafe是百度出品的一個基於Robotium的測試框架,它提供了跨程序的測試解決方案。

11. Athrun

http://code.taobao.org/p/athrun/wiki/index/

Athrun 是taobao出的一個移動測試框架,它支援Android和IOS。Android部分是基於Instrumentation,在Android原有的ActivityInstrumentationTestCase2類基礎上進行了擴充套件,提供了一整套物件導向的API。 IOS上的自動化測試包括注入式自動化框架AppFramework,和基於錄製的自動化框架Athrun_IOS, InstrumentDriver。

12. 其他

其他自動化框架還有應用於穩定性測試的Monkey系列(Monkey, Monkeyrunner, MonkeyTalk), 其中MonkeyTalk 支援iOS 和 Android,它可以為應用進行真實的,功能性互動測試。MonkeyTalk 提供簡單的 “smoke tests”,複雜資料驅動的測試套件。MonkeyTalk 支援原生,移動和混合應用,真實裝置或者模擬器。MonkeyTalk 使得場景捕獲非常容易,可以記錄高階別,可讀的測試指令碼。還有適用於瀏覽器自動測試的Selenium WebDriver,可以真實測試使用者行為,使用者互動如觸控、手指滾動、長按等,還支援HTML5的一些特性,比如本地儲存、session儲存、應用快取等。而CTS則是應用於相容性測試的自動化工具,
CTS大部分是基於Junit和儀表盤技術編寫的。還擴充套件了自動化測試過程,可以自動執行用例,自動收集和彙總測試結果。CTS採用XML配置檔案的方式將這些測試用例分組成多個測試計劃(plan),第三方也可以建立自己的plan。

總結(Android)

各個測試框架的繼承關係如下,繼承關係決定了有些框架的先天優勢或先天不足. 在實際應用中可以整合多個框架。

  • 基於Instrumentation的測試框架,比如Espresso,Robotium,Selendroid等,都不能支援跨APP使用。 如自動化測試中有跨APP操作,可以結合UiAutomator實現。
  • 支援BDD的自動化框架比較少,可以在calabash 和 RoboSpock及Jbehave之間選擇。
  • 若想同時支援Android和IOS,可選框架有Appium和Calabash,或AthRun。
  • 若為單元測試選擇框架,可選Instrumentation或Robolectric。Robolectric實現了shadow object 類,耗時短。

IOS自動化框架

1. XCTest

https://developer.apple.com/library/mac/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/01-introduction.html

XCTest是蘋果在iOS 7和Xcode5引入的一個簡單而強大的測試框架,它的測試編寫起來非常簡單,並且遵循xUnit風格。XCTest的優點是與Xcode深度整合,有專門的Test導航欄,但因為受限於官方測試API,因此功能不是很豐富。

2. UIAutomation

https://developer.apple.com/library/ios/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/UIAutomation.html

UIAutomation是蘋果提供的UI自動化測試框架,使用Javascript編寫。基於UIAutomation有擴充套件型的工具框架和驅動型的框架。擴充套件型框架以JavaScript擴充套件庫方法提供了很多好用js工具,注入式的框架通常會提供一些Lib或者是Framework,要求測試人員在待測應用的程式碼工程中匯入這些內容,框架可以通過他們完成對app的驅動。驅動型UI Automation 在自動化測試底層使用了UI Automation庫,通過TCP通訊的方式驅動UI Automation來完成自動化測試,通過這種方式,編輯指令碼的語言不再侷限於JavaScript。

3. Frank

http://www.testingwithfrank.com/

Frank是iOS平臺一款非常受歡迎的app測試框架,它使用Cucumber語言來編寫測試用例, Frank包含一個強大的“app inspector”–Symbiote,可以用它來獲得執行中app的詳細資訊,便於開發者將來進行測試回顧。 它允許使用Cucumber編寫結構化英語句子的測試場景。 Frank要求測試時在應用程式內部編譯,這意味著對原始碼的改變是強制性的。操作方式為使用Cucumber和JSON組合命令,將命令傳送到在本地應用程式內部執行的伺服器上,並利用UISpec執行命令。

優點: 測試場景是在Cucumber的幫助下,用可理解的英語句子寫的。強大的Symbiote實時檢查工具。 活躍的社群支援。 不斷擴大中的庫。

缺點:對手勢的支援有限。 在裝置上執行測試有點難。 修改配置檔案需要在實際裝置上執行。 記錄功能不可用。

4. KIF

http://www.oschina.net/translate/ios-ui-testing-with-kif

KIF是Keep It Functional專案的縮寫,是一款iOS app功能性測試框架,使用Objective-C語言編寫,對蘋果開發者來說非常容易上手,更是一款開發者廣為推薦的測試工具。KIF tester使用私有API來了解App中的檢視層級。但缺點是執行較慢。

5. Calabash-ios

詳見Calabash-android 描述。

6. Subliminal

http://inkling.github.io/Subliminal/

Subliminal是另一款與XCTest整合的框架。與KIF不同的是,它基於UIAutomation編寫,旨在對開發者隱藏UIAutomation中一些複雜的細節。

7. Kiwi

https://github.com/kiwi-bdd/Kiwi/wiki/Getting-Started-with-Kiwi-2.0

Kiwi是對XCTest的一個完整替代,使用xSpec風格編寫測試。 Kiwi帶有自己的一套工具集,包括expectationsmocksstubs,甚至還支援非同步測試。它是一個適用於iOS
開發的Behavior Driven Development(BDD)庫,優點在於其簡潔的介面和可用性,易於設定和使用,非常適合新手開發者。Kiwi使用Objective-C語言編寫,易於IOS開發人員上手。

總結(IOS)

IOS自動化測試框架繼承關係如下. XCTest與 Xcode 的 IDE 直接整合,使用簡單, 但其不支援stub和mock, 所以單使用XCTest框架的較少. Kiwi是一個iOS平臺十分好用的行為驅動開發BDD的測試框架,有著非常漂亮的語法,可以寫出結構性強,非常容易讀懂的測試。UI Automation是Apple官方提供的UI自動化測試的解決方法,但介面不夠豐富。

  • KIF、Frank、Calabash都是通過使用程式碼的形式來模擬事件觸發,使得被測程式碼就像是由使用者行為所觸發的一樣。但這樣的代價是插入一個額外層的複雜度。
  • IOS測試框架中支援BDD的有calabash 和Kiwi。
  • 可選用的單元測試框架有Kiwi,Specta,Quick等,而KIF,Subliminal和calabash更適用於UI級驗收測試。

一些有趣的自動化測試框架

1. Sikuli 圖形化程式設計技術

http://www.sikuli.org/

Sikuli 是由 MIT 的研究團隊釋出的新型圖形化程式設計技術。它以影象檢索技術為基礎,提供了一套基於Python 的指令碼語言以及整合開發環境。使用者可利用螢幕截圖直接引用 GUI 元素進行程式設計,完成互動操作。Sikuli的指令碼編寫遵循 Python語法規範。由於 Sikuli基於 Python,其核心程式碼由 Java 編寫,可在使用者自定義的 Java 工程中將其作為 Java 標準類庫進行引用。

它的指令碼是這樣式的:

Sikuli將 GUI 物件的螢幕截圖作為函式的引數直接引用,整個程式碼的語義清晰明瞭,可讀性極強。指令碼執行過程中,利用影象檢索演算法分析匹配當前螢幕中對應的控制元件,並對其應用相應的滑鼠或鍵盤操作。這種方式使得我們在指令碼編寫時,既無需關心繁瑣的應用程式相關 API 亦不用獲取 Web 內容物件。

缺點:

1、僅支援windows, MACOSX,和Linux平臺,還不支援移動平臺。

2、依賴螢幕截圖,使得1)在不同平臺,不同解析度,不同作業系統上需要維護一套圖形原始檔,不利於跨平臺移植;2)若出現程式邏輯外的介面遮擋,則影響程式執行。

但作為現有自動化測試工具的補充,尤其是對無法獲取API的工程,比如flash 動畫, 是非常有效的。

2. A/B test 框架 AppGrader

https://www.utest.com/articles/utest-launches-appgrader-for-android

雖然AppGrader不是一流的測試框架,但也有所長。它可以幫開發者將自己的應用與其他眾多同型別應用進行多方面比較,比如圖形和功能。通過對比結果,開發者可以更有針對性地提高和改進自己的應用。目前AppGrader僅支援Android平臺。

3. IOS A/B test 框架 FlipTest

http://www.fliptest.co.uk/

FlipTest是一個優秀的iOS app A/B測試框架,可為app挑選最佳的UI。FlipTest會基於外觀和易用性等眾多因素返回測試結果,進而幫開發者解決UI問題。用FlipTest進行測試無需向App Store重新提交應用或者大幅更改程式碼,只需要在app中新增一行程式碼,節省了不少時間。

轉載自:http://tmq.qq.com/2016/09/mobile-app-test-automation-framework/