AOSP bao gồm các mẫu thử nghiệm cho các mô-đun thử nghiệm không phải là lớp con Python phía máy chủ của BaseTest của VTS.
Nhà phát triển có thể sử dụng các mẫu này để giảm thiểu công sức trong việc tích hợp các thử nghiệm đó. Phần này bao gồm việc định cấu hình và sử dụng các mẫu thử nghiệm (nằm trong thư mục mẫu/trường hợp thử nghiệm VTS) và cung cấp các ví dụ về các mẫu thường được sử dụng.
Mẫu thử nghiệm nhị phân
Sử dụng mẫu BinaryTest để tích hợp các thử nghiệm thực hiện trên thiết bị đích trong VTS. Các thử nghiệm phía mục tiêu bao gồm:
- Các bài kiểm tra dựa trên C++ được biên dịch và đẩy vào thiết bị
- Các bài kiểm tra Python phía mục tiêu được biên dịch dưới dạng nhị phân
- Tập lệnh Shell có thể thực thi được trên thiết bị
Các thử nghiệm này có thể được tích hợp vào VTS có hoặc không có mẫu BinaryTest.
Tích hợp các thử nghiệm phía mục tiêu với mẫu BinaryTest
Mẫu BinaryTest được thiết kế để giúp các nhà phát triển dễ dàng tích hợp các thử nghiệm 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 ví dụ 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ủ tương đối của nguồn nhị phân kiểm tra sẽ cho phép mẫu xử lý việc chuẩn bị, đẩy tệp, thực hiện kiểm tra, phân tích kết quả và dọn dẹp.
- Mẫu chứa các phương thức liên quan đến việc tạo trường hợp thử nghiệm để các lớp con ghi đè.
- Mẫu 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 sử dụng làm tên trường hợp kiểm thử theo mặc định.
Tùy chọn cấu hình
Mẫu BinaryTest hỗ trợ các tùy chọn cấu hình sau:
| Tên tùy chọn | Loại giá trị | Sự miêu tả |
|---|---|---|
| nguồn kiểm tra nhị phân | dây | Đường dẫn nguồn kiểm tra nhị phân liên quan đến thư mục trường hợp thử nghiệm vts trên máy chủ. Ví dụ: DATA/nativetest/test |
| thư mục làm việc kiểm tra nhị phân | dây | Thư mục làm việc (đường dẫn phía thiết bị). Ví dụ: /data/local/tmp/testing/ |
| kiểm tra nhị phân-envp | dây | Biến môi trường cho nhị phân. Ví dụ: PATH=/new:$PATH |
| kiểm tra nhị phân-args | dây | Kiểm tra đối số hoặc cờ. Ví dụ: --gtest_filter=test1 |
| đường dẫn nhị phân-kiểm tra-ld-thư viện | dây | Biến môi trường LD_LIBRARY_PATH .Ví dụ: /data/local/tmp/lib |
| khung kiểm tra nhị phân-vô hiệu hóa | boolean | Chạy adb stop để tắt Android Framework trước khi kiểm tra. Ví dụ: true |
| kiểm tra nhị phân-dừng-bản địa-máy chủ | boolean | Dừng tất cả các máy chủ gốc được cấu hình đúng cách trong quá trình thử nghiệm. Ví dụ: true |
| loại thử nghiệm nhị phân | sợi dây | 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 tùy chọn này cho mẫu này vì bạn đã chỉ định binary-test-source . |
Đối với các tùy chọn có strings loại giá trị, bạn có thể thêm nhiều giá trị bằng cách lặp lại các tùy chọn trong cấu hình. Ví dụ: đặt binary-test-source hai lần (như được hiển thị trong ví dụ VtsDeviceTreeEarlyMountTest ).
Thẻ thử nghiệm
Bạn có thể thêm thẻ kiểm tra bằng cách thêm tiền tố vào các tùy chọn có giá trị strings và sử dụng :: làm dấu phân cách. Thẻ kiểm tra đặc biệt hữu ích khi bao gồm các nguồn nhị phân có cùng tên nhưng có bitness hoặc thư mục gốc khác nhau. Ví dụ: để tránh đẩy tệp hoặc xung đột tên kết quả 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ư được hiển thị trong ví dụ VtsDeviceTreeEarlyMountTest với hai nguồn dt_early_mount_test , các thẻ kiểm tra là _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 bài kiểm tra là có sẵn cho một bit ABI; tức là các thử nghiệm với thẻ _32bit không được thực thi trên ABI 64 bit. Không chỉ định thẻ tương đương với việc sử dụng thẻ có chuỗi trống.
Các tùy chọn có cùng thẻ sẽ được nhóm và tách biệt khỏi các thẻ khác. Ví dụ: binary-test-args với 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 với cùng một thẻ. Tùy chọn binary-test-working-directory là tùy chọn cho các thử nghiệm nhị phân, cho phép bạn chỉ định một thư mục làm việc duy nhất cho một thẻ. Khi tùy 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 gắn trực tiếp vào tên trường hợp thử nghiệm trong báo cáo kết quả. Ví dụ: trường hợp kiểm thử testcase1 có thẻ _32bit xuất hiện dưới dạng testcase1_32bit trong báo cáo kết quả.
Tích hợp các thử nghiệm phía mục tiêu mà không cần mẫu BinaryTest
Trong VTS, định dạng kiểm tra mặc định là các bài kiểm tra Python phía máy chủ được mở rộng từ BaseTest trong trình chạy VTS. Để tích hợp các thử nghiệm phía mục tiêu, trước tiên bạn phải đẩy các tệp thử nghiệm vào thiết bị, thực hiện thử nghiệm bằng lệnh shell, sau đó phân tích kết quả bằng cách sử dụng tập lệnh Python phía máy chủ.
Tệp nhị phân thử nghiệm đẩy
Chúng tôi khuyên bạn nên đẩy các tệp bằng cách sử dụ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ư sau:
- Kiểm tra kết nối thiết bị.
- Xác định đường dẫn tệp nguồn tuyệt đối.
- Đẩy các tập tin bằng lệnh
adb push. - Xóa các tập tin sau khi kiểm tra 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 tra Python phía máy chủ tuân theo quy trình tương tự.
Chạy thử nghiệm
Sau khi đẩy tệp vào thiết bị, hãy chạy thử nghiệm bằng lệnh shell trong tập lệnh thử nghiệm 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 thử nghiệm GTest, mỗi tệp thường chứa nhiều trường hợp thử nghiệm. Mẫu này mở rộng mẫu BinaryTest bằng cách ghi đè thiết lập, tạo trường hợp thử nghiệm và phương pháp phân tích kết quả, do đó tất cả cấu hình BinaryTest đều được kế thừa.
GtestBinaryTest thêm tùy chọn gtest-batch-mode :
| Tên tùy chọn | Loại giá trị | Sự miêu tả |
|---|---|---|
| loại thử nghiệm nhị phân | sợi dây | Loại mẫu. Sử dụng giá trị gtest . |
| chế độ gtest-batch | boolean | Chạy các tệp nhị phân Gtest ở chế độ hàng loạt. Ví dụ: true |
Nói chung, việc đặt gtest-batch-mode thành true sẽ tăng hiệu suất trong khi giảm độ tin cậy một chút. Trong các thử nghiệm 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 chế độ không được chỉ định thì chế độ này sẽ mặc định là không theo đợt.
Chế độ không theo đợt
Chế độ không theo đợt thực hiện các lệnh gọi riêng lẻ tới mã nhị phân GTest cho từng trường hợp thử nghiệm. Ví dụ: nếu tệp nhị phân GTest chứa 10 trường hợp thử nghiệm (sau khi lọc theo cấu hình phía máy chủ), thì tệp nhị phân được gọi 10 lần trên vỏ thiết bị mỗi lần với một bộ lọc thử nghiệm khác. Đối với mỗi trường hợp thử nghiệm, một XML đầu ra kết quả GTest duy nhất được tạo và phân tích cú pháp theo mẫu.
Ưu điểm của việc sử dụng chế độ không theo đợt bao gồm:
- Cách ly trường hợp thử nghiệm . Sự cố hoặc treo trong một trường hợp thử nghiệm không ảnh hưởng đến các trường hợp thử nghiệm khác.
- Độ chi tiết . Dễ dàng hơn để có được phép đo hồ sơ/phạm vi bảo hiểm, systrace, bugreport, logcat, v.v. Kết quả và nhật ký kiểm tra được truy xuất ngay sau khi mỗi trường hợp kiểm thử kết thúc.
Những nhược điểm của việc sử dụng chế độ không theo đợt bao gồm:
- Tải dư thừa . Mỗi lần nhị phân GTest được gọi, nó 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.
- Chi phí truyền thông . Sau khi quá trình kiểm tra hoàn tất, máy chủ và thiết bị đích sẽ giao tiếp để phân tích kết quả và đưa ra các lệnh tiếp theo (có thể tối ưu hóa trong tương lai).
Chế độ hàng loạt
Trong chế độ hàng loạt GTest, tệp nhị phân thử nghiệm chỉ được gọi một lần với giá trị bộ lọc thử nghiệm dài chứa tất cả các trường hợp thử nghiệm được lọc theo cấu hình phía máy chủ (điều này tránh được vấn đề tải dư thừa ở chế độ không theo đợt). Bạn có thể phân tích kết quả kiểm tra cho GTest bằng cách sử dụng tệp out.xml hoặc sử dụng đầu ra của thiết bị đầu cuối.
Khi sử dụng out.xml (mặc định):
Như ở chế độ không theo đợt, kết quả kiểm tra được phân tích cú pháp thông qua tệp xml đầu ra GTest. Tuy nhiên, do xml đầu ra được tạo sau khi tất cả các thử nghiệm được hoàn thành, nếu một trường hợp thử nghiệm bị lỗi thì tệp xml hoặc thiết bị không có kết quả nào được tạo.
Khi sử dụng đầu ra đầu cuối:
Trong khi GTest đang chạy, nó sẽ in nhật ký kiểm tra và tiến tới thiết bị đầu cuối ở định dạng có thể được phân tích cú pháp theo khung để biết trạng thái, kết quả và nhật ký kiểm tra.
Ưu điểm của việc sử dụng chế độ hàng loạt bao gồm:
- Cách ly trường hợp thử nghiệm . Cung cấp mức cách ly trường hợp kiểm thử tương tự như chế độ không theo lô nếu khung khởi động lại tệp nhị phân/thiết bị sau sự cố với bộ lọc kiểm thử bị giảm (không bao gồm các trường hợp kiểm thử đã hoàn thành và bị hỏng).
- Độ chi tiết . Cung cấp mức độ chi tiết của trường hợp thử nghiệm tương tự như chế độ không theo đợt.
Những nhược điểm của việc sử dụng chế độ hàng loạt bao gồm:
- Chi phí bảo trì . Nếu định dạng ghi nhật ký GTest thay đổi, tất cả các bài kiểm tra sẽ bị hỏng.
- Lú lẫn . Một trường hợp thử nghiệm có thể in nội dung nào đó 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.
Vì những nhược điểm này nên chúng tôi đã tạm thời loại bỏ tùy chọn sử dụng đầu ra dòng lệnh. Chúng tôi sẽ xem lại tùy chọn này trong tương lai để cải thiện độ tin cậy của chức năng 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. Những thử nghiệm này bao gồm:
- Các tệp nhị phân thử nghiệm được biên dịch có thể thực thi được trên máy chủ
- Các tập lệnh có thể thực thi được bằng shell, Python hoặc các ngôn ngữ khác
Một ví dụ là thử nghiệm phía máy chủ chính sách VTS Security SELinux :
<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 tra tương tự. Trong ví dụ trên, tùy 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 tra và binary-test-type là host_binary_test . Tương tự như mẫu BinaryTest, tên tệp nhị phân được sử dụng làm tên trường hợp thử nghiệm 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 trực tiếp trong cấu hình thử nghiệm để bao gồm các thử nghiệm không phải Python hoặc mở rộng chúng trong một lớp con để xử lý các yêu cầu thử nghiệm cụ thể. Các mẫu trong kho VTS có các phần mở rộng sau:
Các nhà phát triển được khuyến khích mở rộng mọi mẫu hiện có cho bất kỳ yêu cầu thử nghiệm cụ thể nào. Các lý do phổ biến để mở rộng mẫu bao gồm:
- Quy trình thiết lập thử nghiệm đặc biệt, chẳng hạn như chuẩn bị một thiết bị với các lệnh đặc biệt.
- Tạo các trường hợp thử nghiệm và tên thử nghiệm khác nhau.
- Phân tích 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.
Để giúp mở rộng các mẫu hiện có dễ dàng hơn, các mẫu chứa các phương thức chuyên biệt cho từng chức năng. Nếu bạn đã cải tiến thiết kế cho các mẫu hiện có, chúng tôi khuyến khích bạn đóng góp cho cơ sở mã VTS.