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

Ví dụ kiểm tra tự dụng cụ

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

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

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

  • Các hoạt động bó cần thiết để thử nghiệm.
  • Chia sẻ ID người dùng với hệ thống.
  • Được ký với khóa nền tảng.
  • Được biên dịch dựa trên nguồn khung chứ không phải SDK công khai.

Thể loại kiểm tra thiết bị này đôi khi được gọi là tự kiểm tra. Dưới đây là một số ví dụ về các bài kiểm tra tự thiết bị trong nguồn nền tảng:

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ó. Hướng dẫn này sử dụng thử nghiệm sau đây để làm ví dụ:

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

Thông thường, nhóm của bạn sẽ có một mẫu địa điểm được thiết lập để kiểm tra mã và địa điểm để thêm các bài kiểm tra. Hầu hết các nhóm sở hữu một kho lưu trữ git duy nhất hoặc chia sẻ một nhóm với các nhóm khác nhưng có một thư mục con chuyên dụng có 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ó srctests các thư mục bên dưới nó và 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 thử nghiệm 'AndroidTest.xml'.

Vì bạn đang thêm một thử nghiệm hoàn toàn mới, có lẽ bạn sẽ cần phải tạo thư mục tests bên cạnh src thành phần của bạn và điền nó vào nội dung.

Trong một số trường hợp, nhóm của bạn có thể có các cấu trúc thư mục tiếp theo trong tests do nhu cầu đóng gói các bộ kiểm tra khác nhau vào các mục riêng lẻ. Và trong trường hợp này, bạn sẽ cần tạo một thư mục con mới trong tests .

Bất kể cấu trúc nào, cuối cùng bạn sẽ điền vào thư mục tests hoặc thư mục con mới được tạo với các tệp tương tự như trong thư mục instrumentation trong thay đổi gerrit mẫu. Các phần dưới đây sẽ giải thích chi tiết hơn về mỗi tệp.

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. Xem ví dụ tại platform_testing / tests / example / instrumentation / AndroidManifest.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="android.test.example.helloworld" >

    <uses-sdk android:minSdkVersion="21" android:targetSdkVersion="21" />

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

    <instrumentation android:name="android.support.test.runner.AndroidJUnitRunner"
                     android:targetPackage="android.test.example.helloworld"
                     android:label="Hello World Test"/>

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

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 đó.

Hơn nữa, thuộc tính package này giống như những gì ComponentName#getPackageName() trả về, và cũng chính là thứ 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.

 android:sharedUserId="android.uid.system"
 

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

  • một số quyền hoặc API được bảo vệ chữ ký, yêu cầu chứng chỉ ký giống nhau
  • một số quyền hoặc API yêu cầu nhận dạng người dùng system của người gọi, yêu cầu gói gọi để chia sẻ id người dùng với system , nếu đó là gói riêng biệt từ 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 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="android.test.example.helloworld"
 

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

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à đủ. Để biết chi tiết, xem Cấu hình kiểm tra đơn giản .

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

Đối với những trường hợp phức tạp hơn này, 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. Xem ví dụ tại / pl platform_testing/tests/example/instrumentation/AndroidTest.xml .

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

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

Điều này báo cho Liên đoàn thương mại cài đặt HelloWorldTests.apk vào 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="android.test.example.helloworld"/>
  <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.

Để biết thêm thông tin, xem Kiểm tra mô-đun thử nghiệm .

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ó. Xem ví dụ tại / pl platform_testing/tests/example/instrumentation/src/android/test/example/helloworld/HelloWorldTest.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.

 @RunWith(JUnit4.class)
public class HelloWorldTest {
 

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.

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

Các @Before@After chú thích được sử dụng trên các phương pháp bởi Junit4 để thực hiện thiết lập thử nghiệm trước và sau thử nghiệm teardown. Tương tự, @BeforeClass@AfterClass chú thích đượ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 trước của JUnit, 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ệ.

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

Truy cập instrumentation

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

Bởi vì các bài 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 lấy phiên bản Instrumentation thông qua InstrumentationTestCase#getInstrumentation() , thay vào đó, trình chạy thử nghiệm mới quản lý nó 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ữ.

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

 Instrumentation instrumentation = InstrumentationRegistry.getInstrumentation()
 

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