Trang này mô tả những gì có thể điều chỉnh cho một mô-đun bộ ( AndroidTest.xml ) thông qua sharding và đạt được hiệu suất tốc độ tốt nhất trong quá trình thực thi liên tục trong phòng thí nghiệm. Chúng tôi sẽ cố gắng mô tả các tùy chọn một cách chung chung với lý do căn bản cho việc sử dụng từng tùy chọn.
Khi chạy liên tục một bộ phần mềm trong phòng thí nghiệm, bộ phần mềm đó thường được phân chia trên nhiều thiết bị để giảm tổng thời gian hoàn thành. Bộ khai thác thường cố gắng cân bằng thời gian thực hiện của từng phân đoạn để giảm thiểu thời gian hoàn thành tổng thể (khi phân đoạn cuối cùng kết thúc); nhưng do tính chất của một số thử nghiệm, không phải lúc nào chúng tôi cũng có đủ khả năng xem xét nội tâm và cần chủ sở hữu mô-đun điều chỉnh một số hành vi.
Có thể phân chia được hay không phân chia được?
Có thể gắn thẻ một mô-đun ( AndroidTest.xml ) bằng <option name="not-shardable" value="true" /> để thông báo cho dây nịt rằng nó không nên bị phân mảnh.
Trong một mô-đun điển hình, việc để bộ khai thác phân mảnh mô-đun của bạn (hành vi mặc định) là điều nên làm. Nhưng trong một số trường hợp, bạn có thể muốn ghi đè hành vi đó:
- Khi việc thiết lập mô-đun của bạn tốn kém:
Việc phân chia mô-đun dẫn đến quá trình chuẩn bị (cài đặt APK, tệp đẩy, v.v.) có thể chạy một lần trên mỗi thiết bị liên quan. Nếu quá trình thiết lập mô-đun của bạn dài, tốn kém và không đáng để sao chép so với thời gian chạy thử nghiệm, bạn nên gắn thẻ mô-đun của mình là không thể phân đoạn được.
- Khi số lượng bài kiểm tra trong mô-đun của bạn thấp:
Việc phân chia một mô-đun dẫn đến tất cả các trường hợp thử nghiệm có thể thực thi độc lập trên các thiết bị khác nhau. Điều này liên quan đến điểm đầu tiên; nếu số lượng bài kiểm tra của bạn thấp, bạn có thể kết thúc bằng một bài kiểm tra duy nhất hoặc không có bài kiểm tra nào trong một số phân đoạn, điều này sẽ khiến bất kỳ bước chuẩn bị nào trở nên khá tốn kém. Ví dụ: việc cài đặt APK cho một trường hợp thử nghiệm thường không có giá trị.
Kiểm tra thiết bị: Số lượng phân đoạn tối đa?
Thử nghiệm thiết bị đo lường chạy qua AndroidJUnitTest không tiết lộ số lượng thử nghiệm là một phần của thiết bị đo lường cho đến khi chúng tôi thực sự cài đặt và chạy APK. Các hoạt động này rất tốn kém và không thể thực hiện được tại thời điểm phân chia cho tất cả các phần mô-đun của bộ phần mềm.
Dây nịt có thể làm hỏng quá trình kiểm tra thiết bị đo đạc và kết thúc với một số mảnh trống; Việc phân chia một bài kiểm tra thiết bị đo bằng năm bài kiểm tra trong sáu phân đoạn sẽ tạo ra năm phân đoạn có một bài kiểm tra và một phân đoạn không có bài kiểm tra. Mỗi phân đoạn này sẽ yêu cầu cài đặt APK tốn kém.
Vì vậy, khi số lượng thử nghiệm trong APK thử nghiệm thiết bị đo đạc thấp, việc gắn thẻ mô-đun bằng <option name="not-shardable" value="true" /> sẽ cho phép bộ khai thác biết rằng việc phân chia mô-đun đó là không đáng.
Trình chạy AndroidJUnitTest có một tùy chọn đặc biệt cho phép nó chỉ định số lượng phân đoạn tối đa được phép phân đoạn thành: <option name="ajur-max-shard" value="5" /> .
Điều này cho phép bạn chỉ định số lần tối đa mà thiết bị có thể được phân chia bất kể số lượng phân đoạn được yêu cầu ở cấp độ yêu cầu. Theo mặc định, thiết bị đo sẽ được phân chia thành số lượng phân đoạn được yêu cầu cho lệnh gọi.
Ví dụ: nếu APK thử nghiệm thiết bị đo đạc của bạn chỉ chứa hai trường hợp thử nghiệm nhưng bạn vẫn muốn phân đoạn nó thì việc có giá trị ajur-max-shard là 2 sẽ đảm bảo bạn không tạo các phân đoạn trống.