针对 Fuchsia (CTF) 的兼容性测试是一组测试，旨在涵盖通过 Fuchsia SDK 提供给开发者的应用编程接口 (API) 和应用二进制接口 (ABI) 元素（例如头文件、FIDL 文件）。其最初提议为 RFC 0015，项目代码位于 //sdk/ctf。
背景、动机和目标
CTF 旨在确定在特定设备上运行的 Fuchsia 平台 build 是否正确实现（或兼容）特定 Fuchsia SDK 公开的 API 和 ABI。换句话说，它证明 build 正确实现了 Fuchsia。
如果运行 Fuchsia 的系统通过了特定 ABI 修订版本的 CTF 测试，则其开发者可以确信为该修订版本构建的组件适用于系统，并且系统可向后兼容该修订版本。
每个版本的 Fuchsia 平台都捆绑了一组软件开发套件 (SDK)，其中包含工具、库和头文件，可让开发者以 Fuchsia 的 API 和 ABI 为目标。我们将 API 和 ABI 称为平台表面区域（或 PlaSA）。每个 SDK 都将与一组 CTF 测试配对，用于测试其公开的 Surface 区域。这些测试将提供源代码和二进制文件形式。
CTF 测试并不全面。他们无法保证针对一个 SDK 构建的任何组件都可以针对任何特定 Fuchsia 版本运行。因此，CTF 必须配合特定于产品的测试进行补充。
考虑到这一点，可以使用 CTF 通过以下方式实现兼容性：
面向平台开发者（包括在 fuchsia.git 工作的开发者）、系统集成商、产品开发者和设备开发者
可以针对运行 Fuchsia 的设备上运行 CTF 二进制文件测试，以确保该设备上的 build 与 CTF 的关联 SDK 进行 ABI 兼容。这样可以强制执行向后兼容性保证：如果给定 SDK 的 CTF 通过，就意味着根据该 SDK 构建的程序将继续正常运行（但并非硬性指示）。此外，它还可以让您确信，在树内测试未执行且在设备上运行的软件（例如树外设备驱动程序）不会更改平台的行为。
以表格形式：
| 跑步 → 反对 ↓ | CTF N | CTF N + 1 |
|---|---|---|
| 版本 N 的 SDK / 产品 build | A | B |
| 版本 N + 1 的 SDK / 产品 build | C | A |
其中：
A = 希望确保产品 build 正确实现其声明的 ABI 修订版本的人员。
B = 希望确保产品 build 向前兼容较新的 ABI 修订版本的人员。Fuchsia org 不提供这种保证。
C = 希望确保产品 build 向后兼容较旧的 ABI 修订版本的人员。Fuchsia 组织为代码针对旧版 SDK 的客户提供了这种保证。
对于 SDK 供应商
可以针对某个 SDK 构建 CTF 源代码测试，以确保该 SDK 与 CTF 的关联 SDK 兼容。此外，CTF 还包含针对 SDK 主机工具的一系列测试。通过这些测试，您可以确信对 SDK 所做的更改不会破坏开发者代码和工作流。例如，我们可以针对支持 API 版本 N+1 的 SDK 构建适用于 API 版本 N 的 CTF，看看该 SDK 是否破坏了 API 兼容性。目前，CTF 项目支持的唯一 SDK 供应商是 Fuchsia 组织本身。
以表格形式：
| 构建 → 反对 ↓ | CTF N | CTF N + 1 |
|---|---|---|
| 版本 N 的 SDK | A | B |
| 版本 N + 1 的 SDK | C | A |
其中：
A = 希望确保 SDK 正确实现其声明的 API 级别的人员。其中包括 Fuchsia 组织（在树顶端测试）。
B = 希望确保 SDK 向前兼容新 API 级别的人员。Fuchsia org 不提供这种保证。
C = 想要确保 SDK 向后兼容较低 API 级别的人员。Fuchsia 组织为代码针对旧版 SDK 的客户提供了这种保证。