自动化测试的理想境界：AppCrawler自动遍历工具-CSDN博客

内容来源：2017 年 6 月 24 日，TesterHome联合创始人黄延胜在“Testwo第一届测试分享沙龙”进行《App crawler自动遍历工具》演讲分享。IT 大咖说（微信id：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。

阅读字数：3308 | 9分钟阅读

获取嘉宾演讲视频及PPT:

摘要

本次演讲主要围绕App Crawler来展开，介绍该工具背后的实现方法论。

开发背景

开篇先说下开发AppCrawler时候的背景，当时我是在一家互联网金融公司内，业务测试的主要痛点在于金融领域的业务变更较快，业务线众多且流程复杂，很难做到全面的覆盖。

简单介绍下常见的几个问题。比如不容易感知到股票信息中字段内容的丢失或数据异常，用户网络慢时发出请求后退出当前页面发生崩溃，某系界面在4.4和5.0的系统上操作体验不同，还有最典型的在app的某些特定页面崩溃或某接口报错。

后续我们总结分析了下这些测试的难点。首先是快速迭代导致自动化用例吃力，现有的自动化框架无法满足稳定性和易用性的要求。其次是验证的内容点太多，比如界面字段正确性、接口返回内容等都需要一一验证。另外是变更范围测试覆盖困难，因缺少对代码流和功能的关键建模，所以无法从代码层分析出可靠的变更范围。

自动化测试理想情况应该是这样的，较少的自动化代码维护，能够稳定执行，可以对众多的待验证数据进行自动验证，能够代替人自动对app的每个角落进行检查分析。总结起来有3项必要功能：自动遍历、业务建模以及数据自动对比，这些已会包含在接下来讲到的AppCrawler中。

AppCrawler

自动遍历的目标

安卓原先的自动化测试工具Monkey是通过随机的事件来遍历所有的App，其本质是健壮型测试工具只不过附带了测试页面的特性。在此基础上要做的改进有两点，一是可控，做到自定义遍历的路径，二是可定制，实现自动输入或自动滑动等。

结构分析方面我们期望有点击前后的截图对比，结构的数据建模，新老版本的UI Diff，app结构思维导图的展示。

其他框架

（现有的自动化测试框架比较）

（各框架发展趋势）

目前AppCrawler已支持appium和macaca，将来可能会支持selenium，而appium底层又包含wda、selendroid、uiautomator2。从上图中可以看到appium的增长非常迅速，这主要是因为它同时支持安卓、iOS、混合型应用以及全量的脚本语言。

这种方式其实就是协程的体系。通过提升CPU利用率，减少线程切换，进而提升程序运行效率。

延伸开来协程主要有三个特性。第一个是可控制，不同于线程协程能做到可被控制的发起子任务；第二个是轻量级，协程非常小、占用资源比线程还少，在JVM平台上它的本质就是一次方法的调用；第三个是语法糖，目前能够使用协程的语言都提供了很好的语法糖支持，使多任务或多线程切换不在使用回调语法。

使用流程

在实际应用中可以直接在测试版本上运行AppCrawler，也可以用于冒烟阶段开发人员自行测试，首先配合使用LeakCanary、Apm、Bugly、Appetizer这几个工具抓取App中的各种BUG，然后打包成DEBUG版本交给遍历工具。执行测试之后能够探测出内存泄露和健壮性，回归大部分的流程，老版本做diff对比分析。

上图是执行AppCrawler之后安卓的效果图。左下方的列出的是所有能遍历到的界面，选中其中某一个就会在右侧显示出具体界面和点击的控件。左上方展示的是不同解析状态的次数。

这是跑完之后另外的数据文件，他们被统一存放在一个目录下。文件名包含着关键信息，序号表示第几次点击，后面紧随的是点击的页面名、控件，处于点击前后的哪个状态。

Diff对比

上面列出的是关于diff对比的相关命令，candidate参数是当前的测试报告，master参数上一轮app的测试报告。

这是新老版本的UI Diff报告，每一处变更都会有一条信息展现，如图中红线框出的。如果不想检测某种变更，可以通过黑名单屏蔽掉该字段，便于过滤大量属于正常变更的情况。

自动化支持（实验性支持）

目前自动化还处于实验阶段，通过yaml来配置，主要有这几个关键参数。AutoCrawl是否自动化后执行遍历，name测试用例名字，xpath定位操作，then断言。

技术原理剖析

技术点

对跨平台的支持是基于Appium。配合Yaml来使用更简化的方式写配置文件。采用以自动遍历为核心功能点，在此之上提供简单的自动化框架支持的自动化策略。支持插件机制便于开发与扩展。

与传统WebDriver的不同点

传统WebDriver所有的元素都要根据id、name、xpath进行定位，然后再做截图、点击之类的操作。AppCrawler是先getPageSource获取所有的元素列表，再直接在列表中分析xpath得到真正的定位符，也就是说即使是使用id、name的定位方式在AppCrawler中速度都是一样的。另外截图时增加了对选择控件的高亮区分，自动化机制的策略相对宽松。

Xpath定位方式

Xpath支持多种匹配特性，常规的xpath方式例如*[@resource-id=”xxx”]，也可以使用正则例如“^确定&”。更夸张的是包含的方式，直接输入控件包含的字段就可以直接定位，比如通过输入“密码”定位到密码输入框。

自动遍历过程

自动遍历的第一步是获取信息，把当前app的界面dump为xml结构。然后判断是否还在当前app，否则后退backApp backButton，一直退到app内。

重点是获取待遍历的元素，使用“//*”这个Xpath表达式可以找出所有的控件。之后通过selectList 设置要测试的控件进行第一步操作，第二步通过blackList过滤黑名单、小控件或不可见控件，第三步重排控件顺序以确定点击流程，第四步通过tagList跳过已点击或限制点击的控件，最后根据匹配的规则执行action。

以上步骤做完之后，再在新的页面中循环执行。

Action支持列表

Action默认支持back（后退）、backApp、monkey（随机事件）。其中backApp一般情况下等价于back，不过是可定制的，比如某些场景下不能通过back直接回到App中，此时可以自定义逻辑想办法回去。另外对于像“xxx（）”这样的形式会被认为是可运行的Java编程语句，比如Thread.sleep(3000)、driver.swipe(0.9, 0.5, 0.1, 0.5)。如果非以上所有行为会被认为是输入。

收益

实现基础功能的回归测试，节省了很大的工作量。可以通过截图观察app流程正确性，基于UI diff对比功能正确性。能够结合LeakCanary MLeakFinder发现大部分的内存泄露以及低级的异常和健壮性问题。

自动遍历的优缺点

自动遍历并非银弹，它仅能解决整个测试环节中的80%，包括自动化的路径探索测试、回归测试、冒烟测试，这些可以用自动化来代替人工。但是剩下的20%还需要手工测试，比如新功能的业务流程，需要定制化的复杂操作或业务逻辑。

这种自动遍历方式的潜力无疑是巨大的。除开老的功能回归之外，还可以做异常场景和性能的自动遍历，有更强大的自动化框架BDD加改进特性支持。还有个重点——测试分析，之前提到的UI diff就是一种简单的分析策略，其实在拿到新旧版本的不同数据的时候还可以做更深入的挖掘，比如通过一定的方法分析股票涨跌幅是否满足特定特征。