Эта страница переведена с помощью Cloud Translation API.

Масштабируйте свои тесты с помощью управляемых сборкой устройств.

Устройства, управляемые сборкой, повышают согласованность, производительность и надежность ваших автоматизированных инструментальных тестов. Эта функция, доступная для уровней API 27 и выше, позволяет настраивать виртуальные или удаленные физические тестовые устройства в файлах Gradle вашего проекта. Плагин Android Gradle использует эти конфигурации для полного управления — то есть, создания, развертывания и удаления — этих устройств при выполнении автоматизированных тестов.

Эта функция предоставляет плагину Android Gradle возможность отслеживать не только выполняемые тесты, но и жизненный цикл устройств, что улучшает качество тестирования следующими способами:

Обрабатывает проблемы, связанные с устройством, для обеспечения выполнения ваших тестов.
Для виртуальных устройств используются снимки эмулятора, что позволяет сократить время запуска устройства и уменьшить использование памяти, а также восстановить устройства в чистом состоянии между тестами.
Кэширует результаты тестов и повторно запускает только те тесты, которые, вероятно, дадут другие результаты.
Обеспечивает согласованную среду для запуска тестов как локально, так и удаленно.

Создайте виртуальное устройство, управляемое сборкой.

В файле сборки на уровне модуля вы можете указать виртуальное устройство, которое хотите использовать для тестирования вашего приложения. В следующем примере кода создается устройство Pixel 2 с API уровня 30, управляемое сборкой.

Котлин

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

Классный

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

Определите группы устройств

Чтобы масштабировать тестирование на различных конфигурациях устройств, таких как разные уровни API и форм-факторы, вы можете определить несколько устройств, управляемых сборкой, и добавить их в именованную группу. Затем плагин Android Gradle сможет параллельно выполнять ваши тесты на всех устройствах в группе.

В приведенном ниже примере показаны два устройства, добавленные в группу устройств под названием phoneAndTablet .

Котлин

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

Классный

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

Запустите свои тесты

Чтобы запустить тесты, используя настроенные вами устройства, управляемые сборкой, воспользуйтесь следующей командой. device-name — это имя устройства, настроенного в вашем скрипте сборки Gradle (например, pixel2api30 ), а BuildVariant — это вариант сборки вашего приложения, которое вы хотите протестировать, например, Debug .

Linux и macOS

./gradlew device-nameBuildVariantAndroidTest

Windows

gradlew device-nameBuildVariantAndroidTest

Для запуска тестов на группе устройств, управляемых сборкой, используйте следующую команду.

Linux и macOS

./gradlew group-nameGroupBuildVariantAndroidTest

./gradlew group-nameGroupBuildVariantAndroidTest

Windows

gradlew group-nameGroupBuildVariantAndroidTest

Результаты тестирования включают путь к HTML-файлу, содержащему отчет о тестировании. Вы также можете импортировать результаты тестирования в Android Studio для дальнейшего анализа, нажав «Запуск» > «История тестов» в IDE.

Включить сегментирование тестов

Устройства, управляемые сборкой, поддерживают сегментирование тестов, которое позволяет разделить набор тестов на несколько идентичных экземпляров виртуальных устройств, называемых сегментами , работающих параллельно. Использование сегментирования тестов может помочь сократить общее время выполнения тестов за счет дополнительных вычислительных ресурсов.

Чтобы задать количество шардов, которые вы хотите использовать в конкретном тестовом запуске, укажите следующее в файле gradle.properties :

android.experimental.androidTest.numManagedDeviceShards=<number_of_shards>

При запуске тестов с использованием этой опции управляемые сборкой устройства выделяют указанное вами количество сегментов для каждого профиля устройства в тестовом запуске. Например, если вы развернули тесты на группе из трех устройств и установили numManagedDeviceShards равным двум, управляемые сборкой устройства выделят в общей сложности шесть виртуальных устройств для вашего тестового запуска.

После завершения тестов Gradle выводит результаты тестов в файл .proto для каждого сегмента, использованного в тестовом запуске.

Используйте автоматизированные тестовые устройства.

Устройства, управляемые сборкой, поддерживают тип эмулятора, называемый устройством автоматического тестирования (ATD), который оптимизирован для сокращения ресурсов ЦП и памяти при выполнении инструментальных тестов. ATD улучшают производительность во время выполнения несколькими способами:

