指定應用程式範例

這種檢測設備測試與指定目標 一般 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 中的 setUptearDown 方法類似。 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

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