Fuchsia 可測試性評分量表

目標

本文件的目標

Fuchsia 可測試性是一種可讀性形式，著重於確保對 Fuchsia 所做的變更導入可測試及測試的程式碼。

與任何可讀性流程一樣，這些規範和標準都是公開提供給審查者和審查人員的參考依據。本文件為 Fuchsia 可測試性，相當於程式設計語言可讀性程序的風格指南。

建議您以一致的方式套用可測試性標準，因此參與測試程序的任何相關人員都應研究文件 (無論是查看變更或編寫編寫指令碼)。

文件的確切內容可能會隨著時間而變更。

您設為可測試性審查員的目標

  • 判斷變更是否已經過測試。如果您同意測試，請套用 Code-Review+2，並在回覆中註明遺漏的內容。
  • 持續套用標準 (本文件)。
  • 如果變更是否需要符合標準，請提供可做為行動依據的意見回饋。
  • 推動 Fuchsia 測試和可測試性。
  • 找出本文件未處理的案例，並提出變更建議。
  • 堅守標準，但也請善加判斷。目標是改善品質並推廣測試文化。您不應執行精確的決策演算法。

你成為改變作者的目標

  • 閱讀本文件以告知您標準 (建議您立即完成！)。
  • 請尊重測試人員的自願者擔任這個角色的自願者，並做出適當的選擇。
  • 請針對可透過測試提高可信度的方法提供意見回饋。

要測試哪些項目？測試方法

  • 對功能變更應具有在不經變更的情況下失敗的測試。
  • 測試必須位於要變更的程式碼本機中：測試涵蓋範圍的依附元件不會計入測試涵蓋範圍。舉例來說，如果「B」使用「A」，而「B」包含測試，則不會提供「A」的涵蓋率。如果「B」的測試偵測到錯誤，就會間接顯現，使得「A」難以判斷。同樣地，如果「B」已淘汰 (或僅變更其依附元件)，「A」的所有涵蓋範圍都將失效。
  • 測試必須以自動化方式執行 (支援 CI/CQ)。手動測試並不夠，因為日後對程式碼的變更 (尤其是當其他工程師編寫時) 一定會執行相同的手動測試。為了辨識持續性的自動化問題，程式碼集的某些部分可能會遇到例外狀況。
  • 測試必須盡量減少外部依附元件。我們的測試基礎架構會明確佈建每項測試並附上特定資源，但測試能夠存取的數量超過已佈建的資源。資源範例包括硬體、CPU、記憶體、永久儲存空間、網路、其他 IO 裝置、保留的網路通訊埠和系統服務。我們無法保證未明確為測試佈建的資源穩定性和可用性，因此測試存取這類資源的測試固然不穩定，且 / 或難以重現。測試不得存取測試基礎架構控制以外的外部資源。舉例來說，測試不得存取網際網路上的服務。在必要時，測試只能使用為該測試明確佈建資源以外的資源。舉例來說，測試可能需要存取沒有可用測試組別的系統服務。這項規則有少數例外狀況供端對端測試使用。
  • 舊版程式碼的變更 (舊程式碼是符合「可測試性」規定，且測試效果不佳的舊程式碼)，則必須進行測試。與測試程式碼較差的程度，並不是測試新程式碼的理由。未經測試的舊版程式碼不一定是舊式程式碼，不一定是過時的內容，而是可能經過實證及嚴謹的強化，而未測試的新程式碼很有可能會失敗！
  • 您要對他人的程式碼進行變更時，也有相同的可測試性規定。如果作者變更的程式碼，讓使用者不熟悉或對該程式碼負責，我們就更需要妥善測試。因此，作者應與負責的個人或團隊合作，找出有效的測試方法。負責變更程式碼的個人應協助作者獲得與作者變更相同優先順序的可測試性。

不需要測試的項目

即使缺少下文的測試涵蓋範圍，也無法阻止變更接收 Code-Review+2。

  • 記錄。在多數情況下，測試元件的記錄檔輸出可能並不值得。系統的其餘部分通常會將記錄輸出視為不透明資料，這表示對記錄輸出所做的變更不太可能破壞其他系統。不過，如果記錄檔輸出會以某種方式載入 (例如，其他系統可能必須觀察某些記錄訊息)，那麼該合約就值得測試。這個做法也適用於其他形式的檢測作業，例如追蹤。這不適用於合約做為合約使用的檢測作業。舉例來說，您可以測試檢查用的用量，也應該依照預期正常運作 (例如在 ffx inspect 或意見回饋報表中) 進行檢測。
  • 非自有程式碼 (可靠資料來源不在 Fuchsia 樹狀結構中)。如果變更會從其他位置複製原始碼更新，變更就不需要進行可測試性要求。
  • 純重構 (這是完全由自動化重構工具進行的變更)，像是移動檔案、重新命名符號或刪除符號，亦不需要可測試性。某些語言可能有這類變更的行為 (例如執行階段反射)，因此可能不適用例外狀況。
  • 產生的程式碼。由工具產生的變更 (例如格式化，或以黃金檔案形式產生進行檢查的程式碼) 不在可測試性要求。此外，我們一般不建議檢查產生的程式碼 (而不是使用工具並在建構期間產生程式碼)，但在特殊情況下，不需要測試機器編寫的程式碼。
  • 可測試性啟動。如果變更正在準備變更程式碼的可測試性，且作者明確記錄這點，測試性審查人員即可自行斟酌是否遵循 IOU。
  • 手動測試。手動測試通常用於測試或示範以自動化方式難以測試的功能。因此，新增或修改手動測試並不需要自動化測試。不過，我們強烈建議您將手動測試與描述執行方法的 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 解決為止。