我们非常高兴地宣布，Android 测试支持库 (ATSL) 1.0 版现已发布。
ATSL 1.0 版对现有测试 API 进行了重要更新，不仅添加了许多新功能、还提升了性能和稳定性，同时还修复了若干问题。它可提供齐全的 API，功能与现已弃用的 Android 平台测试 API 相当。此版本还添加了许多我们在 Google I/O 2017 论坛上讨论过的功能，如为 Multiprocess Espresso 和 Android Test Orchestrator 提供原生支持。
我们也非常高兴地宣布，从 1.0 版开始，我们将在 Google 的 Maven 代码库中分发版本，让您能够更轻松地使用 ATSL 进行构建。如需了解有关如何使用此代码库的更多信息，请参阅 Google Maven 代码库入门指南。请注意，今后我们不再将测试基础设施更新与平台更新捆绑在一起。如果您尚未将您的测试升级至 ATSL，这次正是升级的绝佳机会。
最后，我们想要宣布对我们的 Android 测试文档进行的一项重大更新。我们已将旧测试文档从我们的 GitHub 网站迁移至 developers.android.com/testing。所有测试文档现在都显示在同一个位置，让您更容易了解如何在 Android 上编写和执行测试。
下面我们进入本博文的高潮部分，这一部分概要地介绍了我们将在此版本中提供的新 API 和工具。
Espresso 增强功能
Espresso 3.0.0 带来了出色的新功能，并提升了整体性能。其中的一些亮点包括：Multiprocess Espresso、Idling Registry 和新的 Idling Resources。下面，我们更详细地介绍一下这些新功能：
Multiprocess Espresso
从 Android O 开始，此平台将包含对在您的应用默认进程之外进行仪器测试的支持。（在 Android O 之前，您只能在应用默认进程中测试应用组件。）Multiprocess Espresso 实现了这一支持。它允许您无缝测试跨进程界限的应用界面交互，同时仍可保证 Espresso 同步。
好消息是，Espresso 可执行上述所有工作；您不必针对多进程对界面设置进行任何更改。您可以继续像为单进程应用编写测试一样为多进程编写 Espresso 测试，Espresso 将自动处理进程间通信 (IPC) 和进程间同步。
下图展示了 Espresso 的多个实例如何相互通信：
如需了解有关 Multiprocess Espresso 及其用法的更多信息，请查看我们的文档和 Multiprocess 示例。
Idling Registry
有些应用使用 Gradle 中的构建风味或依赖注入框架（如 Dagger）来生成注册空闲资源的测试构建配置。其他应用只是通过其操作组件公开空闲资源。所有这些方法都存在一个问题，即它们会增加开发工作流程的复杂性，其中有些方法甚至会破坏封装。借助最新版本的 Espresso，通过引入新的
IdlingRegistry API，让您可以更轻松地在应用代码中注册空闲资源。IdlingRegistry 是一个轻量型注册表，它不会引入完整的 Espresso 库，因此，您可以更轻松地从您的应用代码注册资源。将此
API 与 Multiprocess Espresso 结合使用时，您可以在应用代码中注册来自任何进程的空闲资源。 Espresso 类的注册现已弃用。
Idling Resources
编写自定义空闲资源非常耗时，因此，Espresso 3.0.0 现在附带了更多可以直接使用的空闲资源，以同步您的线程。新资源包括：
IdlingThreadPoolExecutor 和 IdlingScheduledThreadPoolExecutor。我们还将提供更多资源！ 要利用新的空闲资源，请将以下新的依赖项添加到 build.gradle 文件：
androidTestCompile "com.android.support.test.espresso.idling:idling-concurrent:3.0.0"
此外，之前在 Espresso contrib 中弃用的
CountingIdlingResource 已在此版本中移除。因此，您需要更新您的测试以使用新的 CountingIdlingResource 软件包，其位于 Espresso 空闲资源中。如需完整的迁移详细信息，请参阅我们的版本说明。 ProviderTestRule
现在，测试
ContentProvider 对象时，您可以使用 ProviderTestRule 替代 ProviderTestCase2。ProviderTestRule 让您可以更轻松地使用 AndroidJUnit4 当前可用的其他测试规则。 ProviderTestRule 包括用于初始化的 API，以及针对正在测试的 ContentProvider 运行的命令。如果您的 ContentProvider 基于 SQLite 数据库，您可以使用用于设置数据库文件的 ProviderTestRule 命令和初始化命令。 如需了解更多信息，请查阅
ProviderTestRule 文档。 授予权限规则
Android M（API 级别 23）允许应用在运行时请求权限。不过，请求运行时权限的对话框将使测试进入无法继续的状态，从而导致测试失败。通过使用
GrantPermissionRule，您可以跳过所有弹出对话框，并模拟用户为您的应用授予运行时权限。
Android Test Orchestrator
AndroidJUnitRunner 通常在同一个仪器进程中运行所有测试，这会导致许多问题。例如，这些测试会共享它们在内存中的状态，如果一个测试崩溃，它将阻止测试套件的其余测试运行。
尽管可以通过发起序列
adb 命令隔离测试，但此进程会增加主机端处理负载。通过改用全新的 Android Test Orchestrator，您可以在设备上实现完全的测试隔离，如下图所示：
请注意，如果您的测试 需要 传递共享状态，则协调器会导致它们失败。此行为是设计使然。截至本博文发布时，Android Test Orchestrator 已进入 Beta 测试阶段，可通过命令行使用。我们计划不久推出 Firebase Test Lab 和 Android Studio 集成。
如需了解详细信息，请参阅 Android Testing Orchestrator 开发者指南。
AndroidJUnitRunner
AndroidJUnitRunner 现在包含许多附加功能：
- 您可以使用
JUnitParams。 - 您可以使用运行器参数来配置类加载器和自定义 JUnit 测试过滤器。
有时，作为测试工作流程的一部分，您需要对您实时创建和配置的操作组件进行测试。现在，您可以使用一个
InterceptingActivityFactory 配置 MonitoringInstrumentation（并扩展到
AndroidJUnitRunner）。您可以使用一个特定于测试的配置创建要测试的操作组件，无需依赖编译时注入。 上面的概述仅重点介绍了我们对 ATSL 进行的一些最重要变更。此外，还有更多值得探索的变更。如需完整的版本详细信息，请参阅我们的 版本说明。
最后，我们想感谢为此版本贡献功能的所有开发者。我们还要感谢来自 American Express、Slack 的移动工程团队的 Android 测试专家以及 GDE Chiu-Ki Chan，感谢他们与我们大力合作和针对 Android 测试支持库预发行版提供宝贵的反馈意见。
ATSL 团队祝您测试愉快！
