針對應用示例

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

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

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

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

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

確定源位置

因為儀器測試將針對應用程序,所以慣例是將測試源代碼放在平台源代碼樹中組件源目錄根下的tests目錄中。

請參閱自檢測測試的端到端示例中有關源位置的更多討論。

清單文件

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

在繼續之前,強烈建議先閱讀App Manifest 概覽

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

可以在以下位置訪問示例 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()返回的內容相同,也與您通過adb shell與各種pm子命令交互pm使用的相同。

另請注意,雖然包名通常與 Java 包名具有相同的風格,但實際上與它無關。換句話說,您的應用程序(或測試)包可能包含具有任何包名稱的類,但另一方面,您可以選擇簡單並在應用程序中使用頂級 Java 包名稱或測試與應用程序包名稱相同。

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

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

android:targetPackage="com.android.shell"

com.android.shell檢測的目標包設置為com.android.shell 。當通過am instrument命令調用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 安裝到目標設備上。 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。

在此處查看有關測試模塊配置的更多信息

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() {
    ...

@Before在方法上使用@Before註釋來執行預測試設置。雖然在這個例子中沒有使用,但也有@After用於測試後拆卸。類似地,@ @BeforeClass@AfterClass註釋可用於 JUnit4 的方法上,以在執行測試類中的所有測試之前執行設置,然後進行拆卸。請注意,類範圍設置和拆卸方法必須是靜態的。

至於測試方法,與早期版本的 JUnit 不同,它們不再需要以test開頭的方法名稱,而是每個方法都必須使用@Test進行註釋。像往常一樣,測試方法必須是公共的,沒有聲明返回值,沒有參數,並且可能會拋出異常。

        Context context = InstrumentationRegistry.getTargetContext();

由於 JUnit4 測試不再需要公共基類,因此不再需要通過基類方法通過getContext()getTargetContext()獲取Context實例;相反,新的測試運行器通過InstrumentationRegistry管理它們,其中存儲了由檢測框架創建的上下文和環境設置。通過這個類,你還可以調用:

  • getInstrumentation() : Instrumentation類的實例
  • getArguments() :通過-e <key> <value>傳遞給am instrument的命令行參數

在本地構建和測試

對於最常見的用例,請使用Atest

對於需要更多定制的更複雜的情況,請按照儀器說明進行操作