iOS自動化測試調研方案

前文：根據Martin Fowler 的測試理論，測試應該遵循以下測試金字塔組合，測試金字塔最底層是單元測試，而後是集成測試，繼而是面向應用程序服務層的中間層測試，最高層是面向用戶的業務邏輯測試。

iOS的測試分爲兩塊：UI測試和Unit測試，因Unit測試先定義行爲，而後定義測試用例，接着再編寫代碼。 實踐中發現，一般沒有那麼多時間來先定義行爲，須要 去投入很大一塊精力去進行單元測試，沒法有效構建一個合理的單元測試環境。

原生測試弊端：

（一）Unit測試

1，經驗困境反倒更難以解決，且教程很少，新手入手難度較大。

2， 在 iOS經常會須要測試異步方法的正確性。咱們經常會用到 ‘作異步等待。太依賴嚴重於當前環境。

3， 編寫單元測試會增長程序員工做量。單元測試跟生產代碼是同樣的，並不會應爲是用來測試的就有所不一樣，開發人員一樣要面對測試代碼的編寫、維護等工做，也一樣要面對避免重複代碼等一系列問題，可否寫出好的測試代碼仍是取決於開發人員的設計和編碼能力。

對思想上的學習挑戰較大，並不能，單一模仿代碼實現類的完整測試，須要站立於模塊的基礎進行行爲的定義，來測試代碼流程

（二）UI測試：

目前只能進行一些簡單的測試，且測試的過程還須要人工干預

測試方案：

一,基於KIF：

原理簡介：

KIF的全稱是Keep it functional。它是一個創建在XCTest的UI測試框架，經過accessibility來定位具體的控件，再利用私有的API來操做UI。因爲是創建在XCTest上的，因此你能夠完美的藉助XCode的測試相關工具（包括命令行腳本），能幫助咱們去模擬用戶輸入來測試。

KIF繼承自XCTest測試框架，可直接使用私有API對UI界面進行操做，支持UIWebView的測試。

KIF利用Accessibiility來作界面測試的基本原理，須要注意的是，因爲KIF基於Accessibility，所以咱們在初始化控件時，不論是代碼仍是InterfaceBuilder，都要記得對須要測試的控件設置AccessibilityLabel和AccessibilityTrait

使用語言：Object C & Swift, 在iOS 10以後，無正式版的lib和App

KIF 優點

1，測試時直接獲取到UIView：KIF在測試過程當中，是直接獲取到應用程序，能夠直接取得UIView等控件，所以各類屬性能夠直接判斷；而 XCTest就顯得很不方便，它並無直接取得應用程序，而是在現有的視圖上取得XCUIElement，該類和UIView有很大差異，基本上UIView的屬性咱們沒法判斷。

2，XCTest原則上每一個UI測試都要從新啓動一遍應用，這樣的耗時是驚人的，而KIF則不用。文檔、教程比較多：KIF從2011年推出至今，網上已有大量的教程和問答，可能很方便找到解決方案，而XCode UI Test則不一樣，推出不久，相關資料還不是不少。

自動化實施步驟：

一、KIF搭建,配置Target項目參數；

二、安裝KIF第三方框架；

三、用例編寫與組織：accessibility 屬性設置；用例經常使用操做接口，分 爲交互操做和測試用例操做，系統功能完整性的實現；

四、用例的運行獨立和 retry 機制；

KIF自動化的持續集成：

持續集成是一個自動化的週期性的集成測試過程，從檢出代碼、編譯構建、運行測試、結果記錄、測試統計等都是自動完成的，無需人工干預。UI 測試目標是覆蓋最核心的代碼，儘量去掉依賴，讓不穩定因子降到最低；持續集成最大的好處在於可以儘早高效發現問題，下降解決問題的成本。

藉助Jenkins ，完成基於KIF 的 UI 自動化持續集成搭建，Jenkins 以Job 爲單位運行項目；是一套開源的持續集成工具，須要本身在服務器（iOS項目只能是MacOS）先部署好，而後能夠對接項目的Git倉庫地址，配置一些定時／事件觸發的任務，經過腳原本編譯、測試、打包。

