Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release thay vì aosp-main để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.

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

Viết trình chạy kiểm thử Tradefed
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.

Trang này mô tả cách viết trình chạy kiểm thử mới trong Tradefed.

Thông tin khái quát

Nếu bạn muốn tìm hiểu về vị trí của trình chạy kiểm thử trong cấu trúc Tradefed, hãy xem phần Cấu trúc của trình chạy kiểm thử.

Đây không phải là điều kiện tiên quyết để viết trình chạy kiểm thử mới; bạn có thể viết trình chạy kiểm thử một cách độc lập.

Tối thiểu: Triển khai giao diện

Điều tối thiểu để đủ điều kiện trở thành trình chạy kiểm thử Tradefeed là bạn phải triển khai Giao diện IRemoteTest và cụ thể hơn là phương thức run(TestInformation testInfo, ITestInvocationListener listener).

Phương thức này là phương thức được bộ điều khiển gọi khi sử dụng trình chạy kiểm thử, tương tự như một Runnable Java.

Mọi phần của phương thức đó đều được coi là một phần của quá trình thực thi trình chạy kiểm thử.

Báo cáo kết quả từ trình chạy kiểm thử

Phương thức run trong giao diện cơ sở cấp quyền truy cập vào đối tượng trình nghe thuộc loại ITestInvocationListener. Đối tượng này là chìa khoá để báo cáo có cấu trúc kết quả từ trình chạy kiểm thử đến khai thác.

Bằng cách báo cáo kết quả có cấu trúc, trình chạy kiểm thử có các thuộc tính sau:

Báo cáo danh sách thích hợp về tất cả các chương trình kiểm thử đã chạy, thời lượng chạy và liệu các chương trình kiểm thử đó có đạt, không đạt hay ở một số trạng thái khác hay không.
Báo cáo các chỉ số liên kết với các thử nghiệm (nếu có), ví dụ: các chỉ số về thời gian cài đặt.
Phù hợp với hầu hết các công cụ cơ sở hạ tầng, chẳng hạn như hiển thị kết quả và chỉ số, v.v.
Thường dễ gỡ lỗi hơn vì có dấu vết chi tiết hơn về quá trình thực thi.

Tuy nhiên, bạn không bắt buộc phải báo cáo kết quả có cấu trúc; một trình chạy thử nghiệm có thể chỉ muốn đánh giá trạng thái của toàn bộ lượt chạy là ĐẠT hoặc KHÔNG THÀNH CÔNG mà không mọi chi tiết của quá trình thực thi thực tế.

Bạn có thể gọi các sự kiện sau trên trình nghe để thông báo cho harness về tiến trình thực thi hiện tại:

testRunStarted: Thông báo về việc bắt đầu một nhóm các trường hợp kiểm thử có liên quan với nhau.
- testStarted: Thông báo khi một trường hợp kiểm thử bắt đầu.
- testFailed/testIgnored: Thông báo về sự thay đổi trạng thái của trường hợp kiểm thử đang diễn ra. Một trường hợp kiểm thử không có bất kỳ thay đổi nào về trạng thái sẽ được coi là đã vượt qua.
- testKết thúc: Thông báo về việc kết thúc trường hợp kiểm thử.
testRunFailed: Thông báo về trạng thái chung của nhóm các trường hợp kiểm thử không thực thi được. Chạy kiểm thử có thể là đạt hoặc không thành công độc lập với kết quả trường hợp kiểm thử, tuỳ thuộc vào việc thực thi như mong đợi. Ví dụ: một tệp nhị phân chạy một số trường hợp kiểm thử có thể báo cáo tất cả các trường hợp kiểm thử đạt nhưng kèm theo mã thoát lỗi (đối với bất kỳ lý do: tệp rò rỉ, v.v.).
testRunEnded: Thông báo kết thúc nhóm các trường hợp kiểm thử.

Việc duy trì và đảm bảo thứ tự thích hợp của các lệnh gọi lại là trách nhiệm của người triển khai trình chạy kiểm thử, ví dụ như đảm bảo rằng testRunEnded được gọi trong trường hợp ngoại lệ bằng mệnh đề finally.

Bạn không bắt buộc phải sử dụng lệnh gọi lại cho trường hợp kiểm thử (testStarted, testEnded, v.v.). Một lần chạy kiểm thử có thể xảy ra mà không có trường hợp kiểm thử nào.

