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

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

指定應用程式範例

這類檢測設備測試與以一般 Android 應用程式為目標的測試差異不大。請注意，包含檢測設備的測試應用程式，必須與目標應用程式使用相同的憑證簽署。

請注意，本指南假設您已具備平台來源樹狀結構工作流程的相關知識。如未顯示，請參閱需求條件。本節涵蓋的範例是撰寫新的檢測設備測試，並在自己的測試應用程式套件中設定目標套件。如果您不熟悉這個概念，請詳閱平台測試簡介。

本指南使用下列測試做為範例：

frameworks/base/packages/Shell/tests

建議您先瀏覽程式碼，大致瞭解內容，再繼續操作。

決定來源位置

由於檢測設備測試會以應用程式為目標，因此慣例是將測試原始碼放在平台原始碼樹狀結構中，元件原始碼目錄根目錄下的 tests 目錄中。

如要進一步瞭解來源位置，請參閱自我檢測測試的端對端範例。

資訊清單檔案

就像一般應用程式一樣，每個檢測設備測試模組都需要資訊清單檔案。如果將檔案命名為 AndroidManifest.xml，並在測試模組的 Android.mk 旁邊提供該檔案，BUILD_PACKAGE 核心 Makefile 就會自動納入該檔案。

強烈建議您先詳閱「應用程式資訊清單總覽」，再繼續進行後續步驟。

本文將概略介紹資訊清單檔案的基本元件及其功能。

如要存取範例 Gerrit 變更的最新版資訊清單檔案，請前往： https://android.googlesource.com/platform/frameworks/base/+/android16-release/packages/Shell/tests/AndroidManifest.xml

為方便起見，我們在此附上快照：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

    <application>
        <uses-library android:name="android.test.runner" />

        <activity
            android:name="com.android.shell.ActionSendMultipleConsumerActivity"
            android:label="ActionSendMultipleConsumer"
            android:theme="@android:style/Theme.NoDisplay"
            android:noHistory="true"
            android:excludeFromRecents="true">
            <intent-filter>
                <action android:name="android.intent.action.SEND_MULTIPLE" />
                <category android:name="android.intent.category.DEFAULT" />
                <data android:mimeType="*/*" />
            </intent-filter>
        </activity>
    </application>

    <instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
        android:targetPackage="com.android.shell"
        android:label="Tests for Shell" />

</manifest>

資訊清單檔案的幾項重要備註：

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

package 屬性是應用程式套件名稱，也就是 Android 應用程式架構用來識別應用程式 (或在此情境中為測試應用程式) 的專屬 ID。系統中的每位使用者只能安裝一個具有該套件名稱的應用程式。

由於這是獨立於受測應用程式套件的測試應用程式套件，因此必須使用不同的套件名稱，常見的慣例是加上 .test 後置字元。

此外，這個 package 屬性與 ComponentName#getPackageName() 傳回的屬性相同，也與您透過 adb shell 與各種 pm 子指令互動時使用的屬性相同。

另請注意，雖然套件名稱通常與 Java 套件名稱的樣式相同，但實際上兩者關係不大。換句話說，您的應用程式 (或測試) 套件可能包含任何套件名稱的類別，但另一方面，您也可以選擇簡化，讓應用程式或測試中的頂層 Java 套件名稱與應用程式套件名稱相同。

<uses-library android:name="android.test.runner" />

所有 Instrumentation 測試都必須這麼做，因為相關類別會封裝在個別的架構 JAR 程式庫檔案中，因此當應用程式架構叫用測試套件時，需要額外的類別路徑項目。

android:targetPackage="com.android.shell"

這會將檢測作業的目標套件設為 com.android.shell。透過 am instrument 指令叫用檢測設備時，架構會重新啟動 com.android.shell 程序，並將檢測設備程式碼插入程序中，以執行測試。這也表示測試程式碼可以存取在受測應用程式中執行的所有類別例項，並視公開的測試掛鉤而定，可能可以操控狀態。

簡單的設定檔

每個新測試模組都必須有設定檔，才能使用模組中繼資料、編譯時間依附元件和封裝指示，引導建構系統。在大多數情況下，Soong 型 Blueprint 檔案選項就已足夠。詳情請參閱「簡單測試設定」。

