Infrastructure de test automatisée

Android 9 inclut une infrastructure de suite de tests du fournisseur (VTS) pour les tests automatisés de VTS, CTS ou d'autres tests sur les appareils partenaires exécutant l'image système générique (GSI) AOSP. Auparavant, ces les tests étaient une opération hautement manuelle ; la nouvelle infrastructure de test VTS conçu pour effectuer des tests automatisés plusieurs fois par jour sur plusieurs appareils.

Architecture

L'infrastructure de tests automatisés de VTS utilise l'architecture suivante:

Architecture de test automatisé

Figure 1. Architecture de l'infrastructure de test automatisée VTS

Lorsqu'un test est déclenché, l'infrastructure de test automatisé VTS effectue les tâches suivantes:

  1. Récupère les artefacts de compilation et les ressources de test à partir de différents emplacements :
    • Partner Android Build (PAB) Pour le GSI, le framework VTS et certains autres builds.
    • Système de fichiers local, Google Cloud Storage ou autre système spécifique au fournisseur système de compilation. Pour les partenaires qui ne stockent pas de builds dans le cloud.
  2. Flashe les artefacts de compilation (à partir de l'appareil) et le GSI (à partir d'AOSP) sur l'un ou les appareils connectés.
  3. Exécute des tests VTS à l'aide de TradeFed local ou d'un TradeFed dans le cloud.
  4. Enregistre les résultats des tests dans le tableau de bord VTS

Le processus est coordonné par le contrôleur hôte (HC) VTS, une machine du laboratoire qui dirige le comportement de tous les appareils connectés en cours de test. Le centre d'aide est chargé de récupérer les derniers builds, de les flasher sur les appareils et en appelant des tests (en local ou par le biais du commandant). Il communique également avec Cloud Scheduler, et dirige le trafic entre celui-ci Une instance TradeFed (ou un autre outil) s'exécutant sur le centre d'aide. Pour en savoir plus sur le contrôleur hôte, reportez-vous à la section Gestion des Architecture du contrôleur.

Fournisseurs de ressources

Les tests automatisés nécessitent des ressources telles que des builds système, des fichiers de test et des artefacts VTS. Bien qu'il soit possible de les créer à partir de la source, il est plus facile de les compiler à partir de la pointe de l'arbre régulièrement, puis publier les artefacts pour les télécharger.

Les partenaires peuvent accéder aux ressources d'automatisation depuis les emplacements suivants:

  • Build Android du partenaire Accès programmatique accordé par compte.
  • Système de fichiers local (ou similaire). Pour les partenaires utilisez Partner Android Build.

Pour pouvoir flasher les appareils ultérieurement, les ressources incluent des fournisseurs de build pour les deux options, en partant d'un seul build_provider.py qui stocke les builds dans des répertoires temporaires locaux.

Build Android du partenaire

Dans les versions d'Android 8.1 et antérieures, les partenaires Android devaient accéder au Site Web partenaire Android Build (https://partner.android.com/build). accéder à son compte et récupérer les dernières images système de commande. Pour aider les partenaires à éviter ce processus lent et laborieux, Android 9 permet de télécharger automatiquement ces ressources à partir de la PAB lorsque les identifiants appropriés sont fournis.

Établir l'accès

L'accès programmatique utilise OAuth2 sur les API Google pour accéder aux RPC requis. À l'aide de l'approche standard pour générer des identifiants OAuth2, le partenaire doit configurer une paire ID client/secret avec Google. Lorsque PartnerAndroidBuildClient est dirigé vers ce secret pour la première fois, une fenêtre de navigateur s'ouvre pour que l'utilisateur puisse se connecter à son compte Google, ce qui génère les identifiants OAuth2 nécessaires pour continuer. La les identifiants (jeton d'accès et jeton d'actualisation) sont stockés localement, les partenaires n'ont besoin de se connecter qu'une seule fois.

Demande POST pour l'URL

Cliquez sur un lien de ressource dans la PAB pour envoyer une requête POST incluant les données nécessaires à cette ressource, y compris :

  • build_id, build_target
  • nom de la ressource
  • branche
  • nom de la version candidate et si elle s'agit d'un build interne ou non

La requête POST est reçue par la méthode downloadBuildArtifact. du RPC buildsvc, qui renvoie une URL pouvant être utilisée pour pour accéder à la ressource.

  • Pour les ressources APK Clockwork Companion, l'URL est une URL lisible hébergée sur le PAB (qui est protégé par authentification et accessible avec les identifiants OAuth2 appropriés).
  • Pour les autres ressources, il s'agit d'une URL longue et non protégée contre les attaques API Android Build (qui expire au bout de cinq minutes).

Obtenir l'URL

Pour éviter la falsification de requêtes intersites, le RPC buildsvc nécessite un le jeton XSRF doit être envoyé via la méthode POST avec les autres paramètres. Bien que ce jeton rende processus plus sécurisé, mais cela rend également l'accès programmatique beaucoup plus difficile, car (qui n'est disponible que dans le code JavaScript de la page du bouton d'action flottant) est désormais également requis pour l'accès.

Pour éviter ce problème, Android 9 repense le schéma d'attribution de noms d'URL pour tous les fichiers (et pas seulement les APK) afin d'utiliser des noms d'URL prévisibles pour accéder aux listes d'artefacts et aux URL d'artefacts. Le PAB utilise désormais un format d'URL pratique qui permet aux partenaires de télécharger des ressources. Les scripts HC peuvent télécharger ces APK facilement, car le format d'URL est connu, et HC peut contourner les problèmes XSRF/cookie, car il n'a pas besoin de l'RPC buildsvc.

Système de fichiers local

À partir d'un répertoire contenant une liste (ou un fichier ZIP) d'artefacts, le fournisseur de compilation définit les images pertinentes en fonction du contenu du répertoire. Vous pouvez utiliser l'outil gsutil pour copier des fichiers depuis Google Cloud Storage vers un répertoire local.

Compilations Flash

Une fois les images les plus récentes de l'appareil téléchargées sur l'hôte, ces images doivent être flashées sur les appareils. Pour ce faire, vous devez utiliser les commandes adb et fastboot et les sous-processus Python ; en fonction des chemins d'accès aux fichiers temporaires stockés par les fournisseurs de compilation.

Actions autorisées :

  • Flasher uniquement la GSI
  • Flasher des images individuelles à partir du système principal (par exemple, fastboot flash boot boot.img)
  • Flashage de toutes les images à partir du système principal. Exemple: <ph type="x-smartling-placeholder">
      </ph>
    • fastboot flashall (avec la flashall intégrée) fournisseur d'énergie)
    • fastboot flash (une à la fois)

Exécuter des tests

Dans Android 9, l'infrastructure de test automatisé VTS n'est compatible qu'avec le faisceau de test TradeFed, mais elle pourrait être étendue à d'autres faisceaux à l'avenir.

Une fois les appareils préparés, vous pouvez appeler des tests à l'aide de l'un des les options suivantes:

  • Lorsque vous utilisez TradeFed localement, utilisez la commande test dans le contrôleur hôte, qui prend le nom d'un plan de test VTS (par exemple, vts-selftest) et exécute le test.
  • Lorsque vous utilisez un cluster TradeFed (éventuellement connecté à MTT), utilisez le lease dans la console du contrôleur hôte, qui recherche et non satisfaites.

Si vous utilisez TradeFedCluster, TradeFed s'exécute localement, en tant que gestionnaire à distance. Sinon, les tests sont appelés à l'aide de sous-processus Python.

Résultats du rapport

Les résultats des tests sont automatiquement signalés à certains projets de tableau de bord VTS par VtsMultiDeviceTest