Fuchsia 可測試性評分量表

目標

這份文件的目標

Fuchsia 可測試性是一種可讀性，旨在確保使用者能夠 變更 Fuchsia 中的程式碼，導入可測試及測試的程式碼。

如同所有可讀性程序，指南和標準內容最完善 公開提供給審查人員與審查人員這份文件是 Fuchsia 相當於程式設計語言可讀性的樣式指南的可測試性 上傳資料集之後，您可以運用 AutoML 自動完成部分資料準備工作

請務必持續套用可測試性標準，因此 重點在於，「可測試性」的所有參與人員都應研究這份文件 並對變更內容提出變更要求

文件的確切內容可能會隨時間變動。

你做為可測試性審查員的目標

  • 判斷是否要測試變更。如果您符合以下情況，請套用Code-Review+2 表示接受測試，並回覆缺失或缺失的部分。
  • 統一套用標準 (本文件)。
  • 如需修訂異動以符合標準，請提供可行 提供意見回饋。
  • 宣傳 Fuchsia 測試與可測試性。
  • 找出未由這份文件處理的案件，並提出變更建議。
  • 堅持遵守標準，但也秉持優秀的評估標準。目標為 有助於改善品質及營造考試文化您必須遵守 執行精確的決策演算法

你成為改革者的目標

  • 閱讀本文件，讓自己瞭解相關標準 (你的做法正確無誤) 立即啟動！)。
  • 請尊重可測試性審查人員擔任這個職務的自願性 妥善處理
  • 想想有哪些意見回饋可以提升產品的信心 測試變更。

要測試哪些項目？如何測試？

  • 功能變更應具有失敗的測試 做出的改變
  • 測試必須來自變更的程式碼：包含測試的依附元件 涵蓋率不會計入測試涵蓋範圍。舉例來說，如果「A」標籤 「B」和「B」含有測試，並不提供「A」的涵蓋率。 如果在「B」測試中偵測到錯誤，它們就會間接導致 也更難精準找出「A」同樣地，如果「B」已停止支援 變更其依附元件) 所有「A」的涵蓋範圍因此就遺失了
  • 測試必須為自動化作業 (如支援 CI/CQ)。手動測試 十分方便，因為這無法保證程式碼日後會變更 (尤其是由其他工程師編寫時) 必須練習相同的手冊 測試。程式碼集的某些部分可能會發生例外狀況，以利辨識 但自動化功能帶來的挑戰也不夠完整
  • 測試必須盡可能減少外部依附元件。我們的測試基礎架構 明確佈建每項測試使用特定資源，但測試能 以便存取比已佈建的更多資源資源範例 包括硬體、CPU、記憶體、永久儲存空間、網路、其他 IO 裝置、保留的網路通訊埠和系統服務。穩定性和 可用性，以便測試未明確佈建用於測試的資源 無法提供保證，因此，測試存取這類資源的測試 不穩定且 / 或難以重現。測試不得存取外部 無法控制測試基礎架構例如 不得在網際網路上存取服務。測試應只使用資源 所需的資源適用對象 例如，測試可能必須存取未進行測試的系統服務 提供雙倍數。這項規則有一小部分的例外狀況 端對端測試
  • 修改舊版程式碼 (早於可測試性規定的舊程式碼) 且未經妥善測試) 必須進行測試。程式碼測試不良的情況 讓您有機會測試新程式碼未經測試的舊版程式碼不見得過時 而且可能會經過實證及戰鬥，而新程式碼則會 如果不測試，很可能失敗！
  • 您對他人的程式碼所做的變更也會遵循 可測試性需求。如果作者更改了程式碼，從未修改過程式碼 因此更加容易 作者能與負責的個人或團隊合作 找出測試變更的有效方式負責程式碼的人員 且能協助作者進行測試 優先處理。

不需測試的項目

