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 suitegeneral-tests, anche se sono specifici per un ABI o una dimensione in bit o funzionalità hardware come HWASan (esiste un targetgeneral-testsseparato 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 sottovendor/. 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 comegeneral-testsanche 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
RootTargetPreparernelAndroidTest.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:
- Vai alla directory contenente il file
TEST_MAPPING. 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"
}
]
}