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 việc 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ả các lựa chọn theo cách chung chung kèm theo lý do sử dụng từng lựa chọn.
Khi chạy liên tục một bộ kiểm thử trong phòng thí nghiệm, bộ kiểm thử thường được phân đoạn trên nhiều thiết bị để giảm tổng thời gian hoàn thành. Thông thường, bộ kiểm thử sẽ cố gắng cân bằng thời gian thực thi của từng 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 tính 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ự xem xét 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 hay không thể phân mảnh?
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 bộ khung rằng mô-đun đó không được phân mảnh.
Trong một mô-đun thông thường, việc cho phép bộ kiểm thử phân đoạn 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ột 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 cho mỗi thiết bị có liên quan. Nếu quá trình thiết lập mô-đun của bạn diễn ra trong thời gian dài và tốn kém, đồng thời 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 phân mảnh.
- Khi số lượng kiểm thử trong mô-đun của bạn thấp:
Việc phân đoạn một mô-đun có thể khiến tất cả các trường hợp kiểm 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ử của bạn thấp, bạn có thể kết thúc bằng một kiểm thử duy nhất hoặc không có kiểm thử nào trong một số phân đoạn, đ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ử duy nhất 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 thông qua AndroidJUnitTest không cho biết cho bộ công cụ biết có bao nhiêu kiểm thử thuộc quy trình đ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 thuộc bộ.
Harness có thể phân đoạn quá mức bài kiểm thử đo lường và kết thúc bằng một số phân đoạn trống; việc phân đoạn một bài kiểm thử đo lường có 5 bài kiểm thử thành 6 phân đoạn sẽ dẫn đến 5 phân đoạn có 1 bài kiểm thử và 1 phân đoạn không có bài kiểm thử. Mỗi phân đoạn này sẽ yêu cầu một quy trình cài đặt APK tốn kém.
Vì vậy, khi số lượng kiểm thử trong APK kiểm thử đo lường thấp, việc gắn thẻ mô-đun bằng <option name="not-shardable" value="true" /> sẽ cho phép bộ kiểm thử biết rằng việc phân đoạn mô-đun đó là không đáng.
Trình chạy AndroidJUnitTest có một lựa chọn đặc biệt cho phép chỉ định số lượng phân đoạn tối đa mà trình chạy đượ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à hoạt động đo lường có thể được phân đoạn, 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 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 2 trường hợp kiểm thử nhưng bạn vẫn muốn phân đoạ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.