Trang này mô tả những nội dung có thể điều chỉnh cho mô-đun bộ kiểm thử (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 cùng với 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ử này 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. Hệ thống thường 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 hoàn tất); nhưng do tính chất của một số bài kiểm thử, chúng tôi không phải lúc nào cũng có đủ khả năng tự phân tích 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 hệ thống rằng mô-đun đó
không được phân đoạn.
Trong một mô-đun thông thường, việc cho phép hệ thống phân đoạn mô-đun của bạn (hành vi mặc định) là điều nên làm. Tuy nhiên, trong một số trường hợp, bạn có thể muốn ghi đè hành vi đó:
- Khi quá trình thiết lập mô-đun của bạn tốn kém:
Việc phân đoạn một mô-đun sẽ dẫn đến quá trình 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 tốn nhiều thời gian và chi phí, đồng thời không đáng để sao chép so với thời gian chạy của bài kiểm thử, 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 thử trong mô-đun của bạn thấp:
Việc phân đoạn một mô-đun sẽ dẫn đến việc 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 bài kiểm thử của bạn thấp, thì bạn có thể chỉ có một bài kiểm thử hoặc không có bài 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ử thường không đáng.
Kiểm thử đo lường: Số lượng phân đoạn tối đa?
Bài kiểm thử đo lường chạy thông qua AndroidJUnitTest không cho hệ thống biết có bao nhiêu bài kiểm thử là một phần của quá 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ộ kiểm thử.
Hệ thống có thể phân đoạn quá mức bài kiểm thử đo lường và kết thúc với 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ử trong 6 phân đoạn sẽ dẫn đến 5 phân đoạn có một bài kiểm thử và một 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 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 bằng <option name="not-shardable" value="true" /> sẽ cho phép hệ thống biết rằng việc phân đoạn mô-đun đó 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 này đượ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 mà khả nă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ời gọi. Theo mặc định, khả nă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ời 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.