Testa mappatura

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 di test

Il mapping di test è un approccio basato su Gerrit che consente agli sviluppatori di creare e le regole per il test post-invio direttamente nella struttura di origine Android e lascia decisioni di filiali e dispositivi da testare nell'infrastruttura di test. Le definizioni del mapping di test sono file JSON denominati TEST_MAPPING che puoi in qualsiasi directory di origine.

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

Guarda questi esempi:

Il mapping di test si basa Cinturino di test della Federazione commerciale (TF) per l'esecuzione dei test e la generazione di report sui risultati.

Definisci i gruppi di test

Esegui i test dei gruppi di mappatura 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 per eseguite 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 Trade Federation possa eseguire i moduli di test per una determinata build, questi moduli devono avere test_suites impostato per Soong o LOCAL_COMPATIBILITY_SUITE impostato per Make su 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 eseguire la pulizia al termine dell'operazione, ad esempio eliminando eventuali generati durante il test.
  • Devi modificare le impostazioni di sistema impostandole sul valore predefinito o originale.
  • Non deve presumere che un dispositivo si trovi in un determinato stato, ad esempio in stato di root pronto. La maggior parte dei test non richiede i privilegi di root per essere eseguita. 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"/>
    

Creare file di mappatura di test

Per la directory che richiede la copertura di test, aggiungi un file JSON TEST_MAPPING che assomiglia all'esempio. Queste regole assicurano che i test vengano eseguiti controlli preinvia quando vengono toccati file nella directory o nei suoi file 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 ciascun 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 della Trade Federation (percorso risorsa del file XML di test, ad esempio 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 (Utilizzo di esempio 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 ti consente di impostare un elenco di stringhe di espressioni regolari per la corrispondenza del percorso relativo di qualsiasi file di codice sorgente (relativo al contenente il file TEST_MAPPING). Nell'esempio, il test CtsWindowManagerDeviceTestCases viene eseguito in pre-invio solo quando viene modificato un file Java che inizia con Window o Activity ed esiste nella stessa directory del file TEST_MAPPING o di una delle sue sottodirectory. Le barre rovesciate "" devono essere precedute dal carattere di escape perché si trovano in un file JSON.

L'attributo imports ti consente di includere test in altri file TEST_MAPPING senza copiarne i contenuti. I file TEST_MAPPING nell'elemento principale del percorso importato vengono incluse. La mappatura di prova consente importazioni nidificate; significa che due file TEST_MAPPING possono importarsi reciprocamente il mapping di test può unire i test inclusi.

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

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

tradefed.sh run commandAndExit [test_module] --help

Consulta Gestione delle opzioni in Tradefed per ulteriori dettagli sul funzionamento delle opzioni.

Esegui test con Atest

Per eseguire localmente le regole per il test precedente all'invio:

  1. Vai alla directory contenente il file TEST_MAPPING.
  2. Esegui il comando:

    atest
    

Tutti i test pre-invio configurati nei file TEST_MAPPING dell'attuale vengono eseguite tutte le directory principali. Atest individua ed esegue due test per il pre-invio (A e B).

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

Strutturare il codice sorgente

Questo esempio mostra come configurare file TEST_MAPPING in struttura 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 in cui eseguire test nei file TEST_MAPPING in cui . Il comando seguente 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 postsubmit definite in TEST_MAPPING in src_path (il valore predefinito è CWD) e relative directory principali:

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

Esegui solo test che non richiedono alcun dispositivo

Puoi utilizzare l'opzione --host per Atest per eseguire solo i test configurati in base a l'host che non richiedono alcun dispositivo. Senza questa opzione, Atest esegue entrambi i test, quelli che richiedono un dispositivo e quelli in esecuzione sull'host e non richiedono alcun dispositivo. La 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 i TEST_MAPPING file nelle sottodirectory, usa l'opzione --include-subdir per forzare 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).

Commenti a livello di riga supportati

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

Esempio:

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