Cette page a été traduite par l'API Cloud Translation.

Tester le mappage

Il s'agit d'une brève introduction à la mise en correspondance des tests et d'une explication de la façon d'obtenir a commencé à configurer des tests dans le projet Android Open Source (AOSP).

À propos du mappage test

Le mappage de test est une approche basée sur Gerrit qui permet aux développeurs de créer des et les règles de test post-envoi directement dans l'arborescence source Android. les décisions des branches et des appareils à tester sur l’infrastructure de test. Les définitions de mappage de test sont des fichiers JSON nommés TEST_MAPPING que vous pouvez dans n'importe quel répertoire source.

Atest peut utiliser les fichiers TEST_MAPPING pour exécuter des tests avant envoi dans le annuaires associés. Avec le mappage de test, vous pouvez ajouter le même ensemble de tests vérifications avant envoi avec un minimum de modifications dans l'arborescence source Android.

Consultez les exemples suivants:

Le mappage des tests s'appuie sur L'harnais de test de la fédération de commerce (TF) pour l'exécution des tests et la création de rapports sur les résultats.

Définir des groupes de test

Testez les groupes de mappage avec un groupe de test. Le nom d'un groupe de test peut être n'importe quelle chaîne. Par exemple, presubmit peut être le nom d'un groupe de tests pour lors de la validation des modifications. Et postsubmit peut être les tests utilisés pour valider les compilations après la fusion des modifications.

Règles du script de compilation du package

Pour que l'atelier de test de la Fédération commerciale pour exécuter des modules de test pour une compilation donnée, ils doivent avoir test_suites défini pour Soong ou LOCAL_COMPATIBILITY_SUITE défini pour utiliser l'une de ces deux suites:

general-tests est destiné aux tests qui ne dépendent pas d'un type d'appareil (comme le matériel spécifique au fournisseur que la plupart des appareils ne dont vous disposez). La plupart des tests doivent se trouver dans la suite general-tests, même s'ils sont spécifiques à une ABI ou un bitness ou à des fonctionnalités matérielles comme HWASan (il existe une cible test_suites distincte pour chaque ABI), et même si celles-ci doivent s'exécuter sur un appareil.
device-tests est destiné aux tests qui dépendent des fonctionnalités spécifiques à l'appareil. En règle générale, ces tests se trouvent sous vendor/. Propre à l'appareil fait uniquement référence aux fonctionnalités propres à un appareil. Cette règle s'applique donc aux tests JUnit et aux tests GTest (qui doivent généralement être marqués general-tests, même s'ils sont spécifiques à l'ABI).

Exemples :

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

Configurer des tests à exécuter dans une suite de tests

Pour qu'un test s'exécute dans une suite de tests, il doit:

Ne doit pas avoir de fournisseur de compilation.
Vous devez effectuer un nettoyage après la fin de l'opération, par exemple, en supprimant toute générés pendant le test.
Vous devez rétablir la valeur par défaut ou la valeur d'origine des paramètres système.
Ne partez pas du principe qu'un appareil se trouve dans un certain état, par exemple, lorsqu'il est en mode root. La plupart des tests ne nécessitent pas de droits racine pour s'exécuter. Si un test doit requérir racine, il doit spécifier cela avec RootTargetPreparer dans son AndroidTest.xml, comme dans l'exemple suivant:
```
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
```

Créer des fichiers de mappage de test

Pour le répertoire nécessitant une couverture de test, ajoutez un fichier JSON TEST_MAPPING. semblables à exemple. Ces règles garantissent que les tests s'exécutent dans les vérifications préliminaires lorsque des fichiers sont modifiés dans ce répertoire ou dans l'un de ses des sous-répertoires.

Suivre un exemple

Voici un exemple de fichier TEST_MAPPING (au format JSON, mais avec des commentaires) compatibles):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsDeqpTestCases",
      "options": [
        {
          // Use regex in include-filter which is supported in AndroidJUnitTest
          "include-filter": "dEQP-EGL.functional.color_clears.*"
        }
      ]
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Définir les attributs

Dans cet exemple, presubmit et postsubmit sont les noms de chaque groupe de test. Pour en savoir plus, consultez Définir des groupes de test. sur les groupes de test.

Vous pouvez définir le nom du module de test ou du test d'intégration de la fédération name (chemin d'accès à la ressource du fichier XML de test, par exemple, uiautomator/uiautomator-demo) dans la valeur de l'attribut name. Notez que le champ name ne peut pas Utilisez la classe name ou la méthode de test name. Pour affiner les tests à exécuter, utilisez des options telles que include-filter. Voir (exemple d'utilisation de include-filter).

Le paramètre host d'un test indique s'il s'agit d'un test sans appareil exécuté sur l'hôte ou non. La valeur par défaut est false, ce qui signifie que le test nécessite un appareil pour fonctionner. Les types de tests acceptés sont les suivants : HostGTest pour Binaires GTest et HostTest pour JUnit tests.

