Một số mô-đun kiểm thử có thể yêu cầu chế độ thiết lập tuỳ chỉnh và chia nhỏ các bước 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ã kiểm thử phía máy chủ để thực hiện các tác vụ như vậy. Điều này đòi hỏi phải hiểu rõ về bộ điều khiển Trade Federation và thường làm tăng độ phức tạp của mô-đun kiểm thử.
Bằng việc vay mượn CTS, chúng tôi đã đưa ra khái niệm cấu hình mô-đun kiểm thử để hỗ trợ tác vụ như vậy, danh sách tác vụ phổ biến ở trên có thể đạt được chỉ bằng một vài dòng config. Để có được độ 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, đồng thời định cấu hình các trình chuẩn bị đó để 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ô-đ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". Tệp XML tuân theo định dạng của tệp cấu hình mà bộ tự động hoá kiểm thử của 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 thử nghiệm là “target_preparer” và "kiểm thử" các thẻ.
Người chuẩn bị mục tiêu
Thẻ “target_preparer”, như tên gọi, xác định trình chuẩn bị mục tiêu (xem ITarget Preparer) cung cấp phương thức thiết lập, phương thức này được gọi trước khi thực thi mô-đun kiểm thử để thử nghiệm; và nếu lớp được tham chiếu trong thẻ “target_preparer” cũng triển khai ITargetCleaner, phương thức chia nhỏ sẽ được gọi sau khi mô-đun kiểm thử kết thúc.
Để sử dụng cấu hình mô-đun phổ biến tích hợp sẵn, hãy thêm tệp mới "AndroidTest.xml" tại thư mục cấp cao nhất cho mô-đun kiểm thử của bạn và điền thông tin sau vào thư mục đó nội dung:
<?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ẻ tuỳ chọn sau (ở phần nhận xét "chèn" ở 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 tuỳ chọn sẽ định cấu hình khai thác kiểm thử để:
- trước khi mô-đun kiểm thử được gọi, thực thi lệnh shell "settings putCài đặt bảo mật" hỗ trợ tiếp cận 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, tính năng 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 một ví dụ đơn giản được minh hoạ, bạn cần phải trình bày thêm thông tin chi tiết về cách sử dụng thẻ "option". Như đã trình bày ở trên, thẻ có thể có hai thuộc tính: tên, giá trị. Thuộc tính tên phải tham chiếu đế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 value phụ thuộc vào cách trình chuẩn bị xác định tuỳ chọn: trường này 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. Dưới đây là phần tóm tắt về 3 yếu tố chuẩn bị mục tiêu phổ biến:
tên lớp: PushFilePreparer
- tên ngắn: tệp đẩy
- function: đẩy các tệp tuỳ ý trong thư mục trường hợp kiểm thử vào điểm đến trên thiết bị
- lưu ý:
- trình chuẩn bị này có thể đẩy từ thư mục này sang thư mục khác hoặc tệp này sang tệp khác; nghĩa là bạn không thể đẩy một tệp trong 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 đó
- tuỳ chọn:
- push-file:Thông số đẩy, chỉ định tệp cục bộ cho đường dẫn vị trí bạn nên đẩy trên thiết bị. Có thể lặp lại. Nếu có nhiều tệp được định cấu hình để đẩy đến cùng một đường dẫn từ xa, mã mới nhất sẽ được đẩy.
- push: (không dùng nữa) Một thông số đẩy, 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 bên ngoài chính thư mục đó. - post-push: Một lệnh để chạy trên thiết bị (với `
adb shell <your command>`) sau khi đã thử tất cả các lần đẩy. Cách sử dụng thông thường trong trường hợp là dùng chmod để cấp quyền
tên lớp: InstallApkSetup
- tên ngắn:install-apk
- hàm: đẩy các tệp APK tuỳ ý vào đích đến trên thiết bị
- tuỳ chọn:
- test-file-name: tên của tệp APK cần cài đặt vào thiết bị.
- install-arg: Các đối số bổ sung cần được truyền đến pm install gồm cả dấu gạch ngang ở đầu, ví dụ: “-d”. Có thể lặp lại
tên lớp: RunCommandTargetPreparer
- short name: 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ử
- tuỳ chọn:
- run-command: lệnh shell adb để chạy. Có thể lặp lại
- teardown-command:lệnh adb shell để chạy trong giai đoạn chia nhỏ. Có thể lặp lại
Lớp kiểm thử
Lớp kiểm thử là lớp Liên kết thương mại sử 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>
Dưới đây là 3 lớp kiểm thử phổ biến:
tên lớp: GTest
- tên ngắn: gtest
- function: Kiểm thử chạy gói kiểm thử gốc trên thiết bị nhất định.
- options:
- native-test-device-path: Đường dẫn trên thiết bị chứa các quy trình kiểm thử gốc.
tên lớp: InstrumentationTest
- tên ngắn: đo lường
- function: Bài kiểm thử chạy một gói kiểm thử đo lường trên một thiết bị nhất định
- options:
- package: Tên gói tệp kê khai của ứng dụng kiểm thử Android sẽ 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: Kiểm thử chạy một gói kiểm thử đo lường trên bằng cách sử dụng android.support.test.runner.AndroidJUnitRunner Đây là cách chính để thực thi một bài kiểm thử đo lường.