排解失敗問題

本指南將概述 排解 Fuchsia (CTF) 測試失敗和步行相容性測試問題 並說明哪些故障原因，以及如何解除封鎖 CL 提交內容。

CTF 測試斷言在發布分支版本上發生軟體凍結， 建構於 fuchsia.git main 分支版本的軟體。如果這些斷言失敗 由於不相容，系統將封鎖提交 CL 。

CTF 的目的並非禁止針對相容性造成的破壞性變更，而是要禁止 目的是清楚顯示這些故障情形 並予以解決

Scenarios

每個情境都會發生一個實際相容性問題，導致 CTF 並禁止提交 CL 提交要求。相容性問題可能很簡單 例如變更測試所用現有 FIDL 通訊協定的傳回值。三 假設下列情境皆適用於下列情境 (詳情請參閱動機) 測試情境)：

• FIDL 用戶端在 F19 上處於 ctf_fuchsia_package 凍結狀態 echo-service-tests。這會連至 回應。

• generate_ctf_tests.gni 包含規則 合併傳入用戶端的 template("generate_echo-service-tests") 內含建構於 main 的伺服器套件。(請參閱使用手冊 詳情)。

• 用戶端會在伺服器上呼叫 Echo 方法，將其做為輸入內容 字串並傳回為字串，如下所示：

  auto server_proxy = connect_to_named_protocol("my_protocol.EchoService");
  ASSERT_EQ(
    server_proxy.echo("Hello"),
    "Hello"
  );
  

假設我們想變更 echo 的行為，改為傳回小寫 字串表示法。我們可以於 main將測試更新為 ：

ASSERT_EQ(
  server_proxy.echo("Hello"),
  "hello"
);

這通過 ctf_in_development 項測試，但執行凍結用戶端測試時， 並對這個新伺服器執行舊斷言，測試就會失敗：

FAILURE: "hello" != "Hello"

目前已封鎖 CL 提交作業，後續路徑則視拒絕原因而定 這種故障狀況

非蓄意破壞性變更 - 柔和轉換

在這種情況下，我們無意造成相容性中斷。如果有 預先建構或樹狀結構外元件依附舊行為同時 包含變更 Echo 的平台元件會導致 非預期的行為

在這種情況下，安全措施是輕柔轉換到新行為：

1. 推出以新行為的新方法：

   protocol Echo {
    // ...
    @available(added=20)
    EchoLowercase(struct {input string}) -> (string);
   };
   

2. 將舊方法標示為已淘汰或已移除 (選用)：

   protocol Echo {
    @available(removed=20)
    Echo(/* ... */) -> (string);
    // ...
   };
   

3. 在伺服器中實作新方法。

4. 將 fuchsia.git 呼叫端變更為使用新方法，而非舊方法。

伺服器必須支援這兩種方法，直到舊資料的所有 API 級別 方法。在上述範例中，這表示 由於 F19 中的舊回音方法已從 F20 中移除，因此不支援 F19 (因為 @available(removed=20))。

蓄意破壞性變更 - 發布分支版本中的變更測試

在這種情況下，相容性中斷是刻意的。這可能發生在 原因如下：

• 我們希望變更 API 的行為，並接受 預先建立或樹狀結構外用戶端破壞。這是真陽性 我們會明確確認這個錯誤

• 變更的行為僅限測試內部，並不代表 SDK 介面本身的破壞性變更這是偽陽性 失敗，因為我們抓到與測試不相容而非 SDK 不相容情形

無論是哪一種情況，解決方式都是修改「版本」分支版本，讓測試 與變更前或後變更程式碼執行時 在 main。

變更執行方式如下：

1. 查看版本分支：

   fx sync-to refs/heads/releases/f19
   

2. 修改斷言，使其接受兩種輸出內容 (或加上註解)：

   EXPECT_THAT(
    server_proxy.echo("Hello"),
    AnyOf(Eq("Hello"), Eq("hello"))
   );
   

3. 測試您的變更是否能在 main生效 (請見下方說明)

4. 修訂並推送變更：

   git push origin HEAD:refs/for/releases/f19
   

5. 將 CL 送交審核並提交。

6. 已禁止封鎖 CL。

7. 清除發布分支版本，以便僅接受新行為 (選用)。

   EXPECT_EQ(
     server_proxy.echo("Hello"),
     "hello"
   );
   

