Android测试基础教程 on 重定向学院

Android测试（一）：在Android中测试App

Wed, 20 Dec 2017 14:55:12 +0800

原文：https://developer.android.com/training/testing/index.html

测试你的App是开发过程中的重要组成部分。通过对应用程序持续的运行测试，你可以验证程序的正确性、功能和可用在发布之前。

测试还提供了以下优点：

快速反馈失败。
开发周期的早期问题检测。
安全地重构代码，让你优化代码而不用担心回归。
稳定开发速度，帮助你减少技术债务。

这里的特指测试通过代码实现的“单元”测试。所以，它可以更早、更快的帮我们发现问题，使我们的代码重构更有信心；单元测试虽然前期编写会比较耗时，但是它可以有效的代码的质量，不会导致项目后期代码充满坏味道，严重拖慢开发进度；所以，减少你技术债务。

资源

在Android测试库、Android平台和开源社区都提供了帮助你编写Android应用测试的工具：

Espesso

Espresso是android应用开发自带测试库。他是一款白盒风格的UI测试工具。UI测试就都是黑盒的么？为什么会是白盒风格。

说白盒是因为，通过Espresso编写测试调用Android控件的方式和 Android开发中是一样的。来看一段Android开发中，Activity中编写的代码。

/** Called when the user clicks the Send button */
public void sendMessage(View view) {
 // Do something in response to button
 Intent intent = new Intent(this, DisplayMessageActivity.class);
 EditText editText = (EditText) findViewById(R.id.edit_message);
 String message = editText.getText().toString();
 intent.putExtra(EXTRA_MESSAGE, message);
 startActivity(intent);
}

通过 R.id.edit_message 调用布局文件中输入框中的内容，并转交到另外一个Activity处理。

Android测试（二）：Android 测试基础

Wed, 20 Dec 2017 14:50:12 +0800

原文：https://developer.android.com/training/testing/fundamentals.html

用户在不同的级别上与你的应用产生交互。从按下按钮到将信息下载到他们的设备上，因此，你应该在迭代开发应用程序时测试各种用例和交互。

使用迭代开发工作流

当你的应用程序进行扩展时，你可能会发现需要从服务器获取数据，与设备的传感器进行交互，可以还需要访问本地存储，或呈现复杂的用户界面。应用程序的多样性需要一个全面的测试策略。

在迭代开发一个新的特性时，首先需要编写一个新的测试，或者在现有单元测试中添加新的测试例和断言。测试一开始是失败的，因为这个新特性还没有实现。

在设计新功能时，考虑单元测试的设计很重要。对于每个功能单元编写一个相应的单元测试。你的单元测试应该尽可多的涵盖到所有可能与单元的交互，包括标准的交互、无效的输入、以及资源不可用的情况。

图：测试驱动开发：两个周期与迭代过程。

完整的工作流，如上图，包含一系列嵌套的循环迭代。其中长、慢、UI驱动的集成测试，你可以用更短、更快的单元测试驱动开发周期来完成。这一系列循环一直持续到你的应用程序满足每个用例为止。

测试金字塔

图：测试金字塔，显示应该在应用程序的测试套件中包含的三个测试类别。

测试金字塔，如上图所示，说明你的应用程序应该如何包括三种类型的测试：小测试、中测试和大测试。

小测试是你可以在与生产系统隔离的情况下运行的单元测试。它们通常会mock所有主要组件，并在PC上快速运行。
中测试是介于小测试和大测试之间的集成测试。它们集成了几个组件，并在Android模拟器或真实设备上运行。
大测试是通过完成UI工作流来运行的集成和UI测试。它们确保关键的终端用户任务在Android模拟器或真实设备上正常工作。

注：这里测试金字塔的定义是Google针对Android应用的测试划分。不同类型的应用，通过测试金字塔模型进行划层级的划分，以及每层的定义会有所不同。

尽管小测试的速度很快，而且重点突出，可以让您快速处理失败，但它们是低保真和独立的，让你很难相信通过测试的应用是可以正常运行的，所以需要通过大测试进行补足。

