AOSP bao gồm các mẫu kiểm thử cho các mô-đun kiểm thử không phải là lớp con Python phía máy chủ của BaseTest của trình chạy VTS.
Nhà phát triển có thể sử dụng các mẫu này để giảm thiểu nỗ lực cần thiết trong việc tích hợp các kiểm thử như vậy. Phần này trình bày cách định cấu hình và sử dụng các mẫu kiểm thử (nằm trong thư mục testcases/template của VTS) và cung cấp ví dụ về các mẫu thường dùng.
Mẫu BinaryTest
Sử dụng mẫu BinaryTest để tích hợp các chương trình kiểm thử thực thi trên thiết bị mục tiêu trong VTS. Các kiểm thử phía mục tiêu bao gồm:
- Các chương trình kiểm thử dựa trên C++ được biên dịch và đẩy đến thiết bị
- Các chương trình kiểm thử Python phía mục tiêu được biên dịch dưới dạng tệp nhị phân
- Tập lệnh shell có thể thực thi trên thiết bị
Bạn có thể tích hợp các chương trình kiểm thử này vào VTS có hoặc không có mẫu BinaryTest.
Tích hợp kiểm thử phía mục tiêu bằng mẫu BinaryTest
Mẫu BinaryTest được thiết kế để giúp nhà phát triển dễ dàng tích hợp các chương trình kiểm thử phía mục tiêu. Trong hầu hết các trường hợp, bạn có thể thêm một vài dòng cấu hình đơn giản trong AndroidTest.xml. Cấu hình mẫu từ
VtsDeviceTreeEarlyMountTest:
<configuration description="Config for VTS VtsDeviceTreeEarlyMountTest."> ... <test class="com.android.tradefed.testtype.VtsMultiDeviceTest"> <option name="test-module-name" value="VtsDeviceTreeEarlyMountTest"/> <option name="binary-test-source" value="_32bit::DATA/nativetest/dt_early_mount_test/dt_early_mount_test" /> <option name="binary-test-source" value="_64bit::DATA/nativetest64/dt_early_mount_test/dt_early_mount_test" /> <option name="test-timeout" value="5m"/> </test> </configuration>
Trong cấu hình này:
binary-test-sourcevàbinary-test-typelà dành riêng cho mẫu.- Việc chỉ định đường dẫn máy chủ lưu trữ tương đối của nguồn nhị phân kiểm thử cho phép mẫu xử lý việc chuẩn bị, đẩy tệp, thực thi kiểm thử, phân tích cú pháp kết quả và dọn dẹp.
- Mẫu này chứa các phương thức liên quan đến việc tạo trường hợp kiểm thử để các lớp con ghi đè.
- Mẫu này giả định một trường hợp kiểm thử cho mỗi mô-đun nhị phân kiểm thử và tên tệp nguồn nhị phân được dùng làm tên trường hợp kiểm thử theo mặc định.
Các lựa chọn về cấu hình
Mẫu BinaryTest hỗ trợ các tuỳ chọn cấu hình sau:
| Tên tuỳ chọn | Loại giá trị | Mô tả |
|---|---|---|
| binary-test-source | chuỗi | Đường dẫn nguồn kiểm thử nhị phân tương ứng với thư mục trường hợp kiểm thử vts trên máy chủ. Ví dụ: DATA/nativetest/test |
| binary-test-working-directory | chuỗi | Thư mục đang hoạt động (đường dẫn phía thiết bị). Ví dụ: /data/local/tmp/testing/ |
| binary-test-envp | chuỗi | Biến môi trường cho tệp nhị phân. Ví dụ: PATH=/new:$PATH |
| binary-test-args | chuỗi | Kiểm thử đối số hoặc cờ. Ví dụ: --gtest_filter=test1 |
| binary-test-ld-library-path | chuỗi | Biến môi trường LD_LIBRARY_PATH.Ví dụ: /data/local/tmp/lib |
| binary-test-disable-framework | boolean | Chạy adb stop để tắt Khung Android trước khi kiểm thử.
Ví dụ: true |
| binary-test-stop-native-servers | boolean | Dừng tất cả các máy chủ gốc được định cấu hình đúng cách trong quá trình kiểm thử. Ví dụ:
true |
| binary-test-type | string | Loại mẫu. Các loại mẫu khác mở rộng từ mẫu này, nhưng bạn không phải chỉ định tuỳ chọn này cho mẫu này vì bạn đã chỉ định binary-test-source. |
Đối với các tuỳ chọn có loại giá trị strings, bạn có thể thêm nhiều giá trị bằng cách lặp lại các tuỳ chọn trong cấu hình. Ví dụ: đặt binary-test-source hai lần (như trong ví dụ về VtsDeviceTreeEarlyMountTest).
Thẻ thử nghiệm
Bạn có thể thêm thẻ kiểm thử bằng cách thêm tiền tố vào các tuỳ chọn có giá trị strings và sử dụng :: làm dấu phân cách. Thẻ kiểm thử đặc biệt hữu ích khi đưa vào các nguồn nhị phân có cùng tên nhưng có số bit hoặc thư mục mẹ khác nhau. Ví dụ: để tránh xung đột tên kết quả hoặc đẩy tệp cho các nguồn có cùng tên nhưng từ các thư mục nguồn khác nhau, bạn có thể chỉ định các thẻ khác nhau cho các nguồn này.
Như trong ví dụ VtsDeviceTreeEarlyMountTest với hai nguồn dt_early_mount_test, các thẻ kiểm thử là tiền tố _32bit:: và _64bit:: trên binary-test-source. Các thẻ kết thúc bằng 32bit hoặc 64bit sẽ tự động đánh dấu các chương trình kiểm thử là có sẵn cho một bit ABI; tức là các chương trình kiểm thử có thẻ _32bit sẽ không được thực thi trên ABI 64 bit. Việc không chỉ định thẻ tương đương với việc sử dụng thẻ có chuỗi trống.
Các tuỳ chọn có cùng thẻ được nhóm lại và tách biệt với các thẻ khác. Ví dụ: binary-test-args có thẻ _32bit chỉ được áp dụng cho binary-test-source có cùng thẻ và được thực thi trong binary-test-working-directory có cùng thẻ. Tuỳ chọn binary-test-working-directory là không bắt buộc đối với kiểm thử nhị phân, cho phép bạn chỉ định một thư mục hoạt động duy nhất cho một thẻ. Khi tuỳ chọn binary-test-working-directory không được chỉ định, các thư mục mặc định sẽ được sử dụng cho mỗi thẻ.
Tên thẻ được thêm trực tiếp vào tên trường hợp kiểm thử trong báo cáo kết quả.
Ví dụ: trường hợp kiểm thử testcase1 có thẻ _32bit sẽ xuất hiện dưới dạng testcase1_32bit trong báo cáo kết quả.
Tích hợp các kiểm thử phía mục tiêu mà không cần mẫu BinaryTest
Trong VTS, định dạng kiểm thử mặc định là các kiểm thử Python phía máy chủ được mở rộng từ BaseTest trong trình chạy VTS. Để tích hợp các chương trình kiểm thử phía mục tiêu, trước tiên, bạn phải đẩy các tệp kiểm thử vào thiết bị, thực thi các chương trình kiểm thử bằng các lệnh shell, sau đó phân tích cú pháp kết quả bằng tập lệnh Python phía máy chủ.
Đẩy tệp nhị phân kiểm thử
Bạn nên đẩy tệp bằng trình chuẩn bị mục tiêu VtsFilePusher.
Ví dụ:
<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher">
<option name="push" value="DATA/test->/data/local/tmp/test"/>
</target_preparer>
VtsFilePusher thực hiện những việc sau:
- Kiểm tra khả năng kết nối của thiết bị.
- Xác định đường dẫn tệp nguồn tuyệt đối.
- Đẩy các tệp bằng lệnh
adb push. - Xoá các tệp sau khi kiểm thử hoàn tất.
Ngoài ra, bạn có thể đẩy tệp theo cách thủ công bằng cách sử dụng tập lệnh kiểm thử Python phía máy chủ tuân theo quy trình tương tự.
Chạy chương trình kiểm thử
Sau khi đẩy tệp vào thiết bị, hãy chạy kiểm thử bằng các lệnh shell trong tập lệnh kiểm thử Python phía máy chủ. Ví dụ:
device = self.android_devices[0] res = device.shell.Execute(["chmod a+x /data/local/tmp/test", "/data/local/tmp/test"]) asserts.AssertFalse(any(res[return_codes]))
Mẫu GtestBinaryTest
Mẫu GtestBinaryTest lưu trữ các tệp nhị phân kiểm thử GTest, mỗi tệp thường chứa nhiều trường hợp kiểm thử. Mẫu này mở rộng mẫu BinaryTest bằng cách ghi đè các phương thức thiết lập, tạo trường hợp kiểm thử và phân tích cú pháp kết quả, vì vậy, tất cả cấu hình BinaryTest đều được kế thừa.
GtestBinaryTest thêm tuỳ chọn gtest-batch-mode:
| Tên tuỳ chọn | Loại giá trị | Mô tả |
|---|---|---|
| binary-test-type | string | Loại mẫu. Sử dụng giá trị gtest. |
| gtest-batch-mode | boolean | Chạy tệp nhị phân Gtest ở chế độ hàng loạt. Ví dụ: true |
Nhìn chung, việc đặt gtest-batch-mode thành true sẽ tăng hiệu suất trong khi giảm nhẹ độ tin cậy. Trong các bài kiểm thử tuân thủ VTS, nhiều mô-đun sử dụng chế độ hàng loạt để cải thiện hiệu suất. Tuy nhiên, để đảm bảo độ tin cậy, nếu bạn không chỉ định chế độ, thì chế độ mặc định sẽ là không theo lô.
Chế độ không theo lô
Chế độ không theo lô thực hiện các lệnh gọi riêng lẻ đến tệp nhị phân GTest cho mỗi trường hợp kiểm thử. Ví dụ: nếu tệp nhị phân GTest chứa 10 trường hợp kiểm thử (sau khi lọc theo cấu hình bên máy chủ), thì tệp nhị phân này sẽ được gọi 10 lần trên màn hình thiết bị, mỗi lần với một bộ lọc kiểm thử khác nhau. Đối với mỗi trường hợp kiểm thử, mẫu sẽ tạo và phân tích cú pháp một tệp XML đầu ra kết quả GTest duy nhất.
Sau đây là một số ưu điểm của việc sử dụng chế độ không theo lô:
- Tính năng tách biệt trường hợp kiểm thử. Sự cố hoặc tình trạng treo trong một trường hợp kiểm thử không ảnh hưởng đến các trường hợp kiểm thử khác.
- Độ chi tiết. Dễ dàng hơn trong việc đo lường phân tích tài nguyên/mức độ sử dụng cho mỗi trường hợp kiểm thử, systrace, bugreport, logcat, v.v. Kết quả kiểm thử và nhật ký được truy xuất ngay sau khi mỗi trường hợp kiểm thử kết thúc.
Sau đây là các nhược điểm của việc sử dụng chế độ không theo lô:
- Tải thừa. Mỗi khi tệp nhị phân GTest được gọi, tệp này sẽ tải các thư viện liên quan và thực hiện các thiết lập lớp ban đầu.
- Mức hao tổn khi giao tiếp. Sau khi kiểm thử hoàn tất, máy chủ và thiết bị mục tiêu sẽ giao tiếp để phân tích cú pháp kết quả và các lệnh tiếp theo (có thể tối ưu hoá trong tương lai).
Chế độ hàng loạt
Ở chế độ hàng loạt GTest, tệp nhị phân kiểm thử chỉ được gọi một lần với giá trị bộ lọc kiểm thử dài chứa tất cả các trường hợp kiểm thử được lọc theo cấu hình phía máy chủ (điều này giúp tránh vấn đề tải dư thừa ở chế độ không phải hàng loạt). Bạn có thể phân tích cú pháp kết quả kiểm thử cho GTest bằng output.xml hoặc bằng kết quả đầu ra của dòng lệnh.
Khi sử dụng output.xml (mặc định):
Giống như ở chế độ không theo lô, kết quả kiểm thử được phân tích cú pháp thông qua tệp xml đầu ra của GTest. Tuy nhiên, vì tệp xml đầu ra được tạo sau khi tất cả các chương trình kiểm thử hoàn tất, nên nếu một trường hợp kiểm thử gặp sự cố với tệp nhị phân hoặc thiết bị, thì tệp xml kết quả sẽ không được tạo.
Khi sử dụng đầu ra của dòng lệnh:
Trong khi chạy, GTest sẽ in nhật ký kiểm thử và tiến trình vào thiết bị đầu cuối ở định dạng mà khung có thể phân tích cú pháp cho trạng thái kiểm thử, kết quả và nhật ký.
Sau đây là các ưu điểm của việc sử dụng chế độ hàng loạt:
- Tính năng tách biệt trường hợp kiểm thử. Cung cấp cùng cấp độ tách biệt trường hợp kiểm thử như chế độ không theo lô nếu khung khởi động lại tệp nhị phân/thiết bị sau khi xảy ra sự cố với bộ lọc kiểm thử giảm (ngoại trừ các trường hợp kiểm thử đã hoàn tất và gặp sự cố).
- Độ chi tiết. Cung cấp cùng độ chi tiết của trường hợp kiểm thử như chế độ không theo lô.
Sau đây là một số nhược điểm của việc sử dụng chế độ hàng loạt:
- Chi phí bảo trì. Nếu định dạng ghi nhật ký GTest thay đổi, tất cả các chương trình kiểm thử sẽ bị lỗi.
- Sự bối rối. Một trường hợp kiểm thử có thể in nội dung tương tự như định dạng tiến trình GTest, điều này có thể gây nhầm lẫn cho định dạng.
Do những hạn chế này, chúng tôi đã tạm thời xoá tuỳ chọn sử dụng đầu ra dòng lệnh. Chúng tôi sẽ xem xét lại tuỳ chọn này trong tương lai để cải thiện độ tin cậy của hàm này.
Mẫu HostBinaryTest
Mẫu HostBinaryTest bao gồm các tệp thực thi phía máy chủ không tồn tại trong các thư mục khác hoặc trong tập lệnh Python. Các kiểm thử này bao gồm:
- Tệp nhị phân kiểm thử được biên dịch có thể thực thi trên máy chủ lưu trữ
- Tập lệnh có thể thực thi trong shell, Python hoặc các ngôn ngữ khác
Ví dụ: Kiểm thử phía máy chủ về chính sách bảo mật SELinux của VTS:
<configuration description="Config for VTS Security SELinux policy host-side test cases">
...
<test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
<option name="test-module-name" value="VtsSecuritySelinuxPolicyHost"/>
<option name="binary-test-source" value="out/host/linux-x86/bin/VtsSecuritySelinuxPolicyHostTest" />
<option name="binary-test-type" value="host_binary_test"/>
</test>
</configuration>
HostBinaryTest không mở rộng mẫu BinaryTest nhưng sử dụng các cấu hình kiểm thử tương tự. Trong ví dụ trên, tuỳ chọn binary-test-source chỉ định đường dẫn tương đối phía máy chủ đến tệp thực thi kiểm thử và binary-test-type là host_binary_test. Tương tự như mẫu BinaryTest, tên tệp nhị phân được dùng làm tên trường hợp kiểm thử theo mặc định.
Mở rộng các mẫu hiện có
Bạn có thể sử dụng các mẫu ngay trong cấu hình kiểm thử để đưa vào các kiểm thử không phải Python hoặc mở rộng các kiểm thử đó trong một lớp con để xử lý các yêu cầu kiểm thử cụ thể. Các mẫu trong kho lưu trữ VTS có các đuôi sau:
Nhà phát triển nên mở rộng mọi mẫu hiện có cho mọi yêu cầu kiểm thử cụ thể. Sau đây là một số lý do phổ biến khiến bạn nên mở rộng mẫu:
- Quy trình thiết lập kiểm thử đặc biệt, chẳng hạn như chuẩn bị thiết bị bằng các lệnh đặc biệt.
- Tạo nhiều trường hợp kiểm thử và tên kiểm thử.
- Phân tích cú pháp kết quả bằng cách đọc đầu ra lệnh hoặc sử dụng các điều kiện khác.
Để dễ dàng mở rộng các mẫu hiện có, các mẫu này chứa các phương thức chuyên biệt cho từng chức năng. Nếu đã cải thiện thiết kế cho các mẫu hiện có, bạn nên đóng góp vào cơ sở mã VTS.