前文：根據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則不同，推出不久，相關資料還不是很多。
自動化實施步驟：
1、KIF搭建,配置Target專案引數；
2、安裝KIF第三方框架；
3、用例編寫與組織：accessibility 屬性設定；用例常用操作介面，分 為互動操作和測試用例操作，系統功能完整性的實現；
4、用例的執行獨立和 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的工具的使用學習，和任選一門指令碼語言的學習成本，
因支援的指令碼語言比較廣泛， 使用者量大，文件豐富。較易上手。支援多種指令碼語言，不會將測試人員限制在某種特定語言或者框架上，門檻低。
四、UI測試框架EarlGrey
簡介：
EarlGrey是Google推出iOS功能性UI測試框架，其所提供的主要特性：強大的內建同步機制，測試會在與UI進行互動前自動等待動畫、網路請求等事件。
可見性檢測：所有的互動都發生在使用者可以看到的元素上。
靈活的設計：用於確定元素選擇、互動、斷言與同步的元件在設計上就是可擴充套件的。
EarlGrey是個原生iOS UI自動化測試框架，EarlGrey與XCTest框架協同工作，並且整合到了Xcode的Test
Navigator中，這樣你就可以直接在Xcode中或是在命令列中（使用xcodebuild）執行測試了。
安裝：
對於EarlGrey，我們強烈推薦CocoaPods作為入門的最佳方式，並保持EarlGrey版本同步到最新版本。（官網原話）
優點：
1、EarlGrey是個原生iOS UI自動化測試框架，可以幫助你編寫出更加清晰、簡明的測試。
2、藉助於EarlGrey框架，你可以使用增強的同步特性。
3、EarlGrey會自動與UI、網路請求及各種查詢保持同步，同時在必要的情況下，你還可以手工實現自定義的定時器。
4、EarlGrey的同步特性可以確保在執行動作前，UI會處於一種穩定的狀態。這極大地增強了測試穩定性，使得測試變得高度可重複。
5、EarlGrey與XCTest框架協同工作，並且整合到了Xcode的Test
Navigator中，這樣你就可以直接在Xcode中或是在命令列中（使用xcodebuild）執行測試了。
6、適配環境 < (更新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年較為流行，最近的測試框架並不在推薦範圍內。