Удалите предустановленные приложения, которые обычно не полезны для тестирования вашего приложения.
Отключите некоторые фоновые службы, которые обычно не нужны для тестирования вашего приложения.
Отключить аппаратную отрисовку

Прежде чем начать, убедитесь, что вы обновили эмулятор Android до последней доступной версии. Затем укажите образ "-atd" при определении управляемого сборкой устройства в файле сборки на уровне модуля, как показано ниже:

Котлин

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

Классный

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

Вы также можете создавать группы устройств, как и с другими устройствами, управляемыми сборкой. Для дальнейшего повышения производительности вы можете использовать ATD с сегментированием тестов , чтобы сократить общее время выполнения набора тестов.

Что удаляется с изображений ATD?

Помимо работы в безголовом режиме, ATD также оптимизируют производительность, удаляя или отключая приложения и службы, которые обычно не требуются для тестирования кода вашего приложения. В таблице ниже представлен обзор компонентов, которые мы удалили или отключили в образах ATD, а также описание причин, по которым они могут быть бесполезны.

Что удаляется из изображений ATD?	Почему это может вам не понадобиться при запуске автоматизированных тестов
Приложения продуктов Google: Почта Карты Хром Сообщения Play Store и другие	Ваши автоматизированные тесты должны быть сосредоточены на логике вашего собственного приложения, предполагая при этом, что другие приложения или платформа будут функционировать корректно. С помощью Espresso-Intents вы можете сопоставлять и проверять исходящие интенты или даже предоставлять заглушки вместо фактических ответов на интенты.
Настройки приложений и служб: CarrierConfig Экстренная информация OneTimeInitializer Фотостол (заставки) Обеспечение Приложение «Настройки» StorageManager Настройка APN для телефонии WallpaperCropper WallpaperPicker	Эти приложения предоставляют пользователям графический интерфейс для изменения настроек платформы, настройки устройства или управления хранилищем устройства. Как правило, это выходит за рамки автоматизированного тестирования на уровне приложения. Примечание: Поставщик настроек по-прежнему доступен в образе ATD.

SystemUI	Ваши автоматизированные тесты должны быть сосредоточены на логике вашего собственного приложения, предполагая при этом, что другие приложения или платформа будут функционировать корректно.
Приложения и сервисы AOSP: Browser2 Календарь Камера2 Контакты Дозвонщик Настольные часы Галерея2 ЛатинИМЕ Launcher3QuickStep Музыка QuickSearchBox НастройкиИнтеллект	Эти приложения и сервисы, как правило, выходят за рамки автоматизированных тестов кода вашего приложения.

Используйте устройства Firebase Test Lab.

При использовании устройств, управляемых сборкой, вы можете запускать автоматизированные инструментальные тесты в масштабе на устройствах Firebase Test Lab . Test Lab позволяет одновременно запускать тесты на широком спектре устройств Android, как физических, так и виртуальных. Эти тесты выполняются в удаленных центрах обработки данных Google. Благодаря поддержке устройств, управляемых сборкой, система сборки может полностью управлять запуском тестов на этих устройствах Test Lab в соответствии с вашими конфигурациями.

Начать

Следующие шаги описывают, как начать использовать устройства Firebase Test Lab с устройствами, управляемыми сборкой. В этих шагах для предоставления учетных данных пользователя используется CLI gcloud, который может не подходить для всех сред разработки. Для получения дополнительной информации о том, какой процесс аутентификации использовать в ваших целях, см. раздел «Как работают учетные данные приложения по умолчанию» .

Чтобы создать проект Firebase, перейдите в консоль Firebase . Нажмите «Добавить проект» и следуйте инструкциям на экране, чтобы создать проект. Запомните идентификатор вашего проекта.
Примечание: Включение Google Analytics необязательно и не требуется для использования Firebase Test Lab. Если вы не планируете использовать один из перечисленных сервисов, зависящих от Google Analytics, мы рекомендуем не включать Google Analytics при появлении соответствующего запроса в процессе создания проекта.
Для установки Google Cloud CLI выполните действия, описанные в разделе «Установка gcloud CLI» .
Настройте локальную среду.
1. Создайте ссылку на свой проект Firebase в gcloud:
```
gcloud config set project FIREBASE_PROJECT_ID
```
2. Разрешите использование ваших учетных данных для доступа к API. Мы рекомендуем авторизовать доступ, передав в Gradle JSON-файл с данными учетной записи службы, используя DSL в скрипте сборки на уровне модуля:
  Котлин
  firebaseTestLab { ... serviceAccountCredentials.set(file(SERVICE_ACCOUNT_JSON_FILE)) }
  Классный
  firebaseTestLab { ... serviceAccountCredentials = file(SERVICE_ACCOUNT_JSON_FILE) }
  В качестве альтернативы, вы можете авторизоваться вручную, используя следующую команду в терминале:
