指定應用程式範例

這類檢測設備測試與以一般 Android 應用程式為目標的測試並無太大差異。值得一提的是,包含檢測設備的測試應用程式必須使用與目標應用程式相同的憑證簽署。

請注意,本指南假設您已具備平台來源樹工作流程的相關知識。如果沒看到,請參閱相關規定。 這裡的範例是為新的檢測設備測試,在其測試應用程式套件中設定目標套件。如果您不熟悉這個概念,請參閱平台測試簡介

本指南會使用追蹤測試做為範例:

  • frameworks/base/packages/Shell/tests

建議您先瀏覽程式碼,取得大致印象,再繼續操作。

決定來源位置

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

如要進一步瞭解來源位置,請參閱自檢測設備測試的端對端範例

資訊清單檔案

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

在繼續操作之前,強烈建議您先詳閱「應用程式資訊清單總覽」。

這份文件將概略說明資訊清單檔案的基本元件及其功能。

如要存取範例 Gerrit 變更的最新版資訊清單檔案,請前往以下網址: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 應用程式架構用來識別應用程式 (或在此情境中,也就是測試應用程式) 的專屬 ID。系統中的每位使用者只能安裝一個套件名稱相同的應用程式。

由於這是測試應用程式套件,與受測試的應用程式套件無關,必須使用其他套件名稱:新增後置字串 .test 的常見慣例如下。

此外,這個 package 屬性與 ComponentName#getPackageName() 傳回的內容相同,也是您透過 adb shell 與各種 pm 子命令互動的內容。

另請注意,雖然套件名稱通常與 Java 套件名稱的樣式相同,但實際上只能搭配極少數操作。換句話說,應用程式 (或測試) 套件可包含任何套件名稱的類別,但您也可以選擇簡化方式,讓應用程式或測試中的頂層 Java 套件名稱與應用程式套件名稱相同。

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

所有檢測設備測試都必須完成,因為相關類別均封裝在獨立的架構 jar 程式庫檔案中,因此應用程式架構叫用測試套件時,需要額外的類別路徑項目。

android:targetPackage="com.android.shell"

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

簡易設定檔

每個新的測試模組都必須具有設定檔,以透過模組中繼資料、編譯時間依附元件和封裝操作說明來引導建構系統。在大多數情況下,以 Soong 為基礎的藍圖檔案選項就足夠了。詳情請參閱「簡易測試設定」。

複雜的設定檔

對於較複雜的測試,您還需要為 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 安裝到目標裝置上。貿易聯盟的開發人員有許多目標準備工具,可以用來在執行測試之前,確保裝置已正確設定。

<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 中的 setUptearDown 方法。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()getTargetContext() 取得 Context 執行個體。相反地,新的測試執行器會透過 InstrumentationRegistry (儲存檢測架構建立的情境與環境設定) 管理這些執行個體。您也可以透過這個類別呼叫:

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

在本機建構及測試

針對最常見的用途,請採用 Atest

如需更複雜的做法,且需要更多自訂功能,請按照檢測器操作說明操作。