自从我的Nexus 6加入了Android beta计划以来，我便在很早的时候就体验上了Android Nougat的一些新特性，自然也体验到了比较重要的Multi-Window新特性。不过，在当前Android Nougat普及度特别低（尤其是我的Nexus 6还没有收到官方ota）的情况下，Multi-Window的体验也大打了不少折扣。

我曾经在开发Android Application的过程中遇到过那个有名的65k方法数的问题。如果你开发的应用程序变得非常庞大，你八成会遇到这个问题。

到目前为止，我们已经完成了对Espresso的介绍。从之前的文章我们可以看到，Espresso对Android APP的自动化测试提供了一系列非常强大的工具和方法。

之前的文章中，我们介绍了Android自动化测试的一些背景，以及Espresso的基本应用。除了之前介绍过的Espresso的相关用法，Espresso还提供了一些其他的用法，可以让我们在不同场景下灵活使用。这篇文章我们依然关注于Espresso提供的功能。

在之前的文章中，我们简单介绍了Espresso的使用。通过onView()方法我们可以快速定位到界面上我们需要测试的目标元素。整体来说，onView()比较适用于UI比较简单的情况，在不需要过于复杂的匹配条件的情况下是很方便的。但是，对于类似ListView这种有UI复用的元素来说，只是通过onView()就显得复杂了一点，我们来看一下针...

关于onView()方法，我们需要首先知道目标控件的一些属性值，然后再围绕我们的目标属性构建一个匹配规则。但有些时候，控件的属性并不是那么明显，或者并没有那么容易获取到，这时，我们可以使用Android提供的uiautomatorviewer工具帮助我们进行分析。

这个思路的意思是在于，我要让机器模拟我的测试过程，那么我就需要针对那些我（作为用户）能看到的东西，也就是UI。比如说，我并不关心某个网络请求返回值的具体数据是否正确，我关心的是我能在UI上看到我希望看到的结果。基于此，我做各个测试用例的一个通用的思路就是：

根据该系列文章的第一篇：Hello Testing，大家已经对整个自动化测试运行流程有了一个基本的了解，接下来我们该集中精力关注具体的脚本实现了！在具体实现之前，我们先来了解一下Android提供的对于自动化测试的一些支持。

最近在做Android上的自动化测试，从最初的第三方自动化测试框架appium到后来的Android Support Testing Library，再到最终完成答疑君Android客户端一些核心流程的自动化测试，期间也是经历了各种大大小小的坑。这个系列的文章也是想通过描述整个探索道路来记录一下整个Android自动化测试的入门过程，同时也采用了我自己...