Bạn có thể nhận thấy rằng cấu trúc sự kiện này được lấy cảm hứng từ cấu trúc JUnit thông thường. Điều này là có chủ ý để giữ mọi thứ gần với những kiến thức cơ bản mà nhà phát triển thường có.

Báo cáo nhật ký từ trình chạy kiểm thử

Nếu bạn đang viết lớp kiểm thử hoặc trình chạy thương mại của riêng mình, bạn sẽ triển khai IRemoteTest và nhận ITestInvocationListener thông qua phương thức run(). Bạn có thể sử dụng trình nghe này để ghi nhật ký tệp như sau:

    listener.testLog(String dataName, LogDataType type_of_data, InputStreamSource data);

Kiểm thử bằng thiết bị

Giao diện tối thiểu ở trên cho phép chạy các kiểm thử rất đơn giản, và không yêu cầu tài nguyên cụ thể nào, ví dụ như kiểm thử đơn vị Java.

Người viết chương trình kiểm thử muốn chuyển sang bước tiếp theo trong quy trình kiểm thử thiết bị sẽ cần các giao diện sau:

IDeviceTest cho phép nhận đối tượng ITestDevice đại diện cho thiết bị đang được kiểm thử và cung cấp API để tương tác với thiết bị đó.
IBuildReceiver cho phép kiểm thử lấy đối tượng IBuildInfo được tạo ở bước trình cung cấp bản dựng chứa tất cả thông tin và cấu phần phần mềm liên quan đến việc thiết lập kiểm thử.

Người chạy kiểm thử thường quan tâm đến các giao diện này để có được cấu phần phần mềm liên quan đến quá trình thực thi, ví dụ như các tệp bổ sung và nhận thiết bị kiểm thử được nhắm mục tiêu trong quá trình thực thi.

Kiểm thử với nhiều thiết bị

Tradefeed hỗ trợ chạy kiểm thử trên nhiều thiết bị cùng lúc. Điều này rất hữu ích khi kiểm thử các thành phần yêu cầu tương tác bên ngoài, chẳng hạn như ghép nối điện thoại và đồng hồ.

Để viết trình chạy kiểm thử có thể sử dụng nhiều thiết bị, bạn sẽ cần triển khai IMultiDeviceTest. Trình chạy này sẽ cho phép nhận bản đồ của ITestDevice đến IBuildInfo chứa danh sách đầy đủ các bản trình bày thiết bị và thông tin bản dựng liên quan của các bản trình bày đó.

Phương thức setter từ giao diện sẽ luôn được gọi trước phương thức run, vì vậy có thể giả định rằng cấu trúc sẽ có sẵn khi run được gọi.

Kiểm thử nhận biết chế độ thiết lập

Một số cách triển khai trình chạy kiểm thử có thể cần thông tin về chế độ thiết lập tổng thể để hoạt động đúng cách, chẳng hạn như một số siêu dữ liệu về lệnh gọi hoặc target_preparer nào đã chạy trước đó, v.v.

Để đạt được điều này, trình chạy kiểm thử có thể truy cập vào đối tượng IConfiguration nó là một phần của và được thực thi. Xem đối tượng cấu hình để biết thêm chi tiết.

Để triển khai trình chạy kiểm thử, bạn sẽ cần triển khai phương thức IConfigurationReceiver để nhận đối tượng IConfiguration.

Trình chạy kiểm thử linh hoạt

Trình chạy kiểm thử có thể cung cấp cách linh hoạt để chạy kiểm thử nếu có quyền kiểm soát chi tiết đối với các kiểm thử đó, ví dụ: trình chạy kiểm thử JUnit có thể chạy từng kiểm thử đơn vị riêng lẻ.

Điều này cho phép bộ điều khiển và cơ sở hạ tầng lớn hơn tận dụng khả năng kiểm soát tinh vi đó và người dùng có thể chạy một phần trình chạy kiểm thử thông qua tính năng lọc.

Hỗ trợ lọc được mô tả trong giao diện ITestFilterReceiver, cho phép nhận các bộ lọc include và exclude cho các chương trình kiểm thử nên hoặc không nên chạy.

Theo quy ước của chúng tôi là một kiểm thử sẽ được chạy IFF khớp với một hoặc nhiều bao gồm bộ lọc VÀ không phù hợp với bất kỳ bộ lọc loại trừ nào. Nếu không bao gồm đã cung cấp, tất cả thử nghiệm sẽ được chạy miễn là chúng không khớp với bất kỳ các bộ lọc loại trừ.