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

Trang này mô tả cách viết mộ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 một trình kiểm thử mới; trình kiểm thử có thể được viết riêng.

Mức tối thiểu: Triển khai giao diện

Điều kiện tối thiểu để đủ điều kiện làm trình chạy thử nghiệm Tradefed là 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 gọi bởi bộ công cụ khi sử dụng trình chạy kiểm thử, tương tự như Java Runnable.

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ở cho phép truy cập vào một đối tượng trình nghe thuộc loại ITestInvocationListener. Đối tượng này là chìa khoá để báo cáo kết quả có cấu trúc từ trình chạy kiểm thử đến harness.

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 phù hợp của tất cả các kiểm thử đã chạy, thời gian chạy và liệu từng kiểm thử có đạt, không đạt hay ở một số trạng thái khác.
Báo cáo các chỉ số liên quan đến kiểm thử (nếu có), ví dụ: chỉ số 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, ví dụ: 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, việc báo cáo kết quả có cấu trúc là không bắt buộc; một trình chạy kiểm thử có thể chỉ muốn đánh giá trạng thái của toàn bộ quá trình chạy là ĐẠT hoặc KHÔNG ĐẠT mà không cần bất kỳ thông tin chi tiết nào về 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 bộ công cụ 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 bắt đầu một kịch bản kiểm thử.
- 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 được coi là đã vượt qua.
- testEnded: Thông báo kết thúc trường hợp kiểm thử.
testRunFailed: Thông báo rằng trạng thái chung của việc thực thi nhóm trường hợp kiểm thử là không thành công. Lần chạy thử có thể là đạt hoặc không đạt độc lập với kết quả của các trường hợp kiểm thử tuỳ thuộc vào những gì mà quá trình thực thi 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 có mã thoát lỗi (vì bất kỳ lý do nào: tệp bị rò rỉ, v.v.).
testRunEnded: Thông báo khi nhóm trường hợp kiểm thử kết thúc.

Việc duy trì và đảm bảo đúng thứ tự 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ụ: đảm bảo rằng testRunEnded được gọi trong trường hợp ngoại lệ bằng cách sử dụng mệnh đề finally.

Các lệnh gọi lại trường hợp kiểm thử (testStarted, testEnded, v.v.) là không bắt buộc. Một lần chạy thử có thể xảy ra mà không có trường hợp thử nghiệm 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ó mục đích để giữ mọi thứ gần với những điều cơ bản mà nhà phát triển thường có kiến thức.

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

Nếu đang viết lớp hoặc trình chạy kiểm thử Tradefed 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ể dùng trình nghe này để ghi nhật ký các 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, riêng biệt và không yêu cầu bất kỳ tài nguyên cụ thể nào, chẳng hạn như kiểm thử đơn vị Java.

Những người viết bài kiểm thử muốn chuyển sang bước tiếp theo của 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ử nhận được đối tượng IBuildInfo được tạo ở bước 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 chế độ thiết lập kiểm thử.

Các trình chạy kiểm thử thường quan tâm đến những giao diện này để nhận các cấu phần phần mềm liên quan đến quá trình thực thi, chẳng hạn như các tệp bổ sung và nhận thiết bị đang được kiểm thử sẽ là mục tiêu trong quá trình thực thi.

Kiểm thử trên nhiều thiết bị

Tradefed hỗ trợ chạy các bài kiểm thử trên nhiều thiết bị cùng một lúc. Điều này hữu ích khi kiểm thử các thành phần yêu cầu một hoạt động 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 mộ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 một bản đồ 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 được liên kết của chúng.

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

Các kiểm thử nhận biết được chế độ thiết lập của chúng

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, ví dụ: 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 mà trình chạy kiểm thử là một phần và được thực thi trong đó. Hãy xem nội dung mô tả đối tượng cấu hình để biết thêm chi tiết.

Đối với việc triển khai trình chạy kiểm thử, bạn sẽ cần triển khai 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 một cách linh hoạt để chạy các 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 riêng từng kiểm thử đơn vị.

Điều này cho phép bộ công cụ và cơ sở hạ tầng lớn hơn tận dụng khả năng kiểm soát chi tiết đó và người dùng chạy một phần trình chạy kiểm thử thông qua 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 những kiểm thử nên hoặc không nên chạy.

Quy ước của chúng tôi là một thử nghiệm sẽ được chạy NẾU nó khớp với một hoặc nhiều bộ lọc bao gồm VÀ không khớp với bất kỳ bộ lọc loại trừ nào. Nếu không có bộ lọc include nào được đưa ra, thì tất cả các kiểm thử sẽ được chạy miễn là chúng không khớp với bất kỳ bộ lọc exclude nào.