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

指定應用程式範例

這種檢測設備測試與指定目標一般 Android 應用程式值得一提的是包含此檢測的 Pod 仍需使用相同的憑證簽署指定為其指定的應用程式

請注意，本指南假設您已具備平台來源樹工作流程的相關知識。如果不符合，請參閱「規定」一節。這裡的範例是編寫具有目標的新檢測設備測試封裝在本身的測試應用程式套件中設定如果您不熟悉建議您先詳閱平台測試簡介，

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

frameworks/base/packages/Shell/tests

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

決定來源位置

由於檢測設備測試是針對應用程式，因此慣例是將測試原始碼放在根目錄下的 tests 目錄中。

如要查看更多來源位置的相關討論，請參閱以下項目的端對端範例：自我檢測測試

資訊清單檔案

和一般應用程式一樣，每個檢測設備測試模組都需要資訊清單檔案如果將檔案命名為 AndroidManifest.xml，然後在稍後提供至「Android.mk」的模組中，該模組將自動由 BUILD_PACKAGE 核心 makefile。

繼續之前，強烈建議您先完成應用程式資訊清單總覽首先。

這概略說明資訊清單檔案的基本元件和以及功能。

可供存取樣本來源變更的最新版資訊清單檔案於： https://android.googlesource.com/platform/frameworks/base/+/main/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 應用程式架構用來識別應用程式 (或在此情境中，也就是您的測試應用程式)。系統中的每位使用者只能安裝一個使用該套件名稱的應用程式。

由於這是測試應用程式套件，獨立於應用程式測試中的套件，必須使用不同的套件名稱：一種常見的慣例加入後置字串 .test

此外，這個 package 屬性與 ComponentName#getPackageName() 傳回的結果，就像用來與各種 pm 子發布商互動一樣指令adb shell。

另請注意，雖然套件名稱通常屬於同一樣式視為 Java 套件名稱，但相關操作其實很少換句話說，應用程式 (或測試) 套件可包含任何套件名稱的類別，但您也可以選擇簡化方式，讓應用程式或測試中的頂層 Java 套件名稱與應用程式套件名稱相同。

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

所有檢測設備測試都必須提供此項目，因為相關的類別封裝在單獨的架構 jar 程式庫檔案中，因此需要額外的應用程式架構叫用測試套件時的 classpath 項目。

android:targetPackage="com.android.shell"

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

簡易設定檔

每個新測試模組都必須有設定檔，以便透過模組中繼資料、編譯時間依附元件和封裝指示，引導建構系統。在多數情況下，Soong 型的 Blueprint 檔案選項為而負責任的 AI 技術做法有助於達成這項目標詳情請參閱「簡易測試設定」。

複雜設定檔

如要進行更複雜的測試，您也需要編寫測試設定檔案。

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

可供存取樣本來源變更的最新版設定檔於： 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>

這會指示貿易聯盟將 ShellTests.apk 安裝至目標透過指定的 target_preparer 控制裝置。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>

這會指定要用來執行測試和會傳入執行中的套件，以及測試執行器也就是 JUnit

詳情請參閱「測試模組設定」一文

JUnit4 功能

使用 android-support-test 程式庫做為測試執行工具，即可採用新的 JUnit4 樣式測試類別，而範例變數變更包含一些非常基本的相關功能

您可以透過以下網址存取範例變數變更的最新原始碼： 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。同樣地，@BeforeClass 和 @AfterClass 註解也可用於在測試類別中執行所有測試之前，JUnit4 會執行設定。拆解成本請注意，類別範圍的設定和拆除方法必須是靜態的。

至於測試方法，與早期版本的 JUnit 不同，這些方法的名稱不再需要以 test 開頭，而是必須使用 @Test 標註。如常，測試方法必須是公開的，且不宣告任何傳回值、不採用任何參數，且可能擲回例外狀況。

        Context context = InstrumentationRegistry.getTargetContext();

由於 JUnit4 測試不再需要通用基礎類別，因此不再需要透過 getContext() 或Context 透過基礎類別方法使用 getTargetContext()；新的測試執行工具透過 InstrumentationRegistry 進行管理其中，檢測架構建立的情境與環境設定儲存。透過本課程，您也可以呼叫：

getInstrumentation()：Instrumentation 類別的例項
getArguments()：透過以下方式傳遞至 am instrument 的指令列引數： -e <key> <value>

在本機建構及測試

最常見的用途是 Atest。

如果是需要層級大幅自訂的較複雜案例，請遵循檢測操作說明。