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

Posted by 西维蜀黍 on 2020-07-15, Last Modified on 2024-08-28

iOS

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

同时,苹果推出了一款名为 XCUITest 的新型自动化技术,从 iOS 9.3iOS 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 通过使用供应商提供的自动化框架来满足需求:

Appium 是开源的。

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

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

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

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

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

Macro Recorder

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

Reference