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

iOS的測試分為兩塊：UI測試和Unit測試，因Unit測試先定義行為，然后定義測試用例，接著再編寫代碼。?實踐中發(fā)現(xiàn)，通常沒有那么多時間來先定義行為，需要 去投入很大一塊精力去進行單元測試，無法有效構(gòu)建一個合理的單元測試環(huán)境。

原生測試弊端：

（一）Unit測試

1，經(jīng)驗困境反倒更難以解決，且教程不多，新手入手難度較大。

2， 在 iOS常常會需要測試異步方法的正確性。我們常常會用到 ‘做異步等待。太依賴嚴重于當前環(huán)境。

3， 編寫單元測試會增加程序員工作量。單元測試跟生產(chǎn)代碼是一樣的，并不會應為是用來測試的就有所不同，開發(fā)人員同樣要面對測試代碼的編寫、維護等工作，也同樣要面對避免重復代碼等一系列問題，能否寫出好的測試代碼還是取決于開發(fā)人員的設(shè)計和編碼能力。

?對思想上的學習挑戰(zhàn)較大，并不能，單一模仿代碼實現(xiàn)類的完整測試，需要站立于模塊的基礎(chǔ)進行行為的定義，來測試代碼流程

（二）UI測試：

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

測試方案：

一,基于KIF：

原理簡介：

KIF的全稱是Keep it functional。它是一個建立在XCTest的UI測試框架，通過accessibility來定位具體的控件，再利用私有的API來操作UI。由于是建立在XCTest上的，所以你可以完美的借助XCode的測試相關(guān)工具（包括命令行腳本），能幫助我們?nèi)ツM用戶輸入來測試。

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

KIF利用Accessibiility來做界面測試的基本原理，需要注意的是，由于KIF基于Accessibility，因此我們在初始化控件時，不管是代碼還是InterfaceBuilder，都要記得對需要測試的控件設(shè)置AccessibilityLabel和AccessibilityTrait

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

KIF 優(yōu)勢

1，測試時直接獲取到UIView：KIF在測試過程中，是直接獲取到應用程序，可以直接取得UIView等控件，因此各種屬性可以直接判斷；而 XCTest就顯得很不方便，它并沒有直接取得應用程序，而是在現(xiàn)有的視圖上取得XCUIElement，該類和UIView有很大差別，基本上UIView的屬性我們無法判斷。

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

自動化實施步驟：

1、KIF搭建,配置Target項目參數(shù)；

2、安裝KIF第三方框架；

3、用例編寫與組織：accessibility 屬性設(shè)置；用例常用操作接口，分? 為交互操作和測試用例操作，系統(tǒng)功能完整性的實現(xiàn)；

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

KIF自動化的持續(xù)集成：

持續(xù)集成是一個自動化的周期性的集成測試過程，從檢出代碼、編譯構(gòu)建、運行測試、結(jié)果記錄、測試統(tǒng)計等都是自動完成的，無需人工干預。UI 測試目標是覆蓋最核心的代碼，盡可能去掉依賴，讓不穩(wěn)定因子降到最低；持續(xù)集成最大的好處在于能夠盡早高效發(fā)現(xiàn)問題，降低解決問題的成本。

借助Jenkins ，完成基于KIF 的 UI 自動化持續(xù)集成搭建，Jenkins 以Job 為單位運行項目；是一套開源的持續(xù)集成工具，需要自己在服務器（iOS項目只能是MacOS）先部署好，然后可以對接項目的Git倉庫地址，配置一些定時／事件觸發(fā)的任務，通過腳本來編譯、測試、打包。

學習成本：

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

Jenkins環(huán)境配置的要求+使用學習，因涉及到領(lǐng)域的跨界，需要Java基礎(chǔ)，java語法上好上手，做到熟練需要循序漸進；配置簡單，直接集成到XCode上，不需要安裝多余的包。 像用戶一樣測試，測試代碼模仿用戶操作，代碼很簡單；自動集成XCode5以上的測試工具，在XCode上使用就像使用蘋果原生的測試框架一樣，支持XCode的各種測試工具。

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

二，基于Frank:

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

安裝過程：

1，安裝frank-cucumber；

命令：sudo gem install frank-cucumber

2，在你的項目下設(shè)置frank以及執(zhí)行下面的命令；

命令: frank setup

3，編譯frank

命令：frank build

4，啟動模擬器

命令：frank launch

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

優(yōu)點：

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

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

學習成本：

需要ruby的基礎(chǔ)，操作方式為使用Cucumber和JSON組合命令，將命令發(fā)送到在本地應用程序內(nèi)部運行的服務器上，并利用UISpec運行命令。需要學習ruby語言，跨界性較大。近兩年的學習資料較少

三，基于APPium+XCUITest

原理簡介：

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

appium?采用Client - Server的測試框架，的核心就是一個遵守REST設(shè)計風格的web服務器，它接受客戶端的連接，接收客戶端的命令，在手機設(shè)備上執(zhí)行命令，然后通過HTTP的響應收集命令執(zhí)行的結(jié)果。

