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

移动开发前线 · 公众号 · 前端 · 2017-04-18 23:56

正文

请到「今天看啥」查看全文

给我们的测试方案取了一个高大上的名称——ETP 测试方案，也就是 Espresso Test Platform 的简称。大家如果看过 Google 官方的 Demo 的话，就应该能理解官方的思路其实是每个测试是完成一条完整的逻辑测试，比如完成添加一个笔记的测试逻辑。

这样的测试流程总结下来有两个比较明显的问题：

每条测试用例需要单独编写，代码的复用性差，导致编写单元测试的成本较高，虽然 Google 官方提供录制测试脚本的功能，但是生成的代码可用性并不强，大多数情况下还是需要靠人来编写。
复杂场景的处理能力，这样一条单独的测试流程容易被触发性的弹窗或者引导提示打断，如果在单条测试中做过多的判断，又会让单条测试用例变得臃肿，从而让所有的测试用例都变得臃肿而且难于维护和更新。

单页面测试

这是我为我们测试平台定义的一个基本测试单位，也是我们整个测试方案里面的一个核心概念。这里有两个方面需要明确一下。

有些人会说这是 Espresso 的标准写法，因为你在定义一个 Espresso 测试文件时就必须要指定一个启动的 Activity。但是从官方的 Demo 来看，他们倾向于这个 Activity 仅仅是一个入口，你应该在完成一条完成的测试用例（你可以根据需要跳转到任何页面）以后再进行相应验证。但是在我们的这里，启动的这个页面（可以是 Activity 或者 Fragment）以后就只做当前页面相关的逻辑测试，如果有页面跳转也仅仅是测试是否能成功跳转，不会再对应的界面产生更多的交互。
由于 Espresso 是基于 JUnit 实现的，所以你可以针对单个页面编写多个独立得测试用例，它们会以随机的顺序被调用。在我们的单页面测试中，只有单一的测试入口，然后顺序执行这个页面需要执行的所有测试。

在单页面测试中，会根据需求尽可能覆盖这个页面的所有的功能。这个时候有人可能会说，在不同的应用状态下（比如：登录是否），通过 UI 测试所能产生的逻辑并不一致，怎么做到全覆盖能。我们的解决方案是在这个页面的测试代码中，需要全部覆盖该页面所有的逻辑分支，当开始执行这个单页面测试的时候，是怎么样的状态，就进入怎样的逻辑分支。这个时候又有人开始有疑问了，这样怎么做到全功能覆盖呢。想象力丰富的人可能已经想到了解决方案，我们先给到一张图启发一下，后面再介绍我们引入的下一个概念——测试流。