考慮選擇測試框架的幾種影響因素。首先,使用的語言和框架決定了測試人員的持續性學習成本,iOS 測試人員對 Object C 和 XCTest 熟悉和掌握程度高,不需要消耗額外的學習成本,人員更替時的接手成本也相對較低;其次,測試框架支持的 UI 操作的豐富性決定了測試用例的覆蓋完整度,使用私有 API 的測試框架支持的 UI 操作較為全面,而同時支持 UIWebView 的測試框架則更占優勢;另外,App 程序 UI 變化快,使用開發效率高、調試方便的測試框架能使我們在適應新 UI 變化、新需求時獲得更小的投入產出比。
綜合以上考慮,KIF 框架已經展現了他的優勢,并且 KIF 使用 XCTest 框架,使得其測試流程 iOS 程序的單測無異,可完全復用單測的持續集成流程,維護持續集成的成本相對降低;另外,KIF 是一個活躍的開源測試框架,可擴展性好,升級更新快,有活躍社區來探討和解決使用過程中遇到的問題。鑒于上述優勢,我們選擇了 KIF 作為 iOS 的 UI 自動化測試框架。
KIF 利用 Apple 給所有控件提供的輔助屬性 accessibility attributes 來定位和獲取元素,完成界面的交互操作;結合使用 Xcode 的 XCTest 測試框架,擁有 XCTest 測試框架的特性,使得測試用例能以 command line build 工具運行并獲取測試報告。
下面介紹如何進行 KIF 自動化實施。
KIF 以第三方庫的形式編譯運行于工程中,搭建 KIF 之前,應該確保工程在 Xcode 上編譯運行通過。
KIF 基于 XCTest 框架,繼承了 XCTest 的所有特性。和 XCTest 一樣,我們首先應該在工程項目中創建基于 Cocoa Touch Testing Bundle 模板的 Target ,并確保創建的 Target 的屬性有如下設置:
項目的設置準備好后,需要安裝 KIF 庫源碼到項目。即可開始 KIF 編寫用例之旅。
KIF 通過屬性值(AccessibilityLabel, AccessibilityIdentifier, AccessibilityTraits,Value...)在界面中定位元素。為了獲取到目標元素,我們必須先設置元素的 accessibility 屬性。如下,想要獲取程序中一個列表的 cell 元素,我們給列表的 cell 控件設置 accessibility 屬性(如左圖所示),設置為“Section XX Row XX”,編譯運行,即可獲得歷史列表的 cell 元素;用模擬器的 Accessibility Inspector 抓取到了這個歷史列表元素(如右圖所示):
原文轉自:https://zhuanlan.zhihu.com/p/22283843