Android常用的测试方法概览

1.前言

---

应用测试是每个程序员的基本功，目的是为了保证自己写的代码的正确性。公司一般都有专门的测试人员，他们负责对整个应用或功能模块进行测试。两者之间有什么区别呢？这得从测试的目的说起。
　　测试是为了避免开发过程中的问题所带来的风险，本着越早发现越早解决，这样可以减少修改时所需要的代价。举个例子，测试人员在应用上线前测出Bug，需要在整个应用所有模块中，定位到有问题的地方，将错误现象告知相应开发人员去修改，然后再次合并打包成完整应用。这个过程仅消耗的时间，就比开发人员完成逻辑后，按照文档进行测试，再合并打包的时间要长，所以开发人员懂得测试是很重要的。

2.测试支持库

---

Google提供了测试支持库，详细信息参考官网支持库。其中AndroidJUnitRunner类是JUnit测试运行器，可在Android设备上运行JUnit 3或JUnit 4样式的测试类（不能混合使用），包括使用Espresso和UI Automator测试框架的设备。测试运行器可以将测试软件包和被测试的应用一起加载到设备、运行测试并报告测试结果，如下图所示：

AndroidJUnitRunner.png

3.测试的分类

---

根据AndroidJUnitRunner的作用可以将测试分为两大类，一类运行在计算机本地Java虚拟机（JVM）上，另一类运行在硬件设备或模拟器上。官方给出的分类是（详见 Android Studio用户指南）：

• 本地单元测试。当测试没有Android框架依赖项或使用Mockito之类的库模拟Android框架依赖项时，可以利用此类测试来尽量缩短执行时间。JUnit测试就是最佳代表，它用于测试功能的正确性，通过断言进行验证。
  模块级build.gradle需要依赖的库文件：

dependencies {
    // Required -- JUnit 4 framework
    testCompile 'junit:junit:4.12'
    // Optional -- Mockito framework
    testCompile 'org.mockito:mockito-core:1.10.19'
}

IDE提供的最简单的测试：

import org.junit.Test;
import static org.junit.Assert.*;
// 这是测试示例
public class ExampleUnitTest {
    // 1.通过注解标明测试方法的生命周期
    @Test
    public void addition_isCorrect() throws Exception {
        // 2.调用不涉及Android框架的逻辑代码
        int sum = 2 + 2;
        // 3.通过断言判断对错
        assertEquals(4, sum);
    }
}

• 设备测试。按有权访问的类型，将测试分为两类。
  第一类是设备单元测试，有权访问Instrumentation API，可以获取某些信息（例如，被测试应用的Context），并且允许通过测试代码来控制受测应用。
  第二类是自动化UI测试，有权访问UI组件，可以编写集成和功能UI测试来自动化用户交互，可以解决模拟对象无法满足的部分Android依赖项。
  由于自动化UI测试依赖于设备单元测试，所以一起说一下基本操作（在模块级build.gradle中进行）。
  首先，需配置运行器：

android {
    defaultConfig {
        ...
        testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
    }
}

接着，需要依赖相应的支持库：

dependencies {
    // Required -- JUnit 4 test runner
    androidTestCompile 'com.android.support.test:runner:0.5'
    // Optional -- solve a dependency conflict with support-annotations
    androidTestCompile 'com.android.support:support-annotations:24.0.0'
    // Optional -- JUnit 4 test rules
    androidTestCompile 'com.android.support.test:rules:0.5'
    // Optional -- Hamcrest library
    androidTestCompile 'org.hamcrest:hamcrest-library:1.3'
    // Optional -- UI testing with Espresso
    androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {
        // solve a dependency conflict with support-annotations
        exclude group: 'com.android.support', module: 'support-annotations'
})
    // Optional -- UI testing with UI Automator
    androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.2'
}

最后，通过设备单元测试调用Android框架 API，进行基本逻辑验证；而通过Espresso库提供的方法访问视图，进行交互操作；UI Automator最为强大，除了可以与自己应用交互，还可以与系统交互，完全模仿用户操作，不需要知道应用内部实现。详细使用方式，请参考官方培训。

4.源集的概念

---

由于设备测试内置于APK中（与被测试的应用APK分离），因此可能需要拥有自己的AndroidManifest.xml文件来指定最小版本号（除UI Automator需要API 18，其它为API 8以上即可）和注册测试专用的运行侦听器。构建应用时，Gradle会将多个清单文件合并成一个清单，先来分析一下里面的逻辑。

Module.png

开发过Android的都知道，若新建一个项目，它的工程结构默认只包含app主模块。在模块的src目录下，每个文件夹都是一个源集（对应构建的特定应用版本），存放着代码和资源，而共用的部分就放在系统默认的main源集下。
　　源集的名称由两个可缺省的部分组成（src/<productFlavorBuildType>/），前半部分为产品风味，因为每个渠道都有自己的特色，所以基本上以渠道命名；后半部分为构建类型，在上图中就是androidTest、test，分别表示设备测试和本地单元测试。尤其注意，所有测试均针对debug构建类型运行，若想修改参考如下代码（位于模块级build.gradle文件）：

android {
    ...
    testBuildType "staging"
}

应用构建时需要将特定的源集与main合并，具体由Gradle配置文件决定。如果不同源集包含同一文件的不同版本，Gradle将按以下优先顺序决定使用哪一个文件（左侧源集替换右侧源集的文件和设置）：构建变体 （含有风味与类型）> 构建类型 > 产品风味 > main源集 > 库依赖项。这样一来，Gradle便可使用专用的构建文件，同时对与其他应用版本共用的Activity、应用逻辑和资源加以重复利用。
　　在合并多个清单文件时，Gradle使用同一优先顺序，使每个构建过程都能在最终清单中定义不同的组件或权限。

5.总结

---

除了以上测试外，还有其它类型的测试，比如压力测试等。这篇文章旨在说明测试方法之间的逻辑联系、依赖关系以及适用场景等，具体使用方法会单独讲解。若急于入门，可以看看fodroid的文章。