Questa pagina è stata tradotta dall'API Cloud Translation.

Testa mappatura

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

Informazioni sulla mappatura dei test

La mappatura dei test è un approccio basato su Gerrit che consente agli sviluppatori di creare regole di test pre-invio e post-invio direttamente nella struttura di origine di Android e di lasciare le decisioni relative ai branch e ai dispositivi da testare all'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 i test di preinvio nelle 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:

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 è destinato ai test che non dipendono dalle funzionalità specifiche del dispositivo (ad esempio l'hardware specifico del fornitore che la maggior parte dei dispositivi non ha). 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.test_suites
device-tests è destinato ai test che dipendono da funzionalità specifiche del dispositivo. In genere, questi test si trovano in vendor/. Specifico per dispositivo si riferisce solo alle funzionalità specifiche di un dispositivo, pertanto questo vale sia per i test JUnit che per i test GTest (che in genere dovrebbero essere contrassegnati come 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, deve:

Non deve avere alcun provider di build.
Deve essere eseguita la pulizia al termine, ad esempio eliminando eventuali file temporanei generati durante il test.
Devi modificare le impostazioni di sistema impostandole sul valore predefinito o originale.
Non deve assumere che un dispositivo sia in un determinato stato, ad esempio pronto per il root. La maggior parte dei test non richiede i privilegi di root per essere eseguita. Se un test deve richiedere il ruolo di amministratore, deve specificarlo con RootTargetPreparer nel suo 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 dei test, aggiungi un file JSON TEST_MAPPING simile all'esempio. Queste regole assicurano che i test vengano eseguiti nei controlli preinvio quando vengono modificati file nella directory o in una delle sue sottodirectory.

Segui un esempio

Ecco un file TEST_MAPPING di esempio (è in formato JSON, ma supporta i commenti):

{
  "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 gli attributi

Nell'esempio, presubmit e postsubmit sono i nomi di ciascun gruppo di test. Consulta Definire i gruppi di test per ulteriori informazioni 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ò utilizzare la classe name o il metodo di test name. Per restringere i test da eseguire, utilizza opzioni come include-filter. Consulta include-filter un esempio di utilizzo.

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

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 prima dell'invio solo quando un file Java inizia con Window o Activity, che esiste nella stessa directory del file TEST_MAPPING o in una qualsiasi delle sue sottodirectory. Le barre oblique inverse (\) devono essere sfuggite perché si trovano in un file JSON.

L'attributo imports ti consente di includere 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 opzioni aggiuntive 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.

Eseguire test con Atest

Per eseguire a livello locale le regole di test pre-invio:

Vai alla directory contenente il file TEST_MAPPING.
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 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. Atest individua e utilizza il file TEST_MAPPING nel CWD e in tutte le sue directory principali.

Strutturare il codice sorgente

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 test che non richiedono alcun dispositivo

Puoi utilizzare l'opzione --host per Atest per eseguire solo i test configurati contro l'host che non richiedono 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 distinte:

atest [--test-mapping] --host

Identificare i gruppi di test

Puoi specificare i gruppi di test nel comando Atest. Il seguente comando esegue 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, l'esecuzione dei test in TEST_MAPPING con Atest esegue solo i test pre-invio configurati nel file TEST_MAPPING nel CWD (o nella directory specificata) e nelle relative directory principali. Se vuoi eseguire test in tutti i file TEST_MAPPING nelle sottodirectory, utilizza 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).

Commento a livello di riga supportato

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-elaborano TEST_MAPPING in un formato JSON valido senza commenti. Per mantenere pulito il file JSON, è supportato solo il commento in formato // a livello di riga.

Esempio:

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