Infrastructure de test automatisée

Android 9 inclut une infrastructure Vendor Test Suite (VTS) pour les tests automatisés de VTS, CTS ou d'autres tests sur des appareils partenaires exécutant l'image système générique (GSI) AOSP. Auparavant, l'exécution de ces tests était une opération hautement manuelle ; la nouvelle infrastructure de test VTS est conçue pour prendre en charge des tests automatisés plusieurs fois par jour sur plusieurs appareils.

Architecture

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

Automated test architecture

Figure 1. Architecture de l'infrastructure de test automatisé 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 build et teste les ressources à partir de différents emplacements :
    • Partenaire Android Build (PAB) . Pour le framework GSI, VTS et quelques autres builds.
    • Système de fichiers local, Google Cloud Storage ou autre système de compilation spécifique au fournisseur . Pour les partenaires qui ne stockent pas les builds dans le cloud de Google.
  2. Clignote les artefacts de construction (à partir de l'appareil) et le GSI (à partir de l'AOSP) sur le ou les appareils connectés.
  3. Exécute des tests VTS à l'aide de TradeFed local ou d'un TradeFed dans le cloud.
  4. Rapporte les résultats des tests au tableau de bord VTS

Le processus est coordonné par le contrôleur hôte VTS (HC), une machine du laboratoire qui dirige le comportement de tous les appareils connectés sous test. Le HC est chargé de récupérer les dernières versions, de les flasher sur les appareils et d'invoquer des tests (soit localement, soit via le commandant). Il communique également avec un planificateur cloud et dirige le trafic entre le planificateur et l'instance TradeFed (ou un autre harnais) s'exécutant sur le HC. Pour plus d'informations sur le contrôleur hôte, consultez Architecture du contrôleur hôte .

Fournisseurs de ressources

Les tests automatisés nécessitent des ressources telles que des versions de 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 créer régulièrement à partir de la pointe de l'arbre, puis de publier les artefacts en téléchargement.

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

  • Partenaire Android Build . Accès programmatique accordé sur une base par compte.
  • Système de fichiers local (ou similaire). Pour les partenaires qui n'utilisent pas Partner Android Build.

Pour une utilisation ultérieure dans le flashage des périphériques, les ressources incluent des fournisseurs de build pour les deux options, s'étendant à partir d'un seul build_provider.py qui stocke les builds dans des répertoires temporaires locaux.

Version Android partenaire

Dans Android 8.1 et les versions antérieures, les partenaires Android devaient visiter le site Web Partner Android Build ( https://partner.android.com/build ), accéder à leur compte et récupérer les dernières images système via l'interface utilisateur. Pour aider les partenaires à éviter ce processus lent et fastidieux, Android 9 inclut la prise en charge du téléchargement automatique de ces ressources à partir de PAB lorsque les informations d'identification appropriées sont fournies.

Établissement de l'accès

L'accès programmatique utilise OAuth2 sur les API Google pour accéder aux RPC requis. En utilisant l' approche standard pour générer des informations d'identification OAuth2, le partenaire doit configurer une paire ID client/secret avec Google. Lorsque le PartnerAndroidBuildClient pointe vers ce secret pour la première fois, il ouvre une fenêtre de navigateur permettant à l'utilisateur de se connecter à son compte Google, ce qui génère les informations d'identification OAuth2 nécessaires pour avancer. Les informations d'identification (jeton d'accès et jeton d'actualisation) sont stockées localement, ce qui signifie que les partenaires ne doivent se connecter qu'une seule fois.

Requête POST pour l'URL

Cliquer sur un lien de ressource dans PAB envoie une requête POST qui inclut les données nécessaires pour cette ressource, notamment :

  • ID de construction, cible de construction
  • nom de la ressource
  • branche
  • nom du candidat de la version et s'il s'agit ou non d'une version interne

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

  • Pour les ressources APK Clockwork Companion, l'URL est une URL lisible hébergée sur PAB (qui est protégée par l'authentification et accessible avec les informations d'identification OAuth2 appropriées).
  • Pour les autres ressources, l'URL est une URL longue et non protégée de l'API interne Android Build (qui expire après cinq minutes).

Obtenir l'URL

Pour éviter la falsification de requêtes intersites, le buildsvc RPC nécessite qu'un jeton XSRF soit POSTé avec les autres paramètres. Si ce jeton rend le processus plus sûr, il rend également l'accès programmatique beaucoup plus difficile puisque le jeton (qui n'est disponible que dans le JavaScript de la page PAB) est désormais également requis pour l'accès.

Pour éviter ce problème, Android 9 redéfinit le schéma de dénomination d'URL pour tous les fichiers (pas seulement les fichiers 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 du RPC buildsvc .

Système de fichiers local

Étant donné un répertoire avec une liste (ou un fichier zip) d'artefacts, le fournisseur de build définit les images pertinentes en fonction de ce qui se trouve dans le répertoire. Vous pouvez utiliser l'outil gsutil pour copier des fichiers de Google Cloud Storage vers un répertoire local.

Constructions clignotantes

Une fois les images de périphérique les plus récentes téléchargées sur l'hôte, ces images doivent être flashées sur les périphériques. Cela se fait à l'aide des commandes adb et fastboot standard et des sous-processus Python, basés sur les chemins de fichiers temporaires stockés par les fournisseurs de build.

Actions prises en charge :

  • Clignotant uniquement le GSI
  • Flashage d'images individuelles du système principal (par exemple, fastboot flash boot boot.img )
  • Flashage de toutes les images du système principal. Exemple:
    • fastboot flashall (à l'aide de l'utilitaire flashall )
    • fastboot flash (un à la fois)

Tests en cours

Dans Android 9, l'infrastructure de test automatisé VTS ne prend en charge que le harnais de test TradeFed, mais pourrait être étendue pour prendre en charge d'autres harnais à l'avenir.

Une fois les appareils préparés, vous pouvez invoquer des tests à l'aide de l'une des 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.
  • Lors de l'utilisation d'un cluster TradeFed (éventuellement connecté à MTT), utilisez la commande lease dans la console du contrôleur hôte, qui recherche les exécutions de test non réalisées.

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

Rapporter les résultats

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