```
gcloud auth application-default login
```
3. Необязательно: добавьте свой проект Firebase в качестве проекта с квотой. Этот шаг необходим только в том случае, если вы превысили бесплатную квоту для Test Lab .
```
gcloud auth application-default set-quota-project FIREBASE_PROJECT_ID
```
  Примечание: Чтобы получить доступ к квоте сверх бесплатного порога, ваш проект Firebase должен использовать тарифный план Blaze . Вы можете перейти на тарифный план Blaze в консоли Firebase.
Включите необходимые API.
На странице библиотеки API в консоли разработчиков Google включите API облачного тестирования и API результатов облачных инструментов, введя названия этих API в поле поиска в верхней части консоли, а затем нажав кнопку «Включить API» на странице обзора для каждого API.
Настройте свой Android-проект.
1. Добавьте плагин Firebase Test Lab в основной скрипт сборки:
  Котлин
  plugins { ... id("com.google.firebase.testlab") version "0.0.1-alpha05" apply false }
  Классный
  plugins { ... id 'com.google.firebase.testlab' version '0.0.1-alpha05' apply false }
2. Включите возможность использования пользовательских типов устройств в файле gradle.properties :
```
android.experimental.testOptions.managedDevices.customDevice=true
```
3. Добавьте плагин Firebase Test Lab в скрипт сборки на уровне модуля:
  Котлин
  plugins { ... id "com.google.firebase.testlab" }
  Классный
  plugins { ... id 'com.google.firebase.testlab' }

Укажите устройство для испытательной лаборатории.

В скрипте сборки на уровне модуля вы можете указать устройство Firebase Test Lab для тестирования вашего приложения в Gradle. В следующем примере кода создается устройство Pixel 3 с API уровня 30, управляемое сборкой, под названием ftlDevice . Блок firebaseTestLab {} доступен при применении плагина com.google.firebase.testlab к вашему модулю.

Котлин

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

Классный

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

Чтобы определить группу устройств, управляемых сборкой, включая устройства Firebase Test Lab, см. раздел «Определение групп устройств» .

Для запуска тестов используйте те же команды, что и для запуска других устройств, управляемых сборкой . Обратите внимание, что Gradle не запускает тесты параллельно и не поддерживает другие конфигурации Google Cloud CLI для устройств Test Lab.

Оптимизируйте запуск тестов с помощью интеллектуального сегментирования.

Тестирование на устройствах Test Lab, управляемых сборкой, поддерживает интеллектуальное шардирование. Интеллектуальное шардирование автоматически распределяет ваши тесты по шардам таким образом, чтобы каждый шард выполнялся примерно одинаковое время, сокращая трудозатраты на ручное распределение и общую продолжительность выполнения тестов. Интеллектуальное шардирование использует историю ваших тестов, или информацию о том, сколько времени выполнялись ваши тесты ранее, для оптимального распределения тестов. Обратите внимание, что для использования интеллектуального шардирования в Firebase Test Lab вам потребуется версия 0.0.1-alpha05 плагина Gradle.

Для включения интеллектуального шардирования укажите время, которое должны занимать тесты в каждом шарде. Следует установить целевую продолжительность времени для шарда как минимум на пять минут меньше, чем timeoutMinutes , чтобы избежать ситуации, когда выполнение тестов в шардах отменяется до их завершения.

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

Чтобы узнать больше, ознакомьтесь с информацией о вариантах DSL для устройств в Firebase Test Lab .

Обновленный DSL для устройств тестовой лаборатории

Существует множество дополнительных параметров DSL, которые можно настроить для персонализации тестовых запусков или перехода с других решений, которые вы, возможно, уже используете. Некоторые из этих параметров описаны в следующем фрагменте кода.

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.
       */
      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
  }
}