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

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

Архитектура

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

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

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

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

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

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

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

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

Для последующего использования при перепрошивке устройств ресурсы включают поставщиков сборок для обоих вариантов, основанных на одном 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 в локальный каталог.

Flash-сборки

После загрузки последних образов устройств на хост эти образы необходимо записать на устройства. Это делается с помощью стандартных команд 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 .