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

針對應用示例

這類儀器測試與針對常規 Android 應用程序的測試沒有太大區別。值得注意的是，包含儀器的測試應用程序需要使用與其目標應用程序相同的證書進行簽名。

請注意，本指南假設您已經對平台源代碼樹工作流程有所了解。如果沒有，請參考 https://source.android.com/source/requirements。此處涵蓋的示例是編寫一個新的儀器測試，目標包設置在其自己的測試應用程序包中。如果你不熟悉的概念，請閱讀通過平台測試介紹。

本指南使用以下測試作為示例：

框架/基礎/包/外殼/測試

建議在繼續之前先瀏覽代碼以獲得粗略的印象。

確定源位置

由於儀器測試將針對應用程序，慣例是放在一個測試源代碼tests目錄平台的源代碼樹的組件的源目錄的根目錄下。

看到源位置在更多的討論結束到終端的例子自我插樁測試。

清單文件

就像常規應用程序一樣，每個儀器測試模塊都需要一個清單文件。如果命名文件AndroidManifest.xml ，並提供它旁邊Android.mk為您的測試tmodule，它會被自動被列入BUILD_PACKAGE核心的makefile。

在進一步討論之前，強烈建議去通過應用清單概述第一。

這給出了清單文件的基本組件及其功能的概述。

可以在以下位置訪問示例 gerrit 更改的清單文件的最新版本：https://android.googlesource.com/platform/frameworks/base/+/master/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" />

這是所有 Instrumentation 測試所必需的，因為相關類被打包在單獨的框架 jar 庫文件中，因此當應用程序框架調用測試包時需要額外的類路徑條目。

android:targetPackage="com.android.shell"

這台儀器到目標包com.android.shell 。當儀器通過調用am instrument命令，則重新啟動框架com.android.shell過程，並注入儀器碼成用於測試執行過程。這也意味著測試代碼將可以訪問在被測應用程序中運行的所有類實例，並且可能能夠根據公開的測試掛鉤來操縱狀態。

簡單的配置文件

每個新的測試模塊都必須有一個配置文件，以使用模塊元數據、編譯時依賴項和打包指令來指導構建系統。在大多數情況下，基於 Soong 的藍圖文件選項就足夠了。見簡單的測試配置的詳細信息。

複雜的配置文件

對於更複雜的測試，您還需要編寫Android的測試工具，測試配置文件貿易聯合會。

測試配置可以指定特殊的設備設置選項和默認參數來提供測試類。

對樣品格里特更改配置文件的最新版本，可以訪問：框架/基/包/殼牌/測試/ 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。

看看這裡的更多信息測試模塊CONFIGS

JUnit4 特性

使用android-support-test庫作為測試運行使新JUnit4風格測試類的adoptation，樣品格里特變化包含了一些非常基本的使用其功能。

用於樣品格里特變化最新的源代碼可在被訪問：框架/鹼/包/殼牌/測試/ SRC / COM /機器人/殼/ BugreportReceiverTest.java

雖然測試模式通常特定於組件團隊，但有一些通常有用的使用模式。

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

JUnit4 的一個顯著區別是測試不再需要從一個公共的基礎測試類繼承；相反，您在純 Java 類中編寫測試並使用註釋來指示某些測試設置和約束。在此示例中，我們指示此類應作為 Android JUnit4 測試運行。

該@SmallTest註解規定的試驗大小為整個測試類：加入本次測試類的所有測試方法繼承了這個測試尺寸標註。預測試類的設置，測試後推倒，上下後測試類撕裂：類似setUp和tearDown在JUnit4方法。 Test註釋用於註釋的實際測試。

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

所述@Before註釋用於在由JUnit4方法來進行預測試設置。雖然在本例中沒有用到，這裡還有@After的測試後拆除。類似地， @BeforeClass和@AfterClass註釋可以由JUnit4方法中使用的測試類執行的所有測試之前執行設置和拆除之後。請注意，類範圍設置和拆卸方法必須是靜態的。

至於測試方法，不像JUnit中的早期版本，他們不再需要與啟動的方法名稱test ，相反，他們每個人都必須有註釋@Test 。像往常一樣，測試方法必須是公共的，沒有聲明返回值，沒有參數，並且可能會拋出異常。

        Context context = InstrumentationRegistry.getTargetContext();

因為JUnit4測試不再需要一個共同的基類，它不再需要獲得Context通過實例getContext()或getTargetContext()經由基類的方法;相反，新的測試運行通過管理它們InstrumentationRegistry其中通過儀表框架創建上下文和環境設置被儲存。通過這個類，你還可以調用：

getInstrumentation()該實例的Instrumentation類
getArguments()傳遞到命令行參數am instrument經由-e <key> <value>

在本地構建和測試

對於最常見的使用情況，應用ATEST 。

對於需要重定制更複雜的情況，按照儀器說明書。