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