自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。

本頁面由 Cloud Translation API 翻譯而成。

測試對應
透過集合功能整理內容你可以依據偏好儲存及分類內容。

這個簡單介紹測試對應，並說明如何取得已開始在 Android 開放原始碼計畫 (AOSP) 中設定測試。

關於測試對應

測試對應是一種以 Gerrit 為基礎的方法，可讓開發人員直接在 Android 來源樹狀結構中建立提交前和提交後測試規則，並將要測試的分支和裝置的決定權交給測試基礎架構。測試對應定義是名稱為 TEST_MAPPING 的 JSON 檔案，您可以放在任何來源目錄中

Atest 可使用 TEST_MAPPING 檔案，在或是相關聯的目錄透過測試對應，您可以在 Android 來源樹中進行最少變更，將相同的測試套用至提交前檢查。

請參閱以下範例：

測試對應必須使用貿易聯盟 (TF) 測試控管工具測試執行和結果報告

定義測試群組

使用測試群組測試對應群組測試。測試群組的名稱可以是任何字串。舉例來說，presubmit 可以是測試群組的名稱會在驗證變更時執行而「提交後」則是用於驗證變更合併後的版本。

套件建構指令碼規則

如何取得貿易聯盟測試工具為特定建構執行測試模組，這些模組必須具備已設為 Soong 或 LOCAL_COMPATIBILITY_SUITE 集合的 test_suites ，到兩個套房之一：

general-tests 適用於不依附裝置個別情況的測試的功能 (例如大多數裝置沒有的廠商專屬硬體) 。大部分測試都應該位於 general-tests 套件中，一個特定的 ABI、位元性或硬體功能，例如 HWASan (有請為每個 ABI 建立獨立的 test_suites 目標)，即使需要執行應用程式。
device-tests 適用於依附裝置專屬功能的測試。一般來說，您可以在 vendor/ 下方找到這些測試。特定裝置 只有「裝置」專屬的功能，因此適用測試 JUnit 測試以及 GTest (通常應標示為 general-tests)。

例如：

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

設定要在測試套件中執行測試

如需在測試套件中執行測試，該測試：

不得有任何建構提供者。
作業完成後就必須進行清理，例如刪除測試期間產生的檔案
必須將系統設定變更為預設值或原始值。
不應假設裝置處於特定狀態，例如 Root 權限就緒。大多數測試不需要 Root 權限即可執行。如果測試必須要求使用 root，則應在其 AndroidTest.xml 中使用 RootTargetPreparer 指定，如以下範例所示：
```
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
```

建立測試對應檔案

針對需要測試涵蓋範圍的目錄，新增 TEST_MAPPING JSON 檔案類似範例。這些規則可確保在該目錄或任何子目錄中觸及任何檔案時，測試會在提交前檢查中執行。

參考範例

以下是 TEST_MAPPING 的範例檔案 (採用 JSON 格式，但附有註解) 支援)：

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsDeqpTestCases",
      "options": [
        {
          // Use regex in include-filter which is supported in AndroidJUnitTest
          "include-filter": "dEQP-EGL.functional.color_clears.*"
        }
      ]
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

設定屬性

在範例中，presubmit 和 postsubmit 是各個字詞的名稱測試群組。詳情請參閱「定義測試群組」一文測試群組

您可以設定測試模組或貿易聯盟整合測試的名稱名稱 (測試 XML 檔案的資源路徑，例如 uiautomator/uiautomator-demo)。 name 屬性值中。請注意，name 欄位無法請使用 name 類別或測試方法 name。如要縮小要執行的測試範圍，請使用 include-filter 等選項。請參閱 include-filter 範例用法。

測試的 host 設定會指出測試是否為在主機上執行的無裝置測試。預設值為 false，表示測試需要裝置才能執行支援的測試類型包括 GTest 二進位檔的 HostGTest，以及 JUnit 測試的 HostTest。

