iOS

对于 iOS 9.2 及更低版本，苹果唯一的自动化技术被称为UIAutomation，它运行在 Instruments 中。从 iOS 10 开始，苹果已经完全删除了 UIAutomation 工具。

同时，苹果推出了一款名为XCUITest 的新型自动化技术，从 iOS 9.3 到 iOS 10 及以上版本，这将是苹果唯一支持的自动化框架。

目前主流的 iOS 移动测试框架

KIF：KIF 使用 XCTest 框架,需要对 Objective—C 、Swift 和 XCTest 掌握程度较高，这个对测试工程师来说学习成本太大
XCUITest：苹果官方提供的 iOS 测试框架，要求同 KIF 一致
WebDriverAgent：由 Facebook 推出的一款 iOS 移动测试框架，也是 Appium 跨平台的底层驱动；WDA 本身也是一个完整的基于 webdriver 协议的框架
Uiautomation ：在 Xcode8 后废弃

XCUITest

可以脱离 iOS App 源码进行UI自动化

XCUITest是XCTest中的一部分，XCTest包括XCUITest（界面测试）Unit Test（单元测试）。

UIAutomation

iOS4时代，Apple发布了一个名为UIAutomation的测试框架，它可以用来在真实设备和iPhone模拟器上执行自动化测试。UIAutomation的功能测试代码是用Javascript编写的。UIAutomation和Accessibility有着直接的关系，你将用到通过标签和值的访问性来获得UI元素，同时完成相应的交互操作。

UIAutomation的 JS 测试脚本，需要在Instrument的Automation控件上测试。但是在Xcode8.0之后，Instrument已经不再有这个模块了。而Apple也不再对它维护了，推广使用UITest来替代它。

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则不同，推出不久，相关资料还不是很多。

Android

Espresso

Espresso 是 Google 针对 Android 平台开源的一款 Android 自动化白盒测试框架，主要是用于 Android App UI 自动化测试。

在这里简单说下 UI 自动化测试：我们作为 App 的使用者，要让机器模拟我们的测试过程，那么就需要针对我们肉眼看到的那些界面，那些按钮，也就是 UI 组件进行相应的操作以及对结果正确性的验证。

比如说，作为用户我们并不关心某个网络请求返回值的具体数据是否正确，我们关心的是在界面上看到我们想要看到的结果。因此，做 UI 自动化测试用例的时候，一个通用的思路就是：找到某个元素，做一些操作，检查结果，把自己当成用户，只关注我能看到的东西。

Espresso 毕竟是 Google 自己出的，优点还是很多的

用 Java 来写代码，对 Android 开发者很友好
API 相当的小，当然也会对拓展开放的
Espresso 的测试跑起来那是相当的快（没有等待、睡眠）
Gradle 和 Android Studio 的支持

UIAutomator

UIAutomator是谷歌提供的一套黑盒测试工具，与之相对的是Espresso（白盒测试）。

UIAutomator是Android提供的自动化测试框架，基本上支持所有的Android事件操作。是用来做UI测试的，也就是普通的手工测试，点击每个控件元素看看输出的结果是否符合预期。对比Instrumentation它不需要测试人员了解代码实现细节（可以用UiAutomatorviewer抓去App页面上的控件属性而不看源码）。能跨App（比如：很多App有选择相册、打开相机拍照，这就是跨App测试）。缺点是只支持SDK 16（Android 4.1）及以上，不支持Hybird App、WebApp。

对UIAutomator2进行封装的一个Python 自动化测试框架：https://github.com/openatx/uiautomator2 。

Monkey测试

随机测试，压力测试，运行在模拟器或实际设备中。

Monkey 即猴子，Monkey 测试，就像一只猴子，在电脑面前，乱敲键盘在测试。

Monkey 测试主要用于Android 应用程序压力测试的小工具，主要目的就是为了测试app是否会Crash。

Monkey 测试原理：Monkey 是 Android 中的一个命令行工具，可以运行在模拟器里或实际设备中。它向系统发送伪随机的用户事件流（如按键输入、触摸屏输入、手势输入等），实现对正在开发的应用程序进行压力测试。通常也称随机测试或者稳定性测试。Monkey 测试是一种为了测试软件的稳定性、健壮性的快速有效的方法。

跨平台

appium

介绍

usage

Appium是跨平台的：它允许您使用相同的API针对多个平台（iOS，Android，Windows）编写测试。

但是底层，Appium 通过使用供应商提供的自动化框架来满足需求：

iOS 9.3及以上版本：Apple的 XCUITest
iOS 9.3及更低版本：Apple的 UIAutomation
Android 4.2+：Google的 UiAutomator / UiAutomator2
Android 2.3+：Google的 Instrumentation
Windows：微软的 WinAppDriver

Appium是开源的。

appium是手机和 PC 之间的代理服务器，完成两者的通信处理。（没错，它就是个中间商）

Appium提供各个语言的第三方库，在库内部会将测试脚本转化成 WebDriver 协议下的标准请求，并发送到Appium Server。

Appium Server是一个基于Node.js的服务，Appium Server发送到各个平台上的代理工具，代理工具在运行过程中不断接收 URL，根据 WebDriver 协议解析出要执行的操作，然后调用各个平台上的原生测试框架完成测试，再将测试结果返回给 Node 服务器。

Appium iOS封装了苹果公司的Instruments框架，主要用了Instrument里的UiAutomation（Apple的自动化测试框架），然后在设备中注入，如下图所示：

WebDriver script 是selenium风格的测试脚本；
中间的是Appium服务，Appium启动一个服务（4723端口），与Selenium-WebDriver测试框架相类似，Appium支持标准的WebDriver JSONWireProtocol。它提供一套Web服务，Appium Server接收WebDriver标准请求，解析请求内容，调用对应框架相应操作；
Appium Server调用instruments.js启动一个sock server，同时分出一个子进程运行instruments.app，将bootstrap.js注入到设备用于和外界进行交互；

Macro Recorder

PyMacroRecord

https://github.com/LOUDO56/PyMacroRecord

Linux

xdotool

sudo apt-get update
sudo apt-get install xdotool

echo $DISPLAY

# 获取鼠标位置
xdotool getmouselocation

xdotool search --name "fei"

xdotool getwindowname 35651587

xwininfo -id WINDOW_ID

【Software Testing】App 自动化测试框架

iOS