iOS自动化测试调研方案

前文：根据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则不一样，推出不久，相关资料还不是不少。

自动化实施步骤：

一、KIF搭建,配置Target项目参数；

二、安装KIF第三方框架；

三、用例编写与组织：accessibility 属性设置；用例经常使用操做接口，分 为交互操做和测试用例操做，系统功能完整性的实现；

四、用例的运行独立和 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的工具的使用学习，和任选一门脚本语言的学习成本，

因支持的脚本语言比较普遍， 用户量大，文档丰富。较易上手。支持多种脚本语言，不会将测试人员限制在某种特定语言或者框架上，门槛低。

4、UI测试框架EarlGrey

简介：

EarlGrey是Google推出iOS功能性UI测试框架，其所提供的主要特性：强大的内建同步机制，测试会在与UI进行交互前自动等待动画、网络请求等事件。

可见性检测：全部的交互都发生在用户能够看到的元素上。

灵活的设计：用于肯定元素选择、交互、断言与同步的组件在设计上就是可扩展的。

EarlGrey是个原生iOS UI自动化测试框架，EarlGrey与XCTest框架协同工做，而且集成到了Xcode的Test

Navigator中，这样你就能够直接在Xcode中或是在命令行中（使用xcodebuild）运行测试了。

安装：

对于EarlGrey，咱们强烈推荐CocoaPods做为入门的最佳方式，并保持EarlGrey版本同步到最新版本。（官网原话）

优势：

一、EarlGrey是个原生iOS UI自动化测试框架，能够帮助你编写出更加清晰、简明的测试。

二、借助于EarlGrey框架，你可使用加强的同步特性。

三、EarlGrey会自动与UI、网络请求及各类查询保持同步，同时在必要的状况下，你还能够手工实现自定义的定时器。

四、EarlGrey的同步特性能够确保在执行动做前，UI会处于一种稳定的状态。这极大地加强了测试稳定性，使得测试变得高度可重复。

五、EarlGrey与XCTest框架协同工做，而且集成到了Xcode的Test

Navigator中，这样你就能够直接在Xcode中或是在命令行中（使用xcodebuild）运行测试了。

六、适配环境 < (更新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年较为流行，最近的测试框架并不在推荐范围内。