Urządzenia zarządzane przez Gradle zwiększają spójność, wydajność i niezawodność zautomatyzowanych testów instrumentowanych. Ta funkcja jest dostępna w interfejsach API na poziomach 27 i pozwala skonfigurować wirtualne lub zdalne fizyczne urządzenia testowe plików Gradle projektu. System kompilacji używa konfiguracji, aby w pełni (czyli tworzyć, wdrażać i demontować) te urządzenia podczas wykonywania testów automatycznych.
Ta funkcja zapewnia Gradle widoczność nie tylko w prowadzonych testach, ale także cykl życia urządzeń, co poprawia jakość proces testowania w następujący sposób:
- Rozwiązuje problemy związane z urządzeniem, aby mieć pewność, że testy zostaną wykonane.
- W przypadku urządzeń wirtualnych używa zrzutów emulatora, aby skrócić czas uruchamiania urządzenia wykorzystanie pamięci i przywrócenie czystego stanu urządzeń między kolejnymi testami.
- Wyniki testów są zapisywane w pamięci podręcznej i ponownie uruchamiają tylko te testy, które przypuszczalnie okażą się inne wyniki
- Zapewnia spójne środowisko do przeprowadzania testów między lokalnymi a lokalnymi zdalne uruchomienia testów
Tworzenie wirtualnego urządzenia zarządzanego przez Gradle
Możesz określić urządzenie wirtualne, którego Gradle ma używać do testowania w pliku kompilacji na poziomie modułu. Ten przykładowy kod pozwala utworzyć Pixela 2 z uruchomionym interfejsem API poziomu 30 jako urządzeniem zarządzanym przez Gradle.
Kotlin
android {
testOptions {
managedDevices {
localDevices {
create("pixel2api30") {
// 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"
}
}
}
}
}
Odlotowe
android {
testOptions {
managedDevices {
localDevices {
pixel2api30 {
// 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"
}
}
}
}
}
Zdefiniuj grupy urządzeń
Aby ułatwić skalowanie testów na różnych konfiguracjach urządzeń, takich jak różnych poziomów interfejsu API i formatów, możesz zdefiniować wiele zarządzanych urządzenia i dodaj je do nazwanej grupy. Gradle może następnie uruchamiać testy na na wszystkich urządzeniach w grupie.
Przykład poniżej przedstawia 2 urządzenia dodane do grupy urządzeń o nazwie
phoneAndTablet
Kotlin
testOptions {
managedDevices {
localDevices {
create("pixel2api29") { ... }
create("nexus9api30") { ... }
}
groups {
create("phoneAndTablet") {
targetDevices.add(devices["pixel2api29"])
targetDevices.add(devices["nexus9api30"])
}
}
}
}
Odlotowe
testOptions {
managedDevices {
localDevices {
pixel2api29 { ... }
nexus9api30 { ... }
}
groups {
phoneAndTablet {
targetDevices.add(devices.pixel2api29)
targetDevices.add(devices.nexus9api30)
}
}
}
}
Przeprowadzanie testów
Aby przeprowadzić testy na skonfigurowanych urządzeniach zarządzanych przez Gradle, użyj
tego polecenia. device-name to nazwa urządzenia skonfigurowanego przez Ciebie
skrypt kompilacji Gradle (np. pixel2api30), a BuildVariant jest
wariant kompilacji, który chcesz przetestować.
Windows:
gradlew device-nameBuildVariantAndroidTest
W systemie Linux lub macOS:
./gradlew device-nameBuildVariantAndroidTest
Aby przeprowadzić testy na grupie urządzeń zarządzanych przez Gradle, użyj tych poleceń.
Windows:
gradlew group-nameGroupBuildVariantAndroidTest
W systemie Linux lub macOS:
./gradlew group-nameGroupBuildVariantAndroidTest
Dane wyjściowe testu zawierają ścieżkę do pliku HTML, który zawiera raport z testu. Ty mogą też zaimportować wyniki testów do Android Studio, aby dokładniej przeanalizować klikając Uruchom > Historia testów w IDE.
Włącz fragmentację testową
Urządzenia zarządzane przez Gradle obsługują fragmentację testową, która umożliwia dzielenie testu w kilku identycznych instancjach urządzeń wirtualnych, nazywanych fragmentami, które działają równolegle. Fragmentowanie testów może pomóc ograniczyć ogólne wykonywanie testów kosztem dodatkowych zasobów obliczeniowych.
Aby ustawić liczbę fragmentów, których chcesz użyć w danym teście, ustaw parametr
następujące elementy w pliku gradle.properties:
android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>
W przypadku przeprowadzania testów z użyciem tej opcji urządzenia zarządzane przez Gradle udostępniają
liczba fragmentów określona dla każdego profilu urządzenia podczas testu. Dlatego w przypadku
np. jeśli wdrożysz testy na grupie 3 urządzeń i ustawisz
Od numManagedDeviceShards do 2, urządzenia zarządzane przez Gradle udostępnią łącznie
6 urządzeń wirtualnych do testów.
Po zakończeniu testów Gradle wyświetla ich wyniki w pliku .proto
dla każdego fragmentu użytego w uruchomieniu testowym.
Używanie zautomatyzowanych urządzeń testowych
Urządzenia zarządzane przez Gradle obsługują typ emulatora o nazwie Urządzenie testowe (ATD), które jest zoptymalizowane w celu zmniejszenia zasobów procesora i pamięci, przeprowadzanie testów instrumentalnych. Rozszerzenia ATD na kilka sposobów poprawiają wydajność środowiska wykonawczego:
- Usuń wstępnie zainstalowane aplikacje, które zwykle nie są przydatne do testowania aplikacji
- Wyłącz usługi w tle, które zwykle nie są przydatne testowanie aplikacji
- Wyłącz renderowanie sprzętowe
Zanim zaczniesz, zaktualizuj emulator Androida do najnowszej wersji. dostępnej wersji. Następnie wpisz „-atd”. obrazu podczas definiowania konta zarządzanego przez Gradle w pliku kompilacji na poziomie modułu, jak pokazano poniżej:
Kotlin
android {
testOptions {
managedDevices {
localDevices {
create("pixel2api30") {
// 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"
}
}
}
}
}
Odlotowe
android {
testOptions {
managedDevices {
localDevices {
pixel2api30 {
// 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"
}
}
}
}
}
Możesz też tworzyć grupy urządzeń tak samo jak inne Urządzenia zarządzane przez Gradle. Aby jeszcze bardziej wykorzystać ulepszenia wydajności, można też użyć elementów ATD z fragmentacją testową, aby zmniejszyć łączną liczbę testów i czasu wykonywania zestawu testów.
Co jest usuwane z obrazów ATD?
Oprócz działania w trybie bez interfejsu graficznego komponenty ATD optymalizują wydajność przez usunięcie lub wyłączenie aplikacji i usług, które zwykle nie są wymagane do testowania kodu aplikacji. W tabeli poniżej znajdziesz omówienie komponentów usunęliśmy lub wyłączyliśmy na obrazach ATD i ich opisach, może być przydatna.
| Co jest usuwane z obrazów ATD | Dlaczego przy przeprowadzaniu testów zautomatyzowanych może to nie być potrzebne |
|---|---|
Aplikacje produktów Google:
|
Testy automatyczne powinny koncentrować się na logice Twojej aplikacji przy założeniu,
że inne aplikacje lub platforma będą działać poprawnie.
Dzięki Espresso-Intents możesz dopasować i zweryfikować swoje intencje, a nawet dostarczyć fragment zamiast rzeczywistych intencji. |
Ustawienia aplikacji i usług:
|
Te aplikacje zawierają GUI, które umożliwia użytkownikom zmianę platformy
ustawieniami, skonfigurować urządzenie lub zarządzać pamięcią urządzenia. Zwykle jest to
poza zakresem automatycznych testów na poziomie aplikacji.
|
| SystemUI | Testy automatyczne powinny koncentrować się na logice Twojej aplikacji przy założeniu, że inne aplikacje lub platforma będą działać poprawnie. |
Aplikacje i usługi AOSP:
|
Takie aplikacje i usługi zwykle nie są objęte automatyzacją do testowania kodu aplikacji. |
Używanie urządzeń Laboratorium Firebase
Test Firebase umożliwia przeprowadzanie na dużą skalę automatycznych testów instrumentowanych Lab urządzenia podczas używania Urządzenia zarządzane przez Gradle. Laboratorium pozwala przeprowadzać testy jednocześnie na z szeroką gamą urządzeń z Androidem – fizycznych i wirtualnych. Te testy są przeprowadzane w zdalnych centrach danych Google. Dzięki obsłudze urządzeń zarządzanych przez Gradle system może w pełni zarządzać testami przeprowadzanymi na tych urządzeniach w laboratorium na podstawie konfiguracji.
Rozpocznij
Poniższe kroki opisują, jak zacząć korzystać z urządzeń z Laboratorium Firebase z Urządzenia zarządzane przez Gradle. Pamiętaj, że w tych krokach korzystasz z interfejsu wiersza poleceń gcloud danych logowania, co może nie mieć zastosowania we wszystkich środowiskach programistycznych. Więcej na temat tego, którego procesu uwierzytelniania należy użyć do swoich potrzeb, można znaleźć w artykule Jak Domyślne dane uwierzytelniające aplikacji Google Cloud.
Aby utworzyć projekt Firebase, otwórz Konsola Firebase. Kliknij Dodaj projekt i postępuj zgodnie z instrukcjami wyświetlanymi na ekranie, aby utworzyć projekt. Zapamiętaj identyfikator projektu.
Aby zainstalować interfejs wiersza poleceń Google Cloud, wykonaj czynności opisane na stronie Zainstaluj interfejs wiersza poleceń gcloud.
Skonfiguruj środowisko lokalne.
Połącz z projektem Firebase w gcloud:
gcloud config set project FIREBASE_PROJECT_ID
Autoryzuj użycie danych logowania użytkownika w celu uzyskiwania dostępu do interfejsu API. Zalecamy autoryzując, przekazując pliku JSON konta usługi do Gradle za pomocą DSL w skrypcie kompilacji na poziomie modułu:
Kotlin
firebaseTestLab { ... serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE)) }Odlotowe
firebaseTestLab { ... serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE) }Możesz też autoryzować ręcznie, używając poniższego terminala polecenie:
gcloud auth application-default login
Opcjonalnie: dodaj projekt Firebase jako projekt z limitami. Ten krok jest jest wymagane tylko wtedy, gdy przekroczysz bezpłatny limit w Laboratorium.
gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
Włącz wymagane interfejsy API.
W stronę z biblioteką interfejsów API w Google Developers Console, włączyć Cloud Testing API, oraz Cloud Tool Score API wpisując te nazwy interfejsów API w polu wyszukiwania u góry konsoli i klikając Włącz API na stronie przeglądu każdego interfejsu API.
Skonfiguruj projekt na Androida.
Dodaj wtyczkę Laboratorium Firebase do skryptu kompilacji najwyższego poziomu:
Kotlin
plugins { ... id("com.google.firebase.testlab") version "0.0.1-alpha05" apply false }Odlotowe
plugins { ... id 'com.google.firebase.testlab' version '0.0.1-alpha05' apply false }Włącz niestandardowe typy urządzeń w pliku
gradle.properties:android.experimental.testOptions.managedDevices.customDevice=true
Dodaj wtyczkę Laboratorium Firebase do skryptu kompilacji na poziomie modułu:
Kotlin
plugins { ... id "com.google.firebase.testlab" }Odlotowe
plugins { ... id 'com.google.firebase.testlab' }
Wskaż urządzenie Laboratorium
Możesz wskazać urządzenie z Laboratorium Firebase dla Gradle, aby wykorzystać je do testowania
w skrypcie kompilacji na poziomie modułu. Następujący przykładowy kod tworzy
Pixel 3 z interfejsem API poziomu 30 jako urządzenie zarządzane przez Gradle w laboratorium o nazwie
ftlDevice Blok firebaseTestLab {} jest dostępny po zastosowaniu
com.google.firebase.testlab.
Kotlin
firebaseTestLab {
managedDevices {
create("ftlDevice") {
device = "Pixel3"
apiLevel = 30
}
}
...
}
Odlotowe
firebaseTestLab {
managedDevices {
ftlDevice {
device = "Pixel3"
apiLevel = 30
}
}
...
}
Aby zdefiniować grupę urządzeń zarządzanych przez Gradle, w tym urządzenia z Laboratorium Firebase, Więcej informacji znajdziesz w artykule Definiowanie grup urządzeń.
Aby uruchomić testy, użyj tych samych poleceń co w przypadku innych zarządzanych aplikacji zarządzanych przez Gradle urządzenia. Pamiętaj, że Gradle nie uruchamia testów równolegle ani nie obsługuje inne konfiguracje Google Cloud CLI dla urządzeń Laboratorium.
Optymalizuj uruchomienia testowe dzięki inteligentnemu fragmentacji
Testowanie na urządzeniach z laboratorium testowym zarządzanym przez Gradle obsługuje inteligentne fragmentowanie. Inteligentny fragmentacja automatycznie rozdziela testy na fragmenty, tak aby każdy z nich trwa mniej więcej ten sam czas, co ogranicza ręczne zarządzanie i ogólny czas trwania testu. Inteligentne fragmentowanie korzysta z Twojej historii testów lub informacji ile czasu wcześniej zajmowały testy, i rozpowszechniać je w w optymalny sposób. Pamiętaj, że potrzebujesz wersji 0.0.1-alfa05 wtyczki do Gradle dla Laboratorium Firebase, aby korzystać z inteligentnego fragmentacji.
Aby włączyć inteligentne fragmentowanie, określ ilość czasu na testy w każdym fragmencie
co powinien zrobić. Ustaw czas trwania fragmentu na co najmniej 5
min mniej niż timeoutMinutes, aby uniknąć sytuacji, w której fragmenty są
anulowano przed zakończeniem testów.
firebaseTestLab {
...
testOptions {
targetedShardDurationMinutes = 2
}
}
Aby dowiedzieć się więcej, przeczytaj o Opcje DSL urządzenia Laboratorium Firebase.
Aktualizacja DSL dla urządzeń Laboratorium
Istnieje więcej opcji DSL, które możesz skonfigurować, aby dostosować uruchomienia testowe lub przeprowadzić migrację z innych rozwiązań, których być może już używasz. Zobacz niektóre z tych opcji jak opisano w tym fragmencie kodu.
firebaseTestLab {
...
/**
* A path to a JSON file that contains service account credentials to access to
* a Firebase Test Lab project.
*/
serviceAccountCredentials.set(file("your_service_account_credentials.json"))
testOptions {
fixture {
/**
* Whether to grant permissions on the device before tests begin.
* Available options are "all" or "none".
*
* Default value is "all".
*/
grantedPermissions = "all"
/**
* Map of files to push to the device before starting the test.
*
* The key is the location on the device.
* The value is the location of the file, either local or in Google Cloud.
*/
extraDeviceFiles["/sdcard/dir1/file1.txt"] = "local/file.txt"
extraDeviceFiles["/sdcard/dir2/file2.txt"] = "gs://bucket/file.jpg"
/**
* The name of the network traffic profile.
*
* Specifies network conditions to emulate when running tests.
*
* Default value is empty.
*/
networkProfile = "LTE"
}
execution {
/**
* The maximum time to run the test execution before cancellation,
* measured in minutes. Does not include the setup or teardown of device,
* and is handled server-side.
*
* The maximum possible testing time is 45 minutes on physical devices
* and 60 minutes on virtual devices.
*
* Defaults to 15 minutes.
*/
timeoutMinutes = 30
/**
* Number of times the test should be rerun if tests fail.
* The number of times a test execution should be retried if one
* or more of its test cases fail.
*
* The max number of times is 10.
*
* The default number of times is 0.
*/
maxTestReruns = 2
/**
* Ensures only a single attempt is made for each execution if
* an infrastructure issue occurs. This doesn't affect `maxTestReruns`.
* Normally, two or more attempts are made by Firebase Test Lab if a
* potential infrastructure issue is detected. This is best enabled for
* latency sensitive workloads. The number of execution failures might be
* significantly greater with `failFast` enabled.
*
* Defaults to false.
*/
failFast = false
/**
* The number of shards to split the tests across.
*
* Default to 0 for no sharding.
*/
numUniformShards = 20
}
/**
* For smart sharding, the target length of time each shard should takes in
* minutes. Maxes out at 50 shards for physical devices and 100 shards for
* virtual devices.
*
* Only one of numUniformShards or targetedShardDurationMinutes can be set.
*
* Defaults to 0 for no smart sharding.
*/
targetedShardDurationMinutes = 15
}
results {
/**
* The name of the Google storage bucket to store the test results in.
*
* If left unspecified, the default bucket is used.
*
* Please refer to Firebase Test Lab permissions for required permissions
* for using the bucket.
*/
cloudStorageBucket = "bucketLocationName"
/**
* Name of test results for the Firebase console history list.
* All tests results with the same history name are grouped
* together in the Firebase console in a time-ordered test history list.
*
* Defaults to the application label in the APK manifest in Flank/Fladle.
*/
resultsHistoryName = "application-history"
/**
* List of paths to copy from the test device's storage to the test
* results folder. These must be absolute paths under /sdcard or
* /data/local/tmp.
*/
directoriesToPull.addAll(
"/sdcard/path/to/something"
)
/**
* Whether to enable video recording during the test.
*
* Disabled by default.
*/
recordVideo = false
/**
* Whether to enable performance metrics. If enabled, monitors and records
* performance metrics such as CPU, memory, and network usage.
*
* Defaults to false.
*/
performanceMetrics = true
}
}