缺少下列項目的測試涵蓋範圍，應該不會導致變更： 接收 Code-Review+2。

  • 記錄：在大多數情況下，測試記錄輸出內容可能並不值得 元件其餘記錄通常會將記錄輸出視為不透明資料 這代表對記錄輸出所做的變更不太可能中斷 有些人會將 Cloud Storage 視為檔案系統 但實際上不是不過，如果記錄輸出以某種方式載入 (例如 一些其他系統可能需要觀察某些記錄訊息)，然後 值得測試的合約這也適用於其他形式的 追蹤，例如追蹤這不適用於檢測作業 舉例來說，您可以將檢查用量視為合約 是否應以預期方式運作 (例如使用 ffx inspect 或意見回饋報告)。
  • 程式碼不屬於我們所有 (可靠資料來源不在 Fuchsia 樹狀結構中)。 記錄從其他位置複製而來的原始碼更新的變更 並非可測試性要求
  • 純重重 (變更可以完全由 自動重構工具，例如移動檔案、重新命名符號或 刪除這些項目，並非可測試性要求。部分語言 曝露在執行階段反射方面的行為 (例如執行階段反射) 的行為， 但可能會有例外狀況。
  • 產生的程式碼。使用工具所產生的變更 (例如格式、 或產生的程式碼檢查是否為黃金檔案) Google Cloud 就是最佳選擇不過，一般來說，最好不要檢查 (更不用說使用工具，並在建構時產生程式碼) 在特殊情況下，您不需要測試由 Google 編寫的程式碼 您甚至可以設定網路介面 並混合執行 Linux 與 Windows 機器
  • 可測試性啟動。或正在準備變更 導入程式碼的可測試性， 則可供測試性審查員自行斟酌， 資源
  • 手動測試：手動測試通常用於 示範難以以自動化方式測試的功能 因此在手動測試中加入或修改，因此不需要 以及自動化測試不過，我們強烈建議 與 README.md 或 TESTING.md 文件配對，說明如何執行這些項目。
  • 硬式編碼值。新增或變更硬式編碼值不會 測試時不一定要執行測試通常，這些值控制的是 無法輕易觀察，例如未公開的實作 詳細資料、經驗法則或「美容」變更 (例如 UI 的背景顏色)。 對 assert_eq!(CONFIG_PARAM, 5); 樣式的測試還不實用 也不必為可測試性設定不過，如果貢獻成果 並做出容易觀察到的行為變化 請納入新行為的測試。

需要測試的項目

如要修正瑕疵，請在 CQ 中測試不穩定

如要修正瑕疵，請在 CQ 中測試不穩定性，藉此確認修正結果。

測試不應進入睡眠階段

睡眠可能導致不穩定測試，因為時間很難控制 不同的測試環境可能造成這種情況的一些因素 難易度是測試目標的 CPU 速度、核心數量和系統 以及溫度等環境因素

  • 請避免：

    // Check if the callback was called.
zx_nanosleep(zx_deadline_after(ZX_MSEC(100)));
EXPECT_EQ(true, callback_happened);

  • 反之，明確等待以下條件：

    // In callback
callback() {
    sync_completion_signal(&event_);
}

// In test
sync_completion_wait(&event_, ZX_TIME_INFINITE);
sync_completion_reset(&event_);

    這個程式碼範例是從 task_test.cc 改編而來。

競爭狀況的迴歸測試

撰寫競爭狀況沒有偏高的競爭狀況時，會難以編寫迴歸測試 錯誤率如果您可以編寫測試可以重現問題的內容 我們會盡力而為請參閱「編寫可重現的確定性測試」 取得提示。否則，如果改善鎖定以修正資料競爭 使用的配置，您可以新增執行緒註解做為迴歸測試。其他種族 您應嘗試設計防止競爭狀況存在的 API。

最近移除的豁免項目

  • Engprod 指令碼 (例如 fx 指令) 和相關聯的設定檔 免於可測試性。「fx」必須整合 然後進行測試FX 團隊可允許例外情形發生 諮詢可測試性審查員後

臨時可測試性豁免項目

下列項目目前不受「可測試性」規範，但持續性工作的目標是 進行變更

  • tools/devshell/contrib 中的 Engprod 指令碼，以及相關聯的 就會豁免設定
  • GN 範本難以測試。我們正在打造一個測試架構 例如 GN 範本在此之前，您可以對建構範本變更 進行手動測試
  • C 樣式的程式碼難以避免資源外洩。長久 因此，請重構這類程式碼，以便使用 Rust 或新型 C++ 慣用語 降低發生資料外洩的可能性，自動化系統應該就能 自動偵測資訊外洩。
  • Gigaboot 是 //src/firmware/gigaboot 中的 UEFI 系統啟動載入程式， 可測試性政策。目前沒有可用的基礎架構 編寫 UEFI 程式碼的整合測試。這項功能正式登場 https://fxbug.dev/42109789 追蹤。已授予可測試性例外狀況 直到 https://fxbug.dev/42109789 解決。