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

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

Архитектура

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

Automated test architecture

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Получение URL

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

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

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

Учитывая каталог со списком (или 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 кластера (необязательно соединенный с МТТ), используйте lease команду в консоли хост - контроллера, который выглядит для невыполненных тестовых прогонов.

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

Отчетность о результатах

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