Sử dụng thử lại bộ

Một bộ có xu hướng bao gồm một số mô-đun thử nghiệm và có thể đạt đến kích thước kho dữ liệu thử nghiệm khá lớn. Ví dụ: Bộ kiểm tra khả năng tương thích Android (CTS) bao gồm hàng trăm mô-đun và hàng trăm nghìn trường hợp kiểm tra.

Có thể xảy ra trường hợp một lượng lớn thử nghiệm không thành công do khả năng cách ly kém hoặc thiết bị rơi vào trạng thái xấu.

Tính năng thử lại bộ ứng dụng nhằm giải quyết các trường hợp đó: Tính năng này chỉ cho phép bạn thử lại các lỗi thay vì thử lại toàn bộ bộ ứng dụng để loại trừ khả năng bị lỗi và khả năng cách ly kém. Nếu một lần kiểm tra liên tục thất bại, lần thử lại cũng thất bại; và bạn nhận được tín hiệu rõ ràng hơn nhiều rằng có vấn đề thực sự.

Thực hiện thử lại bộ

Việc thử lại các kết quả liên quan đến việc đọc các kết quả trước đó và chạy lại lời gọi trước đó.

Giao diện chính điều khiển thử lại là ITestSuiteResultLoader , cho phép bạn tải kết quả trước đó và dòng lệnh trước đó.

RetryRescheduler sau đó sử dụng thông tin này để tạo lại lệnh trước đó và đưa vào một số bộ lọc để chỉ chạy lại các lỗi trước đó hoặc các kiểm tra không được thực hiện.

Bộ ví dụ thử lại: CTS

Cấu hình thử lại trong CTS là:

<configuration description="Runs a retry of a previous CTS session.">
    <object type="previous_loader" class="com.android.compatibility.common.tradefed.result.suite.PreviousResultLoader" />
    <test class="com.android.tradefed.testtype.suite.retry.RetryRescheduler" />

    <logger class="com.android.tradefed.log.FileLogger">
        <option name="log-level-display" value="WARN" />
    </logger>
</configuration>

Điều này có thể áp dụng cho hầu hết các bộ mở rộng nó, ví dụ VTS .

Nó sẽ được gọi với:

cts-tradefed run retry --retry <session>

Phiên sẽ được tìm thấy bằng cách liệt kê các kết quả trước đó trong bảng điều khiển CTS:

cts-tf > l r
Session  Pass  Fail  Modules Complete  Result Directory     Test Plan  Device serial(s)  Build ID   Product
0        2092  30    148 of 999        2018.10.29_14.12.57  cts        [serial]          P          Pixel

Lệnh ban đầu chính xác sẽ được tải lại và chạy lại với các bộ lọc bổ sung. Điều này có nghĩa là nếu lệnh ban đầu của bạn bao gồm một số tùy chọn, thì chúng cũng là một phần của quá trình thử lại.

Ví dụ:

cts-tradefed run cts-dev -m CtsGestureTestCases

Việc thử lại ở trên luôn bị ràng buộc với CtsGestureTestCases vì ​​chúng tôi đang thử lại một lệnh chỉ liên quan đến nó.

Định cấu hình thử lại cho bộ kiểu CTS

Để thử lại hoạt động, các kết quả trước đó cần được xuất ở định dạng proto. Những điều sau đây cần phải được thêm vào:

<result_reporter class="com.android.compatibility.common.tradefed.result.suite.CompatibilityProtoResultReporter" />

Điều này cần được thêm vào cấu hình XML của lệnh chính và nó dẫn đến tệp test-record.pb được tạo trong thư mục kết quả.

Thử lại CTS sau đó tải dữ liệu từ tổ hợp test-record.pbtest_result.xml hiện có để chuẩn bị lệnh gọi thử lại.