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 de BaseTest du VTS Runner.

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

Modèle BinaryTest

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

• Tests basés sur C++ compilés et transférés vers l'appareil
• Tests Python côté cible compilés en binaires
• Scripts shell exécutables sur les appareils

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

Intégrer des 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 de configuration simples 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.
• Spécifier le chemin d'hôte relatif de la source binaire de test permet au modèle de gérer la préparation, l'envoi 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 cas de test que les sous-classes peuvent remplacer.
• Le modèle suppose un scénario de test par module binaire de test, et le nom du fichier source binaire est utilisé comme nom du scénario de test par défaut.

Options de configuration

Le modèle BinaryTest est compatible avec les options de configuration suivantes:

Pour les options avec le type de valeur strings, 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).

Tags de test

Vous pouvez ajouter des balises de test en les ajoutant en préfixe aux options avec des valeurs strings et en utilisant :: comme séparateur. Les balises de test sont particulièrement utiles lorsque vous incluez des sources binaires portant le même nom, mais avec une taille d'octets ou des répertoires parents différents. Par exemple, pour éviter les collisions de noms de fichiers ou de résultats pour les sources portant le même nom, mais provenant de différents répertoires sources, vous pouvez spécifier des balises différentes pour ces sources.

Comme indiqué dans 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 ABI de 64 bits. Autrement dit, les tests avec la balise _32bit ne sont pas exécutés sur ABI 64 bits. Ne pas spécifier de balise revient à utiliser une balise avec une chaîne vide.

Les options associées aux mêmes tags sont regroupées et isolées des autres tags. Par exemple, binary-test-args avec le tag _32bit n'est appliqué qu'à binary-test-source avec le même tag et exécuté dans binary-test-working-directory avec le même tag. L'option binary-test-working-directory est facultative pour les tests binaires. Elle vous permet 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 ajouté directement au nom du cas de test dans le rapport sur les résultats. Par exemple, le scénario de test testcase1 avec le tag _32bit apparaît sous la forme 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 les tests Python côté hôte étendus à partir de BaseTest dans le programme d'exécution VTS. Pour intégrer des tests côté cible, vous devez d'abord transférer les fichiers de test sur 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.

Mettre en ligne des binaires de test

Nous vous recommandons d'importer des fichiers à l'aide du préparateur de 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>

VtsFilePusher effectue les opérations suivantes:

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

Vous pouvez également transférer 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é des 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 des binaires de test GTest, chacun contenant généralement plusieurs scénarios de test. Ce modèle étend le modèle BinaryTest en remplaçant les méthodes de configuration, de création de cas de test et d'analyse des résultats. Toutes les configurations BinaryTest sont donc 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 par lot pour améliorer les performances. Toutefois, pour des raisons de fiabilité, si le mode n'est pas spécifié, il est défini par défaut sur "non groupé".

Mode non par lot

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

Voici quelques avantages de l'utilisation du mode non par lot:

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

Voici quelques inconvénients de l'utilisation du mode non par lot:

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

Mode par lot

En mode par lot 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 configuration côté hôte (cela évite le problème de chargement redondant en mode non par lot). Vous pouvez analyser les résultats des tests pour GTest à l'aide de output.xml ou de la sortie du terminal.

Lorsque vous utilisez output.xml (par défaut):

Comme en mode non par lot, le résultat du test est analysé via le fichier XML de sortie GTest. Toutefois, comme le fichier XML de sortie est généré une fois tous les tests terminés, si un scénario de test a planté le binaire ou l'appareil, aucun fichier XML de résultat n'est généré.

Lorsque vous utilisez la sortie du terminal:

Lorsque GTest est en cours d'exécution, il imprime le journal de test et la progression dans le terminal dans un format pouvant être analysé par le framework pour l'état, les résultats et les journaux des tests.

Voici quelques avantages de l'utilisation du mode par lot:

• Isolement des scénarios de test Fournit le même niveau d'isolation des scénarios de test que le mode non par lot si le framework redémarre le binaire/l'appareil après un plantage avec un filtre de test réduit (à l'exception des scénarios de test terminés et plantés).
• Précision Fournit la même granularité de cas de test que le mode non par lot.

Voici quelques inconvénients de l'utilisation du mode par lots:

• Coût de la maintenance Si le format de journalisation GTest change, tous les tests échouent.
• Confusion Un cas de test peut imprimer quelque chose de semblable au format de progression GTest, ce qui peut prêter à confusion.

En raison de ces inconvénients, nous avons temporairement supprimé l'option permettant d'utiliser la sortie de ligne de commande. Nous reviendrons sur cette option à l'avenir 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 ni dans des scripts Python. Ces tests portent sur les éléments suivants :

• Binaires de test compilés exécutables sur l'hôte
• des scripts exécutables en shell, en Python ou dans d'autres langages ;

Par exemple, le test côté hôte de la stratégie de sécurité SELinux de VTS:

<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. Comme pour le modèle BinaryTest, le nom de fichier binaire est utilisé comme nom du cas de test par défaut.

Étendre les modèles existants

Vous pouvez utiliser des modèles directement dans la configuration de test pour inclure des tests autres que Python ou les étendre dans une sous-classe pour gérer des exigences de test spécifiques. Les modèles du dépôt VTS ont les extensions suivantes:

Les développeurs sont encouragés à étendre un modèle existant pour toute exigence de test spécifique. Voici quelques raisons courantes d'étendre des modèles:

• Procédures de configuration de test spéciales, telles que la préparation d'un appareil avec des commandes spéciales.
• Générer différents scénarios et noms de test
• Analyser les résultats en lisant la sortie de la commande ou en utilisant d'autres conditions.

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