Thiết bị do Gradle quản lý giúp cải thiện tính nhất quán, hiệu suất và độ tin cậy cho các kiểm thử đo lường tự động. Tính năng này có sẵn cho API cấp độ 27 trở lên, cho phép bạn định cấu hình các thiết bị kiểm thử ảo trong các tệp Gradle của dự án. Hệ thống xây dựng sử dụng cấu hình để quản lý hoàn toàn, tức là tạo, triển khai và chia nhỏ các thiết bị đó khi thực thi kiểm thử tự động.
Tính năng này cấp cho Gradle quyền truy cập không chỉ vào kiểm thử bạn đang chạy, mà còn cả vòng đời của các thiết bị, nhờ đó cải thiện chất lượng kiểm thử của bạn theo các cách sau:
- Xử lý các vấn đề liên quan đến thiết bị để đảm bảo thử nghiệm của bạn được thực thi
- Sử dụng ảnh chụp nhanh của trình mô phỏng để cải thiện thời gian khởi động thiết bị và mức sử dụng bộ nhớ đồng thời khôi phục thiết bị về trạng thái sạch giữa các lần kiểm thử
- Lưu các kết quả kiểm thử vào bộ nhớ đệm và chỉ chạy lại các kiểm thử có khả năng cung cấp kết quả khác
- Cung cấp một môi trường nhất quán để chạy các chương trình kiểm thử giữa các lần chạy kiểm thử cục bộ và từ xa
Ngoài ra, Thiết bị do Gradle quản lý giới thiệu một loại thiết bị trình mô phỏng mới tên là Thiết bị kiểm thử tự động (ATD). Công cụ này được tối ưu hoá để cải thiện hiệu suất khi chạy các kiểm thử được đo lường của bạn. Kết hợp với tính năng hỗ trợ phân đoạn kiểm thử, bạn có thể thử nghiệm việc chia tách bộ kiểm thử trên nhiều thực thể ATD để giảm tổng thời gian chạy kiểm thử.
Tạo thiết bị do Gradle quản lý
Bạn có thể chỉ định một thiết bị ảo mà bạn muốn Gradle sử dụng để kiểm thử
ứng dụng của mình trong tệp build.gradle
cấp mô-đun. Mã mẫu sau đây sẽ tạo một
Pixel 2 chạy API cấp 30 dưới dạng một thiết bị do Gradle quản lý.
Groovy
android { testOptions { managedDevices { devices { pixel2api30 (com.android.build.api.dsl.ManagedVirtualDevice) { // Use device profiles you typically see in Android Studio. device = "Pixel 2" // Use only API levels 27 and higher. apiLevel = 30 // To include Google services, use "google". systemImageSource = "aosp" } } } } }
Kotlin
android { testOptions { managedDevices { devices { maybeCreate<com.android.build.api.dsl.ManagedVirtualDevice>("pixel2api30").apply { // Use device profiles you typically see in Android Studio. device = "Pixel 2" // Use only API levels 27 and higher. apiLevel = 30 // To include Google services, use "google". systemImageSource = "aosp" } } } } }
Để chạy kiểm thử bằng thiết bị do Gradle quản lý mà bạn đã định cấu hình, hãy dùng
lệnh sau. device-name
là tên của thiết bị mà bạn đã định cấu hình trong
tập lệnh bản dựng Gradle (chẳng hạn như pixel2api30
) và BuildVariant
là
biến thể bản dựng của ứng dụng mà bạn muốn kiểm thử.
gradlew device-nameBuildVariantAndroidTest
Xác định các nhóm thiết bị
Để giúp bạn mở rộng quy mô kiểm thử trên nhiều cấu hình thiết bị, chẳng hạn như các cấp độ API và hệ số hình dạng, bạn có thể xác định nhiều thiết bị do Gradle quản lý và thêm các thiết bị đó vào một nhóm được đặt tên. Sau đó, Gradle có thể thực thi song song các thử nghiệm của bạn trên tất cả các thiết bị trong nhóm.
Ví dụ bên dưới cho thấy hai thiết bị được quản lý được thêm vào một nhóm thiết bị có tên là phoneAndTablet
.
Groovy
testOptions { managedDevices { devices { pixel2api29 (com.android.build.api.dsl.ManagedVirtualDevice) { ... } nexus9api30 (com.android.build.api.dsl.ManagedVirtualDevice) { ... } } groups { phoneAndTablet { targetDevices.add(devices.pixel2api29) targetDevices.add(devices.nexus9api30) } } } }
Kotlin
testOptions { managedDevices { devices { maybeCreate<com.android.build.api.dsl.ManagedVirtualDevice>("pixel2api29").apply { ... } maybeCreate<com.android.build.api.dsl.ManagedVirtualDevice>("nexus9api30").apply { ... } } groups { maybeCreate("phoneAndTablet").apply { targetDevices.add(devices["pixel2api29"]) targetDevices.add(devices["nexus9api30"]) } } } }
Để chạy kiểm thử bằng nhóm thiết bị do Gradle quản lý, hãy dùng lệnh sau:
gradlew group-nameGroupBuildVariantAndroidTest
Chạy kiểm thử bằng Thiết bị thử nghiệm tự động
Thiết bị do Gradle quản lý hỗ trợ một loại thiết bị trình mô phỏng mới tên là Thiết bị kiểm thử tự động (ATD). Công cụ này được tối ưu hoá để giảm tài nguyên CPU và bộ nhớ khi chạy kiểm thử đo lường. ATD cải thiện hiệu suất thời gian chạy theo một số cách:
- Xoá các ứng dụng cài đặt sẵn thường không hữu ích khi bạn kiểm thử ứng dụng
- Tắt một số dịch vụ nền thường không hữu ích cho việc kiểm thử ứng dụng
- Tắt tính năng kết xuất phần cứng
Trước khi bắt đầu, hãy đảm bảo bạn
cập nhật Trình mô phỏng Android lên
phiên bản mới nhất. Sau đó, hãy chỉ định hình ảnh "-atd" khi xác định một Thiết bị do Gradle
quản lý trong build.gradle
của bạn, như minh hoạ dưới đây:
Groovy
android { testOptions { managedDevices { devices { pixel2api30 (com.android.build.api.dsl.ManagedVirtualDevice) { // Use device profiles you typically see in Android Studio. device = "Pixel 2" // ATDs currently support only API level 30. apiLevel = 30 // You can also specify "google-atd" if you require Google Play Services. systemImageSource = "aosp-atd" } } } } }
Kotlin
android { testOptions { managedDevices { devices { maybeCreate<com.android.build.api.dsl.ManagedVirtualDevice>("pixel2api30").apply { // Use device profiles you typically see in Android Studio. device = "Pixel 2" // ATDs currently support only API level 30. apiLevel = 30 // You can also specify "google-atd" if you require Google Play Services. systemImageSource = "aosp-atd" } } } } }
Bạn cũng có thể tạo nhóm thiết bị tương tự như với các Thiết bị do Gradle quản lý khác. Để tận dụng thêm các cải tiến về hiệu suất, bạn cũng có thể sử dụng ATD với tính năng phân đoạn kiểm thử để giảm tổng thời gian thực thi kiểm thử của bộ kiểm thử.
Những thành phần nào bị xoá khỏi hình ảnh ATD?
Ngoài việc hoạt động ở chế độ không có giao diện người dùng, ATD còn tối ưu hoá hiệu suất bằng cách xoá hoặc vô hiệu hoá các ứng dụng và dịch vụ thường không cần thiết để kiểm thử mã ứng dụng. Bảng dưới đây cung cấp thông tin tổng quan về các thành phần mà chúng tôi đã xoá hoặc vô hiệu hoá trong hình ảnh ATD và mô tả lý do các thành phần này có thể không hữu ích.
Những thành phần bị xoá khỏi hình ảnh ATD | Lý do bạn có thể không cần những phần khi chạy kiểm thử tự động |
---|---|
Ứng dụng sản phẩm của Google:
|
Các bài kiểm thử tự động của bạn nên tập trung vào logic của ứng dụng trong khi giả định
rằng các ứng dụng khác hoặc nền tảng này sẽ hoạt động đúng cách.
Với Espresso-Intents, bạn có thể so khớp và xác thực các ý định gửi đi hoặc thậm chí là cung cấp các phản hồi giả lập thay cho các phản hồi thực tế về ý định. |
Cài đặt ứng dụng và dịch vụ:
|
Những ứng dụng như vậy hiển thị một GUI (Giao diện người dùng đồ hoạ) để người dùng cuối thay đổi chế độ cài đặt
nền tảng, thiết lập thiết bị hoặc quản lý bộ nhớ của thiết bị. Điều này thường
nằm ngoài phạm vi của kiểm thử tự động cấp ứng dụng.
|
SystemUI | Các bài kiểm thử tự động của bạn nên tập trung vào logic của ứng dụng trong khi giả định rằng các ứng dụng khác hoặc nền tảng này sẽ hoạt động đúng cách. |
Ứng dụng và dịch vụ AOSP:
|
Những ứng dụng và dịch vụ này thường nằm ngoài phạm vi kiểm thử tự động cho mã của ứng dụng. |
Bật tính năng phân đoạn kiểm thử
Thiết bị do Gradle quản lý hỗ trợ tính năng phân đoạn kiểm thử, cho phép bạn phân tách bộ kiểm thử trên một số thực thể thiết bị ảo giống nhau, được gọi là phân đoạn (chạy song song). Việc sử dụng tính năng phân đoạn kiểm thử có thể giúp giảm tổng thời gian chạy kiểm thử nhưng sẽ cần tài nguyên điện toán bổ sung.
Để đặt số lượng phân đoạn bạn muốn sử dụng\trong một lần chạy kiểm thử nhất định, hãy đặt
nội dung sau trong tệp gradle.properties
:
android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>
Khi chạy kiểm thử bằng tuỳ chọn này, Thiết bị do Gradle quản lý cung cấp số lượng phân đoạn mà bạn chỉ định cho mỗi hồ sơ thiết bị trong lần chạy kiểm thử. Ví dụ:
nếu bạn triển khai thử nghiệm cho một nhóm thiết bị gồm ba thiết bị và đặt
numManagedDeviceShards
thành hai, thì Thiết bị do Gradle quản lý sẽ cung cấp
tổng cộng sáu thiết bị ảo cho lần chạy kiểm thử đó.
Khi kiểm thử hoàn tất, Gradle sẽ xuất ra kết quả kiểm thử trong một tệp .proto
cho từng phân đoạn được dùng trong lần chạy kiểm thử.