APP自动化测试

【APP自动化测试】一、什么是自动化测试,了解自动化测试
所谓的自动化测试就是前期通过人肉编码,完成测试框架,后期解放双手自动完成规定的测试流程。
自动化测试主要分为三层:UI层、接口层、单元层。
移动端、web端通常所说的自动化测试是指UI层测试,基本原理就是:基于页面元素的识别和定位来模拟用户行为,首先识别到某个元素,比如一个按钮,然后定义一个动作,比如点击,这样就通过代码模拟完成了一次按钮的点击,代替了人工去点击。如果后期再加入数据驱动和Page Object思想就基本可以形成一个UI层自动化测试框架了。
目前我觉得UI层测试有以下几点问题:
版本迭代UI变化太快,导致脚本也需要不断的更新,目前在泰然金融项目中,只针对主流程编写了测试脚本,UI变化带来的问题暂未体现。
见效慢,初期还是有一定的学习成本,包括搭建环境,编写脚本,熟悉测试框架以及设计模式。但是我相信后期自动化测试带来的效果也是非常可观的。
APP端、web端编码可能不够规范,导致很多元素定位和识别非常困难。
总的来说UI自动化测试可能更适合于主流程的测试,就是一些非常重要并且不会频繁变化的流程,对主流程做自动化回归测试,可以有效避免线上重要功能出现bug。
常见自动化测试方案介绍:
iOS:
iOS测试分为UI和Unit测试,Unit测试一般就是用代码检测代码,因此Unit测试比较适用于一些复杂代码的检查验证,以及一些暴露在.h中的方法;UI测试就是上文所描述的。
iOS UI测试的一些常见方案:
KIF 全称是Keep it functional。它是一个建立在XCTest的UI测试框架,通过accessibility来定位具体的控件(所以在编码的时候一定要设置AccessibilityLabel和AccessibilityTrait),再利用私有的API来操作UI。由于是建立在XCTest上的,所以你可以完美的借助Xcode的测试相关工具(包括命令行脚本),去模拟用户输入来测试。同时也支持UIWebView的测试。
Frank 使用Ruby语言,开源内嵌Server型,通过注入Server到APP使用API,通过Server对外通信完成UI操作。支持CI持续集成,不支持UIWebView,要求测试时在应用程序内部编译。
Appium 一个开源的、跨平台的自动化测试工具,支持IOS、Android和FirefoxOS平台。
EarlGrey Google推出的iOS功能性UI测试框架,其所提供的主要特性:强大的内建同步机制,测试会在与UI进行交互前自动等待动画、网络请求等事件。
Android:
Android平台的自动化测试一般分为2个方向:
Android端的自动化测试框架
Espresso 是 Google 针对 Android 平台开源的一款 Android 自动化测试框架,主要是用于 Android App UI 自动化测试。
UI Automator
Appium
Monkey
MonkeyRunner
Robotium
Ronaorex
TestBird
(若有兴趣,请自行搜相关文档了解)
各大云测试平台(腾讯优测云测、HUAWEI开发者联盟、贯众云测试、Testin云测)
二、Appium
为什么选择Appium
Appium是一个开源、跨平台的自动化测试工具,同时支持iOS、Android、H5,接口基本一致,减少开发维护成本;
可以使用多种语言编写测试脚本(如:Ruby、C#、Java、JavaScript、OC、PHP、Python等语言);
不需要重新编译应用就可以进行测试;
不依赖项目源代码;
社区活跃,文档健全;
Appium采用Client-Server的架构设计,并采用标准的HTTP通信协议;Server端负责与iOS、Android原生测试框架交互,无需测试人员关注细节实现;
Client端基本上可以采用任意主流编程语言编写测试用例,减少了学习成本;
Appium相关概念
Client/Server Architecture:Appium是用Node.js编写的服务器,可以使用npm安装,也可以直接安装GUI工具(Appium Desktop)。Server的功能其实就是:监听一个端口,然后由Client端发来指令,将这些指令转成移动设备或者浏览器可以理解的的形式,然后由设备执行这些指令,最后把执行结果返回给Appium Server,并在Client端展示结果。Client是发起指令的设备,一般就是指测试脚本的运行环境,也就是代码,只要实现了WebDriver标准协议就可以,可以是Java、Ruby、Python、JS、OC等语言编写的代码。
Session:自动化始终围绕一个Session进行,客户端初始化一个session来与服务端交互,不同的语言最终都是给服务端发送一个JSON对象,也就是Desired Capabilities,然后服务端就会开启一个自动化的session,并返回一个session id,后续所有的请求都会带上使用这个session id。
Desired Capabilities:以key-value的形式,将配置信息转换成json对象传输给服务端,还有一个重要的作用就是告诉Server本次测试的设备环境,比如iOS、Android还是浏览器。
Appium-Server:通过npm install -g appium安装了appium之后,在命令行输入appium,就是启动了appium server
Appium-Client:appium客户端有很多语言库,Java、Ruby、Python、PHP、JS、C#、OC...这些库都实现了Appium对WebDriver协议的扩展,加入了一些方便的方法,比如swipe之类,Appium Client让我们可以更方便的写出可读性更好的测试用例。
Appium.app/.exe:分别是Mac、Windows系统下的可视化工具,可以直接查看页面的UI结构,还可以录制用户行为生成相应的测试脚本代码,对于元素定位有很大的帮助。
Appium Inspector:用例查看APP的元素结构与基本信息,还可以与元素交互,在Appium GUI工具中可以直接使用,如下图。
WebDriverAgent:Facebook推出的一款iOS移动测试框架,在iOS端实现了一个WebDriver Server,借助这个Server可以远程控制iOS设备,可以启动、关闭应用,点击、滚动视图,或者确定页面展示是否正确。支持iOS模拟器和真机。
Appium工作原理
以Mac系统为例,使用Java(java-client)编写Appium自动化测试脚本并执行,首先会请求Appium-Server,然后Server经过解析,驱动iOS/Android模拟器或者设备来执行Appium自动化脚本,Windows平台原理类似。
Appium环境搭建
目前我们是搭建了一套Appium+Java+Windows/Mac+Android Studio环境(Mac环境搭建步骤),IDE使用Android Studio,也可以用IntelliJ IDEA、Eclipse,使用Java编写测试脚本。
(Windows系统教程:https://www.testwo.com/blog/8000)
(Mac系统教程:https://juejin.im/post/5b2f291ce51d4558d217d5f6)
三、编写自动化测试脚本
元素定位
appium一些常见的定位方式(复杂元素可以配合Inspector查找):
cssSelector # Selenium 最强大的定位方法,比 xpath 速度快,但比 xpath 难上手
linkText # 链接元素的全部显示文字
partialLinkText # 链接元素的部分显示文字
name # 元素的 name 属性,目前官方在移动端去掉这个定位方式,使用 AccessibilityId 替代
tagName # 元素的标签名
className # 元素的 class 属性
id # 元素的 id 属性
xpath # 比 css 定位方式稍弱一些的定位方法,但胜在容易上手,比较好使用,缺点就是速度慢一些。
AccessibilityId # Appium 中用于替代 name 定位方式
AndroidUIAutomator # Android 测试,最强大速度最快的定位方式
iOSNsPredicateString # iOS 谓词的定位方式,仅支持 XCTest 框架,需大于 iOS 9.3或以上
IosUIAutomation # iOS 谓词的定位方式,仅支持 UIAutomation 框架,需大于 iOS 9.3或以下
iOSClassChain # 国外大神 Mykola Mokhnach 开发类似 xpath 的定位方式,仅支持 XCTest 框架,,不如 xpath 和 iOSNsPredicateString 好
windowsAutomation # windows 应用自动化的定位方式
className
使用元素的className属性定位,适用于iOS、Android
driver.findElementByClassName("XCUIElementTypeButton");
id
使用元素的resource-id属性定位,适用于Android4.2以上版本,定位简洁有效,推荐使用。
driver.findElementById("toolbar_back_btn");
xpath
iOS、Android都支持,定位速度非常慢,除非万不得已不要使用,官方也不推荐使用,但是appium框架还是支持xpath的,毕竟很多元素只能使用xpath定位。
比如金融登录页面,手机号输入框,使用xpath定位,寻找元素,并且输入手机号这个流程大概需要24秒;使用className执行这个流程只需要7秒左右。
driver.findElementByXPath("(//XCUIElementTypeOther[@name=\"确认无误\"])[2]");
xpath定位分为4种:
1.使用绝对路径定位(不推荐):
driver.findElementByXPath("className/className/className....")
2.使用相对路径定位:
driver.findElementByXPath("//className")
3.使用元素索引定位:
driver.findElementByXPath("//className[index]")
4.使用元素属性定位:
driver.findElementByXPath("//className[@label="确定"][@enable=true]")
AccessibilityId
替代name属性的定位方式,在iOS上主要是元素的label和name属性,在Android上是content-desc属性,如果label/name/content-desc为空,则不能使用AccessbilityId定位元素
driver.findElementByAccessibilityId("获取验证码");
AndroidUIAutomator
仅支持Android4.2以上系统,可使用元素的单个或者多个属性定位,支持以下属性定位:
index(int index)
text(String text)
resourceId(String id)
className(String className)
packageName(String packageName)
description(String desc)
checked(boolean val)
clickable(boolean val)
enabled(boolean val)
longClickable(boolean val)
password(boolean val)
selected(boolean val)
instance(int val)
# 其他一些详细方法(包括正则表达式匹配),请查看 Android 源码中,UiSelector 类定义的方法
例子:
MobileBy.AndroidUIAutomator("new UiSelector().text(\"确定\").clickable(true)")
iOSNSPredicate
仅支持iOS,可使用元素的单个或者多个属性定位,详细请参考iOSNSPredicate定位
手势操作
Appium提供了点击tap()、滑动swipe()、缩小pinch()、放大zoom()、移动move()等手势操作API。
设计模式
Appium通常使用Page Object设计模式,将每一个测试页面抽象为1个Page类,并在该类中封装了本页面的测试对象和基本的测试步骤,以提高代码的可读性复用性通用性和一致性。使用Page Object模式的项目结构如下图所示:


    推荐阅读