Modèles de test

AOSP inclut des modèles de test pour les modules de test qui ne sont pas une sous-classe Python côté hôte du BaseTest du coureur VTS.

Les développeurs peuvent utiliser ces modèles pour minimiser les efforts impliqués dans l'intégration de ces tests. Cette section couvre la configuration et l'utilisation des modèles de test (situés dans le répertoire testcases/template de VTS) et fournit des exemples de modèles couramment utilisés.

Modèle de test binaire

Utilisez le modèle BinaryTest pour intégrer les tests qui s'exécutent sur l'appareil cible dans VTS. Les tests côté cible comprennent :

• Tests basés sur C++ compilés et transmis à l'appareil
• Tests Python côté cible compilés sous forme de binaires
• Scripts Shell exécutables sur les appareils

Ces tests peuvent être intégrés dans VTS avec ou sans le modèle BinaryTest.

Intégrer les tests côté cible avec le modèle BinaryTest

Le modèle BinaryTest est conçu pour aider les développeurs à intégrer facilement les tests côté cible. Dans la plupart des cas, vous pouvez ajouter quelques lignes simples de configuration dans AndroidTest.xml . Exemple de configuration de VtsDeviceTreeEarlyMountTest :

<configuration description="Config for VTS VtsDeviceTreeEarlyMountTest.">
  ...
<test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
<option name="test-module-name" value="VtsDeviceTreeEarlyMountTest"/>
<option name="binary-test-source" value="_32bit::DATA/nativetest/dt_early_mount_test/dt_early_mount_test" />
<option name="binary-test-source" value="_64bit::DATA/nativetest64/dt_early_mount_test/dt_early_mount_test" />
<option name="test-timeout" value="5m"/>
</test>
</configuration>

Dans cette configuration :

• binary-test-source et binary-test-type sont spécifiques au modèle.
• La spécification du chemin d'hôte relatif de la source binaire de test permet au modèle de gérer la préparation, le transfert de fichiers, l'exécution des tests, l'analyse des résultats et le nettoyage.
• Le modèle contient des méthodes liées à la création de scénarios de test que les sous-classes doivent remplacer.
• Le modèle suppose un scénario de test par module binaire de test et le nom du fichier source binaire est utilisé par défaut comme nom de scénario de test.

Options de configuration

Le modèle BinaryTest prend en charge les options de configuration suivantes :

Pour les options avec strings de type valeur, vous pouvez ajouter plusieurs valeurs en répétant les options dans la configuration. Par exemple, définissez binary-test-source deux fois (comme indiqué dans l'exemple VtsDeviceTreeEarlyMountTest ).

Balises de test

Vous pouvez ajouter des balises de test en les préfixant aux options avec des valeurs strings et en utilisant :: comme délimiteur. Les balises de test sont particulièrement utiles lors de l'inclusion de sources binaires portant le même nom mais avec un nombre de bits ou des répertoires parents différents. Par exemple, pour éviter les collisions de fichiers ou de noms de résultats pour des sources portant le même nom mais provenant de répertoires sources différents, vous pouvez spécifier différentes balises pour ces sources.

Comme le montre l'exemple VtsDeviceTreeEarlyMountTest avec les deux sources dt_early_mount_test , les balises de test sont les préfixes _32bit:: et _64bit:: sur binary-test-source . Les balises se terminant par 32bit ou 64bit marquent automatiquement les tests comme disponibles pour un nombre de bits ABI ; c'est-à-dire que les tests avec la balise _32bit ne sont pas exécutés sur ABI 64 bits. Ne pas spécifier de balise équivaut à utiliser une balise avec une chaîne vide.

Les options avec les mêmes balises sont regroupées et isolées des autres balises. Par exemple, binary-test-args avec la balise _32bit est appliqué uniquement à binary-test-source avec la même balise et exécuté dans binary-test-working-directory avec la même balise. L'option binary-test-working-directory est facultative pour les tests binaires, vous permettant de spécifier un seul répertoire de travail pour une balise. Lorsque l'option binary-test-working-directory n'est pas spécifiée, les répertoires par défaut sont utilisés pour chaque balise.

Le nom de la balise est directement ajouté au nom du scénario de test dans le rapport de résultats. Par exemple, le scénario de test testcase1 avec la balise _32bit apparaît comme testcase1_32bit dans le rapport de résultats.

Intégrer des tests côté cible sans modèle BinaryTest

Dans VTS, le format de test par défaut est celui des tests Python côté hôte étendus à partir de BaseTest dans le coureur VTS. Pour intégrer des tests côté cible, vous devez d'abord envoyer les fichiers de test vers l'appareil, exécuter les tests à l'aide de commandes shell, puis analyser les résultats à l'aide de scripts Python côté hôte.

Pousser les binaires de test

Nous vous recommandons de transférer des fichiers à l'aide du préparateur cible VtsFilePusher . Exemple:

<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher">
        <option name="push" value="DATA/test->/data/local/tmp/test"/>
    </target_preparer>

Le VtsFilePusher effectue les opérations suivantes :

1. Vérifie la connectivité de l'appareil.
2. Détermine le chemin absolu du fichier source.
3. Pousse les fichiers à l’aide de la commande adb push .
4. Supprime les fichiers une fois les tests terminés.

Vous pouvez également envoyer des fichiers manuellement à l'aide d'un script de test Python côté hôte qui suit une procédure similaire.

Exécuter des tests

Après avoir transféré les fichiers sur l'appareil, exécutez le test à l'aide de commandes shell dans un script de test Python côté hôte. Exemple:

device = self.android_devices[0]
res = device.shell.Execute(["chmod a+x /data/local/tmp/test", "/data/local/tmp/test"])
asserts.AssertFalse(any(res[return_codes]))

Modèle GtestBinaryTest

Le modèle GtestBinaryTest héberge les binaires de test GTest, dont chacun contient généralement plusieurs cas de test. Ce modèle étend le modèle BinaryTest en remplaçant les méthodes de configuration, de création de scénario de test et d'analyse des résultats, de sorte que toutes les configurations BinaryTest sont héritées.

GtestBinaryTest ajoute l'option gtest-batch-mode :

En général, définir gtest-batch-mode sur true augmente les performances tout en diminuant légèrement la fiabilité. Dans les tests de conformité VTS, de nombreux modules utilisent le mode batch pour améliorer les performances. Cependant, pour des raisons de fiabilité, si le mode n'est pas spécifié, il est par défaut non batch.

Mode non batch

Le mode non batch effectue des appels individuels au binaire GTest pour chaque scénario de test. Par exemple, si le binaire GTest contient 10 cas de test (après filtrage par configuration côté hôte), le binaire est appelé 10 fois sur le shell du périphérique à chaque fois avec un filtre de test différent. Pour chaque scénario de test, un XML de sortie de résultat GTest unique est généré et analysé par le modèle.

Les avantages de l’utilisation du mode non batch incluent :

• Isolement des cas de test . Un crash ou un blocage dans un scénario de test n'affecte pas les autres scénarios de test.
• Granularité . Il est plus facile d'obtenir un profilage/mesure de couverture par cas de test, un systrace, un rapport de bug, un logcat, etc. Les résultats des tests et les journaux sont récupérés immédiatement après la fin de chaque scénario de test.

Les inconvénients de l’utilisation du mode non batch incluent :

• Chargement redondant . Chaque fois que le binaire GTest est appelé, il charge les bibliothèques associées et effectue les configurations initiales des classes.
• Frais généraux de communication . Une fois le test terminé, l'hôte et le périphérique cible communiquent pour l'analyse des résultats et les commandes suivantes (optimisations futures possibles).

Temps différé

En mode batch GTest, le binaire de test n'est appelé qu'une seule fois avec une longue valeur de filtre de test contenant tous les cas de test filtrés par la configuration côté hôte (cela évite le problème de chargement redondant en mode non-batch). Vous pouvez analyser les résultats des tests pour GTest à l'aide de output.xml ou à l'aide de la sortie du terminal.

Lors de l'utilisation de output.xml (par défaut) :

Comme en mode non batch, le résultat du test est analysé via le fichier XML de sortie GTest. Cependant, étant donné que le fichier XML de sortie est généré une fois tous les tests terminés, si un scénario de test plante le binaire ou le périphérique, aucun fichier XML de résultat n'est généré.

Lors de l'utilisation de la sortie du terminal :

Pendant que GTest est en cours d'exécution, il imprime le journal du test et la progression sur le terminal dans un format qui peut être analysé par le framework pour l'état, les résultats et les journaux du test.

Les avantages de l’utilisation du mode batch incluent :

• Isolement des cas de test . Fournit le même niveau d'isolation des scénarios de test que le mode non-batch si le framework redémarre le binaire/périphérique après un crash avec un filtre de test réduit (à l'exclusion des scénarios de test terminés et en panne).
• Granularité . Fournit la même granularité de scénario de test que le mode non batch.

