Halaman ini diterjemahkan oleh Cloud Translation API.

Menskalakan pengujian Anda dengan perangkat yang dikelola Gradle

Perangkat yang dikelola Gradle meningkatkan konsistensi, performa, dan keandalan untuk pengujian berinstrumen otomatis Anda. Fitur ini, yang tersedia untuk level API 27 dan yang lebih tinggi, memungkinkan Anda mengonfigurasi perangkat pengujian fisik virtual atau jarak jauh dalam file Gradle project Anda. Sistem build menggunakan konfigurasi untuk sepenuhnya mengelola—yaitu membuat, men-deploy, dan menghapus—perangkat tersebut saat menjalankan pengujian otomatis.

Fitur ini membuat Gradle dapat melihat tidak hanya pengujian yang Anda jalankan, tetapi juga siklus proses perangkat, sehingga meningkatkan kualitas pengalaman pengujian Anda dengan cara berikut:

Menangani masalah terkait perangkat untuk memastikan pengujian Anda dijalankan
Untuk perangkat virtual, menggunakan snapshot emulator untuk meningkatkan waktu startup perangkat dan penggunaan memori, serta memulihkan perangkat ke kondisi bersih di antara pengujian
Meng-cache hasil pengujian dan hanya menjalankan ulang pengujian yang kemungkinan akan memberikan hasil yang berbeda
Memberikan lingkungan yang konsisten untuk menjalankan pengujian antara pengujian lokal dan jarak jauh

Membuat perangkat virtual yang dikelola Gradle

Anda dapat menentukan perangkat virtual mana yang akan digunakan Gradle untuk menguji aplikasi di file build level modul. Contoh kode berikut membuat Pixel 2 yang menjalankan level API 30 sebagai perangkat yang dikelola 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"
        }
      }
    }
  }
}

Groovy

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"
        }
      }
    }
  }
}

Menentukan grup perangkat

Untuk membantu menskalakan pengujian di beberapa konfigurasi perangkat, seperti level API dan faktor bentuk yang berbeda, Anda dapat menentukan beberapa perangkat yang dikelola Gradle dan menambahkannya ke grup bernama. Gradle kemudian dapat menjalankan pengujian Anda di semua perangkat dalam grup secara paralel.

Contoh di bawah ini menunjukkan dua perangkat yang ditambahkan ke grup perangkat bernama phoneAndTablet.

Kotlin

testOptions {
  managedDevices {
    localDevices {
      create("pixel2api29") { ... }
      create("nexus9api30") { ... }
    }
    groups {
      create("phoneAndTablet") {
        targetDevices.add(devices["pixel2api29"])
        targetDevices.add(devices["nexus9api30"])
      }
    }
  }
}

Groovy

testOptions {
  managedDevices {
    localDevices {
      pixel2api29 { ... }
      nexus9api30 { ... }
    }
    groups {
      phoneAndTablet {
        targetDevices.add(devices.pixel2api29)
        targetDevices.add(devices.nexus9api30)
      }
    }
  }
}

Menjalankan pengujian Anda

Untuk menjalankan pengujian menggunakan perangkat yang dikelola Gradle yang dikonfigurasi, gunakan perintah berikut. device-name adalah nama perangkat yang Anda konfigurasi dalam skrip build Gradle (seperti pixel2api30), dan BuildVariant adalah varian build aplikasi yang ingin Anda uji.

Di Windows:

gradlew device-nameBuildVariantAndroidTest

Di Linux atau macOS:

./gradlew device-nameBuildVariantAndroidTest

Untuk menjalankan pengujian pada grup perangkat yang dikelola Gradle, gunakan perintah berikut.

Di Windows:

gradlew group-nameGroupBuildVariantAndroidTest

Di Linux atau macOS:

./gradlew group-nameGroupBuildVariantAndroidTest

