Android测试概述

用户在使用APP的某个功能时，与APP的交互方式是多样的。所以在进行应用程序的迭代开发时，应该测试各种使用和交互场景。

使用迭代开发工作流程

随着应用程序功能的扩展，一个APP可能会包含越来越多功能，如：从服务器获取数据、与设备的sensor交互、访问本地存储或呈现复杂的用户界面。因此，需要一个全面的测试策略来保证应用程序的多功能性和复杂性。

当迭代地开发一个特性时，需要同时编写新的测试策略，或在现有的单元测试中添加新的测试用例。在设计新功能时，应该考虑每个责任单元。对于每个单元，都应该编写相应的单元测试。单元测试应该覆盖该单元所有可能的交互，包括标准交互、无效输入和资源不可用的情况。

图1：以迭代和测试驱动软件开发的工作流程
如图1所示：完整的工作流程包含一系列嵌套的迭代循环，其中单元测试耗时短，速度快，测试每个代码单元本身；集成测试以UI驱动、耗时长、速度慢，测试所有代码单元的集成功能。这一系列循环一直持续到应用程序pass每条用例为止。

测试金字塔

图2：测试金字塔显示应用程序的测试策略应包含三种测试类型
如图2所示的测试金字塔，展示了应用程序应该如何包含小型、中型和大型三种测试类型：
•小型测试：能脱离应用程序单独运行的单元测试。小型测试通常模拟每个主要的组件，并在开发环境中快速运行。
•中型测试：介于小型测试和大型测试之间的集成测试。中型测试对几个组件进行集成测试，并运行在模拟器或实际设备上。
•大型测试：是通过完成UI操作来运行的集成和UI测试。大型测试确保面向用户的、关键的功能在模拟器或实际设备上按照预期的效果运行。

虽然小型测试速度快、聚焦性好，利于开发者快速定位问题，但它们的测试对象只是应用程序中很小的一个独立单元，因此通过了这种小型测试并不代表应用程序能正常工作。相反的，大型测试能弥补小型测试的这种不足。

因为每种测试类型的特点不同，所以应用程序的测试策略需要包含测试金字塔中的三种测试类型。虽然每个测试类型的占比是根据应用程序的使用场景而变化的，但一般建议测试类型按照以下比例划分：小型测试占70%、中型测试占20%、大型测试占10%。

编写小型测试

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

Robolectric

如果对应用程序进行单元测试时需要与Android Framework进行广泛的交互，那么可以用Robolectric实现。它基于Java语言，能通过打桩模拟Android Framework。Robolectric能够几乎完全逼真的模拟在Android设备上进行的测试，并且比在真机上的执行速度快。它还支持Android平台的以下几个方面：
•Android 4.1（API 16）及更高
•Android Gradle Plugin 2.4及更高版本
•组件的生命周期
•Event循环
•所有的资源

注：Robolectric有自己的一套测试API和一些新的概念。关于集成Robolectric的API到APP的更多信息，请见Robolectric工具的使用指南。

模拟对象

通过依赖修改后的android.jar执行单元测试，你可以监控与APP交互的Android Framework的元素。此JAR文件不包含任何代码，所以应用程序对Android框架的调用默认情况下会引发异常。使用类似Mockito的框架来配置模拟对象，可以测试与Android系统交互的代码。如果应用程序的代码包含对资源的引用或与Android Framework有复杂的交互，那么你应该使用不同形式的单元测试（如Robolectric）来代替模拟对象。

基于设备的单元测试

你也可以在真机或模拟器上运行基于设备的单元测试，它不涉及对Framework的模拟或打桩。由于这种形式的测试执行速度比运行在开发环境的单元测试要慢得多，所以只有在应用程序的功能与实际设备硬件强相关时，才使用这种测试方法。

编写中型测试

在开发环境中完成了应用程序的每个功能单元的单元测试后，您应该用中型测试验证在模拟器或真机上运行时组件是否正常运行。如果应用程序的某些组件依赖于物理硬件，那么这种测试就特别重要。中型测试评估应用程序如何协调多个功能单元，但他们不测试完整的应用程序。中等测试的例子包括Service测试、集成测试和拟外部依赖行为的封闭UI测试。因为你需要测试多种屏幕尺寸和硬件配置，所以通常情况下最好是在一个模拟设备或基于云的测试服务（如Firebase Test Lab），而不是一个物理设备上，进行中型测试。

编写大型测试

尽管独立地测试应用程序中的每个层级和特性是很重要的，但测试应用程序常见的工作流程和包括完整堆栈（从UI到业务逻辑到数据层）的使用场景同样重要。如果应用程序足够小，你可能只需要一套大型测试来评估应用程序的整体功能。否则，应该根据开发者团队、功能、用户目标来划分大型测试。

注意：对于编写的每一个基于工作流程的大型测试，您还应该编写检查工作流程中包含的每个UI组件功能的中间测试。这样，您的测试策略可以继续在关键功能的每一步中发现潜在的问题，即使相应的大型测试在前几步中仍会失败。

AndroidJUnitRunner类定义了一个允许你在Android设备上运行JUnit 3或JUnit 4 的工具。它能将测试包和正在测试的应用程序加载到设备或模拟器上，运行测试并报告结果。AndroidJUnitRunner类还能从Android Testing Support Library (ATSL)支持以下工具和框架：

JUnit4 Rules

ATSL包括用于管理关键应用程序组件（如Activity和Service）的生命周期的代码。要学习如何定义这些规则，请参考JUnit4 Rules指南。

Espresso

Espresso同步异步任务，同时自动化应用程序中的以下交互：
•在View对象上执行操作。
•完成跨APP进程边界的工作流。仅适用于Android 8（API 26）及更高。
•评估具有可访问性需求的用户如何使用您的应用程序。
•定位和访问RecyclerView和AdapterView对象内的Item。
•验证传出Intent的状态。
•验证WebView对象中的DOM结构。
•跟踪应用程序中长时间运行的后台操作。
更多关于Espresso的使用方法请见Espresso指南。

UI Automator

建议只有当你的应用程序必须与系统进行交互以完成关键的使用场景时，才用UI Automator测试应用程序。因为UI Automator与系统软件和用户界面交互，所以每次系统更新后，你都需要重新运行并修复你的UI Automator测试。这些更新包括Android平台版本升级和谷歌Play服务的新版本升级。

UI Automator的备选方案是：增加封闭测试或把大型测试拆分为小型测试和中型测试。特别是测试应用程序间的通信，例如向其他应用程序发送信息和响应Intent结果。可以用Espresso-Intents实现这些较小型的测试。

UI Automator框架从你的APP的角度执行系统应用程序间的交互，如检查当前显示的UI的层次结构、截图以及分析设备的当前状态。更多关于UI Automator的使用方法，请参考UI Automator使用指南。

Android Test Orchestrator

Android Test Orchestrator每次都是在它的工具沙盒中运行UI测试的，通过减少测试之间的共享状态，并在每个测试基础上隔离应用程序崩溃，从而提高测试套件的可靠性。更多关于Android Test Orchestrator的详细信息，请见Android Test Orchestrator指南。