Một số mô-đun kiểm thử có thể yêu cầu các bước thiết lập và gỡ 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 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 sự 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 kiểm thử là thẻ "target_preparer" và "test".
Trình chuẩn bị mục tiêu
Như tên gọi, thẻ "target_preparer" xác định trình chuẩn bị mục tiêu (xem ITargetPreparer) cung cấp 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, thì phương thức gỡ bỏ của lớp đó 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 mô-đun kiểm thử được gọi, hãy thực thi lệnh shell “settings put safety_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 tương ứng trước/sau khi thực thi mô-đun kiểm thử. Qua một ví dụ đơn giản được minh hoạ, bạn cần cung cấp thêm thông tin chi tiết về cách sử dụng thẻ "tuỳ 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 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à 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: push-file
- function: đẩy các tệp tuỳ ý trong thư mục trường hợp kiểm thử vào đích 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 đó
- options:
- tệp đẩy: Thông số đẩy, chỉ định tệp cục bộ đến đường dẫn mà tệp đó sẽ được đẩy trên thiết bị. Có thể lặp lại. Nếu nhiều tệp được định cấu hình để đẩ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 thông số kỹ thuật đẩ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 chính thư mục out. - 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 điển hình sẽ là sử 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ị
- options:
- 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 cần 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ử
- 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 (hàm): Một chương trình kiểm thử chạy một gói kiểm thử gốc trên một 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: khả năng đ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
- 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
- hàm: Một chương trình 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 bằng cách sử dụng android.support.test.runner.AndroidJUnitRunner. Đây là cách chính để thực thi kiểm thử đo lường.