複雜的設定檔

如要進行更複雜的測試，您也需要為 Android 的測試架構 Trade Federation 編寫測試設定檔。

測試設定可以指定特殊裝置設定選項，以及提供測試類別的預設引數。

如要存取範例 Gerrit 變更的最新版設定檔，請前往： frameworks/base/packages/Shell/tests/AndroidTest.xml

為方便起見，我們在此附上快照：

<configuration description="Runs Tests for Shell.">
    <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
        <option name="test-file-name" value="ShellTests.apk" />
    </target_preparer>

    <option name="test-suite-tag" value="apct" />
    <option name="test-tag" value="ShellTests" />
    <test class="com.android.tradefed.testtype.AndroidJUnitTest" >
        <option name="package" value="com.android.shell.tests" />
        <option name="runner" value="android.support.test.runner.AndroidJUnitRunner" />
    </test>
</configuration>

測試設定檔的幾項重要備註：

<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
  <option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>

這會告知 Trade Federation 使用指定的 target_preparer，將 ShellTests.apk 安裝到目標裝置。開發人員可以在 Trade Federation 中使用許多目標準備工具，確保裝置在執行測試前已正確設定。

<test class="com.android.tradefed.testtype.AndroidJUnitTest">
  <option name="package" value="com.android.shell.tests"/>
  <option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>

這會指定要用來執行測試的 Trade Federation 測試類別，並傳遞要在裝置上執行的套件，以及測試執行工具架構 (本例為 JUnit)。

如要進一步瞭解測試模組設定，請參閱這篇文章

JUnit4 功能

使用 android-support-test 程式庫做為測試執行器，即可採用新的 JUnit4 樣式測試類別，而範例 Gerrit 變更包含其部分基本功能。

如要存取範例 Gerrit 變更的最新原始碼，請前往： frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java

雖然測試模式通常是元件團隊專屬，但仍有一些一般實用的使用模式。

@SmallTest
@RunWith(AndroidJUnit4.class)
public final class FeatureFactoryImplTest {

JUnit4 的重大差異在於，測試不再需要從常見的基礎測試類別繼承，而是以純 Java 類別撰寫測試，並使用註解指出特定測試設定和限制。在本範例中，我們指示這個類別應以 Android JUnit4 測試的形式執行。

@SmallTest 註解為整個測試類別指定了測試大小：新增至這個測試類別的所有測試方法都會沿用這個測試大小註解。測試類別前置設定、測試後終止，以及測試類別後終止：類似於 JUnit4 中的 setUp 和 tearDown 方法。Test 註解用於註解實際測試。

    @Before
    public void setup() {
    ...
    @Test
    public void testGetProvider_shouldCacheProvider() {
    ...

JUnit4 會在方法上使用 @Before 註解，執行測試前設定。雖然這個範例未使用，但也有用於測試後拆除作業的 @After。同樣地，JUnit4 可在方法中使用 @BeforeClass 和 @AfterClass 註解，在執行測試類別中的所有測試前進行設定，並在之後執行清除作業。請注意，類別範圍的設定和清除方法必須是靜態方法。

至於測試方法，與舊版 JUnit 不同，方法名稱不再需要以 test 開頭，而是必須使用 @Test 註解。與往常一樣，測試方法必須是公開方法，不得宣告傳回值，也不得採用任何參數，但可能會擲回例外狀況。

        Context context = InstrumentationRegistry.getTargetContext();

由於 JUnit4 測試不再需要通用基礎類別，因此不再需要透過 getContext() 或基礎類別方法取得 Context 例項；而是由新的測試執行工具透過 InstrumentationRegistry 管理這些例項，其中儲存了檢測設備架構建立的環境和情境設定。getTargetContext()您也可以透過這個類別呼叫下列項目：

getInstrumentation()：Instrumentation 類別的執行個體
getArguments()：透過 -e <key> <value> 傳遞至 am instrument 的指令列引數

在本機建構及測試

如果是最常見的用途，請使用 Atest。

如需更複雜的案例，需要進行更深入的自訂，請按照儀表板操作說明操作。