Инфраструктура автоматизированного тестирования

Android 9 включает инфраструктуру Vendor Test Suite (VTS) для автоматизированного тестирования VTS, CTS или других тестов на партнерских устройствах, на которых запущен общий образ системы AOSP (GSI). Раньше выполнение этих тестов было очень ручной операцией; новая тестовая инфраструктура VTS предназначена для поддержки автоматизированного тестирования несколько раз в день на нескольких устройствах.

Архитектура

Инфраструктура автоматизированного тестирования VTS использует следующую архитектуру:

При запуске теста инфраструктура автоматизированного тестирования VTS выполняет следующие задачи:

1. Извлекает артефакты сборки и тестирует ресурсы из разных мест:
   • Партнерская сборка Android (PAB) . Для GSI, VTS framework и некоторых других сборок.
   • Локальная файловая система, Google Cloud Storage или другая система сборки конкретного поставщика . Для партнеров, которые не хранят сборки в облаке Google.
2. Вспышки создают артефакты (от устройства) и GSI (от AOSP) на подключенном(ых) устройстве(ах).
3. Запускает тесты VTS с использованием локального TradeFed или TradeFed в облаке.
4. Сообщает о результатах тестирования на приборную панель VTS.

Процесс координируется хост-контроллером VTS (HC), компьютером в лаборатории, который управляет поведением всех тестируемых подключенных устройств. HC отвечает за получение последних сборок, их прошивку на устройствах и запуск тестов (локально или через командующего). Он также взаимодействует с облачным планировщиком и направляет трафик между планировщиком и экземпляром TradeFed (или каким-либо другим механизмом), работающим на HC. Дополнительные сведения о хост-контроллере см. в разделе Архитектура хост-контроллера .

Поставщики ресурсов

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

Партнеры могут получить доступ к ресурсам автоматизации, используя следующие места:

• Партнерская сборка Android . Программный доступ предоставляется для каждой учетной записи.
• Локальная файловая система (или аналогичная). Для партнеров, которые не используют Partner Android Build.

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

Партнерская сборка Android

В Android 8.1 и более ранних версиях партнеры Android должны были посетить веб-сайт Partner Android Build ( https://partner.android.com/build ), перейти в свою учетную запись и получить последние образы системы через пользовательский интерфейс. Чтобы помочь партнерам избежать этого медленного и трудоемкого процесса, в Android 9 реализована поддержка автоматической загрузки этих ресурсов из PAB при предоставлении соответствующих учетных данных.

Установление доступа

Программный доступ использует OAuth2 в API Google для доступа к необходимым RPC. Используя стандартный подход для создания учетных данных OAuth2, партнер должен настроить пару идентификатор клиента/секрет в Google. Когда PartnerAndroidBuildClient впервые указывает на этот секрет, он открывает окно браузера, чтобы пользователь мог войти в свою учетную запись Google, что создает учетные данные OAuth2, необходимые для продвижения вперед. Учетные данные (токен доступа и токен обновления) хранятся локально, поэтому партнерам нужно будет войти в систему только один раз.

POST-запрос для URL

Щелчок по ссылке ресурса в PAB отправляет запрос POST, который включает необходимые данные для этого ресурса, в том числе:

• идентификатор сборки, цель сборки
• имя ресурса
• ответвляться
• имя кандидата на выпуск и является ли кандидат внутренней сборкой

Запрос POST принимается методом downloadBuildArtifact RPC buildsvc , который возвращает URL-адрес, который можно использовать для доступа к ресурсу.

• Для ресурсов APK Clockwork Companion URL-адрес — это читаемый URL-адрес, размещенный в PAB (который защищен аутентификацией и доступен с соответствующими учетными данными OAuth2).
• Для других ресурсов URL-адрес представляет собой длинный незащищенный URL-адрес из внутреннего API сборки Android (срок действия которого истекает через пять минут).

Получение URL

Чтобы избежать подделки межсайтовых запросов, RPC buildsvc требует, чтобы токен XSRF был отправлен методом POST с другими параметрами. Хотя этот токен делает процесс более безопасным, он также значительно усложняет программный доступ, поскольку токен (который доступен только в JavaScript на странице PAB) теперь также требуется для доступа.

Чтобы избежать этой проблемы, в Android 9 изменена схема именования URL-адресов для всех файлов (а не только APK), чтобы использовать предсказуемые имена URL-адресов для доступа к спискам артефактов и URL-адресам артефактов. PAB теперь использует удобный формат URL, который позволяет партнерам загружать ресурсы; Сценарии HC могут легко загружать эти APK, поскольку формат URL-адреса известен, а HC может обойти проблемы с XSRF/cookie, поскольку ему не нужен RPC buildsvc .

Локальная файловая система

При наличии каталога со списком (или zip-файлом) артефактов поставщик сборки устанавливает соответствующие изображения в зависимости от того, что находится в каталоге. Вы можете использовать инструмент gsutil для копирования файлов из Google Cloud Storage в локальный каталог.

Мигающие сборки

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

Поддерживаемые действия:

• Прошивка только GSI
• Прошивка отдельных образов из основной системы (например, fastboot flash boot boot.img )
• Прошивка всех образов из основной системы. Пример:
  • fastboot flashall (с помощью встроенной утилиты flashall )
  • fastboot flash (по одному)

Запуск тестов

В Android 9 инфраструктура автоматизированного тестирования VTS поддерживает только тестовую систему TradeFed, но в будущем ее можно будет расширить для поддержки других систем.

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

• При локальном использовании TradeFed используйте команду test в хост-контроллере, которая берет имя плана тестирования VTS (например vts-selftest ) и запускает тест.
• При использовании кластера TradeFed (опционально подключенного к MTT) используйте команду lease в консоли хост-контроллера, которая ищет невыполненные тестовые прогоны.

При использовании TradeFedCluster TradeFed запускается локально как удаленный менеджер . Если нет, тесты вызываются с помощью подпроцессов Python.

Результаты отчетности

Результаты тестирования автоматически передаются в некоторые проекты панели VTS с помощью VtsMultiDeviceTest .