由于每个测试类别的不同特性，你的测试工作应该包含测试金字塔的每一层测试。尽管每个类别的测试比例可能因应用程序的使用情况而有所不同，但我们通常建议以下分类：70%的小测试、20%的中等测试和10%的大测试。

小测试

在添加和更改应用程序的功能时，通过创建和编写单元测试来确保这些功能按照预期的来运行。虽然可以在Android模拟器或真实设备中运行单元测试，但是在开发环境中运行单元测试通常会更快、更容易，根据需要添加Stub或mock方法实现与Android系统进行交互。

Robolectric

如果你的应用程序的测试环境要求单元测试与Android框架进行更广泛的交互，那么你可以使用Robolectric。此工具执行测试友好、基于Java 逻辑Stub来模拟Android框架，由社区来维护这些Stub。

Robolectric测试几乎完全符合Android设备上运行测试的完全保真度，但仍比设备测试运行得更快。它还支持Android平台的以下几个方面:

Android 4.1（API等级16）及更高版本
Android Gradle插件2.4及更高版本
组件生命周期
事件循环
所有资源

Robolectric有自己的一套测试API，并引入了一些新概念。有关将Robolectric的API与应用程序的测试相结合的更多信息，请参见该工具的用户指南

Mock对象

你可以通过修改Android.jar版本来运行单元测试，从而来监控应用与之交互的Android框架元素。这个JAR文件不包含任何代码，所以你的应用程序调用Android框架默认会抛出异常。要测试与Android系统交互的代码元素，请使用像Mockito这样的框架来配置模拟对象。

检测单元测试

你也可以在Andorid模拟器或真实设备上运行检测单元测试，而不涉及任何stub或mock框架。因为这种测试形式的执行时间明显比本地单元测试慢，所以最好仅在需要评估应用程序对当前设备硬件的行为时才依赖此方法。

中测试

在开发环境中测试了应用程序的每个单元之后，应验证在模拟器或设备上运行时组件的行为是否正确。中等测试允许您完成这部分的开发过程。如果某些应用程序的组件依赖于物理硬件，则这些测试对于创建和运行尤其重要。

中等测试你的应用程序如何协调多个单元，但它们不测试完整的应用程序。中等测试的用例包括服务测试、集成测试以及mock外部依赖性行为的UI测试。

通常情况下，最好在Android模拟器或Firebase测试实验室等基于云服务上测试应用程序，而不是在真实设备上测试应用程序，因为你可以更轻松，快速地测试多种屏幕大小和硬件配置组合。

大测试

尽管测试应用程序中的每一层的功能是非常重要的，但是测试涉及整个堆栈的常见工作流和用例（从UI到业务逻辑到数据层）同样重要。

如果您的应用程序足够小，则可能只需要一套大型测试来评估你的应用程序。否则，你应该根据团队所有权，垂直功能或用户目标来划分你的大型测试套件。

对于你所编写的每一个大型的基于工作流程的测试，你还应该编写中测试来检查工作流中包含的每个UI组件的功能。通过这种方式，即使在最初的几个步骤中，相应的大型测试也会失败了，你的测试套件仍然可以在关键用户操作的每一步中继续识别潜在的问题。

AndroidJUnitRunner类定义了一个基于JUnit框架的测试运行器，它允许你在Android设备上运行JUnit 3或JUnit 4样式的测试类。便于将测试包和应用程序加载到真实设备或Android模拟器上，运行测试并报告结果。

Android测试（三）：Android 单元测试

Wed, 20 Dec 2017 14:45:12 +0800

原文：https://developer.android.com/training/testing/unit-testing/index.html

单元测试是你的应用程序测试策略的基本测试。通过针对您的代码创建和运行单元测试，你可以轻松验证各个单元的逻辑是否正确。在每次构建之后运行单元测试可帮助你快速捕获并修复由代码更改引入到应用程序的软件回归。

