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

内容来源：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就是一种简单的分析策略，其实在拿到新旧版本的不一样数据的时候还能够作更深刻的挖掘，好比经过必定的方法分析股票涨跌幅是否知足特定特征。