Output pengujian mencakup jalur ke file HTML yang memiliki laporan pengujian. Anda juga dapat mengimpor hasil pengujian ke Android Studio untuk analisis lebih lanjut dengan mengklik Run > Test History di IDE.

Mengaktifkan sharding pengujian

Perangkat yang dikelola Gradle mendukung sharding pengujian, yang memungkinkan Anda membagi rangkaian pengujian di sejumlah instance perangkat virtual yang identik, yang disebut shard, yang berjalan secara paralel. Menggunakan sharding pengujian dapat membantu mengurangi waktu eksekusi uji secara keseluruhan dengan mengorbankan resource komputasi tambahan.

Untuk menetapkan jumlah shard yang ingin Anda gunakan dalam pengujian tertentu, tetapkan hal berikut dalam file gradle.properties Anda:

android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>

Saat menjalankan pengujian menggunakan opsi ini, perangkat yang dikelola Gradle akan menyediakan jumlah shard yang Anda tentukan untuk setiap profil perangkat selama pengujian dijalankan. Jadi, misalnya, jika Anda men-deploy pengujian ke grup perangkat yang terdiri dari tiga perangkat dan menetapkan numManagedDeviceShards ke dua, perangkat yang dikelola Gradle akan menyediakan total enam perangkat virtual untuk menjalankan pengujian.

Setelah pengujian selesai, Gradle akan memberikan hasil pengujian dalam file .proto untuk setiap shard yang digunakan dalam pengujian.

Menggunakan Perangkat Pengujian Otomatis

Perangkat yang dikelola Gradle mendukung jenis perangkat emulator, yang disebut Perangkat Pengujian Otomatis (ATD), yang dioptimalkan untuk mengurangi resource CPU dan memori saat menjalankan pengujian berinstrumen. ATD meningkatkan performa runtime dengan beberapa cara:

Menghapus aplikasi bawaan yang biasanya tidak berguna untuk menguji aplikasi Anda
Menonaktifkan layanan latar belakang tertentu yang biasanya tidak berguna untuk menguji aplikasi Anda
Menonaktifkan rendering hardware

Sebelum memulai, pastikan Anda mengupdate Android Emulator ke versi terbaru yang tersedia. Kemudian, tentukan image "-atd" saat menentukan perangkat yang dikelola Gradle dalam file build level modul, seperti yang ditunjukkan di bawah ini:

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"
        }
      }
    }
  }
}

Groovy

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"
        }
      }
    }
  }
}

Anda juga dapat membuat grup perangkat seperti yang Anda lakukan dengan perangkat yang dikelola Gradle lainnya. Untuk memanfaatkan peningkatan performa lebih lanjut, Anda juga dapat menggunakan ATD dengan sharding pengujian untuk mengurangi total waktu eksekusi uji pada rangkaian pengujian Anda.

Apa yang dihapus dari image ATD?

Selain beroperasi dalam mode headless, ATD juga mengoptimalkan performa dengan menghapus atau menonaktifkan aplikasi dan layanan yang biasanya tidak diperlukan untuk menguji kode aplikasi Anda. Tabel di bawah memberikan ringkasan komponen yang telah kami hapus atau nonaktifkan dalam image ATD dan deskripsi alasan mengapa komponen tersebut mungkin tidak berguna.

Yang dihapus di image ATD	Alasan mengapa Anda mungkin tidak memerlukannya saat menjalankan pengujian otomatis
Aplikasi produk Google: Email Maps Chrome Messages Play Store, dan lainnya	Pengujian otomatis harus berfokus pada logika aplikasi Anda sendiri sambil mengasumsikan bahwa aplikasi atau platform lain akan berfungsi dengan benar. Dengan Intent Espresso, Anda dapat mencocokkan dan memvalidasi intent keluar Anda atau bahkan memberikan respons stub sebagai pengganti respons intent yang sebenarnya.
Aplikasi dan layanan setelan: CarrierConfig EmergencyInfo OneTimeInitializer PhotoTable (screensaver) Provision Aplikasi Setelan StorageManager Konfigurasi APN Telepon WallpaperCropper WallpaperPicker	Aplikasi ini menyediakan GUI bagi pengguna akhir untuk mengubah setelan platform, menyiapkan perangkat, atau mengelola penyimpanan perangkat. Ini biasanya berada di luar cakupan pengujian otomatis tingkat aplikasi. Catatan: Penyedia setelan masih tersedia di image ATD.

