- 專案主管：shayba@google.com、ananthak@google.com、fsamuel@google.com
- 專案合作夥伴：borthakur@google.com、jasoncampbell@google.com、lite@google.com、ppi@google.com
- 區域：測試
問題陳述
目前缺乏 Fuchsia 平台和產品開發人員進行樹狀結構外系統測試時的需求，或符合錯誤工具的要求，因而導致缺少測試涵蓋範圍或品質不佳的測試。
以 Fuchsia 為基礎的產品開發 (在 Fuchsia 來源樹狀結構 (或 OOT) 外進行) 採用無沙箱防護的系統測試，這類測試可在平台明確定義合約外執行 Fuchsia 平台。這是因為平台元件通常不提供執行必要的檢測方式，以滿足產品測試需求。測試作者已能找出方法規避這些限制，但這些解決方案會導致測試品質不佳。
即使 Fuchsia 平台的開發程序參與 OOT 測試，但測試可能會規避平台合約，因此 Fuchsia 的能力難以更新。
什麼是系統測試？
系統測試是在一組完整的系統上進行測試，目的是驗證系統是否符合特定需求。在實際測試金字塔中，系統測試補充單元測試和整合測試，以填補只能透過測試中完整系統解決的測試落差。
系統測試有時也稱為：
端對端 (或 e2e) 測試，尤其是在系統測試的範圍超過特定目標裝置以一併納入時，包括透過網路介面的遠端伺服器或控制主機機器。
關鍵使用者歷程 (CUJ) 測試，尤其是以模擬和使用者自動輸入和輸出內容形式呈現測試的情況，例如透過插入輸入事件 (例如按下按鈕)，並將 UI 狀態摘要或螢幕截圖與預期的測試結果進行比較。
此外，您還可以進一步檢測這些測試來產生其他值，如下所示：
效能測試除了執行產品 CUJ 外，測試控管也會收集時間、追蹤記錄、每秒影格數統計資料等效能資訊。
持續性測試，在緊密迴圈中練習相同的 CUJ，系統會監控系統是否有壓力跡象，例如資源流失 (RAM、帳號代碼等) 或當機情形。
也有整個類別的系統測試會運動平台功能，並樹狀結構內開發。這些欄位不在本文件的涵蓋範圍內。
Fuchsia 今天的系統測試挑戰
非密封舊版 (v1) 元件測試
Fuchsia 的元件架構提供廣泛的測試支援，在測試環境和其他系統之間達到高度隔離狀態。舊版 (CFv1) 測試仍支援測試尚未遷移至 CFv2 的舊版元件。雖然大部分的實際工作環境元件仍為 CFv1，但大多數測試 (>70%) 都使用 CFv2 測試架構，因為其更穩定，並為開發人員提供了一些新功能。
基於傳統原因，v1 測試執行階段在許多方面並不密封，例如藉由允許存取某些真實系統服務的方式。因此，在無意間，許多 CFv1 測試實際上是以系統測試的形式運作。這些測試有多個問題，包括：
由於測試的完整範圍範圍非常廣泛，或並未嚴格定義，因此測試失敗可能很難進行疑難排解。
測試會受到外部狀態的影響，或是保留外部狀態做為副作用。因此，這些測試可以與其他這類系統測試交叉溝通，導致執行個體故障 (「偽造」) 或在不穩定的條件下重現，例如，以不同的順序重新執行相同的測試。
上述測試假設實作細節不在約定合約中的其他系統元件。
元件測試架構的設計宗旨，是專門用來撰寫隔離的密封單元測試和整合測試。在這類測試中，任何失敗的原因都只能來自測試領域。基於隔離的期望，我們也預期任兩個測試可以並行或任意序列執行，而不影響結果。使用已淘汰的 CFv1 功能來破壞測試沙箱，並編寫系統測試會破壞這些保證，並造成難以進行疑難排解的情境。許多說過測試的作者不知道他們是在實證系統測試。
違反 Fuchsia 系統介面的 OOT CUJ 測試
如果是 OOT 軟體，與 Fuchsia 平台互動的預期和支援方式是透過 Fuchsia 系統介面 (FSI)。不過，現今的 OOT 開發人員提供相關工具，可讓測試作者規避這個介面並違反平台產品合約。
為 Fuchsia 編寫指令碼 (SL4F) 是一種系統自動化架構，旨在編寫全面系統測試。
SL4F 是以「Scripting Layer for Android (SL4A)」為靈感來源。主要用於樹狀結構內平台系統測試。特別是 SL4F 有助於移植這類內容 (例如 Android Comms Test Suite (ACTS) 測試)，其傳達與相同的基礎 JSON-RPC/HTTPS 通訊協定來驅動目標裝置。這個安排對 Fuchsia 連線測試非常有幫助。
SL4F 作為系統自動化架構，也可用來測試 CUJ。例如，SL4F 會針對平台 CUJ 測試提供技術支援。
不過，SL4F 並不適用於 OOT 測試。系統會透過 FSI 以外的通訊協定與 SL4F 互動，且未提供與 FIDL 相同的改進機制。您可以透過導入新的門面來擴充 SL4F 的自動化功能，但所有立面都必須樹狀結構內開發和建構。因此，針對定義及開發的 OOT 產品測試 CUJ 時，使用 SL4F 可引發下方列出的一些問題。
允許過度侵入測試的另一個常見機制是使用 SSH 取得遠端殼層，並在主機和目標之間複製檔案。這與使用 SSH 做為通道通訊協定不同，這對於執行個體進行 Overnet 傳輸非常有用。
目前 Fuchsia 的工程版本包含 SSH Daemon，這個 SSH Daemon 可在無沙箱限制的情況下存取全域命名空間，並將 dash 殼層提供給用戶端。相同的 Daemon 也允許 SCP 功能達到與全域命名空間類似的全域命名空間讀取/寫入權限，例如全域可變動儲存空間。很多時候，這個做法只是 FSI 的一個問題，可讓測試作者觀察或變更在可變動儲存空間中的狀態，以入侵平台元件的支援介面，藉此仰賴平台實作詳細資料，例如 Fuchsia 基本套件的名稱。
針對使用 Dart 中 SL4F 用戶端程式庫的執行個體，測試作者能連結 SSH 和 SCP 存取權。
細微測試模式
SL4F 為測試作者提供許多操控及觀察系統狀態的方法。其中有些機制會略過平台產品合約和必要的抽象層。您在編寫 SL4F 測試時不一定要使用這些機制，且並非所有測試都一定會使用這些機制。但秉持這些精神的精神，將許多反模式納入我們的 SL4F 測試清單。
值得注意的是，這些模式是因必要性不足而開發的，因為平台無法提供完善的替代方案來滿足測試需求。我們在下方列出了這些模式，不批評平台開發人員或測試作者，而是為了瞭解及分類目前必須償還的技術債。
透過非合約觀察狀態
測試中的程式碼可能會透過「檢查」或「檢查」功能，將狀態的相關資訊傳送至系統記錄。這些實用的工具可將執行個體的診斷資料收集為快照。但無法當做合約。Fuchsia 可使用 FIDL 定義強型類型的合約，且該合約具有穩定性和演進機制，例如與二進位檔相容的傳輸格式與版本管理變更，讓非協調的用戶端和伺服器交換 FIDL 訊息。FIDL 專為此用途而設計，只旨在小心使用，而任意文字記錄和檢查則不是。
有些範例特別值得注意
測試中的記錄檔：部分長期測試會使用標示為「錯誤」等級或更高嚴重性等級的記錄檔，找出產品在測試期間遇到非預期的狀況。可惜的是，在測試執行期間發出的「錯誤」訊息，通常從測試作者的觀點視為良性。因此，長期測試作者難免會一直保留已記錄錯誤訊息的許可清單。
在測試中檢查：部分測試驅動程式會讀取所驅動元件的資訊，以便觀察這些元件的狀態。由於 Inspect 是類型資料，可做為單一連貫的快照取得，因此很適合用來根據元件的作者診斷元件的目前狀態。不過，如果用作平台元件與產品測試之間的合約，會使 ABI 看起來很明顯，而且經常會導致毀損。這類故障並不容易排解，因為在基礎平台變更抵達後數週 (在嘗試執行 SDK 擲骰子時) 可能會發生這類錯誤。
透過非合約處理狀態
SL4F 測試可對主機進行許多控制，包括在無沙箱機制的殼層 (即透過全域命名空間) 中執行任意 SSH 指令，以及對全域不可變動與可變動儲存空間的完整讀取/寫入權限。以下列舉幾個重要例子：
終止和重新啟動程序：這通常用於測試中的設定和拆解處理常式。意圖為陽性，測試會想清除任何先前的狀態，並重新開始。不過，測試中的平台元件並不需要經過測試，才能確保其執行多次或以不同順序重新啟動，而這往往會導致不穩定的行為。
這種做法的另一個問題是，讓 OOT 測試終止平台程序時，程序名稱 (不屬於平台合約的一部分) 就會變成合約。如違反預定的介面和合約，會讓平台重構工作更加困難，並讓 OOT 測試更穩定。
操縱可變動儲存空間：執行個體通常會使用這種明顯的沙箱違規行為，以插入使用者憑證做為某些 CUJ 測試的設定步驟。該狀態會於測試讀取的程式碼讀取狀態之前插入，而不是執行憑證插入的預定介面。如果時間不對，測試就會失敗。如果清理失敗，後續測試可能會因交叉測試而失敗。
全域可變動檔案系統存取權的另一個用途，是使用全域的 /tmp 儲存空間目錄做為測試結果、構件和診斷的暫存區域，以處理測試期間收集的執行個體效能追蹤記錄。再次提醒，這是測試無法清理狀態、透過交叉跟蹤或在其他方式註入錯誤或不穩定行為的機會。
不同元件執行個體的獨立儲存目錄可以在同一個分區上管理，因為為不同元件建立個別分區的成本高昂，而且缺乏彈性。隔離方法是在共用分區上建立特定目錄版面配置。目錄版面配置反映平台實作的詳細資料，例如元件拓撲，或元件管理服務如何將拓撲轉換為檔案系統零件。這裡同樣是平台實作細節，而且可能會隨時間改變，而不應向 OOT 測試公開。
結果
在同一項測試中混合使用開放式測試和封閉測試，會產生品質低劣的測試，也就是設定不相關的期望測試，並以各種方式協調及觀察狀態，測試的軟體設計並非支援測試軟體。
以 Fuchsia 平台來說，長久以來都是使用系統測試工具的疏忽，演變成當前情況。畢竟我們可能發現自己接受了許多外來測試，但這些測試並不適用於現有類別，而無與倫比測試最佳做法。
更糟的是，這些測試所仰賴的平台實作詳細資料所提供的詳細資料不可用於演進。許多 FSI 的例子都是由 FIDL 精確定義。FIDL 的設計可讓平台開發人員進行與 ABI 相容的變更，或偵測現有 ABI 何時因特定變更而損毀。FIDL 提供開發人員在不破壞 ABI 的情況下變更類型和通訊協定的多種方式，或以受控制的方式引入中斷：穩定的通訊協定方法序數、彈性資料表、版本管理等。
相較之下，這與使用程序名稱做為合約使用的程序名稱 (例如測試終止程序時) 則是兩者的差別。平台元件實作的程序名稱絕對不隸屬於 FSI，部分原因是對演化沒有負擔 - 任何變更都是破壞性變更、版本管理沒有足夠的空間，且很少能夠同時執行新程序和新程序，以便達到暫時的法規遵循期間。這項規定也適用於全域檔案系統路徑、內部檔案格式、免費文字記錄和其他這類非合約。
缺少 OOT 支援
SL4F 用戶端可以向包含的平台映像檔中隨附的 SL4F Daemon 自動執行系統自動化作業，該映像檔會透過 Fuchsia SDK 執行作業發布給 OOT 測試人員。Daemon 可以執行不同工作，自動化調度管理及檢查系統狀態歸類為「門面」。系統通常在這樣的方面運作得很好，因為系統是穩定的合約，因此也有合理的方法隨著時間持續改進。
不過，開發立面只能樹狀結構內完成，這表示 OOT 目前無法擴充系統自動化功能。SL4F 的特性並不適合 SL4F，純粹並非設計供 OOT 用戶端使用。
分疊
SL4F 提供設定、裝置探索、主機目標網路傳輸通訊協定和一些擴充機制，以及將用戶端程式庫和工具提供給 SDK 客戶的方法。
ffx 也已經以更好的方式解決相同問題。開發 ffx 外掛程式時，如果主機端外掛程式需要目標端協作元件來對目標進行控管，則可開發 FIDL Proxy。主機與目標之間的通訊隨後會根據 FIDL 定義 (與透過 HTTP 的 JSON-RPC 不同)，這可以是 FSI 的一部分，並可能會隨著平台其餘部分和 SDK 的合約發展。其中的部分是因為與結構定義僅存在於程式碼中，與未類型的 JSON 合約相比，維持 ABI 與 FIDL 的相容性比較容易。
另一方面，ffx 堆疊能夠進一步瞭解 Fuchsia 元件，例如知道啟動測試所需元件的時機和方式。也解決了 SL4F 堆疊甚至不會碰到的問題，例如主機目標驗證。這可讓您在 userdebug 建構類型中使用 ffx，而 SL4F 只能在 eng 版本中使用。
其他自訂測試工具
其他的測試解決方案則未列於上方。這些方法涵蓋完整的測試類型，雖然大部分測試都是進行系統測試進行自動化調度管理，因為它們並未使用平臺本身的隔離機制進行測試。
部分 OOT 合作夥伴共用的一組測試解決方案和工具，但部分解決方案和工具之間不一致。因此導致技術負債不斷增加。
解決方案陳述式
Fuchsia 平台團隊會在樹狀圖和 OOT 上建立強大的系統測試解決方案。平台團隊會與產品團隊合作，以瞭解產品測試需求、滿足這些需求，並協助產品團隊推動的所有遷移作業。
新的解決方案將採用元件架構和 ffx 外掛程式的沙箱功能，以執行以下作業：
- 以便撰寫出色的 OOT 測試，包含良好的系統測試。
- 讓編寫測試 OOT 的難度更高 (不可能) 違反 Fuchsia 平台明確定義及支援的合約。
具體違規事項如下：
在適用情況下，宣傳組裝單元和整合測試
如果可將 OOT 測試以元件形式重新導入在測試運作範圍中，以便產生密封單元測試或整合測試，我們就會以這類元件重新實作。為了使測試金字塔能更加健康，我們將提供與 OOT 元件測試一致的支援，以及樹狀結構內元件測試。
重新實作所有非密封的 CFv1 測試
針對存取真實系統服務而違反同質性的所有現有舊版 CFv1 測試，將以其他條件重新實作，滿足相同或更進階的測試需求。無論是以密封的 CFv2 元件測試重新實作這些測試，還是以新系統測試或其他形式重新實作，要測試的程式碼是由其擁有者決定。
如果缺少平台測試支援或支援不足 (例如 CFv1 元件擁有者遭到禁止遷移至 CFv2)，相關的平台團隊將與測試擁有者合作，建立必要的平台解決方案。
為產品擁有者建立新的系統測試平台解決方案
系統測試可以開發及執行 OOT。
其實有一種方法能叫用這些測試並收集結果，確保無論使用何種自動化解決方案，都能確保遵循相同的工作流程並達成一致的結果、在本機開發人員工作流程中測試測試、無論開發人員環境為何，或是否在某些 CI/CQ 自動化中執行相同的測試。
不在預期合約中的平台詳細資料 (例如 Fuchsia 系統介面中定義的平台) 不會向 OOT 系統測試開發人員公開。為了啟用必要的沙箱機制，如果尚未測試和測試架構，則會遷移至 CFv2。
系統測試架構在相關性中，盡可能與
ffx共用堆疊。這包括設定、主機工具和用戶端程式庫發布機制、版本管理、設定、目標裝置探索、主機目標驗證、主機目標傳輸，以及遠端控制機制等。平台系統元件的擁有者可以及將會擴充系統測試架構，以滿足產品開發人員的測試需求。這樣一來，平台開發人員將建立可維護的 ABI，並為這些可測試性合約建立長期擁有權。
減少及淘汰舊版解決方案
平台和產品團隊會協同合作，避免使用先前的解決方案，並配合所有位置採用新的整合式系統測試架構。除非有特殊獎勵，以便繼續使用舊版測試解決方案，例如用於跨平台測試套件的相容性，因此不會長期使用。
優先順序
工作可能應以相關團隊為優先考量的優先程度。不過，我們建議優先處理工作，優先處理最需要維護和維護費用最高的測試，例如先攻擊技術債務曲線的頭部。
無論選擇哪一種特定工作，在思考可以採取哪些行動來支付技術債時，翻新系統測試的工作都視為首要之務。
依附元件
為了填補平台的可測試性落差，並開發及推出新架構，多個平台團隊必須完成各項工作，包括元件架構、測試架構、SDK 工具、EngProd Testing 和 EngProd Infra。
此外，所有產品合作夥伴團隊和平台元件擁有者都必須完成工作，才能找出可測試性落差，並執行遷移至新的測試架構和解決方案。
風險與緩解措施
系統測試不在特定元件或封裝範圍內，但範圍僅限於測試中的整個系統。因此沒有嚴格定義實際測試的程式碼。如果將系統測試從任何架構遷移至另一個架構，可能會失去某些有益的測試涵蓋範圍，而這是系統測試帶來的好處。
部分系統測試的範圍相當大，因此重新實作的門檻相當高。做為實用的預先因素，可能有助於降低範圍或拆分部分測試。
部分現有的系統測試目前沒有專屬的長期擁有者，這類放棄軟體可能難以使用，而且有些遷移工作難免會落入不同的肩膀。
如要調整現代解決方案 (特別是 OOT)，就必須在 OOT 和產品端 CFv2 遷移作業上完成工作。CFv2 遷移作業的進展非常順利，但到目前為止，重點是系統元件，尚未開始遷移 OOT 或產品端元件。這是合理的，我們會預期未知的阻擋器。
一如既往，支付技術債，會與其他團隊的優先事項相互競爭。要有效執行此轉換作業，您必須先與主管階層達成一致性。
不在範圍內
樹狀系統測試
樹狀結構內開發的測試則不屬於本文件的討論範圍。雖然上述工作可能會造成潛在的缺點，但必須樹狀結構內系統測試，但樹狀結構內測試的問題陳述在此處並未討論。舉例來說，樹狀結構內測試可在 Fuchsia 平台介面下方運作，同時不影響 Fuchsia 的可更新性原則和目標。
元件測試
如果是元件測試，也就是以一或多個元件組合表示的測試 (可實作單元測試或整合測試)，請參閱「支援樹狀結構外元件測試的道路圖文件」。
特殊可攜權需求
在許多特殊情況下，現有的測試套件必須在 Fuchsia 上執行，藉此展現相容性或是否符合其他實作項目，或是進行基準測試。在這種情況下，既有的測試必須執行未經修改的測試，否則無法自信地展示相容性。進而定義裝置端測試自動化系統的規格。
這個問題的常見解決方案之一，就是將現有的測試架構移植到 Fuchsia。舉例來說，Fushisia LLVM 工具鍊和 Fuchsia Rust Toolchain 團隊打算分別將 LLVM 和 Rust 測試架構移植至不同目標，以便在 Fuchsia 上從上游執行測試。這有助於將 Fuchsia 分別針對這些外部專案升級至更高層級的工具鍊支援。
另一個常見解決方案，是依據相同規格重新導入測試架構。舉例來說，Fussia Connectivity 團隊已針對 SL4A 的 JSON-RPC/HTTPS 規格實作 SL4F，以便在 Fuchsia 上執行 ACTS 測試。這個做法的好處是為 Fauchsia 提供大量實用的測試，並展現相容性對連線領域而言至關重要。
針對這個獨特的問題空間，這些解決方案是很好的解決方案，前提是他們必須採取正確的原因並謹慎使用。舉例而言，如果我們將 LLVM 測試架構移植到 Fuchsia，然後使用這個架構撰寫新的測試，但這不在合作夥伴專案展示相容性或與合作夥伴專案共用測試的範圍外，這需要額外的正當理由，或是平台團隊不想採用其他方式。