单元测试通常以可重复的方式实现尽可能小的代码单元（可以是方法，类或组件）的功能。当你需要验证应用程序中特定代码的逻辑时，你应该构建单元测试。例如，你创建了一个类，单元测试可以帮助检查该类是否处于正确的状态。通常，单元测试是相对独立的，你的测试只会影响和检查被测试单元的变更，mock框架可以用来隔离你要测试单元的依赖。

注意：单元测试不适合测试复杂的UI交互事件。相反，您应该使用UI测试框架，如UI自动化测试中所述。

为了测试Android应用程序，你通常需要创建这些类型的单元测试：

本地测试： 仅在本地机器上运行的单元测试。这些测试被编译为在Java虚拟机（JVM）本地运行，以最小化执行时间。使用这种方法来运行没有依赖于Android框架的单元测试，或者可以使用mock对象来填充依赖关系。
Instrumented测试： 在Android设备或模拟器上运行的单元测试。这些测试可以访问工具信息，例如被测试的应用程序的上下文。使用此方法运行具有Android依赖关系的单元测试，这些测试不能使用mock对象轻松填充。

接下来将告诉你如何构建这两种类型单元测试。

本课的教训将告诉您如何构建这些类型的自动化单元测试。

Lessons

Building Local Unit Tests（创建本地单元测试）

学习如何构建在本地机器上运行的单元测试。

Building Instrumented Unit Tests（创建Instrumented单元测试）

了解如何构建在Android设备或模拟器上运行的单元测试。

原始封面

Android测试（四）：Local 单元测试

Wed, 20 Dec 2017 14:40:12 +0800

原文：https://developer.android.com/training/testing/unit-testing/local-unit-tests.html

如果你的单元测试没有依赖或者只有简单的Android依赖，则应该在本地开发机器上运行测试。这种测试方法非常高效，因为它可以帮助你避免每次运行测试时将目标应用程序和单元测试代码加载到真机或模拟器上的开销。因此，运行单元测试的执行时间大大减少了。通过这种方法，你通常使用mock框架（如Mockito）来完成任何依赖关系。

设置测试环境

在你的Android Studio项目中，必须将本地单元测试的源文件存储在module-name/src/test/java/ 目录中。在创建新项目时，该目录已经存在。

你还需要配置项目的测试依赖，以使用JUnit 4框架提供的标准API。如果你的测试需要与Android依赖关系进行交互，请包含Mockito库以简化本地单元测试。要了解有关在本地单元测试中使用模拟对象的更多信息，请参阅模拟Android依赖关系。

在你的App程序的目录下找到build.gradle文件中，将这些库指定为依赖项：

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

创建本地单元测试类

你的本地单元测试类应该写成一个JUnit 4测试类。 JUnit是Java最流行和广泛使用的单元测试框架。这个框架的最新版本，JUnit 4，允许你用比前一版本更清晰，更灵活的方式编写测试。与以前的基于JUnit 3的Android单元测试方法（使用JUnit 4）不同，你不需要扩展junit.framework.TestCase类。也不需要在测试方法名称前加上“test”关键字，或者使用junit.framework或junit.extensions包中的任何类。

要创建基本的JUnit 4测试类，请创建一个包含一个或多个测试方法的Java类。测试方法从@Test注释开始，包含代码来练习和验证要测试的组件中的单个功能。

以下示例显示了如何实现本地单元测试类。测试方法emailValidator_CorrectEmailSimple_ReturnsTrue验证被测试的应用程序中的isValidEmail()方法是否返回正确的结果。

import org.junit.Test;
import java.util.regex.Pattern;
import static org.junit.Assert.assertFalse;
import static org.junit.Assert.assertTrue;

public class EmailValidatorTest {

    @Test
    public void emailValidator_CorrectEmailSimple_ReturnsTrue() {
        assertThat(EmailValidator.isValidEmail("name@email.com"), is(true));
    }
    ...
}

