I risultati del test CTS vengono inseriti nel file:
CTS_ROOT/android-cts/results/start_time.zip
Se hai creato tu stesso il CTS, CTS_ROOT è simile a
out/host/linux-x86/cts, ma varia a seconda della piattaforma. Questo riflette il percorso in cui
hai decompresso la CTS ufficiale predefinita
scaricata da questo sito.
All'interno del file zip, il file test_result.xml contiene i risultati effettivi.
Visualizzare i risultati di Android 10 e versioni successive
Nel file ZIP è presente un file test_result.html che puoi aprire direttamente in qualsiasi browser web compatibile con HTML5.
Mostra risultati precedenti ad Android 10
Apri il file test_result.xml in qualsiasi browser web compatibile con HTML5 per visualizzare i risultati del test.
Se questo file mostra una pagina vuota quando utilizzi il browser Chrome,
modifica la configurazione del browser
per attivare il flag della riga di comando --allow-file-access-from-files.
Leggere i risultati del test
I dettagli dei risultati del test dipendono dalla versione di CTS che stai utilizzando:
- CTS v1 per Android 6.0 e versioni precedenti
- CTS v2 per Android 7.0 e versioni successive
Informazioni sul dispositivo
In CTS v1 e versioni precedenti, seleziona Informazioni dispositivo (link sopra il riepilogo del test) per visualizzare i dettagli sul dispositivo, sul firmware (marca, modello, build del firmware, piattaforma) e sull'hardware del dispositivo (risoluzione dello schermo, tastierino, tipo di schermo). CTS v2 non mostra le informazioni sul dispositivo.
Riepilogo dei test
La sezione Riepilogo test fornisce i dettagli del piano di test eseguito, ad esempio il nome del piano CTS e l'ora di inizio e fine dell'esecuzione. Viene inoltre presentato un riepilogo aggregato del numero di test superati, non superati, scaduti o che non è stato possibile eseguire.
Riepilogo del test di esempio CTS per Android 10
Figura 1: riepilogo del test di esempio CTS di Android 10
Riepilogo del test di esempio CTS v2
Figura 2: riepilogo del test di esempio CTS v2
Riepilogo del test di esempio di CTS v1
Figura 3: riepilogo del test di esempio CTS v1
Report del test
La sezione successiva, il report di test CTS, fornisce un riepilogo dei test superati per pacchetto.
Seguono i dettagli dei test effettivi eseguiti. Il report elenca il pacchetto di test, la suite di test, lo scenario di test e i test eseguiti. Mostra il risultato dell'esecuzione del test: superato, non superato, scaduto o non eseguito. In caso di errore del test, vengono forniti i dettagli per aiutarti a diagnosticare la causa.
Inoltre, la traccia dello stack dell'errore è disponibile nel file XML, ma non è inclusa nel report per garantire la brevità. La visualizzazione del file XML con un editor di testo dovrebbe fornire i dettagli dell'errore del test (cerca il tag [Test] corrispondente al test non riuscito e cerca al suo interno il tag [StackTrace]).
Mostra report di esempio del test CTS versione 2
Figura 4: report di test di esempio di CTS versione 2
Mostra report di test di esempio di CTS versione 1
Figura 5: report di test di esempio di CTS v1
Esamina test_result.xml per i moduli di test incompleti
Per determinare il numero di moduli incompleti in una determinata sessione di test, esegui il comando "list results". Il conteggio dei moduli completati e dei moduli totali è elencato per ogni sessione precedente. Per determinare quali moduli sono completi e quali incompleti, apri il file test_result.xml e leggi il valore dell'attributo "done" per ogni modulo nel report sui risultati. I moduli con valore done = "false" non sono stati eseguiti fino al completamento.
Eseguire il triage degli errori di test
Utilizza i seguenti suggerimenti per eseguire il triage degli errori di test.
- Verifica che il tuo ambiente CTS sia configurato correttamente, se un test non riesce a causa di precondizioni errate. Sono inclusi l'ambiente fisico, la configurazione della macchina desktop e la configurazione del dispositivo Android.
- Verifica la stabilità del dispositivo, la configurazione del test o i problemi ambientali, se un test sembra eccessivamente instabile.
- Se il test continua a non riuscire, riprova in isolamento.
- Controlla i fattori esterni che causano errori di test, ad esempio:
- Configurazione dell'ambiente. Ad esempio, una configurazione errata della macchina desktop potrebbe essere la causa degli errori di test che si verificano su tutti i dispositivi in test (DUT), inclusi i dispositivi di riferimento.
- Dipendenze esterne. Ad esempio, se un test non va a buon fine su tutti i dispositivi di più siti a partire da un momento specifico, la causa potrebbe essere un URL non valido.
- Se il DUT non include la patch di sicurezza, il test di sicurezza non riuscirà.
- Convalida e analizza le differenze tra i dispositivi che superano il test e quelli che non lo superano.
- Analizza l'asserzione, il log, il bug report e l'origine CTS. Per un HostTest, l'asserzione e il log possono essere molto generici, quindi è utile controllare e allegare anche il logcat del dispositivo.
- Invia una patch di miglioramento del test per contribuire a ridurre gli errori di test.
Salvare i risultati parziali
Tradefed non salva i risultati parziali del test quando l'invocazione del test non va a buon fine.
Quando Tradefed non genera risultati del test, si presume che si sia verificato un problema grave durante l'esecuzione del test, rendendo inaffidabile il risultato del test. Il risultato parziale è considerato inutile in quanto non fornisce valore durante l'analisi del problema del dispositivo.