file_patterns 屬性可讓您設定規則運算式字串清單，用來比對任何原始碼檔案的相對路徑 (相對於包含 TEST_MAPPING 檔案的目錄)。在範例中，只有在 Java 檔案以 Window 或 Activity 開頭，且位於 TEST_MAPPING 檔案或其任何子目錄所在的目錄時，測試 CtsWindowManagerDeviceTestCases 才會在提交前執行。反斜線 (\) 位於 JSON 檔案中，因此需要轉義。

imports 屬性可讓您在其他 TEST_MAPPING 檔案中加入測試而不必複製內容父項中的 TEST_MAPPING 檔案也會匯出匯入路徑的目錄。測試對應可允許巢狀匯入，也就是說兩個 TEST_MAPPING 檔案可以互相匯入，且測試對應可合併所包含的測試。

options 屬性包含其他 Tradefed 指令列選項。

如要取得特定測試的完整可用選項清單，請執行：

tradefed.sh run commandAndExit [test_module] --help

詳情請參閱換購商品選項處理方式，進一步瞭解選項的運作方式。

使用 Atest 執行測試

如何在本機執行提交前測試規則：

前往包含 TEST_MAPPING 檔案的目錄。
執行下列指令：
```
atest
```

目前 TEST_MAPPING 檔案中設定的所有預先提交測試會執行其父項目錄Atest 找到並執行兩項測試預先提交 (A 和 B)。

這是在 TEST_MAPPING 中執行預先提交測試最直接的方法目前工作目錄 (CWD) 和父項目錄中的檔案。測試找出及使用 CWD 中的 TEST_MAPPING 檔案及其所有父項目錄

結構化原始碼

以下範例說明如何在來源樹狀結構中設定 TEST_MAPPING 檔案：

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

src/TEST_MAPPING的內容：

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

src/project_1/TEST_MAPPING 的內容：

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

src/project_2/TEST_MAPPING的內容：

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

指定目標目錄

您可以指定目標目錄，以便在該目錄中的 TEST_MAPPING 檔案中執行測試。下列指令會執行兩項測試 (A、B)：

atest --test-mapping src/project_1

執行提交後測試規則

您也可以使用這個指令，執行 src_path 中的 TEST_MAPPING (預設為 CWD) 及其父項目錄：

atest [--test-mapping] [src_path]:postsubmit

只執行不需要裝置的測試

您可以使用 --host 選項，僅執行已設定的測試連線至不需要裝置的主機。如果沒有這個選項，Atest 會同時執行測試需使用裝置，以及在主機上執行，但無須安裝裝置。測試會在兩個獨立的套件中執行：

atest [--test-mapping] --host

找出測試組

您可以在 Atest 指令中指定測試群組。以下指令會執行 src/project_1 目錄中與檔案相關的所有 postsubmit 測試，該目錄只包含一個測試 (C)。

或者，您也可以使用 :all 執行所有測試，不分群組。下列指令會執行四個測試 (A、B、C、X)：

atest --test-mapping src/project_1:all

包含子目錄

根據預設，在 TEST_MAPPING 中使用 Atest 執行測試只會執行預先提交作業 CWD 中 TEST_MAPPING 檔案中設定的測試 (或指定目錄) 及其父項目錄如果您想在子目錄中的所有 TEST_MAPPING 檔案中執行測試，請使用 --include-subdir 選項，強制 Atest 也納入這些測試。

atest --include-subdir

如果沒有 --include-subdir 選項，Atest 只會執行測試 A。使用 --include-subdir 選項時，Atest 會執行兩項測試 (A、B)。

支援行層級註解

您可以新增行層級的 // 格式註解，以加入 TEST_MAPPING 檔案，以及下方設定的說明。 ATest 和 Trade Federation 會將 TEST_MAPPING 預先處理為有效的 JSON 格式，且不含註解。保留清理 JSON 檔案，只有行層級的 // 格式註解。

例子：

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}

測試對應 透過集合功能整理內容 你可以依據偏好儲存及分類內容。