Trade Federation（简称 Tradefed 或 TF）是一个持续测试框架，旨在在 Android 设备上运行测试。例如，Tradefed 用于运行兼容性测试套件 (CTS)和供应商测试套件 (VTS)。
Trade Federation 是一个 Java 应用，在主机上运行，并使用 ddmlib（DDMS 后面的库）通过 adb 与一个或多个 Android 设备通信。
我们在下面列出了 TF 的一些主要功能，以及一些示例用例。也就是说，如果您想立即开始使用，可以直接前往从这里开始页面。
功能
- 模块化、灵活、可扩展的设计
- 内置支持运行多种不同类型的 Android 测试：Instrumentation、uiautomator、原生/gtest、基于主机的 JUnit 等
- 在 adb 之上提供可靠性和恢复机制
- 支持并行调度和运行多个设备上的测试
请参阅通过 TF 进行测试，了解有关如何运行现有测试（例如Instrumentation）的最新信息。
用例
Trade Federation 的模块化使其能够直接插入具有现有构建、测试和报告基础架构的环境。我们在下面列出了一些演示性用例，其中 Tradefed 可以实现高效、可扩展的测试实践。
首先，从“哪些部分是可修改的，哪些部分是静态的？”这个问题来看，考虑潜在用例的情况非常有用。例如，设备 OEM 可以修改框架、系统和硬件，但对现有应用几乎没有或根本没有影响。另一方面，应用开发者可以修改应用，但对系统或框架的大多数方面几乎没有控制权。
因此，每个用例中的实体都将有不同的测试目标，并且在出现一组测试失败的情况下，将有不同的选择。尽管存在这些差异，Trade Federation 仍可以帮助使他们的每个测试过程都高效、灵活且可扩展。
设备 OEM
设备 OEM 构建硬件，并且经常调整 Android 系统和框架，以使其在该硬件上良好运行。OEM 可能会努力实现这些目标，同时保持硬件和系统级别的稳定性和性能，并确保框架更改不会破坏与现有应用的兼容性。
OEM 厂商可以实现一个设备刷写模块，该模块将在生命周期的目标设置阶段执行。该模块在其执行期间将完全控制设备，这将允许它潜在地强制设备进入引导加载程序，进行刷写，然后强制设备重启回到用户空间模式。结合一个与持续构建系统绑定的模块，这将允许 OEM 厂商在其更改系统级固件和 Java 级框架时在其设备上运行测试。
一旦设备完全启动，OEM 厂商将能够利用现有的基于 JUnit 的测试，或编写新的测试，来验证感兴趣的功能。最后，他们可以编写一个或多个结果报告模块，以绑定到现有的测试结果存储库，或直接报告结果（例如，通过电子邮件）。
应用开发者
应用开发者构建的应用需要在各种平台版本和各种设备上良好运行。如果在特定平台版本和/或设备上出现问题，唯一的补救方法是添加一个变通方法并继续前进。对于较大的开发者，测试过程可能会被纳入持续构建序列中。对于较小的开发者，它可能会定期或手动启动。
大多数应用开发者将使用 TF 中已存在的 apk 测试安装模块。有一个版本可以从本地文件系统安装，以及一个可以安装从构建服务下载的 apk 的版本。重要的是要注意，后一个版本将继续与在同一主机上运行的任意多个 TF 实例正常工作。
由于 TF 擅长处理多个设备，因此可以轻松地按用于该测试的设备类型对每个测试结果进行分类。因此，TF 可能会为应用程序的每个构建生成一个二维（或多维）兼容性矩阵。
测试服务
例如，测试服务可能允许应用开发者提交应用并在配备功率测量工具的设备上运行测试，以确定应用的功耗。这与之前的两个用例不同，因为服务构建者不控制设备或正在运行的应用程序。
由于 Trade Federation 可以运行任何实现简单 IRemoteTest 接口的 Java 类，因此编写驱动程序来协调某些外部硬件与设备上正在运行的测试用例非常简单。驱动程序本身可以生成线程、向其他服务器发送请求，或执行它可能需要的任何其他操作。此外，结果报告接口 ITestInvocationListener 的简单性和通用性意味着，同样可以轻松地将任意测试结果（包括例如，数值功率指标）表示到标准结果报告管道中。