Android 自动化测试

功能测试

1. 单元测试常用的 Robolectric，具体实现方案是通过实现一套 JVM 能运行的 Android 代码，然后在 unit test 运行的时候去截取 android 相关的代码调用，转到他们的实现的代码去执行这个调用的过程，并且在 android 标准类基础上又丰富了很多扩展接口，这确实极大便利了单元测试过程，但是对于我们关注功能层面的测试同学确实有些麻爪啊，实践意义不是很大。

2. Monkey 是 Android 系统自带的一款稳定性测试工具，很多厂商也将其作为内置产品的稳定性验收衡量工具，他虽然简单易用方便快捷，但是正如其名一样，猴子毕竟还是猴子是无法完成确定功能用例的测试过程，遗憾啊，等着猴子进化成人吧。

3. UIAutomator 是为数不多的 Android 官方支持的自动化测试框架之一，最早发布的版本为 API Level17。作为基于控件的自动化框架，UIAutomator 确实接口明晰容易上手，基于 UIAutomator 也发展出了鼎鼎大名的 Appium 开源自动化框架，业界地位大有舍我其谁之势。然而使用 UIAutomator 的前提是可以用 UIAutomatorViewer 查看到我们预操作控件的属性信息，上面分析我们已经看到，小程序部分控件的父容器是 webview，此 webview 还非标准结构，应该是腾讯自研的 X5 内核。想用 appium UIAutomator 跑自动化的念头自此打消了。

4. 还有 Instrumentation 这种 Android 基因型测试方案可以考虑，著名的 Robotium 自动化测试框架就诞生于此，但是经过一番了解后，逐渐明白 Instrumentation 也好 robotium 也好，需要有产品源码或者签名，测试工程通常是与产品源码放在相同项目目录下，那么问题来了，谁能把微信的源码给我，签名也行啊，喂，大哥你有么？喂，喂，有人能听到吗？!@#@%&^

5. 早期还有一种通过系统提权注入实现的自动化测试能力，例如百度的 café，阿里的 arthrun，大多 copy 了 xposed 架构模式，具有强大的系统控制能力。然而试问这些框架今何在啊，原来因为 android root 难度越来愈高，到目前 6.0 版本几乎成为不可能，所以这类开源框架早在 2014 年左右就停止维护了，不靠谱靠不住，还得另谋他法。

6. 基于图像识别也有一些自动化测试框架，例如 sikuli 还有 testin 的自动化工具，然而小生之所以直接就把这类框架 pass 掉是因为这种测试脚本基本不具备扩展性，系统 ui 风格变更，想要做断言验证，以及日后用例维护等等，想都不敢想。

测试

1. monkeyandroid shell monkey -p 你想测试程序的包名 -v 500

2. Monkeyrunner python 测试

3. UiAutomator

4. adb shell 是 adbd 守护进程执行的