一、测试框架

iOS UI 自动化测试框架有不少，其中 UI Automation 是 Apple 早期提供的 UI 自动化测试解决方法，用 JavaScript 编写测试脚本，通过标签和值的可访问性获得 UI 元素，来完成相应的交互操作。

一些第三方 UI 解决方案以 UI Automation 为基础，对其进行补充和优化，包括扩展型 UI Automation 和驱动型 UI Automation。

扩展型 UI Automation 采用 JavaScript 扩展库方法提高 UI Automation 的易用性，常见的框架有 TuneupJs、ynm3k。

驱动型 UI Automation 在自动化测试底层使用了 UI Automation 库，通过 TCP 等通信方式驱动 UI Automation 来完成自动化测试。这种方式下，编辑脚本的语言不再局限于 JavaScript 。常见的框架有 iOSDriver、Appium。

还有一些其他的第三方解决方案，常见的框架类型有私有 API 型和注入编译型。

私有 API 型框架直接使用 Apple 私有 API 对 UI 界面进行操作。常见的框架主要有 KIF。

注入编译型框架在编译时注入一个 Server 到 App 内部，通过 Server 对外通信完成 UI 操作指令的执行。常见的框架有 Frank、Calabash。

Xcode 7发布后，Apple 提供了一种新的 UI 自动化测试解决方法——UI Testing，它基于 XCTest 测试框架，通过控件的可访问性来定位和获取控件，并提供了多种 UI 操作 API，使用源码语言，能方便地进行调试。

我们在以上分类中挑选具有代表性的自动化框架：Appium、Frank、KIF、Subliminal、Calabash、UI Testing 、UI Automation进行对比

考虑选择测试框架的几种影响因素。首先，使用的语言和框架决定了测试人员的持续性学习成本，iOS 测试人员对 Object C 和 XCTest 熟悉和掌握程度高，不需要消耗额外的学习成本，人员更替时的接手成本也相对较低；其次，测试框架支持的 UI 操作的丰富性决定了测试用例的覆盖完整度，使用私有 API 的测试框架支持的 UI 操作较为全面；另外，App 程序 UI 变化快，使用开发效率高、调试方便的测试框架能使我们在适应新 UI 变化、新需求时获得更小的投入产出比, KIF框架支持OC和Swift,稳定性相对较为良好。

综合以上考虑，KIF 框架已经展现了他的优势，并且 KIF 使用 XCTest 框架，使得其测试流程 iOS 程序的单测无异，可完全复用单测的持续集成流程，维护持续集成的成本相对降低；另外，KIF 是一个活跃的开源测试框架，可扩展性好，升级更新快，有活跃社区来探讨和解决使用过程中遇到的问题。鉴于上述优势，我们选择了 KIF 作为 iOS 的 UI 自动化测试框架。

二、KIF 自动化实施

KIF 基于 XCTest 框架，继承了 XCTest 的所有特性。和 XCTest 一样，我们首先应该在工程项目中创建基于 Cocoa Touch Testing Bundle 模板的 Target ，并确保创建的 Target 的属性有如下设置：

“Build Phases”：设置 Target Dependencies ， UI 自动化测试固然要依赖应用程序的 App 产物，所以需保证应用程序 Target 被添加在 Test Target 的 Target Dependencies 中。

“Build Settings”:

设置 “Bundle loader” 为：$(BUILT_PRODUCTS_DIR)/MyApp.app/MyApp；

设置 “Test Host” 为：$(BUILT_PRODUCTS_DIR)；

设置 “Wrapper Extensions” 为：xctest。

项目的设置准备好后，需要安装 KIF 库源码到项目。即可开始 KIF 编写用例之旅。

 说明

使用KIF测试的所有元素必须设置accessibilityIdentifier或accessibilityLabel才能被KIF框架访问到

accessibilityIdentifier: 可以没有意义，需要保证唯一

accessibilityLabel：需要有意义，可以被VoiceOver访问，故通常使用Identifier标识控件，而accessibilityLabel的值通常是控件上的文本