SystemUI	Pengujian otomatis harus berfokus pada logika aplikasi Anda sendiri sambil mengasumsikan bahwa aplikasi atau platform lain akan berfungsi dengan benar.
Aplikasi dan layanan AOSP: Browser2 Kalender Camera2 Kontak Telepon DeskClock Galeri2 LatinIME Launcher3QuickStep Musik QuickSearchBox SettingsIntelligence	Aplikasi dan layanan ini biasanya berada di luar cakupan pengujian otomatis untuk kode aplikasi Anda.

Menggunakan perangkat Firebase Test Lab

Anda dapat menjalankan pengujian berinstrumen otomatis dalam skala besar di perangkat Firebase Test Lab saat menggunakan perangkat yang dikelola Gradle. Dengan Test Lab, Anda dapat menjalankan pengujian secara bersamaan di berbagai perangkat Android, baik fisik maupun virtual. Pengujian ini berjalan di pusat data Google jarak jauh. Dengan dukungan dari perangkat yang dikelola Gradle, sistem build dapat sepenuhnya mengelola pengujian yang berjalan di perangkat Test Lab ini berdasarkan konfigurasi Anda.

Memulai

Langkah-langkah berikut menjelaskan cara mulai menggunakan perangkat Firebase Test Lab dengan perangkat yang dikelola Gradle. Perhatikan bahwa langkah-langkah ini menggunakan gcloud CLI untuk memberikan kredensial pengguna, yang mungkin tidak berlaku untuk semua lingkungan pengembangan. Untuk informasi selengkapnya tentang proses autentikasi yang digunakan sesuai kebutuhan Anda, lihat Cara kerja Kredensial Default Aplikasi.

Untuk membuat project Firebase, buka Firebase console. Klik Add project dan ikuti petunjuk di layar untuk membuat project. Ingat project ID Anda.

Catatan: Mengaktifkan Google Analytics bersifat opsional, dan tidak diperlukan untuk menggunakan Firebase Test Lab. Kecuali Anda berencana menggunakan salah satu layanan tercantum yang bergantung pada Google Analytics, sebaiknya jangan aktifkan Google Analytics saat diminta dalam alur kerja pembuatan project.
Untuk menginstal Google Cloud CLI, ikuti langkah-langkah di bagian Menginstal gcloud CLI.
Konfigurasi lingkungan lokal Anda.
1. Tautkan ke project Firebase Anda di gcloud:
```
gcloud config set project FIREBASE_PROJECT_ID
```
2. Izinkan penggunaan kredensial pengguna untuk akses API. Sebaiknya beri otorisasi dengan meneruskan file JSON akun layanan ke Gradle menggunakan DSL dalam skrip build level modul:
  Kotlin
  
  firebaseTestLab { ... serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE)) }
  Groovy
  
  firebaseTestLab { ... serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE) }
  Atau, Anda dapat memberi otorisasi secara manual dengan menggunakan perintah terminal berikut:
```
gcloud auth application-default login
```
3. Opsional: Tambahkan project Firebase Anda sebagai project kuota. Langkah ini hanya diperlukan jika Anda melebihi kuota tanpa biaya untuk Test Lab.
```
gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
```
  Catatan: Untuk mengakses kuota di luar nilai minimum tanpa biaya, project Firebase Anda harus berada di Paket harga Blaze. Anda dapat mengupgrade ke paket harga Blaze di Firebase console.
Aktifkan API yang diperlukan.

