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

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

Архитектура

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

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

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

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

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

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

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

• Партнерская программа Android Build . Программный доступ предоставляется на основе учетной записи.
• Локальная файловая система (или аналогичная). Для партнеров, которые не используют 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-адрес, размещенный на PAB (который защищен аутентификацией и доступен с помощью соответствующих учетных данных OAuth2).
• Для других ресурсов используется длинный незащищенный URL-адрес из внутреннего API сборки Android (срок действия которого истекает через пять минут).

Получить URL

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