Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release thay vì aosp-main để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.

Trang này được dịch bởi Cloud Translation API.

Ví dụ về việc nhắm đến một ứng dụng

Danh mục kiểm thử đo lường này không khác nhiều so với những danh mục nhắm đến các ứng dụng Android thông thường. Điều đáng chú ý là ứng dụng kiểm thử có chứa chương trình đo lường cần được ký bằng cùng một chứng chỉ với ứng dụng mà ứng dụng đó nhắm đến.

Xin lưu ý rằng hướng dẫn này giả định rằng bạn đã có một số kiến thức về quy trình làm việc với cây nguồn nền tảng. Nếu không, vui lòng tham khảo phần Yêu cầu. Ví dụ được đề cập ở đây là viết một phép kiểm thử đo lường mới với gói mục tiêu được đặt tại gói ứng dụng kiểm thử riêng. Nếu bạn chưa hiểu rõ về khái niệm này, vui lòng đọc phần Giới thiệu về kiểm thử nền tảng.

Hướng dẫn này sử dụng kiểm thử theo dõi làm mẫu:

frameworks/base/packages/Shell/tests

Bạn nên duyệt qua mã trước để có được ấn tượng sơ bộ trước khi tiếp tục.

Quyết định vị trí nguồn

Vì kiểm thử đo lường sẽ nhắm đến một ứng dụng, nên quy ước là đặt mã nguồn kiểm thử trong thư mục tests bên dưới thư mục nguồn gốc của thành phần trong cây nguồn nền tảng.

Xem thêm các cuộc thảo luận về vị trí nguồn trong ví dụ toàn diện về kiểm thử tự đo lường.

Tệp kê khai

Giống như một ứng dụng thông thường, mỗi mô-đun kiểm thử đo lường đều cần một tệp kê khai. Nếu bạn đặt tên tệp là AndroidManifest.xml và cung cấp tệp đó bên cạnh Android.mk cho mô-đun kiểm thử, thì tệp đó sẽ tự động được đưa vào bởi tệp makefile cốt lõi BUILD_PACKAGE.

Trước khi tiếp tục, bạn nên xem qua bài viết Tổng quan về tệp kê khai ứng dụng trước.

Phần này cung cấp thông tin tổng quan về các thành phần cơ bản của tệp kê khai và chức năng của chúng.

Bạn có thể truy cập vào phiên bản mới nhất của tệp kê khai cho thay đổi mẫu gerrit tại: https://android.googlesource.com/platform/frameworks/base/+/android16-release/packages/Shell/tests/AndroidManifest.xml

Để thuận tiện, chúng tôi có chụp nhanh một phần nội dung:

<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>

Một số nhận xét chọn lọc về tệp kê khai:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.shell.tests">

Thuộc tính package là tên gói ứng dụng: đây là giá trị nhận dạng duy nhất mà khung ứng dụng Android dùng để nhận dạng một ứng dụng (hoặc trong ngữ cảnh này: ứng dụng kiểm thử của bạn). Mỗi người dùng trong hệ thống chỉ có thể cài đặt một ứng dụng có tên gói đó.

Vì đây là một gói ứng dụng kiểm thử, độc lập với gói ứng dụng đang được kiểm thử, nên bạn phải sử dụng một tên gói khác: một quy ước chung là thêm hậu tố .test.

Hơn nữa, thuộc tính package này giống với những gì ComponentName#getPackageName() trả về, cũng như giống với những gì bạn sẽ dùng để tương tác với nhiều lệnh phụ pm thông qua adb shell.

Xin lưu ý rằng mặc dù tên gói thường có cùng kiểu với tên gói Java, nhưng thực tế thì tên gói này có rất ít điểm chung với tên gói Java. Nói cách khác, gói ứng dụng (hoặc gói kiểm thử) có thể chứa các lớp có tên gói bất kỳ, mặc dù bạn có thể chọn cách đơn giản và đặt tên gói Java cấp cao nhất trong ứng dụng hoặc kiểm thử giống với tên gói ứng dụng.

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

Đây là yêu cầu bắt buộc đối với tất cả các Kiểm thử đo lường vì các lớp liên quan được đóng gói trong một tệp thư viện jar khung riêng biệt, do đó, cần có thêm các mục nhập classpath khi gói kiểm thử được gọi bởi khung ứng dụng.

android:targetPackage="com.android.shell"

Thao tác này sẽ đặt gói mục tiêu của hoạt động đo lường thành com.android.shell. Khi hoạt động đo lường được gọi thông qua lệnh am instrument, khung sẽ khởi động lại quy trình com.android.shell và chèn mã đo lường vào quy trình để thực thi kiểm thử. Điều này cũng có nghĩa là mã kiểm thử sẽ có quyền truy cập vào tất cả các thực thể lớp đang chạy trong ứng dụng đang được kiểm thử và có thể thao tác trạng thái tuỳ thuộc vào các lệnh gọi kiểm thử được hiển thị.

Tệp cấu hình đơn giản

Mỗi mô-đun kiểm thử mới phải có một tệp cấu hình để hướng dẫn hệ thống bản dựng bằng siêu dữ liệu mô-đun, các phần phụ thuộc tại thời gian biên dịch và hướng dẫn đóng gói. Trong hầu hết các trường hợp, lựa chọn tệp Blueprint dựa trên Soong là đủ. Hãy xem phần Cấu hình kiểm thử đơn giản để biết thông tin chi tiết.

Tệp cấu hình phức tạp

