背景
目前Android端已完成了相应的框架搭建，并实际落地产出了，由于Android使用的是Unittest+HtmlTestRunner产出报告，需要增加新功能的话需要改动到底层框架，所以目前在负责的iOS端打算采用Pytest+Allure方式来进行，优点是更好的插件支持，报告也会更好看（装逼）点
PS：Android端自动化运行相比iOS自动化确实会稳定很多
一 iOS自动化框架及工具介绍
1.UIAutomation
UIAutomation 是苹果提供的 UI 自动化测试框架，使用 JavaScript 编写。
基于 UIAutomation 有扩展型的工具框架和驱动型的框架。扩展型框架以 JavaScript 扩展库方法提供了很多好用 js 工具，注入式的框架通常会提供一些 Lib 或者是 Framework，要求测试人员在待测应用的代码工程中导入这些内容，框架可以通过他们完成对 app 的驱动。
驱动型 UI Automation 在自动化测试底层使用了 UI Automation 库，通过 TCP 通信的方式驱动 UI Automation 来完成自动化测试，通过这种方式，编辑脚本的语言不再局限于 JavaScript。这个工具在 iOS UI 自动化测试中使用非常广泛
2.XCTest
XCTest 是苹果在 iOS 7 和 Xcode5 引入的一个简单而强大的测试框架，集成在 Xcode 中，用来编写测试代码。它提供了各个层次的测试。
XCTest 测试编写起来非常简单，并且遵循 xUnit 风格。
Xcode 在创建工程时，会默认使用 XCTest，并且默认创建了 Unit Test（单元测试）和 UI Test（界面测试）两个 Target，其中 Unit Test 主要用于测试代码的大部分基本功能，比如绝大多数 Model 的类和方法测试，业务逻辑测试，网络接口调用测试等等。
UI Test 一般会考虑到用户的交互流程，模拟用户的交互操作，利用 XCTest 的 UI 记录特性来获取界面上的一些列视图元素和操作事件，然后在测试方法中触发事件。
所以这是一个可以提供各个层次的测试的框架，比如单元测试，自动化测试，性能测试等
XCTest参考资料
3.KIF
KIF 是 Keep It Functional 项目的缩写，是一款 iOS app 功能性测试框架，来自 Square，该测试框架只支持 iOS。
所有测试使用 Objective-C 语言编写，对测试人员来讲，需要熟练的掌握 Objective-C 语言 ， 对苹果开发者来说非常容易上手，更是一款开发者广为推荐的测试工具。
KIF 使用未公开的 Apple API（私有 API），这对于测试目的而言是安全的，基于第三方 iOS UI 的单元测试框架，所以可以做项目的单元测试，也可以做 UI 集成测试。但缺点是运行较慢。
4.Frank
Frank 是 iOS 开发环境下一款实现自动测试的工具，Xcode 环境下开发完成后，通过 Frank 实现结构化的测试用例，其底层语言为 Ruby，作为一款开源的 iOS 测试工具，在国外已经有广泛的应用。
但是国内相关资料却比较少。其最大的优点是允许我们用熟悉的自然语言实现实际的操作逻辑。
它提供了针对 iOS 平台的功能测试能力，可以模拟用户的操作对应用程序进行黑盒测试，并且使用 Cucumber 编写测试用例，使测试用例如同自然语言一样描述功能需求，让测试以“可执行的文档”的形式成为业务客户与交付团队之间的桥梁。
- 优点
测试场景是在 Cucumber 的帮助下，用可理解的英语句子写的，还有活跃的社区支持，以及不断扩大中的库。
- 缺点
对手势的支持有限，所以在设备上运行测试有点难。
5.Calabash-iOS
Calabash 是一个适用于 iOS 和 Android 开发者的跨平台 app 测试框架，可用来测试屏幕截图、手势和实际功能代码。
Calabash 开源免费并支持 Cucumber 语言，Cucumber 能让你用自然的英语语言表述 app 的行为，实现 BDD（Behavior Driven Development，行为驱动开发）。
而 Calabash-iOS 就是一个基于 Calabash 的 iOS 的功能、自动化测试框架。
- 优点：
有大型社区支持；
列表项简单，类似英语表述的测试语句支持在屏幕上的所有动作，如滑动，缩放，旋转，敲击等。
- 缺点：
测试步骤失败后，将跳过所有的后续步骤，这可能会导致错过更严重的产品问题。
测试耗费时间，因为它总是默认先安装 app，需要 Calabash 框架安装在 iOS 的 ipa
文件中， 因此测试人员必须要有 iOS 的 app 源码。
除了 Ruby，对其他语言不友好
6.Appium
Appium 是一个开源的、跨平台的自动化测试工具，支持 iOS、Android 和 FirefoxOS 平台。
通过 Appium，开发者无需重新编译 app 或者做任何调整，就可以测试移动应用，可以使测试代码访问后端 API 和数据库。
它是通过驱动苹果的 UIAutomation 框架来实现的 iOS 平台支持,底层使用的是WEBDriverAgent来进行驱动
开发者可以使用 WebDriver 兼容的任何语言编写测试脚本，如 Ruby，C#，Java， JS，OC， PHP，Python，Perl 和 Clojure 语言。
7.AirTest
Airtest是由网易游戏推出的UI自动化测试解决方案，是一个跨平台的、 基于图像识别的UI自动化测试框架，适用于游戏和App，支持平台有Windows、Android和iOS。并且提供了基于UI控件识别的Poco框架，目前也支持Android原生、iOS原生、Unity3D、cocos2dx、UE4和Egret等平台。为了让测试人员更好上手，网易还贴心地提供了AirtestIDE工具，内置了Airtest和Poco的相关插件功能，能够使用它快速简单地编写 Airtest 和 Poco 代码
相比于Appium，POCOUI最大的亮点是其内部集成了自研的图像识别进行点击，代码编写的语法会更为精炼
PocoUi 参考资料
结合以上7种方案，如果能使用Object-C进行XCTest用例编写其实是最优选择，但是由于本人对Object-C不熟悉，学习一门语言只用于做iOS自动化相关成本较大，所以综合考量决定在Appium和Airtest之间做对比
Appium做自动化测试的都应该熟悉，Airtest作为网易开源的项目也是很不错的，那么接下来看下两者有何区别
二 Appium与Airtest的iOS自动化测试对比
| 对比项 | Appium | Airtest |
|---|---|---|
| 安装配置 | 中等:需要前置的一些依赖环境和填写启动的参数 | 简单 IDE可直连 |
| 语言支持 | 涵盖主流大部分语言 | python为主 |
| 上手难易 | 中等 | 容易 |
| 市场占有率 | TOP1 | 逐渐增加 |
| 支持平台 | Android，iOS，H5 | Android，iOS，H5 |
| 集成框架 | UiAutomator、UiAutomation框架 | Poco元素识别、Airtest图像识别 |
| 多设备并行 | 支持 | 支持 |
| 相关资料 | 多 | 较少 |
| 社区支持与维护 | 有专门的社区支持维护，交流讨论较多 | 有Q群进行交流 |
| 后续升级 | 有保证 | 取决于网易团队后续维护 |
| 测试报告 | HtmlTestRunner、Allure | 有自己带的报告模板 |
| CI持续集成 | 支持 | 支持 |
| 元素定位 | 部分页面无法获取元素 | 个人感觉元素定位不好用 |
| 执行效率 | 文本定位较快，其余定位较慢 | 文本定位较快，其余定位较慢 |
| 稳定性 | 一般，主要取决于WDA | 一般，主要取决于WDA |
| 编写效率 | 取决于对Appium-Api的熟悉程度 | 取决于对Airtest和PocoUI的Api熟悉程度 |
| 适用场景 | 适用于自研，原生的App应用 | 多用于快速构建图形脚本和游戏自动化 |
对比结论：
1.关于执行效率上，Appium与Airtest相差不大，主要还是通过元素的文本方式进行定位，脱离了文本想对元素进行定位速度都比较慢
2.关于代码编写效率上，本人使用Appium会好于Airtest（由于Android项目），Airtest的Api是新的，与appium的有所不同，对Api的熟悉需要一定过程，前期可能会较慢，后期熟练了会较快，Airtest对api的封装会更多一些，初始用者需要自己对Appium的Api进行封装
3.关于稳定性，Appium-wda和iOS-tagent都是基于facebook-wda（facebook未维护了，appium团队对其进行改造有在维护，airtest目前也有在改造维护中）进行封装改造的，试用时稳定性差不多，暂未出现掉线情况，iOS-tagent据说简化了内部的一些逻辑调用，不过总体体验下来差不多，对于高版本的iOS，Airtest官方好像还是推荐Appium的wda
4.关于适用场景，Appium主要是通过元素定位来进行自动化运行，适用于原生App下没有特殊强调对某种类型的app会更好用，属于兼容性较强的场景使用性，Airtest由于背靠网易，所以在场景使用方面更受游戏公司的自动化运行，尤其是他的图像识别点击，能够更好的识别游戏自动化中的场景，不过Airtest也可以通过PocoUI进行元素点击，涉及图形多的，如游戏类的可以使用Airtest
5.对于特定场景的元素定位，部分App流下，Appium与Airtest均无法获取到其中的元素信息，从而导致无法对该部分内容进行校验，Appium每次切换页面需要手动刷新页面
Airtest可以实时显示界面，Airtest的连接方式相对于Appium会稍简单
6.关于后续版本维护方面，Appium目前社区维护稳定，几天一更新，Airtest目前看最新的维护时间是在3个月前，相比之下Appium的维护工作会更好
7.关于多设备并行，Appium与Airtest都可以运行多设备，目前我这都是根据Tidevice启动多个wda服务开启多个端口号进行，使用情况差不多
8.相对于其他方面的比较基本都差不多
由于公司的App是原生+H5相关的，对Appium的使用也比较了解，两者区别不是很大的情况下，还是选择使用Appium做iOS自动化测试
三 Appium驱动原理
驱动原理
XCUITest是苹果开发的一个做IOS自动化测试的框架，需要了解些Swift等iOS编程知识
WebDriverAgent是Facebook开发的一个iOS自动化测试工具，先来看下面的这张原理图：
WDA在Client创建了一个Server，在手机端安装了一个叫作WebDriverAgentRunner 的一个应用；这个应用会接收来自 Server 的指令，并连接底层的XCTest.framwork，让 XCTest.framwork 调用苹果API来操作手机进行自动化
而appium是把WebDriverAgentRunner 给集成进去了，因此实现了appium的跨平台能力
通过上图我们了解到 Appium 很粗暴的把整个 WebDriverAgent 直接集成到自己的项目里，然后通信机制就走 WebDriverAgent，Appium 其实就提供了一个 Client 端的作用。所以 iOS 9.3 系统之后自动化测试核心是 WebDriverAgent，Appium 就提供了一个 Client 端来写脚本和发送指令。
Appium 自动化架构模式可以用一个抽象的架构表示，如下图所示：
从图中可以看出：
- Client 端是 Appium 之前本身提供的；
- Server 端是：WebDriverAgent 和 Instruments；（ Appium 直接把 WebDriverAgent 整个集成进来，Instruments 是为了支持 iOS 9.3 之前的系统）
- 之前 Server 是和 bootstrap.jar 通信，这里 WebDriverAgent提供了WebDriverAgentRunner （类似 jar 的功能），WebDriverAgent与之通信；
- WebDriverAgentRunner 是一个应用，Client 和 server 运行了之后，WebDriverAgentRunner 会被装到手机上，这个应用会接收来自 Server 的指令，并连接底层的framwork，并告诉XCTest.framwork操作手机进行自动化
关于WebDriverAgent
FaceBook 出品:
- 实现了一个 server，通过 server 可以远程控制 iOS 设备：启动应用、关闭应用、点击、滚动等操作；
- 通过连接 framework 调用苹果的 API 执行动作；
- 支持多个设备同时进行自动化；
- Appium、Macaca 已经集成。
- 但是 WebDriverAgent仅仅只提供了一个 server（和 inspect 进行元素定位），并没有像Appium 一样提供 java 或 python 的 Client 端去写脚本，脚本执行的时候发送指令给server，然后去运行。WebDriverAgent 要求你自己去实现 Client 端，即拿 Java/ Python 的WebDriver 库进行封装，然后发送指令。所以 WebDriverAgent 其实就类似于 Appium server，就只是一个server。
Appium简介
Appium原理
- Appium是一个开源、跨平台的测试框架，可以用来测试原生及混合的移动端应用。Appium支持IOS、Android及FirefoxOS平台。Appium使用WebDriver的jsonwire协议，来驱动Apple系统的UIAutomation库、Android系统的UIAutomator框架。Appium对IOS系统的支持得益于Dan Cuellar’s对于IOS自动化的研究。Appium也集成了Selendroid，来支持老android版本。
- Appium支持Selenium WebDriver支持的所有语言，如java、Object-C、JavaScript、Php Python、Ruby、C#、Clojure，或者Perl语言，更可以使用Selenium WebDriver的Api。Appium支持任何一种测试框架。如果只使用Apple的UIAutomation，我们只能用javascript来编写测试用例，而且只能用Instruction来运行测试用例。同样，如果只使用Google的UIAutomation，我们就只能用java来编写测试用例。Appium实现了真正的跨平台自动化测试。
- appium选择了client-server的设计模式。只要client能够发送http请求给server，那么的话client用什么语言来实现都是可以的，这就是appium及webdriver如何做到支持多语言的；
Appium优点
- 开源
- 跨架构:Native App、Hybird App、Web App
- 跨设备:Android、iOS、Firefox OS
- 不依赖源码
- 使用任何 WebDriver 兼容的语言来编写测试用例。比如 Java， Objective-C， JavaScript with
Node.js (in both callback and yield-based flavours)， PHP， Python，
Ruby， C#， Clojure， 或者 Perl. - 不需要重新编译APP
- 支持IOS手机录制视频
Appium理念
- 你无需为了自动化，而重新编译或者修改你的应用。
- 你不必局限于某种语言或者框架来写和运行测试脚本。
- 一个移动自动化的框架不应该在接口上重复造轮子。（移动自动化的接口应该统一）
- 无论是精神上，还是名义上，都必须开源。
Appium 在 iOS 下工具的变革
- iOS 9 之前一直以 instruments 下的 UIAutomation为驱动底层技术（弊端由于 instruments
的限制，单台 mac 只能对应单台设备）； - iOS 9.3 时代推出 XCUITest 工具，用以替代 UIAutomation；
- iOS 10 时代苹果直接废弃了 UIAutomation、Facebook 推出 WebDriverAgent（实现的 server
能够支持单台 mac 对应多个设备）； - Appium 在iOS 9.3 后全面采用 WebDriverAgent 的方案。
2353
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
