Nhắm mục tiêu một ví dụ ứng dụng

Loại kiểm thử đo lường này không khác với các tiêu chí nhắm mục tiêu các ứng dụng Android thông thường. Lưu ý rằng ứng dụng kiểm thử có bao gồm khả năng đo lường cần được ký bằng cùng một chứng chỉ dưới dạng ứng dụng mà nhóm nhắm mục tiêu.

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

Tài liệu hướng dẫn này sử dụng quy trình kiểm thử sau đây để làm mẫu:

  • khung/cơ sở/gói/Vỏ/kiểm thử

Bạn nên duyệt qua mã trước để có ấn tượng rõ ràng trước khi tiếp tục.

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

Vì bài 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 trong thư mục gốc của thư mục nguồn thành phần trong cây nguồn của 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 cần có một tệp kê khai. Nếu bạn đặt tên tệp là AndroidManifest.xml và cung cấp tệp này ở bước tiếp theo vào Android.mk cho mô-đun kiểm thử của bạn, thì mô-đun này sẽ tự động được đưa vào Tệp makefile chính BUILD_PACKAGE.

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

Bài viết 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à các thành phần .

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

Để thuận tiện cho bạn, tôi xin cung cấp thông tin tổng quan nhanh:

<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 trong 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ị duy nhất mà khung ứng dụng Android sử dụng để xác định ứng dụng (hoặc trong ngữ cảnh này: ứng dụng thử nghiệm 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à gói ứng dụng kiểm thử, độc lập với ứng dụng gói đang được kiểm thử, 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.

Ngoài ra, thuộc tính package này giống với thuộc tính ComponentName#getPackageName() cũng như cách bạn sẽ sử dụng để tương tác với pm phụ qua adb shell.

Xin lưu ý rằng mặc dù tên gói thường theo cùng một kiểu là tên gói Java, nhưng thực sự nó không có nhiều tác dụng. Trong khu vực khác các từ khác, gói ứng dụng (hoặc kiểm thử) của bạn có thể chứa các lớp có gói bất kỳ khác, mặt khác, bạn có thể chọn tính đơn giản và có được tên gói Java cấp trong ứng dụng của bạn hoặc kiểm thử giống với ứng dụng tên gói.

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

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

android:targetPackage="com.android.shell"

Thao tác này sẽ đặt gói mục tiêu của khả năng đo lường thành com.android.shell. Khi khả năng đo lường được gọi thông qua lệnh am instrument, khung này khởi động lại quá trình com.android.shell và chèn mã đo lường vào quy trình chạy thử nghiệm. Đ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ể có thể thao tác trạng thái tuỳ thuộc vào các hook kiểm thử được đưa ra.

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 để chuyển hướng hệ thống xây dựng với siêu dữ liệu mô-đun, phần phụ thuộc thời gian biên dịch và đóng gói . Trong hầu hết các trường hợp, tuỳ chọn tệp Blueprint, dựa trên Soong là là đủ. Xem phần Cấu hình kiểm thử đơn giản để biết chi tiết.

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

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

Cấu hình kiểm thử có thể chỉ định các tuỳ chọn thiết lập thiết bị đặc biệt và để cung cấp 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 để thay đổi tệp gerrit mẫu vào lúc: frameworks/base/packages/Shell/tests/AndroidTest.xml

Để thuận tiện cho bạn, tôi xin cung cấp thông tin tổng quan nhanh:

<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 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 trên mục tiêu bằng cách sử dụng target_preparer cụ thể. Có nhiều người chuẩn bị mục tiêu dành cho các nhà phát triển trong Liên đoàn Thương mại và có thể sử dụng các mã này để đảm bảo thiết bị được thiết lập đúng cách trước khi chạy thử nghiệm.

<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ử Liên kết Thương mại sẽ sử dụng để thực thi phép kiểm thử và truyền trong gói trên thiết bị cần được thực thi và trình chạy kiểm thử trong trường hợp này là JUnit.

Tìm hiểu thêm thông tin về Cấu hình mô-đun kiểm thử tại đây

Các tính năng của JUnit4

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

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

Mặc dù 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ố các mẫu sử dụng thường hữu ích nhất.

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

Một điểm khác biệt đáng kể trong JUnit4 là 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 mã kiểm thử bằng Java thuần tuý các lớp và sử dụng chú giải để cho biết một số cách thiết lập kiểm thử cũng như các quy tắc ràng buộc. Trong trong ví dụ này, chúng ta sẽ hướng dẫn rằng lớp này nên được chạy dưới dạng một Android Thử nghiệm 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ả phương thức kiểm thử được thêm vào lớp kiểm thử này sẽ kế thừa chú thích kích thước kiểm thử này. thiết lập lớp kiểm tra trước, chia nhỏ lớp kiểm thử sau và chia nhỏ lớp kiểm tra sau bài kiểm tra: tương tự như các phương thức setUp và tearDown trong JUnit4. Chú giải Test dùng để chú thích kiểm thử thực tế.

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

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

Đối với các phương thức kiểm thử, không giống như trong phiên bản trước của JUnit, phương thức kiểm thử này không còn cần để bắt đầu tên phương thức bằng test. Thay vào đó, mỗi phương thức đều phải được chú thích cùng với @Test. Như thường lệ, phương thức kiểm thử phải là công khai, không khai báo giá trị trả về, không nhận tham số và có thể gửi 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ữa nên lớp này không còn nữa cần thiết để lấy thực thể Context thông qua getContext() hoặc getTargetContext() thông qua các phương thức của lớp cơ sở; thay vào đó, trình chạy kiểm thử mới quản lý chúng thông qua InstrumentationRegistry trong đó chế độ thiết lập theo bối cảnh và môi trường do khung đo lường tạo ra là lưu trữ. Thông qua lớp này, bạn cũng có thể gọi:

  • getInstrumentation(): một thực thể của lớp Instrumentation
  • getArguments(): các đối số dòng lệnh được chuyển đến am instrument 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 Cuộc thi.

Đối với các trường hợp phức tạp hơn yêu cầu tùy chỉnh nặng hơn, hãy làm theo hướng dẫn đo lường.