Testa mappatura

Questa è una breve introduzione della mappatura dei test e una spiegazione di come iniziare a configurare facilmente i test in Android Open Source Project (AOSP).

Informazioni sulla mappatura di test

La mappatura di test è un approccio basato su Gerrit che consente agli sviluppatori di creare regole di test pre e post-invio direttamente nell'albero di origine di Android e lasciare le decisioni di rami e dispositivi da testare all'infrastruttura di test stessa. Le definizioni del mapping di test sono file JSON denominati TEST_MAPPING che possono essere inseriti in qualsiasi directory di origine.

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

Guarda questi esempi:

Aggiungere test pre-invio a TEST_MAPPING per services.core

Aggiungere test pre-invio a TEST_MAPPING per strumenti/dexter utilizzando le importazioni

La mappatura dei test si basa sull'applicazione di test della Federazione di scambio (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 utilizzando un gruppo di test. Il nome di un gruppo di test può essere qualsiasi stringa. Ad esempio, presubmit può essere utilizzato per l'esecuzione di un gruppo di test durante la convalida delle modifiche. Inoltre, i test postsubmit possono essere utilizzati per convalidare le build dopo l'unione delle modifiche.

Regole dello script di build del pacchetto

Affinché il Trade Federation Test Harness possa eseguire i moduli di test della mappatura di test per una determinata build, questi moduli devono avere test_suites impostato per Soong o LOCAL_COMPATIBILITY_SUITE per Make in una di queste due suite:

• test generali: test che non dipendono da funzionalità specifiche del dispositivo (come hardware specifico del fornitore che la maggior parte dei dispositivi non dispone). La maggior parte dei test dovrebbe essere nella suite di test generali, anche se sono specifica per un'ABI o funzionalità hardware o bitness come HWASan (c'è un target di test_suites separato per ogni ABI) e anche se devono essere eseguite su un dispositivo.
• test dei dispositivi: test che dipendono dalle funzionalità specifiche del dispositivo. In genere questi test si trovano sotto vendor/. Poiché il termine "specifico per dispositivo" non si riferisce alle funzionalità ABI o SoC che altri dispositivi potrebbero o non avere, ma solo a funzionalità specifiche di un dispositivo, questo vale per i test JUnit a ogni bit quanto i test nativi GTest (che in genere dovrebbero essere general-tests anche se sono specifici per 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 ripulire al termine del test, ad esempio eliminando eventuali file temporanei generati durante il test.
• modificare le impostazioni di sistema sul valore predefinito o originale.
• non dovrebbe assumere un dispositivo in un determinato stato, ad esempio root ready. La maggior parte dei test non richiede il privilegio principale per essere eseguita. Se un test deve richiedere la radice, deve specificare che ha RootTargetPreparer nel relativo 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 del test, aggiungi semplicemente un file JSON TEST_MAPPING simile all'esempio riportato di seguito. Queste regole assicurano l'esecuzione dei test nei controlli pre-invio quando eventuali file vengono toccati in quella directory o nelle sue sottodirectory.

Segui un esempio

Ecco un file TEST_MAPPING di esempio (in formato JSON, ma con i 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": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Imposta attributi

Nell'esempio precedente, presubmit e postsubmit sono i nomi di ogni gruppo di test. Consulta Definire i gruppi di test per ulteriori informazioni sui gruppi di test.

Il nome del modulo di test o il nome del test di integrazione della Federazione commerciale (percorso della risorsa per il file XML di test, ad esempio uiautomator/uiautomator-demo) può essere impostato nel valore dell'attributo name. Tieni presente che il campo name non può utilizzare la classe name o il metodo di test name. Per restringere il numero di test da eseguire, puoi utilizzare opzioni come include-filter qui. Consulta la sezione (utilizzo di esempio del filtro "includere-filter").

L'impostazione host di un test indica se il test è 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 i programmi binari GTest e HostTest per i test JUnit.

L'attributo file_patterns consente di impostare un elenco di stringhe regex per trovare la corrispondenza del percorso relativo di qualsiasi file di codice sorgente (relativo alla directory contenente il file TEST_MAPPING). Nell'esempio precedente, il test CtsWindowManagerDeviceTestCases verrà eseguito prima dell'invio solo quando un file Java viene avviato con Window o Activity, che esiste nella stessa directory del file TEST_MAPPING o in una qualsiasi delle sue sottodirectory, viene modificato. Le barre rovesciate \ devono essere precedute da caratteri di escape poiché si trovano in un file JSON.

L'attributo imports ti consente di includere test in altri file TEST_MAPPING senza copiare i contenuti. Tieni presente che saranno inclusi anche i file TEST_MAPPING nelle directory principali del percorso importato. Il mapping di test consente le importazioni nidificate; ciò significa che due file TEST_MAPPING possono importarsi a vicenda e il mapping di test è in grado di unire correttamente 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

Per ulteriori dettagli sul funzionamento delle opzioni, consulta Gestione delle opzioni TradeFed .

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

Vengono eseguiti tutti i test pre-invio configurati nei file TEST_MAPPING della directory corrente e delle relative directory principali. Atest individuerà ed eseguirà due test per il pre-invio (A e B).

Questo è il modo più semplice per eseguire test pre-invio nei file TEST_MAPPING nella directory di lavoro corrente (CWD) e nelle directory principali. Atest individuerà e utilizzerà il file TEST_MAPPING in CWD e in tutte le directory principali.

Strutturare il codice sorgente

L'esempio seguente 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 i test nei file TEST_MAPPING al suo interno. Il comando seguente eseguirà due test (A, B).

atest --test-mapping src/project_1

Esegui le 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 le 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 test configurati sull'host che non richiedono alcun dispositivo. Senza questa opzione, Atest eseguirà entrambi i test, sia quelli che richiedono il dispositivo sia quelli in esecuzione sull'host e non richiedono alcun dispositivo. I test verranno eseguiti in due suite separate.

atest [--test-mapping] --host

Identificare i gruppi di test

Puoi specificare i gruppi di test nel comando Atest. Il seguente comando eseguirà tutti i test postsubmit 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. Il seguente comando 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 eseguiranno solo i test pre-invio configurati nel file TEST_MAPPING in CWD (o una directory specifica) e nelle directory principali. Se vuoi eseguire test in tutti i file TEST_MAPPING nelle sottodirectory, utilizza l'opzione --include-subdir per forzare l'inclusione di questi test anche in Atest.

atest --include-subdir

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

I commenti a livello di riga sono supportati

Puoi aggiungere un commento in formato // a livello di riga per arricchire il file TEST_MAPPING aggiungendo una descrizione dell'impostazione. ATest e la Trade Federation pre-elaboreranno il TEST_MAPPING in un formato JSON valido senza commenti. Per mantenere il file JSON pulito e facile da leggere, sono supportati solo i commenti in formato // a livello di riga.

Esempio:

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