Ví dụ về kiểm thử tự đo lường

Khi bắt đầu một kiểm thử đo lường, gói mục tiêu của kiểm thử đó sẽ được khởi động lại bằng mã đo lường được chèn và bắt đầu thực thi. Một ngoại lệ là gói mục tiêu ở đây không được là chính khung ứng dụng Android, chẳng hạn như gói android, vì việc này dẫn đến tình huống nghịch lý là cần phải khởi động lại khung Android, là yếu tố hỗ trợ các chức năng của hệ thống, bao gồm cả chính hoạt động đo lường.

Điều này có nghĩa là kiểm thử đo lường không thể tự chèn vào khung Android (còn gọi là máy chủ hệ thống) để thực thi. Để kiểm thử khung Android, mã kiểm thử chỉ có thể gọi các giao diện API công khai hoặc các giao diện được hiển thị bằng Ngôn ngữ định nghĩa giao diện Android (AIDL) có trong cây nguồn của nền tảng. Đối với danh mục kiểm thử này, việc nhắm đến bất kỳ gói cụ thể nào cũng không có ý nghĩa. Do đó, thông thường, các công cụ đo lường như vậy sẽ được khai báo để nhắm đến gói ứng dụng kiểm thử riêng, như được xác định trong thẻ <manifest> của AndroidManifest.xml.

Tuỳ thuộc vào yêu cầu, các gói ứng dụng kiểm thử trong danh mục này cũng có thể:

• Cần có các hoạt động gói để kiểm thử.
• Chia sẻ mã nhận dạng người dùng với hệ thống.
• Được ký bằng khoá nền tảng.
• Được biên dịch dựa trên nguồn khung thay vì SDK công khai.

Danh mục kiểm thử đo lường này đôi khi được gọi là tự đo lường. Sau đây là một số ví dụ về kiểm thử tự đo lường trong nguồn nền tảng:

• frameworks/base/core/tests/
• frameworks/base/services/tests/servicestests

Ví dụ được đề cập ở đây là viết một 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ử của riêng nó. Hướng dẫn này sử dụng quy trình kiểm thử sau đây làm ví dụ:

• Kiểm thử đo lường Hello World

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

Thông thường, nhóm của bạn sẽ đã có một mẫu đã thiết lập về các vị trí cần kiểm tra trong mã và các vị trí cần thêm kiểm thử. Hầu hết các nhóm đều sở hữu một kho lưu trữ git hoặc chia sẻ một kho lưu trữ với các nhóm khác nhưng có một thư mục con chuyên dụng chứa mã nguồn thành phần.

Giả sử vị trí gốc cho nguồn thành phần của bạn là <component source root>, hầu hết các thành phần đều có thư mục src và tests bên dưới, cùng một số tệp bổ sung như Android.mk (hoặc được chia thành các tệp .mk bổ sung), tệp kê khai AndroidManifest.xml và tệp cấu hình kiểm thử "AndroidTest.xml".

Vì bạn đang thêm một chương trình kiểm thử hoàn toàn mới, nên có thể bạn sẽ cần tạo thư mục tests bên cạnh thành phần src và điền nội dung vào thư mục đó.

Trong một số trường hợp, nhóm của bạn có thể có thêm cấu trúc thư mục trong tests do cần đóng gói nhiều bộ kiểm thử thành các tệp apk riêng lẻ. Và trong trường hợp này, bạn cần tạo một thư mục con mới trong tests.

Bất kể cấu trúc nào, bạn sẽ điền sẵn thư mục tests hoặc thư mục con mới tạo bằng các tệp tương tự như trong thư mục instrumentation trong thay đổi gerrit mẫu. Thông tin chi tiết về từng tệp sẽ được giải thích ở phần sau của tài liệu này.

Tệp kê khai

Cũng như dự án ứng dụng, mỗi mô-đun kiểm thử đo lường đều yêu cầu một tệp kê khai có tên là AndroidManifest.xml. Để tự động đưa tệp này vào bằng cách sử dụng tệp makefile lõi BUILD_PACKAGE, hãy cung cấp tệp này bên cạnh tệp Android.mk cho mô-đun kiểm thử.

Nếu bạn chưa quen với tệp AndroidManifest.xml, hãy tham khảo phần Tổng quan về tệp kê khai ứng dụng

Sau đây là tệp AndroidManifest.xml mẫu:

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

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="android.test.example.helloworld" >

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 sử dụng để xác định 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 đó.

Hơn nữa, thuộc tính package này giống với giá trị mà ComponentName#getPackageName() trả về, đồng thời cũng giống với giá trị bạn sẽ sử dụng để tương tác với nhiều lệnh con pm sử dụng 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ế tên gói 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 kiểm thử) của bạn có thể chứa các lớp có tên gói bất kỳ, mặc dù mặt khác, bạn có thể chọn đơ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.

android:sharedUserId="android.uid.system"

Điều này khai báo rằng tại thời điểm cài đặt, tệp APK này phải được cấp cùng một mã nhận dạng người dùng, tức là danh tính thời gian chạy, như nền tảng cốt lõi. Xin lưu ý rằng điều này phụ thuộc vào việc tệp APK được ký bằng cùng một chứng chỉ với nền tảng cốt lõi (xem LOCAL_CERTIFICATE trong phần trước), nhưng chúng là các khái niệm khác nhau:

