移動APP自動化測試框架

時間 2019-11-08

標籤移動 app 自動化測試框架欄目無線简体版

原文原文鏈接

簡介

移動APP的UI自動化測試長久以來一直是一個難點，難點在於UI的」變」, 變化致使自動化用例的大量維護。從分層測試的角度，自動化測試應該逐層進行。最大量實現自動化測試的應該是單元測試，最容易實現也最容易在早期發現問題；其次是接口級測試，以驗證邏輯爲目的進行自動化，因爲接口的相對穩定，自動化測試成本相對也能夠接受；自動化成本最大的即是UI級自動化測試，然而UI界面是直接反饋給用戶的效果展現，適度的尤爲是BVT級的自動化測試也是很是必要的。本文經過分析幾種自動化框架的異同，使測試人員在選擇自動化框架時有所參考。html

Android自動化框架

1. Instrumentation android

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

Instrumentaion 是Android自帶的一個測試框架，是不少其它測試框架的基礎，能夠在同進程中加載被測組件。它有不少豐富的高層封裝，使用者可使用基於instrumentation的其餘框架，避免過多二次開發量。但Instrumentation不支持跨應用，致使基於instrumentation的框架都繼承了這個缺點。git

2. Robotium github

https://github.com/robotiumtech/robotiumweb

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. UIAutomatorwindows

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帶有本身的一套工具集，包括expectations、mocks、stubs，甚至還支持異步測試。它是一個適用於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 內容對象。

缺點：

一、僅支持windows， MACOSX，和Linux平臺，還不支持移動平臺。

二、依賴屏幕截圖，使得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中添加一行代碼，節省了很多時間。