| RFC-0141：CTF 程序 | |
|---|---|
| 狀態 | 已接受 |
| 區域 |
|
| 說明 | 說明讓 CTF 測試全面涵蓋的過程。 |
| 變更 | |
| 作者 | |
| 審查人員 | |
| 提交日期 (年/月) | 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。我們將 API 和 ABI 稱為 Platform Surface Area (PlaSA) 透過 SDK 向外樹狀結構外結構開發人員公開的 API 和 ABI。每個 SDK 都有一組 CTF 測試 (用於執行其公開的介面區域)。我們提供來源和二進位格式的測試。
為了讓系統提供價值，我們必須有一套完善且完整的測試組合。健全的測試可重複執行：這類測試可讓開發人員輕鬆識別要測試的平台行為，且不會表現不穩定。如果一組測試會執行該介面所有記錄的行為，即表示測試已完成。
截至 2021 年 9 月，CTF 套件中有許多測試項目。在本文件的其餘部分，我們將找出如何長期打造完善且完整的測試組合。
我們注意到，有許多程序問題與各團隊如何建構涵蓋範圍未受此 RFC 所處理有關。舉例來說，我們不會明確指出追蹤進度的方式，也不會提供實作指南。這些問題超出處理範圍；如有必要，後續的 RFC 將處理這些問題。
相關人員
將於稍後填寫。
講師：
受 FEC 指派的使用者透過 RFC 程序阻斷這個 RFC。
審查者：
shayba@google.com，測試元件和程式庫 anthak@google.com，測試基礎架構 abarth@google.com、Fuchsia TL
FEC 會考量投票結果 (+1 或 -1) 的使用者，在決定該 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 是一項有助於我們強制執行相容性的機制，但本身並不夠。這是必要步驟，但還不夠。
為了確保涵蓋範圍，我們制定了兩項準則。開發人員可以藉此判斷自己的涵蓋範圍是否適當。
首先，根據 API 說明文件評分量表記錄的所有透過 PlaSA 公開的行為，也應該有一個測試保證這項行為的測試。例如，說明文件的評分量表指出應記錄參數為空值時的行為。您應使用 CTF 測試來練習。
請注意，許多 API 都不符合說明文件評分量表。我們鼓勵撰寫測試做為 API 開發的一環，因此撰寫這類測試的程序是擴展說明文件的好時機，並確保其符合評分量表要求。
再者，如果行為變更導致應用程式程式碼在樹狀結構外執行迴歸，表示可能缺少 CTF 測試。CTF 測試應保證新版本呈現的行為與舊版相容。如果 Fuchsia 版本與較舊的版本相容，該版本必須能夠執行以該版本為目標的軟體。因此，如果變更造成應用程式程式碼無法使用樹狀結構的迴歸，系統會產生未經測試的相容性行為，因而缺少 CTF 測試。
在某些情況下，平台行為可能會變更，讓平台行為更符合說明文件。在這種情況下，變更應隨附新的 CTF 測試。
如果平台行為發生變化，也可能造成我們想要保持未記錄的行為，變成未記錄的行為。這種情況不在本文件的討論範圍內CTF 測試不應刻意進行未記錄的行為。
CTF 層級
為盡可能擴大 CTF 涵蓋範圍，我們會逐步推出更多 CTF 涵蓋範圍要求。隨著區域的涵蓋範圍擴大，他們會從較少涵蓋層級移至更多涵蓋層級。在新增測試之前，區域根本不會收費。
指定階層的具體政策是由引用文字加以設定：
這是非制式的文字。
這是命名原則的文字。
第 1 層 (起始)
覆蓋故障
CTF 的目標之一是確保相容性，而與相容性的重要跡象，在於平台或 SDK 版本因行為改變而破壞客戶的情況，因此我們建議盡快採用下列政策：
如果平台或 SDK 版本因為 Fuchsia PlaSA API 或行為的回溯不相容變更導致 SDK 滾動失敗或初期測試版本失敗，則破壞性變更的作者必須負責提供新行為的說明文件，以及涵蓋新行為的 CTF 測試。如果您目前無法針對該表面區域元素編寫 CTF 測試，則擁有該 PlaSA 元素的團隊必須優先制定計畫來開發這些測試。
如果行為打算未記載，我們可能會授予上述例外情況。例外狀況可能涉及記錄該行為並非刻意沒有記錄，或是為使用者提供工具，協助他們識別他們依賴未記錄的行為。
面向 SDK 的新功能
我們期望開發人員除了開發平台測試功能外，也開始開發新的 SDK 功能。
合作夥伴或公用 SDK 隨附的新 SDK 工具 (例如新的 SDK 工具、FIDL 通訊協定或方法和 C++ 標頭) 新增內容都必須通過 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 或 PlaSA 元素所做的任何修改，都必須搭配涵蓋變更的 CTF 測試。
如果您目前無法為現有的公開或合作夥伴途徑區域元素編寫 CTF 測試，負責的團隊必須在變更前提供開發測試的計畫，並盡快按照計畫的 API 審查人員共識執行該計畫。
在這個級別中，我們強烈建議在大幅重新編寫或替換任何會影響 PlaSA 行為的服務、工具或程式庫之前編寫 CTF 測試，無論新程式碼是否用於變更該行為。舉例來說，如果我們想要從頭開始重寫核心，但保留相同的 VDSO 行為，則應在重寫前編寫該行為的測試。
已執行第 1 級需要的所有操作，且確定您對 ABI 或 API 進行的所有變更都涵蓋 CTF 測試，表示您已經達到級別 2。
第 3 級 (完整)
長尾
我們瞭解許多長期穩定的 PlaSA 元素，其中許多元素都不是積極開發。最後，我們想提供整個 PlaSA 的涵蓋範圍。
每個領域都必須制定計畫，以便完整涵蓋其擁有的 PlaSA 元素，並提供該方案的結果。
如果您完成第 2 級需要的所有工作，並擁有您擁有的 PlaSA 元素的完整涵蓋率，就大功告成了。
實作
CTF 計畫是由 Fuchsia 團隊發起，鼓勵擴大平台涵蓋範圍。多個資訊主頁將追蹤 CTF 的涵蓋率。這些資訊主頁的詳細資料會不斷更新，而且不在這個 RFC 的範圍內，但會追蹤每個 PlaSA 元素的基本測試涵蓋範圍。
CTF 團隊負責為開發人員提供執行測試所需的基礎架構。如果測試開發人員沒看到需要的功能，應與 CTF 團隊合作，確保他們能提供可在 CTF 基礎架構中執行的測試。開發人員可以回報錯誤，藉此與 CTF 團隊聯絡。
另外，API 審查也會配合 CTF 測試伴隨變更的需求調整。如果是第 2 級以上的區域，PlaSA 元素的修改或新增內容就必須進行 CTF 測試。該規定最終將擴大適用所有領域，屆時我們預計將透過 API 審查作業正式執行測試。
效能
測試的存在對平台效能沒有任何影響。我們必須仔細追蹤 CTF 測試的機器使用情形，確保測試不會超過 Fuchsia 的機器容量。
人體工學
CTF 團隊的任務是確保區域可輕鬆撰寫基本的 CTF 測試，且擁有執行這些測試的基礎架構。而且不適用於特定領域的基礎架構和架構。
回溯相容性
本提案不會破壞回溯相容性。我們的目標是建立機制，為 Fuchsia 平台強制執行回溯相容性。
安全性考量
我們不認為 CTF 計畫會對 Fuchsia 安全性造成負面影響。
隱私權注意事項
我們不認為 CTF 計畫會對 Fuchsia 隱私權屬性造成負面影響。
測試
這個 RFC 主要會詳細說明程序，因此不需要製定詳細的測試計畫。
說明文件
我們的團隊會與 DevRel 和技術撰寫者合作，提供詳盡且實用的指南，協助您瞭解如何編寫有效的 CTF 測試。
缺點、替代方案和未知
這項變更可為 API 開發人員帶來重要的前期作業，這類開發人員通常不包含 API 變更的測試。我們認為要求開發人員在發布之前撰寫使用其 API 的測試，可提升這些 API 在發布前的需求。
先前的圖片和參考資料
在開發新的 API 時，Android 系統在開發新 API 時，也會提供與 CTF 納入項目類似的程序。
許多程式設計語言對於新的 API 也有類似的測試需求。