自我檢測測試範例

檢測設備測試開始時,其目標套件會 而已插入並啟動執行程式。一 例外狀況是無法將這裡的目標套件 例如 android 套件,因為這樣會導致 必須重新啟動 Android 架構的類似情況 是支援系統功能,包括檢測本身。

這表示檢測設備測試無法自行插入至 Android 也就是系統伺服器為了測試 測試程式碼只能叫用公用 API 介面 使用 Android 介面定義語言 AIDL 可在平台原始碼樹狀結構中找到。對於這類測試,指定任何特定套件都沒有意義。因此,專門針對這類模型 指定其針對其測試應用程式套件進行宣告的檢測, 在其 AndroidManifest.xml<manifest> 標記中定義。

視需求而定,這個類別的測試應用程式套件可能會 另外:

  • 封裝測試所需的活動。
  • 將使用者 ID 提供給系統。
  • 使用平台金鑰簽署。
  • 根據架構來源 (而非公用 SDK) 進行編譯。

這種檢測設備測試的類別有時也稱為 自我檢測以下列舉幾個 平台來源:

本節的範例是撰寫新的檢測設備測試,並將目標套件設為其專屬的測試應用程式套件。本指南會以以下測試做為範例:

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

決定來源位置

一般來說,您的團隊已有一定的檢查地點模式 以及要新增測試的位置大多數團隊都擁有一個 git 存放區,或與其他團隊共用一個存放區,但會設有專屬子目錄,用於儲存元件原始碼。

假設元件來源的根目錄位於 <component source root>,大多數元件都會在其下方建立 srctests 資料夾,以及一些額外的檔案,例如 Android.mk (或分割成額外的 .mk 檔案)、資訊清單檔案 AndroidManifest.xml 和測試設定檔案「AndroidTest.xml」。

由於您要新增的是全新的測試,因此您可能需要建立 tests 目錄 (位於元件 src 旁邊),並填入內容。

在某些情況下,團隊可能需要將不同測試套件封裝成個別的 APK,因此會在 tests 下建立更多目錄結構。在這種情況下,您必須在 tests 下建立新的子目錄。

無論結構為何,您都會填入 tests 目錄或 新建的子目錄,其中包含與 範例變數變更的 instrumentation 目錄。每項要求的詳情 ,本文件稍後會說明。

資訊清單檔案

如同應用程式專案,每個檢測設備測試模組都需要 名為 AndroidManifest.xml 的資訊清單檔案如要使用 BUILD_PACKAGE 核心 Makefile 自動加入這個檔案,請在測試模組的 Android.mk 檔案旁提供這個檔案。

如果您不熟悉 AndroidManifest.xml 檔案,請參閱「應用程式資訊清單總覽

以下是 AndroidManifest.xml 範例檔案:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
  android:sharedUserId="android.uid.system"
  package="android.test.example.helloworld" >

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

    <instrumentation android:name="androidx.test.runner.AndroidJUnitRunner"
                     android:targetPackage="android.test.example.helloworld"
                     android:label="Hello World Test"/>

</manifest>

以下為資訊清單檔案的一些說明:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="android.test.example.helloworld" >

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

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

請注意,雖然套件名稱通常與 Java 套件名稱採用相同的樣式,但實際上兩者之間的關聯性很低。在其他 字詞,您的應用程式 (或測試) 套件可能包含與任何套件相關的類別。 但反過來說,您可以 簡明扼要地 層級的 Java 套件名稱,或測試應用程式和應用程式完全相同的 Java 套件名稱 套件名稱。

android:sharedUserId="android.uid.system"

此宣告宣告,在安裝時,這個 APK 檔案應將 相同的使用者 ID (也就是執行階段身分) 做為核心平台請注意,此 要視簽署的 APK 使用與核心平台相同的憑證而定 (請參閱上一節的 LOCAL_CERTIFICATE) 但不同 概念:

  • 這是因為某些權限或 API 受到簽章保護,因此 簽署憑證
  • 部分權限或 API 需要呼叫端的 system 使用者身分,因此呼叫端套件必須與 system 共用使用者 ID (如果是核心平台本身的獨立套件)
<uses-library android:name="android.test.runner" />

所有檢測設備測試都必須提供此項目,因為相關的類別 封裝於個別架構 JAR 程式庫檔案中,因此需要 應用程式架構叫用測試套件時的 classpath 項目。

