Mappatura test

Questa è una breve introduzione della mappatura di test e una spiegazione di come ottenere ha iniziato a configurare i test nell'Android Open Source Project (AOSP).

Informazioni sulla mappatura dei test

La mappatura di test è un approccio basato su Gerrit che consente agli sviluppatori di creare pre-invio e post-invio delle regole di test direttamente nella struttura di origine Android, lasciando decisioni di filiali e dispositivi da testare nell'infrastruttura di test. Le definizioni di mappatura dei test sono file JSON denominati TEST_MAPPING che puoi collocare in qualsiasi directory di origine.

Atest può utilizzare i file TEST_MAPPING per eseguire test pre-invio nel e directory associate. Con la mappatura di test, puoi aggiungere lo stesso insieme di test a controlli preinviati con una modifica minima all'interno della struttura di origine di Android.

Guarda questi esempi:

La mappatura dei test si basa sull'ambiente di test Trade Federation (TF) per l'esecuzione dei test e la generazione di report sui risultati.

Definisci i gruppi di test

Esegui i test di mappatura dei gruppi con un gruppo di test. Il nome di un gruppo di test può essere qualsiasi stringa. Ad esempio, presubmit può essere il nome di un gruppo di test da eseguire durante la convalida delle modifiche. postsubmit può essere i test utilizzati per convalidare le build dopo l'unione delle modifiche.

Regole dello script di compilazione del pacchetto

Affinché l'ambiente di test della Federazione commerciale possa eseguire i moduli di test per una determinata build, questi moduli devono avere un valore test_suites impostato per Soong o un valore LOCAL_COMPATIBILITY_SUITE impostato per Make in una di queste due suite:

  • general-tests è per i test che non dipendono dalle metriche specifiche del dispositivo funzionalità (come l'hardware specifico del fornitore, che la maggior parte dei dispositivi non supporta ). La maggior parte dei test dovrebbe essere nella suite general-tests, anche se sono specifici per un ABI o una dimensione in bit o funzionalità hardware come HWASan (esiste un target general-tests separato per ogni ABI) e anche se devono essere eseguiti su un dispositivo.
  • device-tests è indicato per i test che dipendono dalle funzionalità specifiche del dispositivo. In genere questi test si trovano sotto vendor/. In base al dispositivo si riferisce solo alle funzionalità specifiche di un dispositivo, pertanto si applica ai test JUnit e GTest (che di solito devono essere contrassegnati come general-tests anche se sono specifiche di ABI).

Esempi:

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

Configurare i test da eseguire in una suite di test

Affinché un test venga eseguito all'interno di una suite di test, il test:

  • Non deve avere alcun provider di build.
  • Deve essere eseguita la pulizia al termine, ad esempio eliminando eventuali file temporanei generati durante il test.
  • È necessario modificare le impostazioni di sistema sul valore predefinito o originale.

  • Non dovrebbe dare per scontato che un dispositivo si trovi in un determinato stato, ad esempio in stato di root pronto. La maggior parte dei test non richiede l'esecuzione del privilegio principale. Se un test richiede principale, dovrebbe essere specificato con RootTargetPreparer nel AndroidTest.xml, come nell'esempio seguente:

    <target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

Crea file di mapping di test

Per la directory che richiede la copertura dei test, aggiungi un file JSON TEST_MAPPING simile all'esempio. Queste regole assicurano che i test vengano eseguiti controlli preinvia quando vengono toccati file nella directory o nei suoi nelle sottodirectory.

Segui un esempio

Ecco un file TEST_MAPPING di esempio (in formato JSON ma con commenti) supportati):

{
  "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"
    }
  ]
}

Imposta attributi

Nell'esempio, presubmit e postsubmit sono i nomi di ogni gruppo di test. Per saperne di più, consulta Definire i gruppi di test sui gruppi di test.

Puoi impostare il nome del modulo di test o del test di integrazione di Trade Federation (per esempio, il percorso della risorsa al file XML del test, uiautomator/uiautomator-demo) nel valore dell'attributo name. Tieni presente che il campo name non può utilizza la classe name o il metodo di test name. Per restringere i test da eseguire, utilizza opzioni come include-filter. Consulta Esempio di utilizzo di include-filter.

L'impostazione host di un test indica se si tratta di un test senza dispositivo in esecuzione sull'host o meno. Il valore predefinito è false, il che significa che il test richiede un dispositivo per l'esecuzione. I tipi di test supportati sono HostGTest per Programmi binari GTest e HostTest per JUnit test.