您可以測試變更套用至 main 後是否能正常運作。您需要兩個 Fuchsia 的結帳記錄，其中一則與版本分支版本同步，另一個則同步至 main。 請完成下列步驟：

1. 在發布分支版本結帳頁面，建立新的 CTF 套件。

   fx set core.x64 --with-tests //sdk/ctf
   fx build
   

2. 在 main 結帳頁面中，建構 CTF 版本測試。

   fx set core.x64 --with-tests //sdk/ctf/release:tests
   fx build
   

3. 在版本分支版本的輸出目錄中，複製已建構的 CTF 至 main 存放區

   cp -fR \
   $RELEASE_BRANCH_FUCHSIA_OUT_DIR/cts/* \
   $MAIN_BRANCH_FUCHSIA_DIR/prebuilt/ctf/f19/linux-x64/cts/
   

4. 重新建構 main 結帳功能、重新找裝置或重新啟動模擬器，然後執行 進行測試。

5. 通過測試後，還原至 CIPD 的版本。

   jiri run-hooks
   

範例：SDK 相容性中斷 (真陽性)

這個 CL 導入了完全相容性方面的中斷， fuchsia.ui.policy.MediaButtonsListener 通訊協定。已在 帶有正確版本管理註解的 MediaButtonsEvent，但 如果該參數留空， 。CTF 針對 F19 的測試找出了這種不相容的問題：

../../src/ui/tests/conformance_input_tests/media-button-validator.cc:243: Failure
Expected equality of these values:
  ToString(listener.events_received()[0])
    Which is: "\n    volume: 0\n    mic_mute: 0\n    pause: 0\n    camera_disable: 0\n    power: 0"
  ToString(MakePowerEvent())
    Which is: "\n    volume: 0\n    mic_mute: 0\n    pause: 0\n    camera_disable: 0\n    power: 1"

我們認為可以接受這項變更，因為 這個通訊協定的預先建構用戶端，並指定 API 級別 19 為目標。

CLs 1044994 和 1049612 已獲選為 F19 版本 分支版本異動項目導入 CTF 後 main使用的版本，原始 CL 已於未經修改。

範例：測試控管工具相容性故障 (偽陽性)

這個 CL 引進了相容性中斷， fuchsia.tracing.controller.Controller 通訊協定。StopTracing 方法之前為 已將方法設為 flexible，但將方法從 strict 變更為 flexible 並未 支援 ABI。

WLAN hw-sim CTF 測試會在這項變更下異常終止，因為該測試聲明 追蹤作業會在測試期間成功停止，即使這與 測試 WLAN 通訊協定而不需要確保正確性。這是「false」 相容性失敗，因為這只會影響測試控管本身。

這個 CL 被誘使，將追蹤失敗變成 而不是嚴重的斷言 而這項變更也成為 F18 發布分支版本。一旦變更到 main，原始 CL 是在未經修改的情況下提交。

刻意捨棄對特定測試的 API 級別支援

在此情境中，我們要在 每項測試的依據。雖然 version_history.json 提供 有支援 API 級別的標準化清單 捨棄特定 API 級別上的特定通訊協定的相容性保證。 例如，重構非關鍵子系統的主要重構，也就是會破壞舊資料舊的子系統 用戶端仍可接受。

在此情況下，我們可以修改申訴程序，跳過以 我們要捨棄的 API 級別：

1. 修改 main 分支版本的 generate_ctf_tests.gni 有條件地略過測試

   template("generate_my-service-tests") {
    forward_variables_from(invoker, [ "test_info" ])
    if (defined(invoker.api_level) && invoker.api_level == "15") {
      # Do not thaw this test for F15
      not_needed([ "test_info" ])
      group(target_name) {
      }
    } else {
      // ...
    }
   }
   

2. 修訂並提交這個 CL。

上述範例在 F15 時略過整個構件。如果不需要 如要略過所有測試，請參閱上一節瞭解如何略過個別測試 發行分支上的案例

範例：主要重構來診斷子系統

這個 CL 已刪除對 DirectoryReady 的支援 元件事件，這個事件已不再使用。主要用途是支援 取得元件的診斷資料 (現在可使用 fuchsia.inspect.InspectSink) 通訊協定。

不幸的是，以 F15 建構的元件仍會以 DirectoryReady，而這項行為的所有診斷 CTF 測試都會失敗 main後。

幸運的是，並沒有針對 F15 的預先建構元件，我們需要使用 以取得診斷資料。已提交 CL 以停用所有用戶端 診斷 F15 的 CTF 測試。