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