使用 Espresso 实现完整覆盖的功能测试

对于基于 UI 的功能测试的需求其实一直存在，理由其实很简单，不想一直让人去做重复机械的事情，而且可靠性完全是靠人力的堆积产生。然而现在行业大多数公司的功能测试工作依然主要是依靠人工来完成，从我们公司的实践来看我觉得有几个方面的因素的影响。

• 之前的 UI 测试框架的表现差强人意。就拿我们公司来说，其实测试部门在去年已经实现并推广一套主要基于 UIAutomator 实现的测试平台，但由于对复杂功能的处理能力较弱，基本只能实现部分功能的检测。这样导致的一个结果是，并不能有效减少测试的工作，而只能增加测试的额外工作，因此测试编写测试代码的积极性不是很高。同时由于测试代码的可重复利用性差，导致测试脚本的编写成本和维护成本偏高，实践中大家只用 UI 测试跑一些主流程业务，覆盖范围非常有限。

• 部分测试人员的编码能力不是很强。由于大部分测试人员可能并没有过多的开发经验，所以在编写测试代码时并不能很顺畅的完成自己想要的效果，这样也会导致测试代码项目的推广阻力会比较大。

• 对于怎么编写 UI 测试，并没有一个被大家接受认可的最佳实践。虽然我用 Espresso 实现了一套完整的覆盖方案，但是其实我用的方法和 Google 官方所建议的写法还是有蛮多差异的。

对比上面的几个因素，我觉得更为主要的原因还是在于现有测试平台对于复杂逻辑处理的能力不够，导致对于 UI 测试的依赖性仅仅局限在安装测试和兼容性测试，只能用来跑一些主流程的东西，对于大多数功能还只能依靠人工的方式完成。

Espresso

Espresso 是 Google 在 2013 年推出的 Android UI 测试的开源框架。其实之前我们团队也多多少少对 Espresso 有过一些尝试，但遗憾的是都没有深入的进行实践。一季度我们将 UI 测试作为一个很明确的坑来填以后，发现 Espresso 已经很强大了，经过实践下来我们发现用 Espresso 实现 80-90% 的功能性覆盖测试基本没有什么问题。而且 Espresso 的测试脚本编写起来非常简单，如果测试和开发共同来完成测试代码的编写，能够有效替代测试大量的重复机械的工作。

下面我就来描述一下我们是怎么用 Espresso 来实现这一样一个完整覆盖的功能性测试平台。这篇文章会讲到一些在使用 Espresso 中遇到的坑，但是并不会在 How-to 的事情上面花太多的精力，如果你对 Espresso 还不是很了解的话，建议先去 

原文转自：http://ohmerhe.com/2017/04/18/espresso_huge_ui_test/