Google cam kết thúc đẩy công bằng chủng tộc cho các cộng đồng Đen. Xem thế nào.
Trang này được dịch bởi Cloud Translation API.
Switch to English

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

Danh mục kiểm tra thiết bị này không khác biệt so với các ứng dụng nhắm mục tiêu vào các ứng dụng Android thông thường. Điều đáng chú ý là ứng dụng thử nghiệm bao gồm thiết bị cần phải được ký với cùng một chứng chỉ với ứng dụng mà nó 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 không, vui lòng tham khảo https://source.android.com/source/requirements. Ví dụ được trình bày ở đây là viết một bài kiểm tra thiết bị mới với gói mục tiêu được đặt ở gói ứng dụng thử nghiệm riêng của nó. Nếu bạn không quen với khái niệm này, vui lòng đọc qua phần giới thiệu thử nghiệm Nền tảng .

Hướng dẫn này sử dụng thử nghiệm sau để phục vụ như một mẫu:

  • khung / cơ sở / gói / Shell / thử nghiệm

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

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

Bởi vì kiểm tra thiết bị sẽ nhắm mục tiêu vào một ứng dụng, quy ước là đặt mã nguồn kiểm tra trong thư mục tests dưới thư mục gốc của thư mục nguồn thành phần của bạ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ụ từ đầu đến cuối để tự kiểm tra dụng cụ .

Tệp kê khai

Giống như một ứng dụng thông thường, mỗi mô-đun kiểm tra thiết bị 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 tmodule thử nghiệm của bạn, nó sẽ được bao gồm tự động bởi BUILD_PACKAGE lõi BUILD_PACKAGE .

Trước khi tiếp tục, trước tiên bạn nên xem qua Tổng quan về biểu hiện ứng dụng .

Điều này cung cấp một cái nhìn tổng quan về các thành phần cơ bản của một tệp kê khai và các chức năng của chúng.

Phiên bản mới nhất của tệp kê khai cho thay đổi gerrit mẫu có thể được truy cập tại: https://android.googlesource.com/pl platform / frameworks / base / + / master / pack / Shell / tests / AgroidManifest.xml

Một ảnh chụp nhanh được bao gồm ở đây để thuận tiện:

 <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 trên 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à định danh duy nhất mà khung ứng dụng Android sử dụng để xác định một ứ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 với tên gói đó.

Vì đây là gói ứng dụng thử nghiệm, độc lập với gói ứng dụng được thử nghiệm, nên phải sử dụng 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 như những gì mà ComponentName#getPackageName() trả về và cũng giống như bạn sẽ sử dụng để tương tác với các lệnh phụ pm khác nhau thông qua adb shell .

Cũng 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ế nó có rất ít thứ để làm với nó. Nói cách khác, gói ứng dụng (hoặc kiểm tra) của bạn có thể chứa các lớp với bất kỳ tên gói nào, mặc dù mặt khác, bạn có thể chọn đơn giản và có tên gói Java cấp cao nhất trong ứng dụng của bạn hoặc kiểm tra giống hệt với tên gói ứng dụng.

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

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

 android:targetPackage="com.android.shell"
 

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

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

Mỗi mô-đun thử nghiệm mới phải có tệp cấu hình để chỉ đạo hệ thống xây dựng với siêu dữ liệu mô-đun, phụ thuộc 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, tùy chọn tệp Blueprint dựa trên Soong là đủ. Xem Cấu hình kiểm tra đơn giản để biết chi tiết.

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

Đối với các thử nghiệm phức tạp hơn, bạn cũng cần phải viết tệp cấu hình thử nghiệm cho khai thác thử nghiệm của Android, Liên đoàn thương mại .

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

Phiên bản mới nhất của tệp cấu hình cho thay đổi gerrit mẫu có thể được truy cập tại: frameworks / base / gói / Shell / tests / AndroidTest.xml

Một ảnh chụp nhanh được bao gồm ở đây để thuận tiện:

 <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 trên tệp cấu hình thử nghiệm:

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

Điều này báo cho Liên đoàn thương mại cài đặt ShellTests.apk lên thiết bị đích bằng cách sử dụng target_preparer được chỉ định. Có nhiều trình chuẩn bị mục tiêu có sẵn cho các nhà phát triển trong Liên đoàn thương mại và chúng có thể được sử dụng để đảm bảo thiết bị được thiết lập đúng trước khi thực hiện kiểm tra.

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

Điều này chỉ định lớp kiểm tra Liên đoàn thương mại sẽ sử dụng để thực hiện kiểm tra và chuyển gói trong thiết bị được thực thi và khung chạy thử nghiệm là JUnit trong trường hợp này.

Nhìn vào đây để biết thêm thông tin về Test Module Configs

Tính năng JUnit4

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

Mã nguồn mới nhất cho thay đổi gerrit mẫu có thể được truy cập tại: frameworks / base / gói / Shell / tests / src / com / android / shell / BugreportReceiverTest.java

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

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

Một sự khác biệt đáng kể trong JUnit4 là các bài kiểm tra không còn cần thiết để kế thừa từ một lớp kiểm tra cơ sở chung; thay vào đó, bạn viết các bài kiểm tra trong các lớp Java đơn giản và sử dụng chú thích để chỉ ra các ràng buộc và thiết lập thử nghiệm nhất định. Trong ví dụ này, chúng tôi đang hướng dẫn rằng lớp này nên được chạy dưới dạng thử nghiệm JUnit4 của Android.

Chú thích @SmallTest chỉ định kích thước thử nghiệm cho toàn bộ lớp thử nghiệm: tất cả các phương thức thử nghiệm được thêm vào lớp thử nghiệm này đều kế thừa chú thích kích thước thử nghiệm này. trước kiểm tra thiết lập lớp, bài kiểm tra rách xuống, và bài kiểm tra lớp giọt nước mắt xuống: tương tự như setUptearDown phương pháp trong Junit4. Chú thích Test được sử dụng để chú thích thử nghiệm thực tế.

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

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

Đối với các phương thức thử nghiệm, không giống như trong phiên bản JUnit trước đó, chúng không còn cần phải bắt đầu tên phương thức bằng test , 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 tra phải được công khai, tuyên bố không có giá trị trả về, không có tham số và có thể ném ngoại lệ.

         Context context = InstrumentationRegistry.getTargetContext();
 

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

  • getInstrumentation() : ví dụ cho lớp Instrumentation
  • getArguments() : các đối số dòng lệnh được truyền cho am instrument qua -e <key> <value>

Xây dựng và thử nghiệm cục bộ

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

Đối với các trường hợp phức tạp hơn đòi hỏi tùy chỉnh nặng hơn, hãy làm theo các hướng dẫn thiết bị .