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 assomiglia a out/host/linux-x86/cts ma differisce in base alla piattaforma. Ciò riflette il percorso in cui hai decompresso il CTS ufficiale precostruito scaricato da questo sito.
All'interno dello zip, il file test_result.xml contiene i risultati effettivi.
Visualizza i risultati di Android 10 e versioni successive
All'interno dell'archivio zip esiste un file test_result.html, puoi aprirlo direttamente in qualsiasi browser web compatibile con HTML5
Visualizza i risultati delle versioni precedenti ad Android 10
Aprire il file test_result.xml in qualsiasi browser Web compatibile con HTML5 per visualizzare i risultati del test
Se questo file visualizza una pagina vuota quando si utilizza il browser Chrome, modificare la configurazione del browser per abilitare 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 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 sul dispositivo (link sopra Riepilogo 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 visualizza le informazioni sul dispositivo.
Riepilogo della prova
La sezione Riepilogo test fornisce i dettagli del piano di test eseguito, come il nome del piano CTS e le ore di inizio e fine dell'esecuzione. Presenta inoltre un riepilogo aggregato del numero di test superati, falliti, scaduti o che non è stato possibile eseguire.
Riepilogo del test di esempio di Android 10 CTS
Figura 1: riepilogo del test di esempio di Android 10 CTS
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
Rapporto di prova
La sezione successiva, il rapporto di test CTS, fornisce un riepilogo dei test superati per 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, fallito, scaduto o non eseguito. In caso di fallimento del test, vengono forniti dettagli per aiutare a diagnosticare la causa.
Inoltre, l'analisi dello stack dell'errore è disponibile nel file XML ma non è inclusa nel report per garantire brevità: la visualizzazione del file XML con un editor di testo dovrebbe fornire dettagli sull'errore del test (cercare il tag [Test] corrispondente a il test fallito e cercare al suo interno il tag [StackTrace] ).
Mostra il rapporto di test di esempio CTS v2
Figura 4: Rapporto di prova campione CTS v2
Mostra il rapporto di test di esempio CTS v1
Figura 5: Rapporto di prova campione CTS v1
Esaminare 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 viene elencato per ciascuna sessione precedente. Per determinare quali moduli sono completi e quali incompleti, aprire il file test_result.xml e leggere il valore dell'attributo "done" per ciascun modulo nel report dei risultati. I moduli con valore done = "false" non sono stati eseguiti fino al completamento.
Fallimenti del test di triage
Utilizzare i seguenti suggerimenti per valutare gli errori dei test.
- Verifica che il tuo ambiente CTS sia configurato correttamente, se un test fallisce a causa di precondizioni errate. Ciò include l'ambiente fisico, la configurazione del computer desktop e la configurazione del dispositivo Android.
- Verifica la stabilità del dispositivo, la configurazione del test o i problemi ambientali, se un test appare eccessivamente instabile.
- Se il problema persiste, riprovare il test isolatamente.
- Verificare la presenza di fattori esterni che causano errori nei test, come ad esempio:
- Configurazione ambientale. Ad esempio, la configurazione di un computer desktop non configurato correttamente può essere la causa di errori di test che si verificano su tutti i dispositivi sottoposti a test (DUT) (inclusi i dispositivi di riferimento).
- Dipendenze esterne. Ad esempio, se un test fallisce su tutti i dispositivi in più siti a partire da un momento specifico, la colpa potrebbe essere un URL errato.
- Se il DUT non include la patch di sicurezza, è previsto il fallimento del test di sicurezza.
- Convalidare e analizzare le differenze tra i dispositivi che passano e quelli che falliscono.
- Analizzare l'asserzione, il registro, la segnalazione di bug 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 dei test.
Salva risultati parziali
Tradefed non salva i risultati parziali del test quando l'invocazione del test fallisce.
Quando Tradefed non genera alcun risultato del test, è implicito che si sia verificato un problema serio durante l'esecuzione del test, rendendo così il risultato del test inaffidabile. Il risultato parziale è ritenuto inutile in quanto non fornisce alcun valore durante l'analisi del problema del dispositivo.