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 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ử.
Mượn từ CTS, chúng tôi đã giới thiệu khái niệm cấu hình mô-đun kiểm thử để hỗ trợ các tác vụ như vậy, danh sách tác vụ phổ biến ở trên có thể được thực hiện chỉ bằng vài dòng cấu hình. Để 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à tệp XML bắt buộc, được thêm vào đầu thư mục nguồn mô-đun cấp, có tên là ‘AndroidTest.xml’. XML tuân theo định dạng của tệp cấu hình được sử dụng bởi việc khai thác tự động hoá thử nghiệm của Liên đoàn Thương mại. 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ẻ.
Trình 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 chung tích hợp sẵn, hãy thêm tệp mới "AndroidTest.xml" vào thư mục cấp cao nhất cho mô-đun kiểm thử 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ẻ tuỳ chọn sau (ở 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 này sẽ định cấu hình bộ kiểm thử để:
- trước khi gọi mô-đun kiểm thử, 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, tính năng hỗ trợ tiếp cận được bật/tắt trước/sau lượt thực thi mô-đun kiểm thử tương ứng. Qua một ví dụ đơn giản, để cung cấp thêm chi tiết về cách sử dụng thẻ "tùy chọn". 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 tuỳ chọn do người chuẩn bị đưa ra.
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à thông tin tóm tắt về 3 trình chuẩn bị mục tiêu phổ biến:
tên lớp: PushFilePreparer
- tên ngắn: tệp đẩy
- hàm: đẩ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ị
- notes:
- 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) 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: Lệnh để chạy trên thiết bị (bằng "
adb shell <your command>") sau khi tất cả các lệnh đẩy đã được thử. Trường hợp sử dụng phổ biến là sử dụng chmod cho các 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 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 cài đặt pm, 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 kiểm thử thực thi mô-đun
- 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>
Sau đây là ba 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 chương trình kiểm thử gốc.
tên lớp: InstrumentationTest
- tên ngắn: đo lường
- hàm: Một kiểm thử chạy gói kiểm thử đo lường trên một thiết bị nhất định
- tuỳ chọn:
- 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.