Google cam kết thúc đẩy công bằng chủng tộc cho Cộng đồng người da đen. Xem cách thực hiện.

Định cấu hình Sharding

Trang này mô tả những gì có thể để điều chỉnh cho một module 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 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ể phân mảnh hoặc không thể phân mảnh?

Có thể gắn thẻ một module ( AndroidTest.xml ) với <option name="not-shardable" value="true" /> để thông báo cho người khai thác mà nó không nên được sharded.

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ẽ làm cho 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?

Một thiết bị đo đạc kiểm tra chạy qua AndroidJUnitTest không tiếp xúc với các khai thác bao nhiêu bài kiểm tra là một phần của thiết bị đo đạc cho đến khi chúng tôi thực sự cài đặt và chạy apk. Các hoạt động này 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 các bài kiểm tra trong APK thử nghiệm thiết bị đo đạc là thấp, gắn thẻ mô-đun với <option name="not-shardable" value="true" /> sẽ cho phép khai thác để biết sharding mô-đun đó không phải là giá trị nó.

Các AndroidJUnitTest Á hậu có một lựa chọn đặc biệt cho phép nó để xác định số lượng tối đa của mảnh nó được phép vào 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 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 sẽ được chia nhỏ thành số 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 có chứa chỉ có hai trường hợp thử nghiệm nhưng bạn vẫn muốn Shard nó, có một ajur-max-shard giá trị của 2 sẽ đảm bảo bạn không tạo mảnh trống rỗng.