本頁面由 Cloud Translation API 翻譯而成。

Fuchsia 的相容性測試

適用於 Fuchsia (CTF) 的相容性測試針對 Fuchsia 預先建構的各種 Fuchsia 軟體版本平台表面區域偵測相容性問題。

透過 CTF 測試，確保用戶端凍結到之前的發布里程碑與應用程式設計介面 (API) 相容透過以下方式提供給開發人員的應用程式二進位檔介面 (ABI) SDK。模擬行為變化卻發生在 Fuchsia 平台中破壞了預先編譯的用戶端。

CTF 基本上是由以下部分組成：

一種在版本分支版本上凍結構件的機制，然後在主要分支版本測試中納入這些構件
一組建構規則，用於選取要凍結的構件的建構規則，可簡化在。
一系列測試會使用這些建構規則，測試產品的相容性舊的用戶端程式碼和最新的平台途徑區域。
該組測試提供的涵蓋範圍系統會測試 FIDL 方法和系統呼叫的相容性，版本。

CTF 最初的提案是 RFC 0015，而專案位於 //sdk/ctf。

提振精神

Fuchsia 平台定義的表面積是由 Fuchsia SDK 中公開的 FIDL 通訊協定。開發人員可以下載，使用 Fuchsia SDK 編寫以 Fuchsia 系統為目標的軟體指定 API 級別

隨著 Fuchsia 平台的表面積不斷演變，以 FIDL 通訊協定的可用性註解表示：

protocol Entry {
  @available(added=12)
  SetValue(struct { value string; });

  @available(added=20)
  GetTimestamp() -> (struct { timestamp int64; });

  @available(added=13, removed=20)
  Encrypt();
};

在上述範例中，通訊協定 Entry 有三種方法：

SetValue，已在 API 級別 12 新增
GetTimestamp (已在 API 級別 20 新增)
Encrypt：已在 API 級別 13 新增，但在 API 級別中移除如果發現帳戶已不再需要 20 天，

使用 Fuchsia SDK 建構的元件必須宣告 API 級別進而影響他們看得到的定義請考量下列要點情境：

元件是以 API 級別 19 為目標：
- 已顯示「SetValue」和「Encrypt」。
- GetTimestamp 不存在，因為 API 級別 19 中尚未存在。
元件建立的目標 API 級別為 21：
- 已顯示「SetValue」和「GetTimestamp」。
- Encrypt 不存在，因為已在 API 級別 20 中移除。

Fuchsia 平台目前只支援部分 API 級別。已檢查支援的 API 級別的標準清單傳送至 fuchsia.git 存放區，並會用來判斷哪個 API 我們將支援 Fuchsia SDK 版本。

指定支援的 API 級別，確保用戶端可以連線僅適用於支援和保證實作的通訊協定但不保證平台行為而針對該 API 的預建元件將保持一致第二，自訂角色只能套用至專案或機構

對元件而言，確保一致行為至關重要在 fuchsia.git 存放區外建構，尤其是當這些物件元件會以預先建構的二進位檔下載產品圖片

例如：相容性問題

假設上述 Entry 通訊協定的簡化版本：

protocol Entry {
  @available(added=20)
  GetTimestamp() -> (struct { timestamp int64; });
};

GetTimestamp 方法會傳回 Entry 的時間戳記以秒為單位。

我們可以透過以下方式測試：

TEST(Timestamp) {
  EntrySyncPtr entry = CreateEntryAtMidnightJan1stUTC();
  ASSERT_EQ(entry.GetTimestamp(), 1704067200);
}

假設我們決定實際需要奈秒的精細程度，三會將 GetTimestamp 的實作變更為傳回奈秒，但請注意，FIDL 定義不會變更。

我們可以按照下列方式更新測試：

TEST(Timestamp) {
  EntrySyncPtr entry = CreateEntryAtMidnightJan1stUTC();
- ASSERT_EQ(entry.GetTimestamp(), 17040672000);
+ ASSERT_EQ(entry.GetTimestamp(), 17040672000000000);
}

這樣會通過「fuchsia.git」的所有支票並提交，導入Fuchsia 平台的相容性中斷。

錯誤時程

讓我們查看導致服務中斷的完整時間表。

SDK 異動前：假設 FooWidget 團隊實作他們的 FooWidget for Fuchsia。他們會下載 Fuchsia SDK 並建立指定 API 級別 20 的元件。這個元件使用 Entry 通訊協定並呼叫 GetTimestamp 方法。目前，GetTimestamp 會傳回秒數。

他們可以採用這種做法，因此 FooWidget 團隊發布一份 Fuchsia 文章。名為 foo-widget 的套件。經過檢查，這個套件的使用者但目標 API 級別為 20
FooWidget 隨附於 Fuchsia 產品：Fchsia 產品組合包含 foo-widget 套件和 Fuchsia 導入這個 API系統將以下列格式擷取 foo-widget 套件無需存取原始碼的預先建構二進位檔，但產品組合您會發現套件在建構時指定的 API 級別為 20，而且 Fuchsia 平台圖片支援 API 級別 20。
系統推出 SDK 變更：目前我們定義的變更高於 fuchsia.git，系統就會產生新的 SDK，已發布。
產品搭配新的 SDK 組合：產品存放區移至新的 SDK，並使用新的 Fuchsia 平台映像檔，與現有預建好的 foo-widget。
FooWidget 呈現該產品：當 foo-widget 元件呼叫 GetTimestamp()，結果將以奈秒為單位而不是幾秒，因此結果可能非常奇怪舉例來說，FooWidget 使用者介面可能開始顯示數百萬次因為這個模型將奈秒視為秒！

變更平台功能的行為具有危險性取決於舊行為

找出相容性問題

CTF 測試利用 Fuchsia 的發行分支程序。如果 CTF 測試失敗以舊版 Fuchsia 平台實作為目標的預建元件將會失敗。可以正常運作如下所示：

每個 Fuchsia 里程碑版本都含有 fuchsia.git 中的相關版本分支版本。代表 Fuchsia 平台推出時的狀態。
該平台實作會通過該平台的一系列測試發行分支。
一組構件包含在 CTF 構件套件中新的分支版本
建立和/或修改發布分支時，CTF 系統會編譯該分支版本的構件並上傳至 CIPD。
各支援的 API 級別適用的 CTF 構件會下載為 main 分支版本上的預先建構，會藉由轉動而破壞納入測試套件中
這些測試套件會針對最新的 Fuchsia 平台執行 main 分支版本。如果失敗，系統會封鎖 CL 提交作業。

這確切反映了建立元件的情況對舊版 Fuchsia SDK 和平台進行呼叫根據目前的 Fuchsia 平台預先建構。

背景和記錄

設有 CTF 以避免對實作的 Fuchsia 造成破壞性變更從平台進入的 API 和 ABI。

CTF 最初的設計目的是讓 Fuchsia 系統正確導入了月球表面而非特定 ABI 修訂版本這意味著檔案編輯是否可在系統上生效回溯相容

CTF 的目前用途是提供凍結機制和「thawing」測試不同版本分支中的測試成果

這項機制可以套用這項機制，確保目前的 Fuchsia 平台支援舊的 API 和 ABI 行為。此外，凍結的測試可能是套用至任意 Fuchsia 圖像，以達成原始目標不會產生 CTF。