要测试应用程序中的组件是否会返回预期的结果，请使用junit.Assert方法执行验证检查（或断言），以便将待测组件的状态与某个预期值进行比较。为了使测试更具可读性，可以使用Hamcrest匹配器（如is（）和equalTo（）方法）将返回的结果与期望的结果进行匹配。

Android测试（五）：Instrumented 单元测试

Wed, 20 Dec 2017 14:35:12 +0800

原文：https://developer.android.com/training/testing/unit-testing/instrumented-unit-tests.html

Instrumented 单元测试是在真机和模拟器上运行的测试，它可以利用Android框架API和支持的API（如Android测试支持库）。如果你的测试需要访问工具信息（例如目标应用程序的Context），或者需要真正实现Android框架组件（如Parcelable或SharedPreferences对象），则应该创建Instrumented 单元测试。

使用Instrumented单元测试还有助于减少编写和维护mock代码所需的工作量。如果你愿意，仍然可以自由地使用一个mock框架模拟任何依赖关系。

设置测试环境

在你的Android Studio项目中，你必须将mock测试的源文件存储在module-name/src/androidTest/java/ 中。创建新项目时该目录已经存在，并包含示例代码。

在开始之前，你应该下载Android测试支持库安装程序，该安装程序提供的API可让你快速构建和运行应用程序的检测代码。测试支持库包括用于功能性UI测试（Espresso和UI Automator）的JUnit 4测试运行器（AndroidJUnitRunner）和API。

还需要为项目配置Android测试依赖项，以使用测试运行程序和测试支持库提供的规则API。为了简化测试开发，还应该包含Hamcrest库，它可以让你使用Hamcrest匹配器API创建更灵活的断言。

在你的App的顶级build.gradle文件中将这些库指定为依赖项：

dependencies {
    androidTestCompile 'com.android.support:support-annotations:24.0.0'
    androidTestCompile 'com.android.support.test:runner:0.5'
    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'
    // Optional -- UI testing with UI Automator
    androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.2'
}

警告： 如果构建配置包含support-annotations库的编译依赖项和espresso-core库的androidTestCompile依赖项，则由于依赖冲突，构建可能会失败。请按照下面步骤更新对espresso-core的依赖关系：

androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {
    exclude group: 'com.android.support', module: 'support-annotations'
})

要使用JUnit 4测试类，请确保将AndroidJUnitRunner指定为项目中的默认测试工具运行器，方法是在应用程序的模块级build.gradle文件中包含以下设置：

Android测试（六）：Android UI自动化测试

Wed, 20 Dec 2017 14:30:12 +0800

原文：https://developer.android.com/training/testing/ui-testing/index.html

用户界面（UI）测试可以确保你的应用程序满足其功能要求，并达到用户最可能成功采用的高质量标准。

UI测试的一种方法是简单地让人类测试人员在目标应用程序上执行一组用户操作，并验证其行为是否正确。但是，这种手动方法可能耗时、乏味、且容易出错。更有效的方法是编写您的UI测试，以便用户操作以自动方式执行。自动化方法使您能够以可重复的方式快速可靠地运行测试。

注意：强烈建议您使用Android Studio来构建测试应用程序，因为它提供了项目设置，包含库和包非常方便。这个里假定你正在使用Android Studio。

要使用Android Studio自动执行UI测试，请在单独的Android测试文件夹src/androidTest/java中实现测试代码。针对Gradle的Android插件将根据你的测试代码构建测试应用程序，然后将测试应用程序加载到与目标应用程序相同的设备上。在测试代码中，可以使用UI测试框架来模拟目标应用程序上的用户交互，以执行覆盖特定使用场景的测试任务。

为了测试Android应用程序，通常会创建这些类型的UI自动化测试：

单个应用程序的UI测试： 这种类型的测试验证当用户执行特定操作或在其活动中输入特定内容时，目标验证应用程序的行为是否符合预期。它允许你检查目标应用程序是否返回正确的UI输出，以响应应用程序活动中的用户交互。像Espresso这样的UI测试框架允许以编程方式模拟用户操作并测试复杂的应用内用户交互。