學習成本：

KIF的集成較易上手，須要學習測試類的使用，好比獲取不一樣控件元素的方式等，易學習；

Jenkins環境配置的要求+使用學習，因涉及到領域的跨界，須要Java基礎，java語法上好上手，作到熟練須要按部就班；配置簡單，直接集成到XCode上，不須要安裝多餘的包。 像用戶同樣測試，測試代碼模仿用戶操做，代碼很簡單；自動集成XCode5以上的測試工具，在XCode上使用就像使用蘋果原生的測試框架同樣，支持XCode的各類測試工具。

大公司使用者: 美團，騰訊均有使用

二，基於Frank:

簡介：使用Ruby語言，開源內嵌Server型，經過注入Server到APP使用API，經過Server對外通訊完成UI操做。支持CI持續集成，不支持UIWebView,要求測試時在應用程序內部編譯。

安裝過程：

1，安裝frank-cucumber；

命令：sudo gem install frank-cucumber

2，在你的項目下設置frank以及執行下面的命令；

命令: frank setup

3，編譯frank

命令：frank build

4，啓動模擬器

命令：frank launch

Frank，這意味着對源代碼的改變是強制性的。

優勢：

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

缺點：對手勢的支持有限。 在設備上運行測試有點難。 修改配置文件須要在實際設備上運行。 記錄功能不可用；

學習成本：

須要ruby的基礎，操做方式爲使用Cucumber和JSON組合命令，將命令發送到在本地應用程序內部運行的服務器上，並利用UISpec運行命令。須要學習ruby語言，跨界性較大。近兩年的學習資料較少

三，基於APPium+XCUITest

原理簡介：

Appium是一個開源的、跨平臺的自動化測試工具，支持IOS、Android和FirefoxOS平臺。

appium 採用Client - Server的測試框架，的核心就是一個遵照REST設計風格的web服務器，它接受客戶端的鏈接，接收客戶端的命令，在手機設備上執行命令，而後經過HTTP的響應收集命令執行的結果。

App至關於一個Server，測試代碼至關於Client，經過發送JSON來操做APP，測試語言能夠是任意的，可使測試代碼訪問後端API和數據庫。它是經過驅動iOS的UIAutomation和Android的UiAutomator框架來實現的雙平臺支持，同時綁定了Selenium WebDriver用於老的Android平臺測試。

基於WebDriver JSON wire protocol對實際的UI操做庫進行了封裝，而且暴露出RESTFUL的接口。而後測試代碼經過HTTP請求的方式，來進行實際的測試。其中，實際驅動UI的框架根據系統版本有所不一樣；在安裝Appium以前，爲了確保Appium的相關依賴已經準備就緒，可使用Appium-doctor來進行驗證。

安裝過程：操做簡易。

優勢：

跨平臺，同時支持iOS、Android、H5，且儘可能能保持接口統一，減小開發維護成本；

開發者可使用WebDriver兼容的任何語言編寫測試腳本，如Ruby，C#，Java， JS，OC， PHP，Python，Perl和Clojure 語言。

不須要從新編譯應用（APP）或者任何方式修改它就能夠進入測試行爲；

測試腳本獨立與源代碼和測試框架；

Appium社區更活躍、有可能歸入Selenium-WebDriver體系，從而成爲事實上的移動應用測試標準；

Appium在不一樣平臺中使用了標準的自動化APIs，因此在跨平臺時，不須要從新編譯或者修改本身的應用；

採用Appium時，無需對被測應用作任何修改，也無需嵌入任何東西；

Appium對iOS和Android的原生自動化測試框架進行了封裝，並提供了統一的API，減小了自動化測試代碼的維護工做量；

Appium採用Client-Server的架構設計，並採用標準的HTTP通訊協議；Server端負責與iOS/Android原生測試框架交互，無需測試人員關注細節實現；Client端基本上能夠採用任意主流編程語言編寫測試用例，減小了學習成本。

缺點：自定義控件支持很差；WebView的支持很差

