一、背景
一年前,我们一直在用monkey进行Android 的稳定性测试 ,主要目的就是为了测试app 是否会产生Crash,是否会有ANR,页面错误等问题,在monkey测试过程中,实现了脱离Case的依赖,但是monkey测试完全随机、不可控,并且只支持Android系统,不支持iOS系统;然而在我们不断的实践中发现,monkey测试已经不能满足于我们的部分业务需求,比如说我们想让稳定性测试更灵活、跨端支持iOS、日志可读、定向场景设计、测指定页面的稳定性、报告清晰展示遍历结果等等,monkey在这些方面的实现局限性很大,经过我们调研发现开源工具appcrawler已然支持这些方面,在我们最近几个版本的appcrawler使用过程中,能够满足我们复杂的业务测试需求,弥补了monkey测试的不足,下面我详细的介绍这个自动化UI遍历工具-appcrawler。
二、appcrawler UI自动化遍历工具介绍
appcrawler,使用Scala编程语言运行在JVM上,它是基于app爬虫的思想,逐渐形成了一种自动化测试方法称为“UI遍历”,其主导思想是尽可能多的去操作被测app的界面元素,每个元素至少操作一遍。支持android和iOS,支持真机和模拟器,最大的特点是灵活性,可通过配置来设定遍历的规则,用于自动化回归测试,实现对整个APP的所有可点击元素进行遍历点击。
自动遍历的价值
- 回归测试,遍历基本的界面,了解主要界面的可用性,比如兼容性,基本功能;
- 利用遍历获取app的加载时间和性能数据,需要借助其他的性能数据抓取工具,比如OneApm,NewRelic;
- 利用遍历验证app的内存泄漏以及稳定性等功能,需要借助LeakCanary和MLeaksFinder;
- UI diff 验证新老版本的功能差异,并识别细节的问题;
- 抓取接口请求 辅助验证一些模块基本接口,并辅助分析接口调用流程,为接口测试做准备;
三、为什么用这个工具
- 支持android和iOS,支持真机和模拟器;
- 可通过配置来设定遍历的规则(比如设置黑名单和白名单,提高遍历的覆盖率);
- 其本身的遍历深度覆盖较全,比如它拥有APP的dom树,根据每个activity下的可点击元素逐个点击,比monkey更具有规律性,覆盖更全面;
- 生成的报告附带截图,可以精确看到点击了哪个元素及结果,对crash类的问题定位清晰;
- 各大云市场上自动遍历功能都多有限制企业无法*定制.;
- 解决monkey等工具可控性差的缺点;
- 发现深层次的UI兼容性问题;
- 通过新老版本的diff可以发现每个版本的UI变动范围;
四、设计理念
appcrawler UI遍历基于app爬虫思想,为了更好的认识app爬虫,这里先介绍一下网络爬虫,在了解网络爬虫框架之后,您将会对app爬虫有一个清晰的认知。
网络爬虫
通用网络爬虫又称全网爬虫(Scalable Web Crawler),爬行对象从一些种子 URL 扩充到整个 Web,主要为门户站点搜索引擎和大型 Web 服务提供商采集数据。这里主要对爬虫以及抓取系统进行一个简单的概述。
一、网络爬虫的基本结构及工作流程
一个通用的网络爬虫的框架如图所示:
网络爬虫的基本工作流程如下:
1.首先选取一部分精心挑选的URL放入种子URL队列中;
2.将种子URL队列中URL放入待抓取URL队列;
3.从待抓取URL队列中取出待抓取的URL,解析DNS,并且得到主机的ip,并将URL对应的网页下载下来,存储进已下载网页库中。此外,将这些URL放进已抓取URL队列。
4.分析已抓取URL队列中的URL,分析其中的其他URL,并且将URL放入待抓取URL队列,从而进入下一个循环。
抓取策略:
在爬虫系统中,待抓取URL队列是很重要的一部分。待抓取URL队列中的URL以什么样的顺序排列也是一个很重要的问题,因为这涉及到先抓取那个页面,后抓取哪个页面。而决定这些URL排列顺序的方法,叫做抓取策略。下面介绍两种常见的抓取策略:
1.深度优先遍历策略
深度优先遍历策略是指网络爬虫会从起始页开始,一个链接一个链接跟踪下去,处理完这条线路之后再转入下一个起始页,继续跟踪链接。我们以下面的图为例:
遍历的路径:A-F-G E-H-I B C D
2.广度优先遍历策略
广度优先遍历策略的基本思路是,将新下载网页中发现的链接直接插入待抓取URL队列的末尾。也就是指网络爬虫会先抓取起始网页中链接的所有网页,然后再选择其中的一个链接网页,继续抓取在此网页中链接的所有网页。还是以上面的图为例:
遍历路径:A-B-C-D-E-F G H I
app爬虫
app爬虫比web端更容易抓取,大部分也都是http/https协议,返回的数据类型大多数为json。也就是指app爬虫会先抓取启动app后初始页面的所有URL,然后再选择其中一个URL进行抓取,然后读取URL、解析URL、执行URL,下面对app爬虫做详细的概述。
一个app爬虫的基本结构及工作流程、通用的app爬虫的框架如图所示:
为了更好的理解app爬虫思想,下面app爬虫的工作流程中,括号中内容时结合业务做的解述。
app爬虫的基本工作流程如下:
1.进入app,首先获取当前BaseURL,支持类型:http、https、ftp、file(比如启动百度外卖app后有N个url);
2.将这些URL放入待抓取的队列(待抓取即待遍历,也就是说有些元素点击后会生成新的url);
3. 从待抓取的队列中取出即将抓取(待遍历)的URL,读取URL,并解析attribute、Label、name放入堆栈中;
4.遍历(执行)已抓取URL中的所有元素,分析当前URL队列是否包含baseURL,如果包含则清空堆栈记录重新计数(分析其中的其他URL,并将URL放入待抓取(待遍历)的URL队列中,从而进入下一个循环),如果不包含,则使用当前页面,不再记录堆栈;
抓取策略:
appcrawler中的采取的抓取策略是:深度优先策略(其中遍历深度可配置)
五、appcrawler技术要点解析
5.1 appcrawler和appium 的关系
5.1.1 appium支持
appcrawler在selenium2.0支持的基础上做了一个针对appium的封装,类名叫MiniAppium,他具有如下的特色。
- 设计极简,除了selenium的自身支持外,增加了几个API用于app的测试;
- 封装了appium命令的启动停止
- 强大的断言
5.1.2 AppiumClient.Scala负责与appium交互
1.监听appium进程的信息(执行成功,执行失败,停止等),从appium获得包名和activity
2.通过xpath找到组件,对重名的id只使用第一个。每隔5秒找一次,找10次后如果还找不到,则放弃
3.对组件的操作(如:滑动,点击,长按等)进行定义,动作是随机取的(类似monkey,方法名也叫monkey),位置信息用的是通过xpath找到的x,y坐标
4. 对每次操作之后的界面截屏(如果界面改变的话)
5.获取页面结构(最多3次)解析xpath的时候拿到一个节点树,对树中所有节点遍历,具体实现在TreeNode.scala和Tree
5.1.3 appium关键字
在selenium支持的基础上只增加了少数几个方法.:
see:元素定位与属性提取
tap:点击
send:入文本
swipe:滑动
原来scalatest的selenium的支持仍然全部可用. 比如click on id("login")
具体用法如下:
1. see()
唯一的元素定位API,see是引用了<阿凡达>电影里面一句台词"I See You",它的作用是当你看到一个控件, 你应该可以根据看见的东西就可以定位它,并获取到这个控件的属性, 无须借助其他工具或者使用findElementByXXX之类的函数,比如有个Button, 名字是"登录",它的id是account,定位它可以通过如下多种方式的任何一种:
• see("登录")
• see("登")
• see("录")
• see("account")
• see("acc")
• see("//UIAButton[@id="account"]")
• see("screen_name")("text")
• see("screen_name").nodes.head("text")
• see("action_bar_title")("text") 文本
• see("action_bar_title")("tag") 类型
• see("action_bar_title")("selected") 是否选中
如果当前界面中存在了有歧义的空间,比如其他一个名字为"登录"的输入框, 那么上述定位方法中定位中两个控件的定位方法会失败, 你需要自己调整即可,这就是关于元素定位你只需要用see这个方法即可。
2. 动作 tap send swipe
目前只封装了3个动作. tap 、send 、swipe.
see("输入手机号").send("13067754297")
see("password").send("xueqiu4297")
see("button_next").tap()
支持链式调用. 当然不推荐日常使用
//对三次连续出现的tip控件点击三次.
see("tip").tap().tap().tap()
see("输入手机号").send("13067754297").see("password").send("x297")
3. 断言
支持标准的scalatest的should风格的断言,支持两种风格的断言
assert风格
assert(2>1)
5.2 测试执行
1.定义URL
- 界面唯一性:每个screen都有一个唯一的id,这样如果在报错的截图中就可以很容易找到那个url,如下图所示
- android的url默认为当前的activity名字
- iOS没有activity概念,默认使用当前页面dom的md5值的后五位作为标记,如果页面不变,那么这个md5值也不会变
- 也可以自己指定某些特征作为url,比如title或者某些关键控件的文本
- 控件的唯一性取决于这个url和控件自身的id name tag text loc等属性
- 比如一个输入框id=input,在多个页面中都出现了
- 如果url为空,那么它只会被点击一次
- 如果url设置为当前activiy的名字,那么有多少页面包含它他就会被点击多少次
- url的定义是一门艺术,可以决定如何优雅的遍历
2.遍历控制
遍历控制依赖于项目目录下的配置文件Baiduwaimai.yml, 里面有详细的注释解释每个配置项的作用
3.如何写配置文件Baiduwaimai.yml(运行的核心所在)
配置文件基本都是以key-value格式,所以可以用文本编辑器,然后改名为 .yml或者.json文件即可。这里展示一下百度外卖app的配置文件 Baiduwaimai.yml部分内容:
后退标记back
android默认是back键,不需要设定.
iOS上没有back键,需要自己指定,通过xpath定位方式指定遍历完所有控件应该点击什么控件返回
黑名单black
控件黑名单为black方法,他会绕过id name或者text中包含特定关键词的控件
url黑名单可以绕过特定的activity
遍历的行为控制
整体的配置项应用顺序为:
capability
androidCapability和iosCapability分别用来存放不同的平台的设置,最后会和capability合并为一个
startupActions
用于启动时候自定义一些划屏或者刷新的动作
selectedList
- 适用于在一些列表页或者tab页中精确的控制点击顺序
- selectedList表示要遍历的元素特征
- firstList表示优先遍历元素特征
- lastList表示最后应该遍历的元素特征
- tagLimit定义特定类型的控件遍历的最大次数. 比如列表项只需要遍历少数
- 需要注意的是firstList和lastList指定的元素必须包含在selectedList中
元素定位的方法
appcrawler大量的使用XPath来表示元素的范围,大部分的选项都可以通过XPath来指定范围,比如黑白名单,遍历顺序等
4. 点击前后截图
URIElementStore.scala负责记录控件是否被点击
1.使用枚举类型,Clicked表示已遍历,Skiped = Value表示跳过
2.使用elementStore(Map类型)存储被点击的组件列表。URIElement.scala用来代表唯一的控件,每个特定的命名控件只被点击一次, 所以这个element的构造决定了控件是否可被点击多次,如果组件url=baiduwaimai,key只有1个,所以只能点一次。如果组件url=baiduwaimai/xxxActivity,由于可能是不同Activity中的,所以可以点击多次
截图加红框是如何实现的?
appcrawler使用了java的ImageIO库, 可以对已有的图片进行标记, appcrawler在点击前会先识别元素的位置,并加上一个红框用于提示.。
5.3 跨平台
Android UI遍历
1.启动appium
appium --session-override
2.启动appcrawler UI遍历
java -jar appcrawler-2.1.1.jar -a bdwm.apk -o demo/ --capability appActivity=.view.WelcomeActivityAlias
3.配置文件的运行方式
java -jar appcrawler-2.1.1.jar -a bdwm.apk -c conf/baiduwaimai.yml
4.跳过重新安装app
java -jar appcrawler-2.1.1.jar -a bdwm.apk -c conf/baiduwaimai.yml --capability appPackage=waimai_4.11.6.apk
IOS UI遍历
模拟器运行:
1.启动appium
appium --session-override
2.启动appcrawler 开始UI遍历
java -jar appcrawler-2.1.1.jar -a bdwm.app -c conf/baiduwaimai.yml
xcode编译出来的app地址可通过编译过程自己查看
真机运行
使用xcode编译源代码, 使用开发证书才能做自动化,编译出真机可自动化的.app或者.ipa包
java -jar appcrawler-2.1.1.jar -a bdwm.ipa -c conf/baiduwaimai.yml
5.4 自定义
5.4.1 Xpath的充分利用
获取控件XPath路径的工具
uiautomatorviewer(最常用)、名字、平台
Android:只能直接生成xpath, 需要自己拼凑
iOS:inspector,只能工作在mac上,
Android和iOS控件差异
tag名字是不一样的.、控件布局不一样
android.view.View
android.widget.XXXXX
关键的定位属性也不一样
iOS:name、label、value
Android:resource-id、content-desc、text
常见xpath表达式用法
5.4.2 插件化
1.代理插件
自动获取app上每次点击对应的网络请求,支持http和https
- 安装
目前是默认自带
- 启用
在配置文件中加入插件
代理插件默认开启7771端口,配置你的Android或者iOS的设备的代理,指向你当前运行appcrawler的机器和7771端口
- 结果
在做每个点击的时候都会保存这期间发送的请求, 也就是记录前后两次点击中间的所有通过代理的请求,最后会在结果目录里面生成后缀名为har的文件
- https支持
如果要录制https,需要安装一个特殊的证书"BrowserMob Proxy",或者用burp把当前端口设置为burp的上游代理,对于一些用url中包含有ip的https请求不支持
2. Log插件
- 作用
自动记录Android的LogCat或者iOS的syslog
- 安装
目前是默认自带
- 启用
在配置文件中加入插件
"pluginList" : [
"com.testerhome.appcrawler.plugin.LogPlugin"
],
- 结果
记录一次点击事件后所发生的log记录, 并保存为后缀名为.log的文件中
3. TagLimit插件
- 作用
智能判断列表和其他的相似布局元素,只遍历前3个相似空间. 适用于微博这种无限刷新的列表, 用于节省时间,原理是利用特定元素的tag布局层级是否完全一样
- 安装
目前是默认自带.
- 启用
在配置文件中加入插件
"pluginList" : [
"com.testerhome.appcrawler.plugin.TagLimitPlugin"
],
- 结果
无
六、appcrawler使用流程
6.1 环境搭建
1. appcrawler的最新jar包(最新的功能多,兼容性比较高),目前最新的是 appcrawler-2.1.2.jar ,
2. appium环境安装
3.Android SDK,主要是为了使用tools文件夹下的 uiautomatorviewer.bat 来定位元素,获取元素的xpath,
6.2 appcrawler目录结构
6.3 执行步骤
1. 手机安装好最新的安装包,
2.开启appium服务
在命令行中输入: appium ,提示: 则开启成功
3.在放 appcrawler-2.1.0.jar 的文件夹下执行以下命令:
Java -jar appcrawler-2.1.0.jar -a bdwm.apk -c baiduwaimai.yml
或者如上目录,运行start.py 脚本
即可自动启动APP,并自动遍历点击元素
因为遍历的深度比较大,在覆盖比较全面的条件下,基本要跑2个半小时左右,截图2600+张
4.输出结果-日志和报告如下:
5. html报告:
七、目前的使用方向和收益
在每个版本的集成测试阶段,会跑3次appcrawler UI 自动遍历,整体测试方式是手工测试+自动遍历
现在我们只在android端进行UI自动遍历测试,运行2小时半左右,大约一小时截图1000张,通过截图+报告可以直观的看到哪些页面正常,哪些页面异常
利用appcrawler发现bug2个:商超方向的一些空白页面
八、工具问题分析
虽然appcrawler对我们app的稳定性测试带了很客观的收益,但是这个工具本身还是有一些不足需要改善,主要不足如下:
1. 测试速度可能比较慢,会对重复的界面进行点击
2. 每个版本的配置文件或许有不同,对比三次测试,一方面是在相似的组件中可能漏掉比较重要的组件,另一方面是为了追求测试覆盖,重复点击了相似的界面组件。两者不能很好地平衡
3. 配置文件有一定的局限性,有时不能很好地表达测试者的意图
4. 不能自动输入文本信息
九、后续TODO
后续我们会更加充分利用appcrawler,并进行二次开发,主要实现以下功能:
ios UI遍历
多端执行,多个设备同时运行
和Jenkins结合
mail通知
调研第三方云测平台