这里不聊为什么android要进行UI测试，主要聊一下android studio集成的两种测试包的区别以及如何搭配使用。
android studio集成了两种的UI测试包Espresso和UIAutomator，搭配使用起来也非常方便(一个测试类中两种测试代码可以混搭使用）。Espresso主要是用于应用内的测试；UIAutomator是用于跨应用的测试。个人觉得：
（1）Espresso非常适合用于单页面测试，之所以这么说，是基于以下原因：
（a) Espresso测试有个很强大的功能是它在多个测试操作中是线程安全的。Espresso会等待当前进程的消息队列中的UI事件，并且在任何一个测试操作中会等待其中的AsyncTask结束才会执行下一个测试。这样就不用处理各种UI加载快慢导致的测试用例运行奔溃问题，这点要比基于Instrumentation的测试框架要简单的多，后者主要是通过设置适当的等待时间，来等待UI绘制完成在进行后续的测试动作，例如打开一个activity后要点击一个按钮，使用后者的测试代码需要在写完“打开activity”这个测试代码后，测试代码中要专门设置一个适当的等待时间，然后才能继续写“点击按钮”测试代码，否则直接执行“点击按钮”操作很容易出现测试奔溃的情况。
(b) Espresso可以模拟页面间的跳转和数据通信。页面间跳转和数据传递，可以用模拟的方法进行测试，而不需要真正跳转到其他页面。比较典型的例子是，测试页面通过startActivityForResult()跳转到a页面，然后关闭a页面返回到测试的onActivityResult方法时，往往会携带Intent数据。这时就可以使用espress-intents包来模拟发送这个Intent数据，而不需要真正的跳转到a页面。因此，一个activity页面在使用Espresso测试时，最好是一个测试类对应一个activity页面，这样比较清晰明朗。
(c) 基于第一点的UI事件驱动测试流程的原因，Espresso测试的运行速度很快。
（2）UIAutomator比较适合多页面或跨应用的功能测试。
（a）所谓的功能测试通俗讲就是一连串的页面跳转，一个app一般都有几个主要的功能流程，例如注册流程、登陆流程等，这些流程都包含一系列的页面跳转，这种跳转可能要跳到其他app页面或者系统的页面。例如“蓝牙搜索”功能大致流程如下：启动页面->弹出用户权限对话框->弹出系统蓝牙开关对话框->蓝牙搜索页面。这当中涉及到系统的弹框，这时候使用Espresso就比较麻烦了，Espresso要实现IdlingResources接口，然后将这个实现类在app代码中（注意不是在测试代码中）实例化，通过阻断测试进程来等待用户弹框的操作结果，这样不能完全分离app代码和测试代码，而且阻断了自动化测试过程（因为要等待测试人员手动点击系统弹框），这是我们不希望看到的。使用UIAutomator可以非常简单的自动点击系统弹框，而且不需要在app页面中嵌入测试代码。
(b) Espresso也可以进行多页面跳转测试，但是它只能获取入口activity的实例，一旦跳转到其他页面，就不能获取(或者说很难获取)到当前activity的实例，这对有些测试情况是很不友好的，例如异步加载数据然后刷新UI的情况。
因此，个人的做法是：
（1）单页面测试主要使用Espresso，这可以覆盖绝大部分页面的详尽测试。
（2）整个app梳理出几条主要的功能流程，针对这些功能流程，使用UIAutomator配合Espresso编写测试用例。
如果需要demo，请在邮箱留言：[email protected]