L'attributo file_patterns consente di impostare un elenco di stringhe di espressioni regolari per la corrispondenza del percorso relativo di qualsiasi file di codice sorgente (rispetto alla directory contenente il file TEST_MAPPING). Nell'esempio, il test CtsWindowManagerDeviceTestCases viene eseguito in pre-invio solo quando un file Java inizia con Window o Activity, che esiste nella stessa directory del TEST_MAPPING o una delle sue sottodirectory. Le barre oblique inverse (\) devono essere sfuggite perché si trovano in un file JSON.

L'attributo imports ti consente di includere i test in altri file TEST_MAPPING senza copiare i contenuti. Sono inclusi anche i file TEST_MAPPING nelle directory principali del percorso importato. La mappatura dei test consente di eseguire importazioni nidificate, il che significa che due file TEST_MAPPING possono essere importati l'uno dall'altro e la mappatura dei test può unire i test inclusi.

L'attributo options contiene ulteriori opzioni della riga di comando Tradefed.

Per un elenco completo delle opzioni disponibili per un determinato test, esegui:

tradefed.sh run commandAndExit [test_module] --help

Per ulteriori dettagli sul funzionamento delle opzioni, consulta la sezione Gestione delle opzioni in Tradefed.

Esegui test con Atest

Per eseguire localmente le regole di test di preinvio:

  1. Vai alla directory contenente il file TEST_MAPPING.

  2. Esegui il comando:

    atest

Vengono eseguiti tutti i test di preinvio configurati nei file TEST_MAPPING della directory corrente e delle relative directory principali. Atest individua ed esegue due test per la pre-pubblicazione (A e B).

Questo è il modo più semplice per eseguire i test di preinvio nei file TEST_MAPPING nella directory di lavoro attuale (CWD) e nelle directory principali. Test individua e utilizza il file TEST_MAPPING in CWD e in tutti i file principali .

Codice sorgente della struttura

Questo esempio mostra come configurare i file TEST_MAPPING nell'albero di origine:

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

Contenuti di src/TEST_MAPPING:

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

Contenuti di src/project_1/TEST_MAPPING:

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

Contenuti di src/project_2/TEST_MAPPING:

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

Specifica le directory di destinazione

Puoi specificare una directory di destinazione per eseguire test nei file TEST_MAPPING al suo interno. Il seguente comando esegue due test (A, B):

atest --test-mapping src/project_1

Esegui regole di test post-invio

Puoi utilizzare questo comando anche per eseguire le regole di test post-invio definite in TEST_MAPPING in src_path (impostazione predefinita per la RDN) e nelle relative directory principali:

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

Esegui solo i test che non richiedono un dispositivo

Puoi utilizzare l'opzione --host per Atest per eseguire solo i test configurati e l'host che non richiede alcun dispositivo. Senza questa opzione, Atest esegue entrambi i test, quelli che richiedono un dispositivo e quelli eseguiti su un host che non richiede alcun dispositivo. I test vengono eseguiti in due suite separate:

atest [--test-mapping] --host

Identificare i gruppi di test

Puoi specificare i gruppi di test nel comando Atest. Viene eseguito il comando seguente tutti i postsubmit test relativi ai file nella directory src/project_1, che contiene un solo test (C).

In alternativa, puoi utilizzare :all per eseguire tutti i test indipendentemente dal gruppo. Le seguenti esegue quattro test (A, B, C, X):

atest --test-mapping src/project_1:all

Includi sottodirectory

Per impostazione predefinita, i test in TEST_MAPPING con Atest vengono eseguiti solo prima dell'invio test configurati nel file TEST_MAPPING in CWD (o data la directory) e le rispettive directory principali. Se vuoi eseguire test in tutti TEST_MAPPING file nelle sottodirectory, utilizza l'opzione --include-subdir per obbligare Atest a includere anche questi test.

atest --include-subdir

Senza l'opzione --include-subdir, Atest esegue solo il test A. Con l'opzione --include-subdir, Atest esegue due test (A, B).

Commento a livello di riga supportato

Puoi aggiungere un commento in formato // a livello di riga per arricchire TEST_MAPPING con la descrizione dell'impostazione che segue. ATest e Trade Federation pre-elabora TEST_MAPPING in un formato JSON valido senza commenti. Per mantenere il file JSON pulito, è supportato solo il commento di formato // a livello di riga.

Esempio:

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