APPcrawler基础原理解析及使用

一、背景

一年前，我们一直在用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 验证新老版本的功能差异，并识别细节的问题；
• 抓取接口请求 辅助验证一些模块基本接口，并辅助分析接口调用流程，为接口测试做准备；

三、为什么用这个工具

1. 支持android和iOS，支持真机和模拟器；
2. 可通过配置来设定遍历的规则（比如设置黑名单和白名单，提高遍历的覆盖率）；
3. 其本身的遍历深度覆盖较全，比如它拥有APP的dom树，根据每个activity下的可点击元素逐个点击，比monkey更具有规律性，覆盖更全面；
4. 生成的报告附带截图，可以精确看到点击了哪个元素及结果，对crash类的问题定位清晰；
5. 各大云市场上自动遍历功能都多有限制企业无法自由定制.；
6. 解决monkey等工具可控性差的缺点；
7. 发现深层次的UI兼容性问题；
8. 通过新老版本的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通知

调研第三方云测平台

时间： 2017-12-04

Tags: 测试, 插件, 配置, android, ios, url, 测试技术, Monkey

APPcrawler基础原理解析及使用的相关文章

Android代码入侵原理解析(一)

Android代码入侵原理解析(一)           1.代码入侵原理 代码入侵,或者叫代码注入,指的是让目标应用/进程执行指定的代码.代码入侵,可以在应用进行运行过程中进行动态分析,也是对应用进行攻击的一种常见方式.我把代码入侵分为两种类型:静态和动态.静态代码入侵是直接修改相关代码,在应用启动和运行之前,指定代码就已经和应用代码关联起来.动态代码入侵是应用启动之后,控制应用运行进程,动态加载和运行指定代码. 2.静态代码入侵 静态代码入侵,有直接和间接的手段. 直接手段是修改应用本身代码

秋色园QBlog技术原理解析：性能优化篇：字节、缓存、并发(十二)

文章回顾: 1: 秋色园QBlog技术原理解析:开篇:整体认识(一) --介绍整体文件夹和文件的作用 2: 秋色园QBlog技术原理解析:认识整站处理流程(二) --介绍秋色园业务处理流程 3: 秋色园QBlog技术原理解析:UrlRewrite之无后缀URL原理(三) --介绍如何实现无后缀URL 4: 秋色园QBlog技术原理解析:UrlRewrite之URL重定向体系(四) --介绍URL如何定位到处理程序 5: 秋色园QBlog技术原理解析:Module之页面基类设计(五) --介绍创建

秋色园QBlog技术原理解析：性能优化篇：access的并发极限及超级分库分散并发方案(十六)

上节回顾:   上节 秋色园QBlog技术原理解析:性能优化篇:数据库文章表分表及分库减压方案(十五) 中, 介绍了 秋色园QBlog 在性能优化方面,从技术的优化手段,开始步入数据库设计优化,并从数据的使用情况上进行了分析,从而将文章内容进行分离,得到新的分表,由于内容比较大,进而分了库,达到一种基础减压.   本节内容:   本节将介绍秋色园 QBlog 的Super分库方案,以及何以如此Super分库的原因.   描述说明:   在进行上了上节的分库方案后,虽然感觉一度秋色园QBlog的访

秋色园QBlog技术原理解析：性能优化篇：数据库文章表分表及分库减压方案(十五)

文章回顾: 1: 秋色园QBlog技术原理解析:开篇:整体认识(一) --介绍整体文件夹和文件的作用 2: 秋色园QBlog技术原理解析:认识整站处理流程(二) --介绍秋色园业务处理流程 3: 秋色园QBlog技术原理解析:UrlRewrite之无后缀URL原理(三) --介绍如何实现无后缀URL 4: 秋色园QBlog技术原理解析:UrlRewrite之URL重定向体系(四) --介绍URL如何定位到处理程序 5: 秋色园QBlog技术原理解析:Module之页面基类设计(五) --介绍创建

Java类加载原理解析

1       基本信息 摘要: 每个java开发人员对java.lang.ClassNotFoundExcetpion这个异常肯定都不陌生,这背后就涉及到了java技术体系中的类加载.Java的类加载机制是java技术体系中比较核心的部分,虽然和大部分开发人员直接打交道不多,但是对其背后的机理有一定理解有助于排查程序中出现的类加载失败等技术问题,对理解java虚拟机的连接模型和java语言的动态性都有很大帮助. 由于关于java类加载的内容较多,所以打算分三篇文章简述一下: 第一篇:java类

iptables系列之基础原理+基础应用+显示扩展

一.防火墙基础原理 1.防火墙是什么?隔离本地网络与外界网络之间的一道防御系统 通俗的说,防火墙就是防火的墙,主要目的就是隔离火并建立安全区域,所以防火墙对于互联网或计算机而言 可能是工作在主机或网络的边缘(计算机的边缘可能是一块网卡,而网络边缘可能是路由),对于进出数据的报文事先定义好的规则中的标准进行检查.监控,一旦符合标准的话,我们就采取由这个规则定义的处理动作,我们称为主机防火墙或网络防火墙 linux:网络防火墙,有两组框架,实现防火功能的主要是netfilter  netfilter

Skinned Mesh原理解析和一个最简单的实现示例

Skinned Mesh原理解析和一个最简单的实现示例   作者:n5 Email: happyfirecn@yahoo.com.cn Blog: http://blog.csdn.net/n5 2008-10月   Histroy: Version:1.01  Date:2008-11-01        修改了一些不精确的用语 Version:1.00 Date:2008-10-19     讲述骨骼动画的资料很多,但大部分都是针对DX8或DX9的SkinnedMesh进行讲解.我觉得对于骨

[IT]JSONP跨域的原理解析

JavaScript是一种在Web开发中经常使用的前端动态脚本技术.在JavaScript中,有一个很重要的安全性限制,被称为"Same-Origin Policy"(同源策略).这一策略对于JavaScript代码能够访问的页面内容做了很重要的限制,即JavaScript 只能访问与包含它的文档在同一域下的内容. JavaScript这个安全策略在进行多iframe或多窗口编程.以及Ajax编程时显得尤为重要.根据这个策略,在baidu.com下的页面中包含的JavaScript代码

Android中微信抢红包插件原理解析及开发思路_Android

一.前言 自从去年中微信添加抢红包的功能,微信的电商之旅算是正式开始正式火爆起来.但是作为Android开发者来说,我们在抢红包的同时意识到了很多问题,就是手动去抢红包的速度慢了,当然这些有很多原因导致了.或许是网络的原因,而且这个也是最大的原因.但是其他的不可忽略的因素也是要考虑到进去的,比如在手机充电锁屏的时候,我们并不知道有人已经开始发红包了,那么这时候也是让我们丧失了一大批红包的原因.那么关于网络的问题,我们开发者可能用相关技术无法解决(当然在Google和Facebook看来的话,他们

【Alljoyn】Alljoyn学习笔记五 AllJoyn开源技术基础概念解析

AllJoyn开源技术基础概念解析 摘要: 总线(Bus) 实现P2P通信的基础 AllJoyn 的底层协议类似于D-Bus,相当于是跨设备分布式的 D-Bus 总线附件(Bus Attachment) 每一个连接到总线上的Alljoyn应用程序被称为总线附件,可用C++或Java编写 每个总线附件 ... 总线(Bus) 实现P2P通信的基础 AllJoyn 的底层协议类似于D-Bus,相当于是跨设备分布式的 D-Bus总线附件(Bus Attachment) 每一个连接到总线上的Alljoy