Fuchsia (CTF) 的相容性測試是一組測試，旨在為透過 Fuchsia SDK 提供給開發人員的應用程式設計介面 (API) 和應用程式二進位檔介面 (ABI) 元素 (例如標頭、FIDL 檔案) 提供涵蓋率。這個範本最初提議採用 RFC 0015，專案程式碼則位於 //sdk/ctf。
背景、動機和目標
CTF 的存在，可判斷在特定裝置上執行的 Fuchsia 平台版本，是否正確實作 (或相容) 特定 Fuchsia SDK 所公開的 API 和 ABI。換句話說，它證明建構作業正確實作 Fuchsia。
如果執行 Fuchsia 的系統通過了特定 ABI 修訂版本的 CTF 測試，則開發人員可以確保針對該修訂版本建構的元件可在系統上運作，且系統能回溯相容於該修訂版本。
每個 Fuchsia 平台版本都隨附一組軟體開發套件 (SDK)，當中包含工具、程式庫和標頭，可讓開發人員鎖定 Fuchsia 的 API 和 ABI。我們將 API 和 ABI 稱為 Platform Surface Area (或 PlaSA)。每個 SDK 都會與一組 CTF 測試搭配使用，藉此測試其公開的表面區域。測試將以來源和二進位格式提供。
CTF 測試僅含部分項目。但無法保證針對單一 SDK 建構的任何元件都能在 Fuchsia 的任何特定版本上執行。因此，CTF 必須搭配產品專屬的測試。
因此，CTF 就能以下列方式強制執行相容性：
平台開發人員，包括在 fuchsia.git 中工作的人員、系統整合商、產品開發人員和裝置開發人員
CTF 二進位檔測試可在搭載 Fuchsia 的裝置上執行，確保該裝置上的建構作業與 CTF 相關 SDK 的 ABI 相容。這可以提供回溯相容性保證：如果特定 SDK 的 CTF 通過，根據該 SDK 建構的程式將繼續運作，是強烈的指標 (但不是結論是結論)。也可以確定在裝置上執行的軟體不會經過樹狀結構內測試 (例如樹狀結構外裝置驅動程式) 不會變更平台行為。
如資料表所示：
| 跑步 → 違反 ↓ | CTF 北 | CTF N + 1 |
|---|---|---|
| 版本 N 的 SDK / 產品版本 | A | B |
| 版本 N + 1 的 SDK / 產品版本 | C | A |
在此情況下：
A = 想要確保產品版本正確實作其所宣稱的 ABI 修訂版本的使用者。
B = 使用者，希望確保產品版本與新版 ABI 修訂版本相容。Fuchsia 機構並未提供這類保證。
C = 想要確保產品版本與舊版 ABI 修訂版本回溯相容的使用者。Fuchsia 機構為程式碼鎖定舊版 SDK 的客戶提供這類保證。
SDK 供應商
CTF 來源測試可根據 SDK 進行建構，確保 SDK 與 CTF 的相關 SDK 相容。此外，CTF 包含一系列適用於 SDK 主機工具的測試。這些測試可以確信變更 SDK 並不會破壞開發人員程式碼和工作流程。舉例來說，我們可以針對包含 API 版本 N+1 支援的 SDK 建構 CTF for API 版本 N，藉此確認 SDK 是否造成 API 相容性故障。目前，CTF 專案支援唯一支援的 SDK 廠商是 Fuchsia 機構。
如資料表所示：
| 建構 → 違反 ↓ | CTF 北 | CTF N + 1 |
|---|---|---|
| 版本 N 的 SDK | A | B |
| 版本 N + 1 的 SDK | C | A |
在此情況下：
= 有人想確保 SDK 正確實作其聲明擁有權的 API 級別。這包括 Fuchsia 機構 (在樹狀圖小點測試)。
B = 使用者想確保 SDK 與新版 API 級別相容。Fuchsia 機構並未提供這類保證。
C = 使用者想確保 SDK 與舊版 API 級別回溯相容。Fuchsia 機構為程式碼鎖定舊版 SDK 的客戶提供這類保證。