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 phân đoạn và nhận đượ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 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ể. 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 bản chất của một số thử nghiệm, chúng tôi không phải lúc nào 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.
Shardable hay không shardable?
Có thể gắn thẻ một mô-đun ( AndroidTest.xml ) với <option name="not-shardable" value="true" /> để thông báo cho bộ khai thác rằng nó không nên bị phân mảnh.
Trong một mô-đun điển hình, việc để dây nịt 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 thiết lập mô-đun của bạn tốn kém:
Chia sẻ mô-đun dẫn đến việc chuẩn bị (cài đặt APK, đẩy tệp, 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 kéo dài, tốn kém và không đáng để sao chép so với thời gian chạy thử nghiệm, thì 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:
Việc chia sẻ 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 ít, bạn có thể chỉ có một bài kiểm tra 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 APK cho một trường hợp thử nghiệm đơn lẻ thường không đáng.
Kiểm tra thiết bị: Số lượng mảnh tối đa?
Thử nghiệm thiết bị chạy qua AndroidJUnitTest không cho người khai thác biết có bao nhiêu thử nghiệm là một phần của thiết bị 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 phân mảnh cho tất cả các phần mô-đun của bộ phần mềm.
Dây nịt có thể phân mảnh quá mức trong bài kiểm tra thiết bị đo đạc và kết thúc với một số mảnh trống; sharding một thử nghiệm thiết bị với năm thử nghiệm trong sáu phân đoạn dẫn đến năm phân đoạn có 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ẻ cho mô-đun bằng <option name="not-shardable" value="true" /> sẽ cho phép bộ khai thác biết việc bảo vệ 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 mà nó được phép phân đoạn vào: <option name="ajur-max-shard" value="5" /> .
Điều này cho phép bạn chỉ định số lần tối đa thiết bị có thể được phân đoạn 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ị sẽ được 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 công 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.