Một số mô-đun kiểm thử có thể yêu cầu các bước thiết lập và huỷ bỏ tuỳ chỉnh mà không thể thực hiện trong chính trường hợp kiểm thử. Các ví dụ điển hình có thể bao gồm:
- cài đặt các tệp APK khác (ngoài tệp APK kiểm thử)
- đẩy một số tệp vào thiết bị
- chạy các lệnh (ví dụ: adb shell pm ...)
Trước đây, các nhóm thành phần thường phải viết một kiểm thử phía máy chủ lưu trữ để thực hiện những tác vụ như vậy. Việc này đòi hỏi phải hiểu rõ về bộ kiểm thử Trade Federation và thường làm tăng độ phức tạp của một mô-đun kiểm thử.
Dựa trên CTS, chúng tôi đã giới thiệu khái niệm về cấu hình mô-đun kiểm thử để hỗ trợ các tác vụ như vậy. Bạn có thể thực hiện danh sách các tác vụ thường gặp ở trên chỉ bằng một vài dòng cấu hình. Để có tính linh hoạt tối đa, bạn thậm chí có thể triển khai trình chuẩn bị mục tiêu của riêng mình, như được xác định bởi ITargetPreparer hoặc ITargetCleaner và định cấu hình chúng để sử dụng trong cấu hình mô-đun kiểm thử của riêng bạn.
Cấu hình mô-đun kiểm thử cho một mô-đun kiểm thử là một tệp XML bắt buộc được thêm vào thư mục nguồn mô-đun cấp cao nhất, có tên là "AndroidTest.xml". XML tuân theo định dạng của một tệp cấu hình do bộ kiểm thử tự động Trade Federation sử dụng. Hiện tại, các thẻ chính được xử lý thông qua cấu hình mô-đun kiểm thử là thẻ "target_preparer" và "test".
Người chuẩn bị mục tiêu
Thẻ "target_preparer", như tên gọi cho thấy, xác định một trình chuẩn bị mục tiêu (xem ITargetPreparer) cung cấp một phương thức thiết lập, được gọi trước khi mô-đun kiểm thử được thực thi để kiểm thử; và nếu lớp được tham chiếu trong thẻ "target_preparer" cũng triển khai ITargetCleaner, phương thức huỷ của lớp đó sẽ được gọi sau khi mô-đun kiểm thử hoàn tất.
Để sử dụng cấu hình mô-đun chung tích hợp, hãy thêm một tệp mới "AndroidTest.xml" vào thư mục cấp cao nhất cho mô-đun kiểm thử của bạn và điền nội dung sau vào tệp đó:
<?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>
Ví dụ: chúng ta có thể thêm các thẻ lựa chọn sau (tại phần nhận xét "insert" ở trên):
<target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
<option name="run-command" value="settings put secure accessibility_enabled 1" />
<option name="teardown-command" value="settings put secure accessibility_enabled 0" />
</target_preparer>
Các lựa chọn này sẽ định cấu hình bộ kiểm thử để:
- trước khi mô-đun kiểm thử được gọi, hãy thực thi lệnh shell "settings put secure accessibility_enabled 1" trên thiết bị
- sau khi hoàn tất mô-đun kiểm thử, hãy thực thi lệnh shell "settings put secure accessibility_enabled 0"
Trong ví dụ cụ thể này, chế độ hỗ trợ tiếp cận được bật/tắt tương ứng trước/sau khi thực thi mô-đun kiểm thử. Với ví dụ đơn giản được minh hoạ, bạn cần tìm hiểu thêm thông tin chi tiết về cách sử dụng thẻ "option". Như minh hoạ ở trên, thẻ này có thể có 2 thuộc tính: tên, giá trị. Thuộc tính tên phải đề cập đến một trong các lựa chọn do người chuẩn bị cung cấp.
Mục đích chính xác của trường giá trị phụ thuộc vào cách người chuẩn bị xác định lựa chọn: đó có thể là một chuỗi, một số, một boolean hoặc thậm chí là một đường dẫn tệp. Sau đây là thông tin tóm tắt về 3 đối tượng chuẩn bị mục tiêu phổ biến:
tên lớp: PushFilePreparer
- tên ngắn: push-file
- function: đẩy các tệp tuỳ ý trong thư mục trường hợp kiểm thử vào đích đến trên thiết bị
- ghi chú:
- trình chuẩn bị này có thể đẩy từ thư mục sang thư mục hoặc từ tệp sang tệp; tức là bạn không thể đẩy một tệp trong một thư mục trên thiết bị: bạn cũng phải chỉ định tên tệp đích trong thư mục đó
- options:
- push-file: Một push-spec, chỉ định tệp cục bộ cho đường dẫn mà tệp đó sẽ được đẩy trên thiết bị. Có thể lặp lại. Nếu bạn định cấu hình nhiều tệp để được đẩy đến cùng một đường dẫn từ xa, thì tệp mới nhất sẽ được đẩy.
- push: (không dùng nữa) Một push-spec, được định dạng là "
/path/to/srcfile.txt->/path/to/destfile.txt" hoặc "/path/to/srcfile.txt->/path/to/destdir/". Có thể lặp lại. Đường dẫn này có thể tương ứng với thư mục mô-đun kiểm thử hoặc chính thư mục đầu ra. - post-push: Lệnh chạy trên thiết bị (có `
adb shell <your command>`) sau khi tất cả các lệnh đẩy đã được thử. Trường hợp sử dụng điển hình là sử dụng chmod cho các quyền
tên lớp: InstallApkSetup
- tên ngắn:install-apk
- function: pushes arbitrary apk files under into destination on device
- options:
- test-file-name: tên của apk sẽ được cài đặt trên thiết bị.
- install-arg: Các đối số bổ sung sẽ được truyền đến lệnh pm install, bao gồm cả dấu gạch ngang ở đầu, ví dụ: "-d". Có thể lặp lại
tên lớp: RunCommandTargetPreparer
- tên ngắn: run-command
- function: thực thi các lệnh shell tuỳ ý trước hoặc sau khi thực thi mô-đun kiểm thử
- options:
- run-command:lệnh adb shell để chạy. Có thể lặp lại
- teardown-command:lệnh adb shell để chạy trong giai đoạn tháo dỡ. Có thể lặp lại
Lớp kiểm thử
Lớp kiểm thử là lớp Trade Federation dùng để 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>
Sau đây là 3 lớp kiểm thử phổ biến:
tên lớp: GTest
- tên ngắn: gtest
- function: Một Kiểm thử chạy gói kiểm thử gốc trên thiết bị đã cho.
- options:
- native-test-device-path: Đường dẫn trên thiết bị nơi các kiểm thử gốc được đặt.
tên lớp: InstrumentationTest
- tên ngắn: đo lường
- function: Một Kiểm thử chạy gói kiểm thử đo lường trên thiết bị đã cho
- options:
- package:Tên gói tệp kê khai của ứng dụng kiểm thử Android cần chạy.
- class:Tên lớp kiểm thử cần chạy.
- method:Tên phương thức kiểm thử cần chạy.
tên lớp: AndroidJUnitTest
- function: Một Kiểm thử chạy gói kiểm thử đo lường trên thiết bị đã cho bằng android.support.test.runner.AndroidJUnitRunner. Đây là cách chính để thực thi một kiểm thử đo lường.