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

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

Архитектура

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

Рисунок 1. Архитектура инфраструктуры автоматизированного тестирования VTS

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

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

Процесс координируется хост-контроллером VTS (HC), машиной в лаборатории, которая управляет поведением всех подключенных тестируемых устройств. HC отвечает за получение последних сборок, их прошивку на устройства и вызов тестов (локально или через Commander). Он также взаимодействует с облачным планировщиком и направляет трафик между планировщиком и экземпляром 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-адрес

Чтобы избежать подделки межсайтовых запросов, buildsvc RPC требует, чтобы токен XSRF был отправлен с другими параметрами. Хотя этот токен делает процесс более безопасным, он также значительно затрудняет программный доступ, поскольку токен (который доступен только в 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 .