| RFC-0141：CTF 程序 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 說明如何執行 CTF 測試，達到全面涵蓋範圍。 |
| Gerrit 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年-月-日) | 2021-09-20 |
| 審查日期 (年-月-日) | 2021-11-15 |
摘要
Fuchsia 相容性測試 (CTF) 現在會在提交佇列 (CQ) 中執行，確保新的平台程式碼不會破壞回溯相容性。不過，測試套件的品質取決於所含的測試，而我們的測試套件只包含少數測試。本文將說明平台適用的 CTF 計畫，以全面涵蓋 API 和 ABI。
提振精神
CTF 的用途是判斷在特定裝置上執行的 Fuchsia 平台建構版本，是否正確實作 (或相容於) 特定 Fuchsia SDK 公開的 API 和 ABI。換句話說，這項測試會證明建構作業正確實作 Fuchsia。
如果執行 Fuchsia 的系統通過特定 ABI 修訂版本的 CTF 測試，開發人員就能確信為該修訂版本建構的元件可在系統上運作，且系統可向後相容於該修訂版本。與我們關心的特定 ABI 和 API 修訂版本相關聯的測試，會在 CQ 系統中執行。
Fuchsia 軟體開發套件 (SDK) 包含工具、程式庫和標頭，可讓開發人員以 Fuchsia 的 API 和 ABI 為目標。我們將透過 SDK 向樹狀結構外開發人員公開的 API 和 ABI 稱為平台表面積 (PlaSA)。每個 SDK 都會搭配一組 CTF 測試，用來練習公開的介面區域。測試以來源和二進位形式提供。
如要讓這個系統發揮價值，我們必須有一套完整且健全的測試。強大的測試可重複執行：開發人員可藉此輕鬆找出要測試的平台行為，且不會出現不穩定情況。如果一組測試涵蓋該介面的所有記錄行為，即為完成。
截至 2021 年 9 月，CTF 套裝組合中已有幾項測試。本文的其餘部分將說明如何逐步建構完整且強大的測試集。
我們發現，許多與各團隊如何建構涵蓋範圍相關的程序問題，並未在本 RFC 中解決。舉例來說，我們不會具體說明追蹤進度的方式，也不會提供實作指引。這些問題不在範圍內，如有必要，後續的 RFC 將會解決這些問題。
利害關係人
稍後再填寫這個部分。
協助人員：
由 FEC 指派，負責在 RFC 程序中引導此 RFC 的人員。
審查者：
shayba@google.com，測試元件和程式庫 ananthak@google.com，測試基礎架構 abarth@google.com，Fuchsia TL
列出投票者 (贊成或反對)，FEC 會在決定是否接受或拒絕這項 RFC 時，將這些投票納入考量。
已諮詢：
列出應審查 RFC 的人員，但不必取得他們的核准。
社交：
這份文件已提供給 CTF 和測試基礎架構團隊。
設計
需求條件
我們有兩項基本規定，用來制定 CTF 政策。
首先，從長遠來看，CTF 測試應完整涵蓋 PlaSA，包括 ABI (目前定義為 Fuchsia 系統介面中的任何項目) 和 API (目前定義為需要 API 審查 +1 的任何項目)，這些項目會透過 SDK 向終端開發人員公開，以及預期的工具行為。如要瞭解涵蓋範圍的定義，請參閱下一節。
其次，CTF 測試應盡可能涵蓋 PlaSA 的預期和實際用途。我們需要涵蓋實際案例，因為如果測試無法反映開發人員對介面區域元素執行的操作，就無法聲稱測試提供任何程度的相容性。我們需要涵蓋預期案例，原因有二。首先，開發人員首次編寫 API 時，只會遇到預期情況。其次，我們認為開發人員在開發 API 時，編寫預期用戶端程式碼是很有用的練習。
在本節中，我們將說明如何透過 CTF 提供廣泛的平台涵蓋範圍。
涵蓋率
在討論平台達到全面涵蓋範圍的意義之前，我們先來瞭解 CTF 的涵蓋範圍。
請注意，在本文件中，「完整涵蓋範圍」並非指必須執行所有可能的行為，而是指必須執行所有記錄的行為 (包括成功和錯誤情況) 和所有介面。非正式來說，測試執行的每個介面都稱為「元素」。
CTF 團隊正在追蹤透過 SDK 匯出的 FIDL 和 C++ 方法涵蓋範圍。團隊會推動相關程序，確保涵蓋所有 FIDL 和 C/C++ 方法，並確保測試程式碼涵蓋 SDK 隨附的程式碼 (例如 libfdio 中的程式碼)。本文所指的「全面涵蓋」，是指 CTF 計畫追蹤的範圍。
不屬於 CTF 的測試不會計入涵蓋範圍。專屬測試 (即不開放且不屬於 Fuchsia 平台的測試) 也不會計入涵蓋範圍。
請注意，完整涵蓋範圍不代表所有 API 的測試品質良好且實用。CTF 計畫不會追蹤許多項目，例如我們無法測試每組可能的參數值 (每個採用 32 位元整數的 API 可能有 2^32 個值，我們不太可能進行 2^32 次測試)。因此，API 開發人員和審查員有責任確保我們提供高品質的涵蓋範圍。
換句話說，CTF 是一種機制，可協助我們強制執行相容性，但光靠 CTF 並不夠。但這還不夠。
為確保涵蓋範圍的品質，我們提供兩項經驗法則。開發人員可根據這些指標判斷測試涵蓋範圍是否足夠。
首先，根據API 說明文件評量標準，透過 PlaSA 公開的每個行為都應有測試，以確保該行為。舉例來說，文件評分標準指出，應記錄參數為空值時的行為。應透過 CTF 測試練習該行為。
請注意，許多 API 不符合說明文件評分標準。我們鼓勵您在開發 API 時編寫測試，因此編寫這類測試的過程，是充實文件內容並確保文件符合評分標準的好時機。
第二，如果行為變更導致應用程式程式碼 (在樹狀結構外執行) 發生回歸，則可能缺少 CTF 測試。CTF 測試應可確保新版本與舊版本相容。如果 Fuchsia 版本與舊版相容，該版本必須能夠執行以舊版為目標的軟體。因此，如果變更導致迴歸，進而中斷樹狀結構外的應用程式碼執行作業，表示有相容性行為未經過測試，也就是缺少 CTF 測試。
在某些情況下，平台行為可能會變更，以更符合文件說明。在這種情況下，變更應附上新的 CTF 測試。
如果我們想保留未記錄的行為，也可能會變更未記錄的行為，進而導致平台行為發生變化。在這種情況下，我們採取的做法不在本文的討論範圍內。CTF 測試不應刻意練習未記錄的行為。
CTF 層級
為盡可能提高 CTF 涵蓋率，我們將逐步推出更多 CTF 涵蓋率規定。隨著區域擴大涵蓋範圍，涵蓋率較低的層級會轉移至涵蓋率較高的層級。新增測試前，區域完全沒有等級。
特定層級的專屬政策會以引用區塊表示：
這是非規範性文字。
這是規範性文字。
第 1 級 (起步)
涵蓋範圍
CTF 的目標之一是確保相容性，而平台或 SDK 版本因行為變更導致客戶中斷，就是不相容的重要徵兆，因此我們建議盡快導入下列政策：
如果平台或 SDK 版本因 Fuchsia PlaSA API 或行為發生不相容的變更，導致 SDK 推出失敗或 Canary 版本失敗，則該重大變更的作者有責任確保新行為有相關文件，並提供涵蓋新行為的 CTF 測試。如果目前無法為該介面區域元素編寫 CTF 測試，則擁有該 PlaSA 元素的團隊必須優先制定開發計畫。
如果該行為不打算記錄，則可授予上述例外狀況。例外狀況可能包括記錄行為未經記錄的事實，或提供工具給使用者，協助他們識別自己依賴未記錄行為的事實。
面向 SDK 的新功能
我們預期開發人員會開始開發平台測試功能，並推出新的 SDK 相關功能。
凡是新增至 PlaSA 的項目 (例如新的 SDK 工具、FIDL 通訊協定或方法，以及 C++ 標頭)，只要是隨合作夥伴或公開 SDK 一併發布，都必須通過 CTF 測試。凡是透過 API 審查取得新 API 元素，並將其納入公開或合作夥伴 SDK 的人員，都必須規劃在新 API 中加入 CTF 測試。
平台變更的平台團隊有責任提供 CTF 測試，並與 CTF 計畫合作進行測試。
API 開發人員在執行測試計畫時，強烈建議他們向 API 審查人員說明打算編寫的測試類型，以便共同瞭解測試計畫，包括哪些測試的優先順序最高。
如果平台團隊針對您擁有的 API 和 ABI 所有破壞回溯相容性的變更，都以測試回應，並為新的平台合約功能和行為編寫測試，該團隊就屬於第 1 層。
請注意，API 審查的 CTF 測試規定僅適用於 PlaSA API 元素。只要 API 未透過 SDK 向終端開發人員公開，就不需要相關的 CTF 測試。
第 2 級 (建築物)
API/ABI 演進
因為變更程式碼時發生中斷的可能性，高於長期穩定的程式碼，且為了提供漸進式涵蓋範圍，我們建議導入下列政策：
無論是新的或現有的 PlaSA 元素，只要對 API 或行為進行修改，都必須附上涵蓋變更的 CTF 測試。
如果目前無法為現有的公開或合作夥伴介面區域元素編寫 CTF 測試，負責團隊必須先提供開發這些測試的計畫，然後再進行變更，並在與 API 審查人員達成共識後，盡快執行該計畫。
在這個層級，我們強烈建議您先編寫 CTF 測試，再大幅重寫或替換任何會影響 PlaSA 行為的服務、工具或程式庫，無論新程式碼是否會改變該行為。舉例來說，如果我們要從頭重寫核心，但保留相同的 VDSO 行為，則應在重寫前編寫該行為的測試。
如果您完成第 1 層的所有必要事項，並確保您對 ABI 或 API 所做的所有變更都涵蓋在 CTF 測試中，即達到第 2 層。
第 3 級 (完成)
長尾
我們瞭解 PlaSA 有許多長期穩定的元素，其中許多元素並未積極開發。最終目標是涵蓋整個 PlaSA。
各個領域都必須制定計畫，全面涵蓋所屬的 PlaSA 元素，並交付該計畫的成果。
如果您已完成第 2 層的所有必要事項，且您擁有的 PlaSA 元素涵蓋範圍完整，即表示已完成。
實作
Fuchsia 團隊將啟動 CTF 計畫，鼓勵全面涵蓋平台。多個資訊主頁會追蹤 CTF 涵蓋範圍。這些資訊主頁的詳細資料會不斷演進，且不在本 RFC 的討論範圍內，但會追蹤每個 PlaSA 元素的基礎測試涵蓋範圍。
CTF 團隊負責為開發人員提供執行測試所需的基礎架構。如果測試開發人員未看到所需功能，應與 CTF 團隊合作，確保他們提供的測試可在 CTF 基礎架構中執行。開發人員可以提出錯誤報告，與 CTF 團隊聯絡。
API 審查程序也會進行調整，以配合 CTF 測試必須伴隨變更的要求。如果區域位於第 2 級或更高層級，對 PlaSA 元素進行修改或新增時，必須通過 CTF 測試。這項規定最終會擴及所有領域；屆時，我們預計會將測試正式納入 API 審查程序。
效能
測試的存在不會影響平台效能。我們必須仔細追蹤 CTF 測試的機器使用情況，確保不會超過 Fuchsia 機器容量。
人體工學
CTF 團隊的任務是確保各領域都能輕鬆編寫基本的 CTF 測試，並提供執行這些測試的基礎架構。不負責特定領域的基礎架構和架構。
回溯相容性
這項提案不會破壞回溯相容性。目標是建立機制，強制執行 Fuchsia 平台的回溯相容性。
安全性考量
我們認為 CTF 計畫不會對 Fuchsia 安全性造成負面影響。
隱私權注意事項
我們認為 CTF 計畫不會對 Fuchsia 的隱私權屬性造成負面影響。
測試
由於這份 RFC 主要詳述程序，因此不需要詳細的測試計畫。
說明文件
團隊會與開發人員關係和技術作家合作，提供詳細實用的指引，說明如何撰寫有效的 CTF 測試。
缺點、替代方案和未知事項
這項異動會為 API 開發人員帶來大量前期工作，他們通常不會在 API 變更中加入測試。我們認為，要求開發人員在發布 API 前，先編寫使用這些 API 的測試，有助於在發布前改善 API 的人體工學。
既有技術和參考資料
開發新 API 時，Android 系統也有類似的 CTF 納入程序。
許多程式設計語言對新 API 也有類似的測試要求。