Di halaman Library API Konsol Developer Google, aktifkan Cloud Testing API dan Cloud Tool Results API dengan mengetik nama API ini ke kotak penelusuran di bagian atas konsol, lalu mengklik Enable API pada halaman ringkasan untuk setiap API.

Konfigurasi project Android Anda.

Tambahkan plugin Firebase Test Lab di skrip build level atas:

Kotlin

plugins {
  ...
  id("com.google.firebase.testlab") version "0.0.1-alpha05" apply false
}

Groovy

plugins {
  ...
  id 'com.google.firebase.testlab' version '0.0.1-alpha05' apply false
}

Aktifkan jenis perangkat kustom di file gradle.properties:

android.experimental.testOptions.managedDevices.customDevice=true

Tambahkan plugin Firebase Test Lab dalam skrip build level modul:

Kotlin

plugins {
 ...
 id "com.google.firebase.testlab"
}

Groovy

plugins {
 ...
 id 'com.google.firebase.testlab'
}

Menentukan perangkat Test Lab

Anda dapat menentukan perangkat Firebase Test Lab untuk Gradle yang akan digunakan untuk menguji aplikasi dalam skrip build level modul. Contoh kode berikut membuat Pixel 3 yang menjalankan level API 30 sebagai perangkat Test Lab yang dikelola Gradle dan disebut ftlDevice. Blok firebaseTestLab {} tersedia saat Anda menerapkan plugin com.google.firebase.testlab ke modul.

Kotlin

firebaseTestLab {
  managedDevices {
    create("ftlDevice") {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

Groovy

firebaseTestLab {
  managedDevices {
    ftlDevice {
      device = "Pixel3"
      apiLevel = 30
    }
  }
  ...
}

Untuk menentukan grup perangkat yang dikelola Gradle termasuk perangkat Firebase Test Lab, lihat Menentukan grup perangkat.

Untuk menjalankan pengujian, gunakan perintah yang sama dengan yang digunakan untuk menjalankan perangkat lain yang dikelola Gradle. Perhatikan bahwa Gradle tidak menjalankan pengujian secara paralel atau mendukung konfigurasi Google Cloud CLI lainnya untuk perangkat Test Lab.

Mengoptimalkan pengujian dengan sharding cerdas

Pengujian pada perangkat Test Lab yang dikelola Gradle mendukung sharding cerdas. Sharding cerdas mendistribusikan pengujian Anda ke seluruh shard secara otomatis sehingga setiap shard berjalan kurang lebih dalam waktu yang sama. Dengan begitu, upaya alokasi manual dan durasi pengujian secara keseluruhan dapat dikurangi. Sharding cerdas menggunakan histori pengujian Anda, atau informasi tentang berapa lama pengujian Anda telah berjalan sebelumnya, untuk mendistribusikan pengujian secara optimal. Perhatikan bahwa Anda memerlukan plugin Gradle versi 0.0.1-alpha05 agar Firebase Test Lab dapat menggunakan sharding cerdas.

Untuk mengaktifkan sharding cerdas, tentukan jumlah waktu yang diperlukan pengujian dalam setiap shard. Anda harus menetapkan durasi waktu shard target menjadi setidaknya lima menit lebih cepat dari timeoutMinutes untuk menghindari situasi ketika shard dibatalkan sebelum pengujian dapat selesai.

firebaseTestLab {
  ...
  testOptions {
    targetedShardDurationMinutes = 2
  }
}

Untuk mempelajari lebih lanjut, baca opsi DSL perangkat Firebase Test Lab.

DSL yang diperbarui untuk perangkat Test Lab

Ada lebih banyak opsi DSL yang dapat Anda konfigurasi untuk membantu menyesuaikan pengujian yang dijalankan atau bermigrasi dari solusi lain yang mungkin sudah Anda gunakan. Lihat beberapa opsi ini seperti yang dijelaskan dalam cuplikan kode berikut.

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
  }
}