• một số quyền hoặc API được bảo vệ bằng chữ ký, yêu cầu cùng một chứng chỉ ký
• một số quyền hoặc API yêu cầu danh tính người dùng system của phương thức gọi, yêu cầu gói gọi chia sẻ mã nhận dạng người dùng với system, nếu đó là một gói riêng biệt với chính nền tảng cốt lõi

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

Điều này là 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 đường dẫn lớp khi gói kiểm thử được khung ứng dụng gọi.

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

Bạn có thể nhận thấy rằng targetPackage ở đây được khai báo giống với thuộc tính package được khai báo trong thẻ manifest của tệp này. Như đã đề cập trong phần kiến thức cơ bản về kiểm thử, danh mục kiểm thử đo lường này thường dành cho việc kiểm thử API khung, vì vậy, việc có một gói ứng dụng được nhắm mục tiêu cụ thể (ngoài chính gói đó) là không có ý nghĩa.

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 xây dựng bằng siêu dữ liệu mô-đun, các phần phụ thuộc tại thời điểm biên dịch và hướng dẫn đó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à đủ. Để biết thông tin chi tiết, hãy xem phần Cấu hình kiểm thử đơn giản.

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

Lưu ý quan trọng: Bạn chỉ cần làm theo hướng dẫn trong phần này đối với các bài kiểm thử CTS hoặc các bài kiểm thử yêu cầu thiết lập đặc biệt, chẳng hạn như tắt Bluetooth hoặc thu thập dữ liệu mẫu. Bạn có thể xử lý tất cả các trường hợp khác thông qua Cấu hình kiểm thử đơn giản. Hãy xem phần Cấu hình kiểm thử phức tạp để biết thêm thông tin chi tiết áp dụng cho phần này.

Đối với những trường hợp phức tạp hơn này, bạn cũng cần viế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 tuỳ chọn thiết lập thiết bị đặc biệt và đối số mặc định để cung cấp lớp kiểm thử. Xem ví dụ tại /platform_testing/tests/example/instrumentation/AndroidTest.xml.

Để thuận tiện, chúng tôi cung cấp một bản tổng quan nhanh tại đây:

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

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="HelloWorldTests.apk"/>
</target_preparer>

Thao tác này sẽ yêu cầu Trade Federation cài đặt HelloWorldTests.apk trên thiết bị mục tiêu bằng cách sử dụng target_preparer đã chỉ định. Có nhiều trình chuẩn bị mục tiêu dành cho nhà phát triển trong Trade Federation và bạn có thể sử dụng các trình này để đả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="android.test.example.helloworld"/>
  <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 nhằm thực thi kiểm thử và truyền trong gói trên thiết bị sẽ được thực thi và khung trình chạy kiểm thử là JUnit trong trường hợp này.

Để biết thêm thông tin, hãy xem phần Kiểm thử cấu hình mô-đun.

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 sử dụng các lớp kiểm thử 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 thư viện này. Xem ví dụ tại /platform_testing/tests/example/instrumentation/src/android/test/example/helloworld/HelloWorldTest.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.

@RunWith(JUnit4.class)
public class HelloWorldTest {

Một điểm khác biệt đáng kể trong JUnit4 là các bài 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 bài 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ố quy tắc thiết lập và quy tắc ràng buộc nhất định của kiểm thử. Trong ví dụ này, chúng tôi hướng dẫn rằng lớp này sẽ chạy dưới dạng kiểm thử JUnit4.

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

Chú thích @Before và @After đượ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ử và gỡ bỏ sau kiểm thử. Tương tự, chú thích @BeforeClass và @AfterClass được JUnit4 sử dụng trên các phương thức để 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 đó huỷ thiết lập. Xin lưu ý rằng các phương thức thiết lập và gỡ bỏ trong phạm vi lớp phải là 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 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 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ệ.

Lưu ý quan trọng: Bản thân các phương thức kiểm thử được chú thích bằng chú thích @Test; và lưu ý rằng để các chương trình kiểm thử được thực thi thông qua APCT, các chương trình kiểm thử đó phải được chú thích bằng kích thước kiểm thử: ví dụ: phương thức được chú thích testHelloWorld là @SmallTest. Bạn có thể áp dụng chú thích ở phạm vi phương thức hoặc phạm vi lớp.

Quyền truy cập vào lớp đo lường

Mặc dù không được đề cập trong ví dụ cơ bản về hello world, nhưng khá phổ biến khi một bài kiểm thử Android yêu cầu quyền truy cập vào thực thể Instrumentation: đây là giao diện API cốt lõi cung cấp quyền truy cập vào ngữ cảnh ứng dụng, các API kiểm thử liên quan đến vòng đời hoạt động và nhiều API khác.

Vì các kiểm thử JUnit4 không còn yêu cầu lớp cơ sở chung, nên bạn không cần phải lấy thực thể Instrumentation thông qua InstrumentationTestCase#getInstrumentation() nữa. Thay vào đó, trình chạy kiểm thử mới sẽ quản lý thực thể này thông qua InstrumentationRegistry, nơi lưu trữ chế độ thiết lập môi trường và ngữ cảnh do khung đo lường tạo.

Để truy cập vào thực thể của lớp Instrumentation, bạn chỉ cần gọi phương thức tĩnh getInstrumentation() trên lớp InstrumentationRegistry:

Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()

Tạo bản 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 các trường hợp phức tạp hơn đòi hỏi phải tuỳ chỉnh nhiều hơn, hãy làm theo hướng dẫn đo lường.