Andriod 自动化测试研究方向

前言

孔子曰：“工欲善其事，必先利其器”，我来云：“工欲利其器，必先知其理”。我们无论学习任何新事物，都要尽量做到“知其然知其所以然”，对于 Andriod 自动化测试知识学习同样如此。虽然今天谷歌、网易、淘宝已经给我们展示了他们堪称完美的 Andriod 自动化测试技术应用或解决方案，但仍美中不足，也正是有了这些美中不足的缺陷，才使得我们将“上下而求索”，去找寻真正完美的 Andriod 自动化测试方案。

By hexieshangwang

一、Andriod 自动化竞品分析

1、工具集优劣对比

Monkey：它是一个命令行工具，直接运行在模拟器里或实际设备的 adb shell 中。它向系统发送伪随机的用户事件流，实现对正在开发的应用程序进行压力测试。它提供了大约 4 类选项，即基本配置选项（如设置尝试的事件数量）、运行约束选项（如设置只对单独的一个包进行测试）、事件类型/频率、调试选项。

分析：这类测试属于随机测试，不具备软件测试的“可控性”特点，但是它作为压力测试还

是一个“好帮手”。

MonkeyRunner：它使用 Python 语言编写，调用 Andriod API 实现自动化。它具备以下特性：

多设备控制（可以跨多个设备或模拟器实施多机型测试）、功能测试自动化（提供按键或触摸事件输入和截屏对比）、回归测试自动化（运行应用程序并将其结果截屏与既定已知正确的结果截屏对比）。

分析：虽然 Python 是一种面向对象、直译式程序设计语言，学习门槛较低，但其代码调试和问题定位对于任何一个初学者来说，都是一个很大的挑战。不过能看出来，它在功能测试/回归测试/兼容性测试时可派上用场。

Instrumentation：它是执行 application instrumentation 代码的基类。当应用程序运行的时候 instrumentation 处于开启，Instrumentation 将在任何应用程序运行前初始化，可以通过它监测系统与应用程序之间的交互。所以，可以把它理解为 Andriod 所有交互事件的监听器。我们可以通过它对 Andriod 自动化测试需求进行自定义。

推荐：这要求大家需要有一定的 Andriod 基础开发知识，同时还需要大家从 Andriod 的FrameWork 层去理解 Activity 的生命周期和运行原理。最重要的是要求大家具备自动化测试框架的搭建能力。据了解，淘宝无线的童鞋们也就是从这里发现 Andriod 自动化测试的灵感和源泉的。

2、应用框架优劣对比



分析：谷歌的 Robotium 无法对 WebView 进行操作（网易的 TestNG+NativeDriver 存在同样的问题），且 Robotium 提供的 API 是面向过程的，测试代码的可扩展性差。看似淘宝的 TMTS可扩展性强大些，但相比之下也存在一定局限性，目前无法支持跨应用测试、稳定性差，同时信息捕获的正确性和及时性还有待完善。

二、Andriod 自动化应用新天地（后续研究方向）

1、Android Scripting Environment

ASE 将脚本语言带入 Android，允许用户编辑和执行脚本，直接在 Android 设备上运行交互式解释器。脚本将能大幅度简化任务界面，用户能在交互式终端中使用脚本。ASE 目前支持 Python，Lua 和 BeanShell，未来将加入对 Ruby 和 JavaScript 的支持。

2、HP 移动性能测试工具

LoadRunner 11 Patch 3开始支持 Mobile TruClient 了，这个协议能让你使用 LoadRunner的 Ajax TruClient 技术来录制用户在基于浏览器的移动应用程序上的行为。不过现在官方限制了下载补丁，需要 Contract identifier(SAID)了，发文时可用 Loadrunner 11中文版

下载地址及补丁。如果你在使用以前的 LoadRunner 而不能使用 Mobile TruClient，你可以看基于模拟器的解决方案：Recording and Performance testing Android applications with HP Loadrunner VuGen 和真实设备的解决方案：Recording mobile device traffic for performance testing iPhone, iOS, Android and Windows Mobile applications with HP Loadrunner。

三、TMTS（TaoBao Mobile Test Studio）解读

