前文：根据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的各种测试工具。
大公司使用者: 美团，腾讯均有使用
简介：使用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是一个开源的、跨平台的自动化测试工具，支持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年较为流行，最近的测试框架并不在推荐范围内。
网友评论