Trade Federation（简称 Tradefed 或 TF）是一种连续的测试框架，专门用于在 Android 设备上运行测试。例如，Tradefed 用于运行兼容性测试套件 (CTS) 和供应商测试套件 (VTS)。
Trade Federation 是一款在主机上运行的 Java 应用，它会使用 ddmlib（DDMS 背后的内容库）通过 adb 与一部或多部 Android 设备进行通信。
我们在下面列出了 TF 的一些主要功能以及几个用例示例。也就是说，如果您想直接进入正题并开始使用，则可直接前往开始使用页面。
功能
- 模块化、灵活、可扩展的设计
- 已内置对运行很多不同类型 Android 测试的支持：instrumentation、uiautomator、原生测试/gtest、基于主机的 JUnit 测试等等
- 在 adb 的基础之上提供可靠性和恢复机制
- 支持同时在多部设备上调度和运行测试
有关如何运行现有测试（例如插桩测试）的最新信息，请参阅通过 TF 进行测试。
用例
Trade Federation 的模块化设计使得融入已有构建、测试和报告基础架构的环境非常简单。我们在下面列出了几个示范性用例，在这些用例中，tradefed 能够实施有效的可扩展测试做法。
首先，从“哪些部分可被修改，哪些部分固定不变？”这个问题来考虑潜在用例的格局非常有用。例如，原始设备制造商 (OEM) 可以修改框架、系统和硬件，但对现有应用的影响微乎其微。与此相反，应用开发者可以修改应用，但对系统或框架的大多数方面几乎没有控制权。
因此，每个用例中的实体将会具有不同的测试目标，并会具有不同的选项（如果一组测试失败的话）。尽管存在这些差异，Trade Federation 仍有助于确保每个测试流程有效、灵活且可扩展。
原始设备制造商
原始设备制造商会构建硬件，且通常会调整 Android 系统和框架以使其在该硬件上运行良好。OEM 可能会努力实现这些目标，同时在硬件和系统级别保持稳定性和性能，并确保框架变更不会破坏与现有应用的兼容性。
OEM 可以实现将在生命周期的目标设置阶段执行的设备刷写模块。该模块将在其执行期间完全控制设备，所以它可能会强制设备进入引导加载程序、进行刷写，然后强制设备重新启动回用户空间模式。与模块结合以连接到连续构建系统，这使得 OEM 能够在更改系统级固件和 Java 级框架时在其设备上运行测试。
当设备完全启动后，OEM 商将能够利用基于 JUnit 的现有测试，或者编写新测试，来验证相关功能。最后，他们可以编写一个或多个结果报告模块，以连接到现有的测试结果存储区，或者直接报告结果（例如通过电子邮件）。
应用开发者
应用开发者负责构建应用，他们构建的应用需要能够在各种平台版本和各种设备上运行良好。如果某个特定的平台版本和/或设备出现问题，唯一的补救措施就是添加解决方法并继续操作。对于大型开发者而言，测试流程可能会并入连续构建序列。对于小型开发团队而言，测试流程可能会定期或手动启动。
大多数应用开发者会使用 TF 中已有的 APK 测试安装模块。有一个版本可从本地文件系统安装，还有一个版本可安装从 build 服务下载的 APK。请务必注意，无论同一宿主机上运行着多少个 TF 实例，后一版本都能持续正常运行。
由于 TF 能够游刃有余地处理多部设备，所以按照该测试所用设备的类型对每项测试结果进行分类会很简便。因此，TF 有可能会分别为相应应用的每个版本生成一个二维（或多维）兼容性矩阵。
测试服务
举例来说，某项测试服务可能让应用开发者既能提交应用，又能在使用功耗测量工具来确定应用耗电量的设备上运行测试。这与之前的两个用例不同，因为服务构建器并不控制设备或正在运行的应用。
由于 Trade Federation 可运行任何能实现简单 IRemoteTest 接口的 Java 类，因此可以轻松编写可协调某些外部硬件与在设备上运行的测试用例的驱动程序。驱动程序本身可以生成线程、向其他服务器发送请求，或执行它可能需要的其他任何操作。此外，结果报告接口 ITestInvocationListener 的简单性和多功能性意味着，表示任意测试结果（例如，数字功率指标）传递到标准结果报告管道中。