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

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

Архитектура

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

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

1. Получает артефакты сборки и ресурсы для тестирования из разных местоположений:
   • Сборка Android для партнеров (PAB). Для GSI, VTS и некоторых других сборок.
   • Локальная файловая система, Google Cloud Storage или другая система сборки, зависящая от поставщика. Для партнеров, которые не хранят сборки в облаке Google.
2. Записывает на подключенные устройства артефакты сборки (с устройства) и образ GSI (из AOSP).
3. Запускает тесты VTS с помощью локальной или облачной версии 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 при наличии соответствующих учетных данных.

Настройка доступа

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

Запрос POST для URL

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

• идентификатор сборки, назначение сборки;
• название ресурса;
• ветка
• название релиз-кандидата и является ли он внутренней сборкой;

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

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

Как получить URL

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