跨越多个应用程序的UI测试： 这种类型的测试验证不同用户应用程序之间或用户应用程序与系统应用程序之间交互的正确行为。例如，可能想要测试你的相机应用程序与第三方社交媒体应用程序或默认的Android照片应用程序正确共享图像。支持跨应用程序交互的UI测试框架（如UI Automator）允许你为这些方案创建测试。

本课的经验将告诉你如何使用Android测试支持库中的工具和API来构建这些类型的自动化测试。在开始使用这些API构建测试之前，你必须安装Android测试支持库，如下载Android测试支持库中所述。

课程

Testing UI for a Single App（单个应用程序的UI测试）

了解如何使用Espresso测试框架在单个应用程序中测试UI。

Testing UI for Multiple Apps （多个应用程序的UI测试）

了解如何使用UI Automator测试框架在多个应用程序中测试UI。

原始封面

Android测试（七）：Espresso 自动化测试

Wed, 20 Dec 2017 14:25:12 +0800

原文：https://developer.android.com/training/testing/ui-testing/espresso-testing.html

在单个应用程序中测试用户交互有助于确保用户在与应用程序进行交互时不会遇到意外的结果，或遇到糟糕的体验。如果需要验证应用的UI功能是否正常，则应该养成创建用户界面（UI）测试的习惯。

Espresso 测试框架，由Android测试支持库提供，用于编写UI测试的API来模拟单个应用程序内的用户交互。Espresso测试可以在运行Android 2.3.3（API等级10）及更高版本的设备上运行。使用Espresso的一个关键好处是，它提供了测试操作与正在测试的应用程序的用户界面的自动同步。 Espresso检测主线程是否处于空闲状态，以便能够在适当的时候运行测试命令，从而提高测试的可靠性。此功能还可以减轻在测试代码中添加任何计时变通方法如Thread.sleep（） 的麻烦。

Espresso测试框架基于instrumentation的API，并通过AndroidJUnitRunner运行测试。

设置Espresso

在使用Espresso构建UI测试之前，请确保配置测试源代码位置和项目依赖关系，如“ Getting Started with Testing”中所述。

在Android应用程序模块的build.gradle文件中，必须设置对Espresso库的依赖关系引用：

dependencies {
    // Other dependencies ...
    androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2.2'
}

关闭测试设备上的动画 - 在测试设备中打开系统动画可能会导致意外的结果，或者可能导致测试失败。通过打开“开发人员”选项关闭“设置”中的动画，并关闭以下所有选项：

窗口动画比例
过渡动画比例
动画师持续时间比例

如果你希望将项目设置为使用核心API提供的Espresso功能以外的功能，请参阅此资源

创建一个Espresso 测试

要创建Espresso测试，请创建遵循此编程模型的Java类：

1.找到想要在活动中测试的UI组件(例如，应用程序中的登录按钮)，调用onView()方法，或者调用AdapterView控件的onData()方法。

2.通过调用ViewInteraction.perform（）或DataInteraction.perform（）方法并传入用户操作（例如，单击登录按钮），模拟特定的用户交互以在该UI组件上执行。要在同一UI组件上对多个操作进行排序，请使用方法参数中的逗号分隔列表链接它们。

3.根据需要重复上述步骤，模拟目标应用中多个活动的用户操作。

4.在执行这些用户交互之后，使用ViewAssertions方法来检查UI是否反映了期望的状态或行为。

以下各节将详细介绍这些步骤。

下面的代码片段显示了你的测试类可能如何调用这个基本的工作流程：


onView(withId(R.id.my_view))            // withId(R.id.my_view) is a ViewMatcher
        .perform(click())               // click() is a ViewAction
        .check(matches(isDisplayed())); // matches(isDisplayed()) is a ViewAssertion

使用Espresso和ActivityTestRule

