Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

Trang này được dịch bởi Cloud Translation API.

Mẫu thử nghiệm

AOSP bao gồm các mẫu kiểm thử cho các mô-đun kiểm thử không phải là Python phía máy chủ lớp con của BaseTest của VTS Runner.

Hình 1. Kiểm thử cấu trúc mẫu.

Nhà phát triển có thể dùng những mẫu này để giảm thiểu công sức tích hợp các thử nghiệm như vậy. Phần này đề cập đến cách định cấu hình và sử dụng mẫu (nằm trong VTS trường hợp kiểm thử/mẫu thư mục) và cung cấp ví dụ cho các mẫu thường được sử dụng.

Mẫu BinaryTest

Sử dụng BinaryTest mẫu để 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 bài 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 lên thiết bị
Các bài 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 các thiết bị

Bạn có thể tích hợp các bài kiểm thử này vào VTS có hoặc không có BinaryTest mẫu.

Tích hợp kiểm thử phía đích với Mẫu BinaryTest

Mẫu BinaryTest được thiết kế để giúp nhà phát triển dễ dàng tích hợp 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 đơn giản trong AndroidTest.xml. Cấu hình mẫu của 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-source và binary-test-type là theo mẫu cụ thể.
Việc chỉ định đường dẫn máy chủ tương đối của nguồn nhị phân kiểm thử sẽ bật mẫu để xử lý công tá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ệp nhị phân theo mặc định, tên tệp nguồn được dùng làm tên trường hợp kiểm thử.

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 của lựa chọn	Loại giá trị	Mô tả
nguồn kiểm thử nhị phân	chuỗi	Đường dẫn nguồn kiểm thử nhị phân liên quan đến thư mục trường hợp kiểm thử vts trên máy chủ lưu trữ. Ví dụ: `DATA/nativetest/test`
thư mục làm việc nhị phân	chuỗi	Thư mục đang làm việc (đường dẫn phía thiết bị). Ví dụ: `/data/local/tmp/testing/`
nhị phân-kiểm thử-envp	chuỗi	Các biến môi trường cho tệp nhị phân. Ví dụ: `PATH=/new:$PATH`
nhị phân-test-args	chuỗi	Kiểm thử đối số hoặc cờ. Ví dụ: `--gtest_filter=test1`
nhị-test-ld-library-path	chuỗi	Biến môi trường `LD_LIBRARY_PATH`. Ví dụ: `/data/local/tmp/lib`
khung-kiểm thử nhị phân vô hiệu hoá	boolean	Chạy `adb stop` để tắt Khung Android trước khi kiểm thử. Ví dụ: `true`
máy chủ kiểm tra nhị phân	boolean	Dừng tất 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`
loại kiểm thử nhị phân	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 lựa chọn này cho mẫu này vì bạn đã `binary-test-source` được chỉ định.

Đối với các lựa 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ư thể hiện trong Ví dụ: VtsDeviceTreeEarlyMountTest).

Kiểm tra thẻ

Bạn có thể thêm các thẻ thử nghiệm bằng cách thêm tiền tố strings vào các thẻ đó vào các lựa chọn và sử dụng :: làm dấu phân cách. Thẻ thử nghiệm đặ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ó tên khác nhau bit bit hoặc thư mục mẹ. Ví dụ: để tránh việc đẩy tệp hoặc tên kết quả xung đột xảy ra với các nguồn có cùng tên nhưng từ thư mục nguồn khác nhau, bạn có thể chỉ định các thẻ khác nhau cho những nguồn này.

Như minh hoạ trong ví dụ về VtsDeviceTreeEarlyMountTest, trong đó hai nguồn dt_early_mount_test, thẻ thử nghiệm là Các tiền tố _32bit:: và _64bit:: đang bật binary-test-source. Thẻ kết thúc bằng 32bit hoặc 64bit tự động đánh dấu các bài kiểm thử là có sẵn cho một bit ABI; tức là các kiểm thử có thẻ _32bit không được thực thi trên ABI 64 bit. Không phải chỉ định thẻ cũng giống như sử dụng thẻ có chuỗi trống.

Các tùy chọn có cùng thẻ sẽ được nhóm lại và tách biệt với các thẻ khác. Cho Ví dụ: binary-test-args với thẻ _32bit là chỉ áp dụng cho binary-test-source có cùng thẻ và được thực thi trong binary-test-working-directory bằng cùng một thẻ. Chiến lược phát hành đĩa đơn Tuỳ chọn binary-test-working-directory là không bắt buộc cho kiểm thử nhị phân, cho phép bạn chỉ định một thư mục hoạt động cho thẻ. Khi Lựa chọn binary-test-working-directory không được chỉ định, mặc định được sử dụng cho mỗi thẻ.

Tên thẻ được nối 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 với thẻ _32bit xuất hiện dưới dạng testcase1_32bit trong báo cáo kết quả.

Tích hợp kiểm thử phía đích mà không cần Mẫu BinaryTest

Trong VTS, định dạng kiểm thử mặc định là các chương trình 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 kiểm thử phía mục tiêu, trước tiên bạn phải đẩy kiểm thử tệp với thiết bị, thực thi 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ủ.

Tệp nhị phân kiểm thử đẩy

Bạn nên đẩy các 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 sẽ 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 quá trình 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 quy trình kiểm thử Python phía máy chủ tập lệnh 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 chương trình 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

Chiến lược phát hành đĩa đơn GtestBinaryTest mẫu lưu trữ các tệp nhị phân thử nghiệm GTest, mỗi tệp nhị phân 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 đè thiết lập, tạo trường hợp kiểm thử và phân tích cú pháp kết quả, để tất cả BinaryTest các cấu hình được kế thừa.

GtestBinaryTest sẽ thêm tuỳ chọn gtest-batch-mode:

Tên của lựa chọn	Loại giá trị	Mô tả
loại kiểm thử nhị phân	string	Loại mẫu. Sử dụng giá trị `gtest`.
chế độ lô-gtest	boolean	Chạy 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 giúp tăng hiệu suất nhưng lại giảm độ tin cậy một chút. Tuân thủ VTS nhiều mô-đun sử dụng chế độ hàng loạt để cải thiện hiệu suất. Đảm bảo độ tin cậy tuy nhiên, nếu chế độ không được chỉ định thì mặc định 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ử. Cho 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 máy chủ cấu hình phụ), tệp nhị phân này được gọi 10 lần trên shell của thiết bị mỗi lần với bộ lọc thử nghiệm khác. Đối với mỗi trường hợp kiểm thử, một kết quả đầu ra GTest duy nhất XML được mẫu tạo và phân tích cú pháp.

Hình 2. Chế độ không theo lô.

Ưu điểm của việc sử dụng chế độ không theo lô bao gồm:

Kiểm thử tính năng tách biệt trường hợp. Gặp sự cố hoặc bị 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 thu thập hồ sơ/mức độ phù hợp cho mỗi trường hợp kiểm thử đo lường, systrace, báo cáo lỗi, logcat, v.v. Kết quả và nhật ký kiểm tra đều được truy xuất ngay sau khi mỗi trường hợp kiểm thử kết thúc.

Nhược điểm của việc sử dụng chế độ không theo lô bao gồm:

Tải thừa. Mỗi lần tệp 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í liên lạc. Sau khi kiểm thử xong, máy chủ lưu trữ và thiết bị mục tiêu giao tiếp để phân tích cú pháp kết quả và các lệnh tiếp theo (trong tương lai tối ưu hoá).

Chế độ lô

Ở chế độ hàng loạt GTest, tệp nhị phân kiểm thử chỉ được gọi một lần với một bài kiểm thử dài giá trị bộ lọc chứa tất cả các trường hợp kiểm tra được lọc theo cấu hình phía máy chủ (giá trị này tránh vấn đề tải dư thừa ở chế độ không theo lô). Bạn có thể phân tích cú pháp bài kiểm tra kết quả cho GTest bằng output.xml hoặc sử dụng đầu ra của thiết bị đầu cuối.

Khi sử dụng output.xml (mặc định):

Hình 3. Chế độ lô, output.xml.

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 lượt kiểm thử đã hoàn tất, nếu một trường hợp kiểm thử gặp sự cố, tệp nhị phân hoặc tệp xml không có kết quả của thiết bị tạo.

Khi sử dụng đầu ra của thiết bị đầu cuối:

Hình 4. Chế độ lô, đầu ra của thiết bị đầu cuối.

Trong khi chạy, GTest sẽ in nhật ký kiểm thử và tiến trình đến 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, kết quả và nhật ký.

Ưu điểm của việc sử dụng chế độ hàng loạt bao gồm:

Kiểm thử tính năng tách biệt trường hợp. Cung cấp cùng một cấp độ kiểm thử cách ly trường hợp dưới dạng chế độ không theo lô nếu khung khởi động lại tệp nhị phân/thiết bị sau sự cố có bộ lọc thử nghiệm giảm (không bao gồm thử nghiệm đã kết thúc và thử nghiệm có sự cố trường hợp).
Độ chi tiết. Cung cấp cùng một trường hợp kiểm thử chi tiết như chế độ không theo lô.

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, mọi thử nghiệm đều sẽ hỏng.
Sự nhầm lẫn. Trường hợp kiểm thử có thể in nội dung nào đó tương tự như GTest định dạng tiến trình, do đó có thể gây nhầm lẫn định dạng.

Do những bất lợi này, chúng tôi đã tạm thời loại bỏ tuỳ chọn sử dụng kết quả đầu ra của dòng lệnh. Chúng tôi sẽ xem 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 các tập lệnh Python. Các kiểm thử này bao gồm:

Tệp nhị phân thử nghiệm được biên dịch có thể thực thi trên máy chủ
Tập lệnh có thể thực thi trong shell, Python hoặc các ngôn ngữ khác

Một ví dụ là VTS (VTS) Kiểm tra phía máy chủ của chính sách SELinux bảo mật:

<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 mẫu tương tự cấu hình kiểm thử. Trong ví dụ trên, binary-test-source chỉ định một đườ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ự với Mẫu BinaryTest, tên tệp nhị phân được sử dụng làm tên trường hợp kiểm thử bằng mặc định.

Mở rộng 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 kiểm thử để đưa vào các kiểm thử 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 kiểm thử cụ thể. Mẫu trong kho lưu trữ VTS có các phần mở rộng sau:

Hình 5. Mở rộng mẫu hiện có trong VTS kho lưu trữ.

Nhà phát triển nên mở rộng mọi mẫu hiện có cho mọi mẫu kiểm thử các yêu cầu. Sau đây là một số lý do phổ biến để mở rộng mẫu:

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.
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 kết quả của 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 phương thức dành riêng cho từng chức năng. Nếu bạn đã cải tiến thiết kế cho chúng tôi khuyến khích bạn đóng góp cho cơ sở mã VTS.