Les inconvénients de l’utilisation du mode batch incluent :

• Coût de maintenance . Si le format de journalisation GTest change, tous les tests seront interrompus.
• Confusion . Un scénario de test peut imprimer quelque chose de similaire au format de progression GTest, ce qui peut confondre le format.

En raison de ces inconvénients, nous avons temporairement supprimé l'option permettant d'utiliser la sortie en ligne de commande. Nous reviendrons sur cette option dans le futur pour améliorer la fiabilité de cette fonction.

Modèle HostBinaryTest

Le modèle HostBinaryTest inclut des exécutables côté hôte qui n'existent pas dans d'autres répertoires ou dans les scripts Python. Ces tests comprennent :

• Binaires de test compilés exécutables sur l'hôte
• Scripts exécutables en shell, Python ou autres langages

Un exemple est le test côté hôte de la politique VTS Security SELinux :

<configuration description="Config for VTS  Security SELinux policy host-side test cases">
    ...
    <test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
        <option name="test-module-name" value="VtsSecuritySelinuxPolicyHost"/>
        <option name="binary-test-source" value="out/host/linux-x86/bin/VtsSecuritySelinuxPolicyHostTest" />
        <option name="binary-test-type" value="host_binary_test"/>
    </test>
</configuration>

HostBinaryTest n'étend pas le modèle BinaryTest mais utilise des configurations de test similaires. Dans l'exemple ci-dessus, l'option binary-test-source spécifie un chemin relatif côté hôte vers l'exécutable de test, et binary-test-type est host_binary_test . Semblable au modèle BinaryTest, le nom de fichier binaire est utilisé par défaut comme nom de scénario de test.

Étendre les modèles existants

Vous pouvez utiliser des modèles directement dans la configuration de test pour inclure des tests non Python ou les étendre dans une sous-classe pour gérer des exigences de test spécifiques. Les modèles du référentiel VTS ont les extensions suivantes :

Les développeurs sont encouragés à étendre tout modèle existant pour toute exigence de test spécifique. Les raisons courantes d’étendre les modèles incluent :

• Procédures de configuration de test spéciales, telles que la préparation d'un périphérique avec des commandes spéciales.
• Génération de différents cas de test et noms de tests.
• Analyser les résultats en lisant le résultat de la commande ou en utilisant d'autres conditions.

Pour faciliter l'extension des modèles existants, les modèles contiennent des méthodes spécialisées pour chaque fonctionnalité. Si vous avez amélioré la conception de modèles existants, nous vous encourageons à contribuer à la base de code VTS.