Infrastructure de test automatisé

Android 9 inclut une infrastructure VTS (Vendor Test Suite) 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 AOSP (GSI). Auparavant, l'exécution de ces tests était une opération très manuelle. La nouvelle infrastructure de test VTS est conçue pour prendre en charge les tests automatisés plusieurs fois par jour sur plusieurs appareils.

Architecture

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

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 :
   • Compilation Android partenaire (PAB) pour la GSI, le framework VTS et certaines autres compilations.
   • 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 compilations dans le cloud de Google's.
2. Flashe les artefacts de compilation (à partir de l'appareil) et la GSI (à partir d'AOSP) sur les appareils connectés.
3. Exécute les tests VTS à l'aide de TradeFed local ou d'un TradeFed dans le cloud.
4. Signale 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 en cours de test. Le HC est responsable de la récupération des dernières compilations, de leur flashage sur les appareils et de l'appel des tests (localement ou 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 en savoir plus 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 compilations système, des fichiers de test et des artefacts VTS. Bien qu'il soit possible de les compiler à partir de la source, il est plus facile de les compiler régulièrement à partir de la pointe de l'arbre, puis de publier les artefacts pour le téléchargement.

Les partenaires peuvent accéder aux ressources d'automatisation à l'aide des emplacements suivants :

• Compilation Android partenaire. Accès programmatique accordé par compte.
• Système de fichiers local (ou similaire). Pour les partenaires qui n'utilisent pas la compilation Android partenaire.

Pour une utilisation ultérieure lors du flashage des appareils, les ressources incluent des fournisseurs de compilation pour les deux options, à partir d'un seul build_provider.py qui stocke les compilations dans des répertoires temporaires locaux.

Compilation Android partenaire

Dans Android 8.1 et les versions antérieures, les partenaires Android devaient accéder au site Web de la compilation Android partenaire (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 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. En utilisant l' approche standard pour générer des identifiants OAuth2, le partenaire doit configurer une paire d'ID/secret client avec Google. Lorsque le PartnerAndroidBuildClient est pointé 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 identifiants OAuth2 nécessaires pour continuer. Les identifiants (jeton d'accès et jeton d'actualisation) sont stockés localement, ce qui signifie que les partenaires ne devraient avoir besoin de se connecter qu'une seule fois.

Requête POST pour l'URL

Lorsque vous cliquez sur un lien de ressource dans la PAB, une requête POST est envoyée. Elle inclut les données nécessaires pour cette ressource, y compris :

• ID de compilation, cible de compilation
• nom de la ressource
• branche
• nom de la version candidate et indication si elle est une compilation interne ou non

La requête POST est reçue par la méthode downloadBuildArtifact du RPC buildsvc, qui renvoie une URL permettant d’accéder à la ressource.

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

Obtenir l'URL

Pour éviter la falsification de requêtes intersites, le buildsvc RPC nécessite qu'un jeton XSRF soit envoyé avec les autres paramètres. Bien que ce jeton renforce la sécurité du processus, il rend également l'accès programmatique beaucoup plus difficile, car 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 repense le schéma de nommage des 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. La 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 facilement ces APK, car le format d'URL est connu, et HC peut contourner les problèmes XSRF/de cookies, car il n'a pas besoin du buildsvc RPC.

Système de fichiers local

Étant donné 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 de Google Cloud Storage vers un répertoire local.

Flasher les compilations

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

Actions prises en charge :

• Flasher uniquement la GSI
• Flasher des images individuelles à partir du système principal (par exemple, fastboot flash boot boot.img)
• Flasher toutes les images du système principal. Exemple :
  • fastboot flashall (à l'aide de l'utilitaire flashall intégré)
  • fastboot flash (une à la fois)

Exécuter des tests

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

Une fois les appareils préparés, vous pouvez appeler 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.
• Lorsque vous utilisez un cluster TradeFed (éventuellement connecté à MTT), utilisez la lease commande dans la console du contrôleur hôte, qui recherche les exécutions de test 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.