L'attribut file_patterns vous permet de définir une liste de chaînes d'expression régulière pour faire correspondre le chemin d'accès relatif de n'importe quel fichier de code source (par rapport au répertoire contenant le fichier TEST_MAPPING). Dans cet exemple : CtsWindowManagerDeviceTestCases test ne s'exécute en préenvoi que lorsqu'un fichier Java commence par Window ou Activity, qui existe dans le même répertoire que TEST_MAPPING ou l'un de ses sous-répertoires. Les barres obliques inverses `` doivent être échappées, car elles se trouvent dans un fichier JSON.

L'attribut imports vous permet d'inclure des tests dans d'autres fichiers TEST_MAPPING. sans en copier le contenu. Les fichiers TEST_MAPPING dans le dossier parent les répertoires du chemin importé sont également inclus. Le mappage de test permet des importations imbriquées ; Cela signifie que deux fichiers TEST_MAPPING peuvent s'importer mutuellement, et le mappage de test peut fusionner les tests inclus.

L'attribut options contient des options de ligne de commande Tradefed supplémentaires.

Pour obtenir la liste complète des options disponibles pour un test donné, exécutez la commande suivante:

tradefed.sh run commandAndExit [test_module] --help

Consultez Gestion des options dans Tradefed pour en savoir plus sur le fonctionnement des options.

Exécuter des tests avec Atest

Pour exécuter en local les règles de test avant envoi, procédez comme suit:

Accédez au répertoire contenant le fichier TEST_MAPPING.
Exécutez la commande suivante :
```
atest
```

Tous les tests de pré-envoi configurés dans les fichiers TEST_MAPPING du test actuel et ses répertoires parents sont exécutés. Atest localise et exécute deux tests pour le pré-envoi (A et B).

Il s'agit de la méthode la plus simple pour exécuter des tests avant envoi dans TEST_MAPPING du répertoire de travail actuel (CWD) et des répertoires parents. Aptitude localise et utilise le fichier TEST_MAPPING dans CWD et tous ses fichiers répertoires.

Structurer le code source

Cet exemple montre comment configurer des fichiers TEST_MAPPING dans le arborescence source:

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

Contenu de src/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

Contenu de src/project_1/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

Contenu de src/project_2/TEST_MAPPING:

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

Spécifier les répertoires cibles

Vous pouvez spécifier un répertoire cible pour exécuter des tests dans des fichiers TEST_MAPPING dans ce . La commande suivante exécute deux tests (A et B):

atest --test-mapping src/project_1

Exécuter les règles de test post-envoi

Vous pouvez également utiliser cette commande pour exécuter les règles du test postsubmit définies dans TEST_MAPPING dans src_path (par défaut, CWD) et ses répertoires parents:

atest [--test-mapping] [src_path]:postsubmit

Exécuter uniquement les tests qui ne nécessitent aucun appareil

Vous pouvez utiliser l'option --host pour Atest afin d'exécuter uniquement les tests configurés pour l'hôte qui ne nécessitent aucun appareil. Sans cette option, Atest exécute les deux tests, ceux qui nécessitent un appareil et celui qui s'exécute sur l'hôte et qui ne nécessitent aucun appareil. La sont exécutés dans deux suites distinctes:

atest [--test-mapping] --host

Identifier les groupes de test

Vous pouvez spécifier des groupes de test dans la commande Atest. La commande suivante exécute tous les tests postsubmit liés aux fichiers du répertoire src/project_1, qui ne contient qu'un seul test (C).

Vous pouvez également utiliser :all pour exécuter tous les tests, quel que soit le groupe. Les éléments suivants : exécute quatre tests (A, B, C, X):

atest --test-mapping src/project_1:all

Inclure les sous-répertoires

Par défaut, les tests dans TEST_MAPPING avec Atest n'exécutent que le préenvoi configurés dans le fichier TEST_MAPPING dans CWD (ou un répertoire donné) et ses répertoires parents. Si vous souhaitez exécuter des tests dans tous les fichiers TEST_MAPPING des sous-répertoires, utilisez l'option --include-subdir pour forcer Atest à inclure également ces tests.

atest --include-subdir

Sans l'option --include-subdir, Atest n'exécute que le test A. Avec l'option --include-subdir, Atest exécute deux tests (A, B).

Commentaire au niveau de la ligne accepté

Vous pouvez ajouter un commentaire de format // au niveau de la ligne pour étoffer le fichier TEST_MAPPING avec une description du paramètre qui suit. ATest et fédération du commerce prétraiter TEST_MAPPING dans un format JSON valide sans commentaires. Pour que le fichier JSON reste propre, seul le commentaire de format // au niveau de la ligne est accepté.

Exemple :

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}