App相當于一個Server，測試代碼相當于Client，通過發(fā)送JSON來操作APP，測試語言可以是任意的，可以使測試代碼訪問后端API和數(shù)據(jù)庫。它是通過驅(qū)動iOS的UIAutomation和Android的UiAutomator框架來實現(xiàn)的雙平臺支持，同時綁定了Selenium WebDriver用于老的Android平臺測試。

基于WebDriver JSON wire protocol對實際的UI操作庫進行了封裝，并且暴露出RESTFUL的接口。然后測試代碼通過HTTP請求的方式，來進行實際的測試。其中，實際驅(qū)動UI的框架根據(jù)系統(tǒng)版本有所不同；在安裝Appium之前，為了確保Appium的相關(guān)依賴已經(jīng)準備就緒，可以使用Appium-doctor來進行驗證。

安裝過程：操作簡易。

優(yōu)點：

跨平臺，同時支持iOS、Android、H5，且盡量能保持接口統(tǒng)一，減少開發(fā)維護成本；

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

不需要重新編譯應用（APP）或者任何方式修改它就可以進入測試行為；

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

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

Appium在不同平臺中使用了標準的自動化APIs，所以在跨平臺時，不需要重新編譯或者修改自己的應用；

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

Appium對iOS和Android的原生自動化測試框架進行了封裝，并提供了統(tǒng)一的API，減少了自動化測試代碼的維護工作量；

Appium采用Client-Server的架構(gòu)設(shè)計，并采用標準的HTTP通信協(xié)議；Server端負責與iOS/Android原生測試框架交互，無需測試人員關(guān)注細節(jié)實現(xiàn)；Client端基本上可以采用任意主流編程語言編寫測試用例，減少了學習成本。

缺點：自定義控件支持不好；WebView的支持不好

學習成本：

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

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

四、UI測試框架EarlGrey

簡介：

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

可見性檢測：所有的交互都發(fā)生在用戶可以看到的元素上。

靈活的設(shè)計：用于確定元素選擇、交互、斷言與同步的組件在設(shè)計上就是可擴展的。

EarlGrey是個原生iOS UI自動化測試框架，EarlGrey與XCTest框架協(xié)同工作，并且集成到了Xcode的Test

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

安裝：

對于EarlGrey，我們強烈推薦CocoaPods作為入門的最佳方式，并保持EarlGrey版本同步到最新版本。（官網(wǎng)原話）

優(yōu)點：

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

2、借助于EarlGrey框架，你可以使用增強的同步特性。

3、EarlGrey會自動與UI、網(wǎng)絡請求及各種查詢保持同步，同時在必要的情況下，你還可以手工實現(xiàn)自定義的定時器。

4、EarlGrey的同步特性可以確保在執(zhí)行動作前，UI會處于一種穩(wěn)定的狀態(tài)。這極大地增強了測試穩(wěn)定性，使得測試變得高度可重復。

5、EarlGrey與XCTest框架協(xié)同工作，并且集成到了Xcode的Test

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

6、適配環(huán)境 < (更新macOS Sierra + Xcode 8.1 + iOS 10.0.2：無法使用)

與KIF的對比：

EarlGrey寫法多樣，操作靈活；KIF比較簡單，適合快速開發(fā)

EarlGrey支持同步；KIF需要手動等待：由于EarlGrey采用了同步機制，所以保證了下一個操作的執(zhí)行；對需要等待的操作，KIF需要手動添加等待事件，

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

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

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

學習成本：

需要學習測試用例的編寫，以及內(nèi)建同步機制等的實現(xiàn)思想；

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

參考專業(yè)人士的描述，其自動化測試的功能更智能，但國內(nèi)的關(guān)于EarlGrey學習資料較少，又寫法多樣，在零基礎(chǔ)的使用上，并不能很好的保證自己的編碼是一個可復制的，具有偶然性。

綜上所述：

UI測試優(yōu)先推薦KIF，如果需要兼顧安卓測試，或者測試人員對OC/Swift很陌生，可以采用appium；就目前搜索有關(guān)于自動化測試的眾多資料顯示，KIF和appiunm的資料較全面，且相對來說，易模仿易復制；KIF的使用，更多涉及到iOS原生代碼思想的學習和編碼實現(xiàn)，以及Jenkins工具的上手；對于appiunm，因其跨平臺，對三端均支持自動化測試，如果兼顧不同平臺的測試，建議首先，同時因為支持腳本語言較多，因Python的易上手，有不少資料顯示，選擇appium與Python的結(jié)合。對于Google推出的EarlGrey框架，功能相對是最好的，因搜索顯示，資料較少，在后期的具體實現(xiàn)上，對于未可預測的問題的解決效率上，會略有挑戰(zhàn)。因Frank在2014年較為流行，最近的測試框架并不在推薦范圍內(nèi)。