移動APP自動化測試架構

標籤：roo   團隊   eve   googl   ios   dev   win   參考   omr   

簡介

 移動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是由Google提供的測試架構，它提供了原生Android app和遊戲的進階UI測試。這是一個包含API的Java庫，用來建立功能性UI測試，還有運行測試的執行引擎。該庫內建Android SDK。

優點：它在運行訪問不同的進程時，會給JUnit測試案例特權。庫由Google社區支援和維護。

缺點：僅支援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或者做任何調整，就可以測試行動裝置 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出的一個Mobile Testing架構，它支援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 內容對象。

缺點：

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/

移動APP自動化測試架構