學習成本：

對於appium的工具的使用學習，和任選一門腳本語言的學習成本，

因支持的腳本語言比較普遍， 用戶量大，文檔豐富。較易上手。支持多種腳本語言，不會將測試人員限制在某種特定語言或者框架上，門檻低。

4、UI測試框架EarlGrey

簡介：

EarlGrey是Google推出iOS功能性UI測試框架，其所提供的主要特性：強大的內建同步機制，測試會在與UI進行交互前自動等待動畫、網絡請求等事件。

可見性檢測：全部的交互都發生在用戶能夠看到的元素上。

靈活的設計：用於肯定元素選擇、交互、斷言與同步的組件在設計上就是可擴展的。

EarlGrey是個原生iOS UI自動化測試框架，EarlGrey與XCTest框架協同工做，而且集成到了Xcode的Test

Navigator中，這樣你就能夠直接在Xcode中或是在命令行中（使用xcodebuild）運行測試了。

安裝：

對於EarlGrey，咱們強烈推薦CocoaPods做爲入門的最佳方式，並保持EarlGrey版本同步到最新版本。（官網原話）

優勢：

一、EarlGrey是個原生iOS UI自動化測試框架，能夠幫助你編寫出更加清晰、簡明的測試。

二、藉助於EarlGrey框架，你可使用加強的同步特性。

三、EarlGrey會自動與UI、網絡請求及各類查詢保持同步，同時在必要的狀況下，你還能夠手工實現自定義的定時器。

四、EarlGrey的同步特性能夠確保在執行動做前，UI會處於一種穩定的狀態。這極大地加強了測試穩定性，使得測試變得高度可重複。

五、EarlGrey與XCTest框架協同工做，而且集成到了Xcode的Test

Navigator中，這樣你就能夠直接在Xcode中或是在命令行中（使用xcodebuild）運行測試了。

六、適配環境 < (更新macOS Sierra + Xcode 8.1 + iOS 10.0.2：沒法使用)

與KIF的對比：

EarlGrey寫法多樣，操做靈活；KIF比較簡單，適合快速開發

EarlGrey支持同步；KIF須要手動等待：因爲EarlGrey採用了同步機制，因此保證了下一個操做的執行；對須要等待的操做，KIF須要手動添加等待事件，

EarlGrey建議使用AccessibiltyIdentifier；KIF使用AccessiblityLable：

兩個框架都是利用Accessibility來找元素，EarlGrey中建議使用AccessibiltyIdentifier，而KIF中大部分的API只支持AccessiblityLable，因此若是使用的是KIF，就只能去修改控件的AccessiblityLable。

EarlGrey支持拍照，能夠存在任何地方；KIF失敗自動拍照，只能存在固定地方。不過須要事先指定存儲路徑。

學習成本：

須要學習測試用例的編寫，以及內建同步機制等的實現思想；

因太靈活，編碼上，沒有固定的套路；

參考專業人士的描述，其自動化測試的功能更智能，但國內的關於EarlGrey學習資料較少，又寫法多樣，在零基礎的使用上，並不能很好的保證本身的編碼是一個可複製的，具備偶然性。

綜上所述：

UI測試優先推薦KIF，若是須要兼顧安卓測試，或者測試人員對OC/Swift很陌生，能夠採用appium；就目前搜索有關於自動化測試的衆多資料顯示，KIF和appiunm的資料較全面，且相對來講，易模仿易複製；KIF的使用，更多涉及到iOS原生代碼思想的學習和編碼實現，以及Jenkins工具的上手；對於appiunm，因其跨平臺，對三端均支持自動化測試，若是兼顧不一樣平臺的測試，建議首先，同時由於支持腳本語言較多，因Python的易上手，有很多資料顯示，選擇appium與Python的結合。對於Google推出的EarlGrey框架，功能相對是最好的，因搜索顯示，資料較少，在後期的具體實現上，對於未可預測的問題的解決效率上，會略有挑戰。因Frank在2014年較爲流行，最近的測試框架並不在推薦範圍內。