I risultati del test CTS vengono inseriti nel file:
CTS_ROOT/android-cts/results/start_time.zip
Se hai creato il CTS autonomamente, CTS_ROOT è simile a
out/host/linux-x86/cts, ma varia in base alla piattaforma. Indica il percorso in cui hai scompattato 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
Nell'archivio ZIP è presente un file test_result.html, che puoi aprire direttamente in qualsiasi browser web compatibile con HTML5
Visualizza i 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.
Leggi i risultati del test
I dettagli dei risultati del test dipendono dalla versione di CTS utilizzata:
- 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 sul dispositivo (link sopra Riepilogo test) per visualizzare i dettagli del dispositivo, del firmware (marca, modello, build del firmware, piattaforma) e dell'hardware del dispositivo (risoluzione dello schermo, tastiera, tipo di schermo). La CTS v2 non visualizza 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 le ore di inizio e fine dell'esecuzione. Presenta anche un riepilogo aggregato del numero di test superati, non riusciti, scaduti o non eseguiti.
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 CTS v1
Figura 3: riepilogo del test di esempio CTS v1
Report del test
La sezione successiva, il report del test CTS, fornisce un riepilogo dei test superati per ciascun pacchetto.
Seguono i dettagli dei test effettivi che sono stati eseguiti. Il report elenca il pacchetto di test, la suite di test, il test case e i test eseguiti. Mostra il risultato dell'esecuzione del test: superato, non superato, timeout o non eseguito. In caso di esito negativo del test, vengono forniti 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 il report di test di esempio CTS v2
Figura 4: report di test di esempio CTS v2
Mostra il report di test di esempio CTS v1
Figura 5: report di test di esempio 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 "elenca risultati". Il conteggio dei moduli completati e dei moduli totali è elencato per ogni sessione precedente. Per determinare quali moduli sono completi e quali no, apri il file test_result.xml e leggi il valore dell'attributo "done" per ogni modulo nel report dei risultati. I moduli con valore done = "false" non sono stati eseguiti fino al completamento.
Riassegnazione degli errori di test
Utilizza i seguenti suggerimenti per eseguire il triage dei fallimenti del test.
- Verifica che il tuo ambiente CTS sia configurato correttamente, se un test non va a buon fine a causa di prerequisiti errati. Sono inclusi l'ambiente fisico, la configurazione del computer e la configurazione del dispositivo Android.
- Verifica la stabilità del dispositivo, la configurazione del test o i problemi dell'ambiente se un test sembra eccessivamente instabile.
- Riprova il test in isolamento se il problema persiste.
- Controlla la presenza di fattori esterni che causano errori di test, ad esempio:
- Configurazione dell'ambiente. Ad esempio, una configurazione errata del computer desktop potrebbe essere la causa di errori di test su tutti i dispositivi di 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 determinato momento, potrebbe essere colpa di un URL non valido.
- Se il DUT non include la patch di sicurezza, è previsto l'errore del test di sicurezza.
- Convalida e analizza le differenze tra i dispositivi che superano e non superano i test.
- Analizza l'affermazione, il log, il report di bug e la sorgente CTS. Per un test host, l'affermazione e il log possono essere molto generici, quindi è utile anche controllare e allegare il logcat del dispositivo.
- Invia una patch di miglioramento del test per contribuire a ridurre gli errori di test.
Salvare 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 di test, si presume che si sia verificato un grave problema durante l'esecuzione del test, rendendo quindi il risultato del test non attendibile. Il risultato parziale non è considerato utile perché non fornisce valore durante la ricerca del problema del dispositivo.