以下部分介绍如何使用JUnit 4样式创建新的Espresso测试，并使用ActivityTestRule来减少需要编写的样板代码的数量。通过使用ActivityTestRule，测试框架在每个使用@Test注释的测试方法之前以及在使用@Before注释的方法之前启动被测活动。测试完成后，框架处理关闭活动，所有使用@After注释的方法都会运行。

Android测试（八）：UI Automator 自动化测试

Wed, 20 Dec 2017 14:20:12 +0800

原文：https://developer.android.com/training/testing/ui-testing/uiautomator-testing.html

涉及跨多个应用程序的用户交互的用户界面（UI）测试可以验证应用程序在用户流量跨越其他应用程序或进入系统UI时的行为。这种用户流程的一个例子是一个消息应用程序，它允许用户输入文本消息，启动Android联系人选择器，以便用户可以选择收件人发送消息，然后将控制权返回给用户的原始应用程序并提交消息。

这一小节介绍如何使用Android测试支持库提供的UI Automator测试框架编写此类UI测试。 UI Automator API可让你与设备上的可见元素进行交互，而不管哪个Activity处于焦点。你的测试可以使用方便的描述符（如该组件中显示的文本或其内容描述）查找UI组件。 UI Automator测试可以在运行Android 4.3（API级别18）或更高版本的设备上运行。

UI Automator测试框架是基于 instrumentation的API，并与AndroidJUnitRunner测试运行器一起使用。

设置UI Automator

在使用UI Automator构建UI测试之前，请确保配置测试源代码位置和项目依赖关系，如前面章节中所述。

在Android应用程序模块的build.gradle文件中，必须设置对UI Automator库的依赖关系引用：

dependencies {
    ...
    androidTestCompile 'com.android.support.test.uiautomator:uiautomator-v18:2.1.1'
}

为了优化您的UI Automator测试，您应该首先检查目标应用程序的UI组件，并确保它们可以访问。这些优化技巧将在下面两节中介绍。

查看设备上的UI

在设计您的测试之前，检查设备上可见的UI组件。为确保您的UI Automator测试可以访问这些组件，请检查这些组件是否具有可见的文本标签、android:contentDescription 值。

uiautomatorviewer工具提供了一个方便的可视化界面来检查布局层次结构，并查看设备前台中可见的UI组件的属性。这个信息可以让你使用UI Automator创建更细致的测试。例如，可以创建一个匹配特定可见属性的UI选择器。

启动uiautomatorviewer工具：

1.在物理设备上启动目标应用程序。

2.将设备连接到你的开发机器。

3.打开终端窗口并导航到<android-sdk> / tools /目录。

4.使用以下命令运行该工具：

$ uiautomatorviewer

要查看您的应用程序的UI属性：

1.在uiautomatorviewer界面中，点击 Device Screensho 按钮。

2.将鼠标悬停在左侧面板中的快照上，查看由uiautomatorviewer工具标识的UI组件。属性列在右下方的面板中，右上方的布局层次中列出。

3.或者，单击 Toggle NAF Nodes 按钮以查看UI Automator无法访问的UI组件。这些组件只有有限的信息可用。

确保你的Activity是可访问的

UI Automator测试框架对已实施Android辅助功能的应用程序执行得更好。当你使用View类型的UI元素或SDK或Support Library中的View的子类时，不需要实现可访问性支持，因为这些类已经为你完成了。

但是，有些应用程序使用自定义UI元素来提供更丰富的用户体验。这些元素不会提供自动的可访问性支持。如果你的应用程序包含不是来自SDK或支持库的View子类的实例，请确保通过完成以下步骤将可访问性功能添加到这些元素：

1.创建一个扩展ExploreByTouchHelper的具体类。

2.通过调用setAccessibilityDelegate（）将新类的实例与特定的自定义UI元素相关联。

有关将辅助功能添加到自定义视图元素的其他指导，请参阅构建可访问自定义视图要详细了解Android上可访问性的一般最佳实践，请参阅使应用程序更易于访问。