针对 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 兼容。这样可以强制执行向后兼容性保证：如果给定 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 org 为代码以较低版本 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 org（在树顶端进行测试）。
B = 希望确保 SDK 向前兼容新 API 级别的人员。Fuchsia org 不提供这种保证。
C = 希望确保 SDK 向后兼容旧 API 级别的人员。Fuchsia org 为代码以较低版本 SDK 为目标平台的客户提供了这种保证。