Đối với các quy trình kiểm thử phức tạp hơn, bạn cũng cần viết một tệp cấu hình kiểm thử cho bộ kiểm thử của Android, Trade Federation.

Cấu hình kiểm thử có thể chỉ định các lựa chọn thiết lập thiết bị đặc biệt và các đối số mặc định để cung cấp cho lớp kiểm thử.

Bạn có thể truy cập vào phiên bản mới nhất của tệp cấu hình cho thay đổi gerrit mẫu tại: frameworks/base/packages/Shell/tests/AndroidTest.xml

Để thuận tiện, chúng tôi có chụp nhanh một phần nội dung:

<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>

Một số nhận xét chọn lọc về tệp cấu hình kiểm thử:

<target_preparer class="com.android.tradefed.targetprep.TestAppInstallSetup">
  <option name="test-file-name" value="ShellTests.apk"/>
</target_preparer>

Thao tác này yêu cầu Trade Federation cài đặt ShellTests.apk lên thiết bị mục tiêu bằng cách sử dụng một target_preparer được chỉ định. Có nhiều trình chuẩn bị mục tiêu mà nhà phát triển có thể sử dụng trong Trade Federation và những trình này có thể được dùng để đảm bảo thiết bị được thiết lập đúng cách trước khi thực thi kiểm thử.

<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>

Thao tác này chỉ định lớp kiểm thử Trade Federation sẽ dùng để thực thi kiểm thử và truyền gói trên thiết bị sẽ được thực thi cũng như khung trình chạy kiểm thử (trong trường hợp này là JUnit).

Hãy xem tại đây để biết thêm thông tin về Cấu hình mô-đun kiểm thử

Tính năng JUnit4

Việc sử dụng thư viện android-support-test làm trình chạy kiểm thử cho phép áp dụng các lớp kiểm thử kiểu JUnit4 mới và thay đổi mẫu gerrit chứa một số cách sử dụng rất cơ bản các tính năng của thư viện này.

Bạn có thể truy cập vào mã nguồn mới nhất cho thay đổi mẫu trên Gerrit tại: frameworks/base/packages/Shell/tests/src/com/android/shell/BugreportReceiverTest.java

Mặc dù các mẫu kiểm thử thường dành riêng cho các nhóm thành phần, nhưng có một số mẫu sử dụng thường hữu ích.

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

Một điểm khác biệt đáng kể trong JUnit4 là các kiểm thử không còn bắt buộc phải kế thừa từ một lớp kiểm thử cơ sở chung; thay vào đó, bạn viết các kiểm thử trong các lớp Java thuần tuý và sử dụng chú thích để cho biết một số chế độ thiết lập và các ràng buộc kiểm thử. Trong ví dụ này, chúng ta đang hướng dẫn rằng lớp này sẽ chạy dưới dạng một kiểm thử Android JUnit4.

Chú thích @SmallTest chỉ định kích thước kiểm thử cho toàn bộ lớp kiểm thử: tất cả các phương thức kiểm thử được thêm vào lớp kiểm thử này đều kế thừa chú thích kích thước kiểm thử này. thiết lập lớp kiểm thử trước, huỷ lớp kiểm thử sau và huỷ lớp kiểm thử sau: tương tự như các phương thức setUp và tearDown trong JUnit4. Chú giải Test được dùng để chú thích kiểm thử thực tế.

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

Chú thích @Before được JUnit4 dùng trên các phương thức để thực hiện quá trình thiết lập trước khi kiểm thử. Mặc dù không được dùng trong ví dụ này, nhưng cũng có @After để huỷ kiểm thử sau khi kiểm thử. Tương tự, JUnit4 có thể dùng chú thích @BeforeClass và @AfterClass trên các phương thức để thực hiện quá trình thiết lập trước khi thực thi tất cả các bài kiểm thử trong một lớp kiểm thử và sau đó là quá trình huỷ thiết lập. Xin lưu ý rằng các phương thức thiết lập và huỷ bỏ ở phạm vi lớp phải là phương thức tĩnh.

Đối với các phương thức kiểm thử, không giống như trong phiên bản JUnit trước đó, các phương thức này không còn cần phải bắt đầu tên phương thức bằng test nữa, thay vào đó, mỗi phương thức phải được chú thích bằng @Test. Như thường lệ, các phương thức kiểm thử phải là phương thức công khai, không khai báo giá trị trả về, không nhận tham số và có thể tạo ra các trường hợp ngoại lệ.

        Context context = InstrumentationRegistry.getTargetContext();

Vì các bài kiểm thử JUnit4 không còn yêu cầu một lớp cơ sở chung, nên bạn không cần phải lấy các thực thể Context thông qua getContext() hoặc getTargetContext() thông qua các phương thức lớp cơ sở nữa. Thay vào đó, trình chạy kiểm thử mới sẽ quản lý các thực thể này thông qua InstrumentationRegistry, nơi lưu trữ chế độ thiết lập theo bối cảnh và môi trường do khung đo lường tạo. Thông qua lớp này, bạn cũng có thể gọi:

getInstrumentation(): thực thể của lớp Instrumentation
getArguments(): các đối số dòng lệnh được truyền đến am instrument thông qua -e <key> <value>

Xây dựng và kiểm thử cục bộ

Đối với các trường hợp sử dụng phổ biến nhất, hãy sử dụng Atest.

Đối với những trường hợp phức tạp hơn đòi hỏi mức độ tuỳ chỉnh cao hơn, hãy làm theo hướng dẫn về việc đo lường.