TMTS 框架主要思想就是通过反射机制调用 Android 框架层 API 拿到当前 Activity 的所

有 View，在此基础上返回需要获得的 View 对象，对获得的 View 通过 Instrumentation 封装

一些此 View 常用的操作，最后返回，这就是 TmtsView 及其子类。



1、PC 端

PC 端提供工具集 TmtsToolkit。它负责测试用例的执行和测试结果的收集，包括 instrument

日志，TmtsFramework 生成的 xml 详细日志，及方便排查问题的截图。

Instrument Runner 借鉴了 Athena 开源框架的执行方式，通过 adb am instrument 命令行方式逐个触发测试类中的测试方法。在测试脚本运行完后，收集命令行返回的结果，并对结果进行分析，决定 pass/fail。

Log Fetcher 读取 TmtsFramework 生成的 xml 详细日志，里面会提供比 instrument 命令行

详细很多的信息，记录测试运行的过程，和失败发生的原因及发生时间。

Screen Capture 基于 ddmlib 库，实现定时截取运行时的图片。并结合 Log Fetcher 拿到的时间信息，找出错误发生时刻的前后截图，作为错误排查的参考。

2、Device（手机端）

TmtsFramework 是脚本的基础，大致分为四块：

1) Device，提供屏幕旋转，键盘模拟等功能。

2) View，提供 TmtsView、TmtsTextView、TmtsWebView、TmtsToast 等基本控件，及

TmtsAbsListView 等容器。并提供一系列方便操作的方法。

其中 TmtsView 是基类，提供 click, focus 等基本方法。还提供进一步查找的方法。

TmtsTextView 是带文本的 view，提供 getText 和 setText 方法

TmtsWebView 提供内嵌 Web 页面的自动化功能。

TmtsToast 提供 getText 方法，返回一闪即逝的 Toast 文本。

TmtsAbsListView 为延迟加载机制提供了一些方便测试使用的方法，如 getChildByIndex,

scrollToLine 等方法会等待加载完成后再往下翻页。

3) Finder 实现所有的查找方法，返回 View 的实例。查找方式有 ById(String)、ById(Int)、

ByText、ByIndex。推荐使用 ById(String)的方式，在控件界面位置变化的时候，不需要改脚本。

4) Logger，生成详细的 xml 日志，写到 SD 卡里。比 logcat 更灵活。像运行日志，失败信

息，出错原因，都可以分标签写在 xml 里。

TestScripts 使用 TmtsFramework 提供的接口，进行自动化脚本的编写。编写采用面向对象

的方式，先通过 Finder 来定位返回一个具体的 View 的实例，再选择一个 View 的实例方法进行操作。

Instrument 的执行方式，允许对已经安装好的 Tao.apk 进行测试，方便在发布前对准备发

布的包进行验收自动化测试。保证被测的 apk 包，就是要发布的包。测试运行完后对被测包

进行 sign off，防止打包过程的失误引入故障。

3、Hudson（持续集成引擎）

1) BuildApk，用于对 Tao 应用进行每日构建和发布前构建，我们现在每天都会打 debug 版和 release 版，所用的 keystore 不一样。Debug 版用于 eclipse 调试。Daily run 的是 release

版本。

现在非开源应用多是使用混淆的方式打包的，淘宝客户端也是一样。由于混淆版无法使用

findViewById(String)的方式进行查找，给测试带来麻烦。针对混淆版，我们在打包的时候，

把 R.java 取出来，放到测试应用中编译，保证可以获得 StringID 与 IntID 的匹配关系。

2) BuildTestApk，会打包测试应用，生成测试包。如果被测开发使用混淆的话，还要引入R.java 进行打包。

3) RunTest 会把被测包 Tao.apk 和测试包 TaoTest.apk 安排到设备上，并触发 TmtsToolkit运行。运行完之后，收集运行日志。TmtsToolkit 提供 junit 格式日志方便直接与 hudson集成。

4) CreateReport 即最后的收集日志，统计结果，生成测试报表。通过邮件或旺旺消息，把每日构建的结果发送给测试和开发，如下图所示：