android:targetPackage="android.test.example.helloworld"

您可能已經注意到,這裡的 targetPackage 宣告與 這個檔案的 manifest 標記中已宣告 package 屬性。如先前所述 通常用於測試架構 API,因此這對客戶來說 但須有特定的指定應用程式套件

簡易設定檔

每個新的測試模組都必須有設定檔 建構系統,其中包含模組中繼資料、編譯時間依附元件和封裝 操作說明。在多數情況下,Soong 型的 Blueprint 檔案選項為 而負責任的 AI 技術做法 有助於達成這項目標詳情請參閱 簡易測試設定

複雜設定檔

如果是較複雜的情況,您還需要撰寫測試設定 為 Android 測試控管檔案 貿易聯盟

測試設定可以指定特殊裝置設定選項和預設引數,以提供測試類別。請參閱 /platform_testing/tests/example/instrumentation/AndroidTest.xml 中的範例。

為了方便起見,以下提供快照:

<configuration description="Runs sample instrumentation test.">
  <target_preparer class="com.android.tradefed.targetprep.TestFilePushSetup"/>
  <target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
    <option name="test-file-name" value="HelloWorldTests.apk"/>
  </target_preparer>
  <target_preparer class="com.android.tradefed.targetprep.PushFilePreparer"/>
  <target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer"/>
  <option name="test-suite-tag" value="apct"/>
  <option name="test-tag" value="SampleInstrumentationTest"/>

  <test class="com.android.tradefed.testtype.AndroidJUnitTest">
    <option name="package" value="android.test.example.helloworld"/>
    <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="HelloWorldTests.apk"/>
</target_preparer>

這會指示貿易聯盟將 HelloWorldTests.apk 安裝到目標 透過指定的 target_preparer 控制裝置。目前有許多目標準備工具 提供給商業聯盟的開發人員使用,這些內容能用來 在執行測試前,裝置已正確設定。

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

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

若需更多資訊,請參閲 測試模組設定

JUnit4 功能

使用 android-support-test 程式庫做為測試執行工具,即可採用新的 JUnit4 樣式測試類別,而範例變數變更包含一些非常基本的 相關功能範例如下: /platform_testing/tests/example/instrumentation/src/android/test/example/helloworld/HelloWorldTest.java

雖然測試模式通常是元件團隊專屬,但有些使用模式通常相當實用。

@RunWith(JUnit4.class)
public class HelloWorldTest {

JUnit4 的一大差異之處在於,測試不再需要繼承自通用基礎測試類別;而是在純 Java 類別中編寫測試,並使用註解指出特定測試設定和限制。於 在本例中,我們指示此類別應做為 JUnit4 測試執行。

    @BeforeClass
    public static void beforeClass() {
    ...
    @AfterClass
    public static void afterClass() {
    ...
    @Before
    public void before() {
    ...
    @After
    public void after() {
    ...
    @Test
    @SmallTest
    public void testHelloWorld() {
    ...

JUnit4 會使用 @Before@After 註解對方法執行 測試前的設定與測試後拆除同樣地,@BeforeClass 和 JUnit4 會在方法上使用 @AfterClass 註解,先執行設定 請在測試類別中執行所有測試,然後再拆卸。請注意,類別範圍的設定和拆除方法必須是靜態的。至於測試方法,與早期版本的 JUnit 不同,這些方法的名稱不再需要以 test 開頭,而是必須使用 @Test 註解。和往常一樣 測試方法必須設為公開、宣告沒有傳回值、不含任何參數,且 可能會擲回例外狀況

檢測類別存取權

雖然沒有以基本的 Hello World 範例來說明,但一般而言, 需要存取 Instrumentation 執行個體的 Android 測試:這是核心 API 提供應用程式結構定義、活動生命週期存取權的介面 相關的測試 API 等等

由於 JUnit4 測試不再需要通用基礎類別,因此不再需要 而需透過其他方式取得 Instrumentation 執行個體 而是使用新的測試執行器 InstrumentationTestCase#getInstrumentation() 透過 InstrumentationRegistry 管理 其中,檢測架構建立的情境與環境設定 儲存。

如要存取 Instrumentation 類別的例項,只要在 InstrumentationRegistry 類別上呼叫靜態方法 getInstrumentation() 即可:

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

在本機建構及測試

最常見的用途是 Atest

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