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

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

Архитектура

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

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

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

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

Получить URL-адрес

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

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

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

Получив каталог со списком (или zip-файлом) артефактов, поставщик сборки подбирает соответствующие образы на основе содержимого каталога. Для копирования файлов из Google Cloud Storage в локальный каталог можно использовать инструмент gsutil .

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 .