Modèles de test

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

Les développeurs peuvent utiliser ces modèles pour minimiser les efforts impliqués dans l'intégration de ces tests. Cette section vous explique comment configurer et utiliser modèles (situés dans le fichier cas de test/modèle ) et fournit des exemples de modèles couramment utilisés.

Modèle BinaryTest

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

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

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

Intégrer des tests côté cible avec Modèle BinaryTest

Le modèle BinaryTest est conçu pour aider les développeurs à intégrer facilement des tests côté cible. Dans la plupart des cas, vous pouvez ajouter quelques lignes simples de configuration dans AndroidTest.xml. Exemple de configuration à partir 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écifique au modèle.
• La spécification du chemin d'accès relatif de l'hôte de la source binaire de test active le modèle pour gérer la préparation, le transfert de fichier, l'exécution des tests, l'analyse des résultats et nettoyage.
• Le modèle contient des méthodes liées à la création de scénarios de test pour que les sous-classes ou un forçage.
• Le modèle suppose un scénario de test par module binaire de test et le code binaire le nom du fichier source est utilisé par défaut comme nom du scénario de test.

Options de configuration

Le modèle BinaryTest accepte les options de configuration suivantes:

Nom de l'option	Type de valeur	Description
source-test-binaire	chaînes	Chemins d'accès sources de test binaire relatifs au répertoire de scénario de test vts sur hôte. Exemple: DATA/nativetest/test
répertoire-test-binaire	chaînes	Répertoires de travail (chemin d'accès côté appareil). Exemple: /data/local/tmp/testing/
Test binaire-envp	chaînes	Variables d'environnement pour le binaire. Exemple: PATH=/new:$PATH
test-binaire-args	chaînes	Tester des arguments ou des options Exemple: --gtest_filter=test1
chemin-d-accès-bibliothèque-binaire-test-ld-library	chaînes	LD_LIBRARY_PATH. Exemple: /data/local/tmp/lib
test binaire-disable-framework	booléen	Exécutez adb stop pour désactiver le framework Android avant le test. Exemple: true
arrêt-test-binaire des serveurs-natives	booléen	Arrêtez tous les serveurs natifs correctement configurés pendant les tests. Exemple: true
type-test-binaire	string	Type de modèle. D'autres types de modèles s'appuient sur ce modèle, inutile de spécifier cette option pour ce modèle, car vous avez déjà binary-test-source spécifié.

Pour les options dont le type de valeur est 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 les VtsDeviceTreeEarlyMountTest, par exemple).

Tester les tags

Vous pouvez ajouter des tags de test en ajoutant le préfixe strings devant les options. valeurs et en utilisant :: comme délimiteur. Les tags de test sont particulièrement utile lorsque vous incluez des sources binaires portant le même nom, mais avec des le répertoire binaire ou parent. Par exemple, pour éviter le transfert de fichier ou le nom du résultat collision pour les sources portant le même nom, mais provenant de répertoires sources différents, vous pouvez spécifier des tags différents pour ces sources.

Comme le montre l'exemple VtsDeviceTreeEarlyMountTest avec la deux sources dt_early_mount_test, les tags de test sont Préfixes _32bit:: et _64bit:: sur binary-test-source Tags finissant par 32bit ou 64bit marque automatiquement les tests comme disponibles pour un bitness d'ABI. Autrement dit, les tests avec le tag _32bit ne sont pas exécutés sur une ABI 64 bits. Non spécifier une balise revient à utiliser une balise avec une chaîne vide.

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

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

Intégrez 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 depuis BaseTest dans VTS runner. Pour intégrer des tests côté cible, vous devez d'abord déployer la méthode les fichiers de test sur l'appareil, exécuter les tests à l'aide de commandes shell, puis analyser le à l'aide de scripts Python côté hôte.

Binaires de test push

Nous vous recommandons de transférer les fichiers à l'aide du programmeur 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 au fichier source.
3. Transférez les fichiers à l'aide de la commande adb push.
4. Supprime les fichiers une fois les tests terminés.

Vous pouvez également transférer les fichiers manuellement à l'aide d'un 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 des 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

La GtestBinaryTest modèle 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 de création, de création de scénarios de test et d'analyse des résultats. Ainsi, tous les tests sont héritées.

GtestBinaryTest ajoute l'option gtest-batch-mode:

Nom de l'option	Type de valeur	Description
type-test-binaire	string	Type de modèle. Utilise la valeur gtest.
mode-lot-gtest	booléen	Exécutez des binaires Gtest en mode de traitement par lot. Exemple : true

En général, définir gtest-batch-mode sur true augmente les performances tout en diminuant légèrement la fiabilité. Conformité avec les VTS tests, de nombreux modules utilisent le mode de traitement par lot pour améliorer les performances. Pour la fiabilité Toutefois, si le mode n'est pas spécifié, la valeur par défaut est non-batch.

Mode sans traitement par lot

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

L'utilisation du mode hors traitement par lot présente les avantages suivants:

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

Voici quelques-uns des inconvénients de l'utilisation du mode autre que le traitement par lot:

• Chargement redondant. Chaque fois que le binaire GTest est appelé, il charge les bibliothèques associées et effectue les configurations initiales de classe.
• Frais de communication. Une fois le test terminé, l'hôte et l'appareil cible communiquent pour l'analyse des résultats et les commandes suivantes (à venir (optimisation possible).

Mode de traitement par lot

En mode de traitement par lot GTest, le binaire de test n'est appelé qu'une seule fois lors d'un test long Valeur de filtre contenant tous les scénarios de test filtrés par configuration côté hôte (ce ce qui permet d'éviter les problèmes de chargement redondants en mode autre que le traitement par lot). Vous pouvez analyser les données pour GTest à l'aide du fichier output.xml ou de la sortie du terminal.

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

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

Lorsque vous utilisez la sortie du terminal:

Pendant l'exécution de GTest, il affiche le journal de test et la progression dans le terminal. dans un format pouvant être analysé par le framework pour connaître l'état, les résultats et journaux.

Le mode de traitement par lot présente les avantages suivants:

• Isolation de scénarios de test. Fournit le même niveau de test l'isolation de cas en mode non-traitement 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 tests terminés et des tests ayant planté) cas).
• Précision : Fournit la même précision pour le scénario de test que non par lot.

Les inconvénients de l'utilisation du mode de traitement par lot sont les suivants:

• Coût de la maintenance. Si le format de journalisation GTest change, tous les tests échoueront.
• Confusion. Un scénario de test peut imprimer un résultat semblable à GTest. le format de progression, ce qui peut confondre le format.

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

• Exécutable de binaires de test compilé sur l'hôte
• Scripts exécutables dans le shell, Python ou d'autres langages

Par exemple, VTS Test de sécurité côté hôte des règles 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 il utilise une méthode similaire les configurations de test. Dans l'exemple ci-dessus, binary-test-source spécifie un chemin d'accès relatif côté hôte vers l'exécutable de test, et "binary-test-type" est "host_binary_test". Semblable à modèle BinaryTest, le nom de fichier binaire est utilisé comme nom du scénario de test par par défaut.

É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. Modèles dans le dépôt VTS possèdent les extensions suivantes:

Nous encourageons les développeurs à étendre les modèles existants pour toute les exigences de test. Voici quelques raisons courantes d'étendre les modèles:

• Des procédures spéciales de configuration du test, telles que la préparation d'un appareil avec des commandes.
• Générer différents scénarios de test et noms de test
• 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, ceux-ci contiennent des méthodes spécialisée pour chaque fonctionnalité. Si vous avez amélioré les conceptions nous vous encourageons à contribuer à la base de code VTS.