Questa pagina è stata tradotta dall'API Cloud Translation.

Test del programma di qualità drawElements

AOSP include la suite di test GPU drawElements Quality Program (deqp) presso https://android.googlesource.com/platform/external/deqp. Questa pagina descrive come eseguire il deployment della suite di test deqp in un nuovo ambiente.

Per lavorare con l'ultimo codice inviato, utilizza la filiale deqp-dev. Per il codice che corrisponde a una release CTS di Android specifica, utilizza la Ramo release-code-name-release (ad es. per Android 6.0, utilizza il ramo marshmallow-release).

Layout di origine

Il layout del codice sorgente per i moduli di test deqp e le librerie di supporto è mostrato nella tabella seguente (l'elenco non è esaustivo ma evidenzia le directory più importanti).

Directory	Descrizione
`android`	Origini dei tester Android e script di build
`data`	File di dati di test
`modules`	Origini moduli di test
`modules/egl`	Modulo EGL
`modules/gles2`	Modulo GLES2
`modules/gles3`	Modulo GLES3
`modules/gles31`	Modulo GLES3.1
`modules/gles32`	Modulo GLES3.2
`targets`	File di configurazione di compilazione specifici per la destinazione
`framework`	framework e utilità dei moduli di test deqp
`framework/delibs`	Portabilità di base e librerie di build
`framework/platform`	Porte della piattaforma
`framework/qphelper`	Libreria di integrazione del programma di test (C)
`framework/common`	Framework Deqp (C++)
`framework/opengl, framework/egl`	Utilità specifiche dell'API
`execserver`	Origine ExecServer lato dispositivo
`executor`	Strumento e utilità della shell dell'esecutore di test lato host
`external`	Crea una directory stub per le librerie libs esterne, libpng e zlib

Componenti open source

La deqp utilizza libpng e zlib, che possono essere recuperati utilizzando lo script platform/external/deqp/external/fetch_sources.py o tramite Git da platform/external/[libpng,zlib].

Creare programmi di test

Il framework di test è stato progettato pensando alla portabilità. L'unico I requisiti obbligatori sono il supporto completo C++ e le librerie di sistema standard I/O, thread e prese.

Sistema di build CMake

Le origini deqp hanno script di build per CMake, che è lo strumento preferito per la compilazione dei programmi dei test.

CMake è un sistema di compilazione open source che supporta più piattaforme e di strumenti. CMake genera file di makefile nativi o file di progetto IDE da di configurazione indipendenti dalla destinazione. Per ulteriori informazioni su CMake, consulta documentazione di CMake.

CMake supporta e consiglia build out-of-source-tree, ossia dovrebbero crea sempre makefile o file di progetto in una directory di build separata al di fuori dell'albero di origine. CMake non ha alcun tipo di "distclean" target, quindi la rimozione di eventuali file generati da CMake deve essere eseguita manualmente.

Le opzioni di configurazione vengono fornite a CMake utilizzando -DOPTION_NAME=VALUE a riga di comando. Di seguito sono elencate alcune delle opzioni di uso comune per deqp.

Opzione di configurazione Descrizione

Opzione di configurazione	Descrizione
`DEQP_TARGET`	Nome target, ad esempio "android" Gli script deqp CMake includeranno il file `targets/DEQP_TARGET/DEQP_TARGET.cmake` e si aspettano di trovare specifiche del target da qui.
`CMAKE_TOOLCHAIN_FILE`	Percorso del file della toolchain per CMake. Utilizzato per la compilazione incrociata.
`CMAKE_BUILD_TYPE`	Tipo di build per le destinazioni del file makefile. I valori validi sono: "Debug" e "Rilascia" Tieni presente che l'interpretazione e il tipo predefinito dipendono dal sistema di build scelto come target. Per informazioni dettagliate, consulta la documentazione di CMake.

DEQP_TARGET

Nome target, ad esempio "android"

Gli script deqp CMake includeranno il file targets/DEQP_TARGET/DEQP_TARGET.cmake e si aspettano di trovare specifiche del target da qui.

CMAKE_TOOLCHAIN_FILE

Percorso del file della toolchain per CMake. Utilizzato per la compilazione incrociata.

CMAKE_BUILD_TYPE

Tipo di build per le destinazioni del file makefile. I valori validi sono: "Debug" e "Rilascia"

Tieni presente che l'interpretazione e il tipo predefinito dipendono dal sistema di build scelto come target. Per informazioni dettagliate, consulta la documentazione di CMake.

Crea un file di build di destinazione

Il sistema di compilazione deqp è configurato per le nuove destinazioni che utilizzano i file di build di destinazione. Un file di build di destinazione definisce quali funzionalità sono supportate dalla piattaforma e quali librerie o sono necessari ulteriori percorsi di inclusione. I nomi dei file di destinazione seguono targets/NAME/NAME.cmake e il target viene selezionato utilizzando il parametro di build DEQP_TARGET.

I percorsi dei file nei file di destinazione sono relativi alla directory di base deqp, non alla Directory targets/NAME. Le seguenti variabili standard possono essere impostate dal file di build di destinazione.

Variabile	Descrizione
`DEQP_TARGET_NAME`	Nome destinazione (verrà incluso nei log di test)
`DEQP_SUPPORT_GLES2`	Se GLES2 è supportato (impostazione predefinita: OFF)
`DEQP_GLES2_LIBRARIES`	Librerie GLES2 (lasciare vuoto se non supportato o se viene utilizzato il caricamento dinamico)
`DEQP_SUPPORT_GLES3`	Se GLES3.x è supportato (impostazione predefinita: OFF)
`DEQP_GLES3_LIBRARIES`	Librerie GLES3.x (lasciare vuoto se non supportato o se viene utilizzato il caricamento dinamico)
`DEQP_SUPPORT_VG`	Se OpenVG è supportato (impostazione predefinita: OFF)
`DEQP_OPENVG_LIBRARIES`	Librerie OpenVG (lascia vuoto se non supportato o se viene utilizzato il caricamento dinamico)
`DEQP_SUPPORT_EGL`	Se EGL è supportato (impostazione predefinita: OFF)
`DEQP_EGL_LIBRARIES`	Librerie EGL (lascia vuoto se non supportato o se viene utilizzato il caricamento dinamico)
`DEQP_PLATFORM_LIBRARIES`	Per il collegamento sono necessarie ulteriori librerie specifiche della piattaforma
`DEQP_PLATFORM_COPY_LIBRARIES`	Elenco di librerie che vengono copiate in ogni directory di build binaria di test. Può essere utilizzate per copiare le librerie necessarie per l'esecuzione dei test, ma che non sono predefinite del percorso di ricerca.
`TCUTIL_PLATFORM_SRCS`	Elenco di origini delle porte della piattaforma. Le origini predefinite sono determinate in base e il sistema operativo. Nota: i percorsi sono relativi a: `framework/platform`

Il file di build di destinazione può aggiungere ulteriori percorsi di inclusione o di collegamento utilizzando il metodo Funzioni CMake include_directories() e link_directories().

Build Win32

Il modo più semplice per creare moduli deqp per Windows è usare la build CMake di un sistema operativo completo. È necessario CMake 2.6.12 o versioni successive e Microsoft Visual C/C++ come compilatore. Il deqp è stato testato con Visual Studio 2013.

I file di progetto Visual Studio possono essere generati con il comando seguente:

cmake path\to\src\deqp -G "Visual Studio 12"

È possibile creare una build a 64 bit selezionando "Visual Studio VERSION Win64" come build generatore:

cmake path\to\src\deqp -G "Visual Studio 12 Win64"

Puoi anche generare makefile NMake con l'opzione -G "NMake Makefiles" come tipo di build (-DCMAKE_BUILD_TYPE="Debug" o "Release").

Creazione del contesto di rendering

Il contesto di rendering può essere creato con WGL o con EGL su Windows.

Supporto WGL

Tutti i file binari Win32 supportano la creazione di contesti GL con WGL poiché richiede solo librerie standard. Il contesto WGL può essere selezionato utilizzando --deqp-gl-context-type=wgl dall'argomento della riga di comando. In modalità WGL, deqp utilizza WGL_EXT_create_context_es_profile per creare contesti OpenGL ES. Questa funzionalità è stata testata per funzionare i driver più recenti di NVIDIA e Intel. I driver AMD non supportano .

Supporto EGL

Il deqp viene creato con il caricamento dinamico per EGL su Windows se DEQP_SUPPORT_EGL su ON. Questa è l'impostazione predefinita nella maggior parte dei target. Quindi, se l'host ha librerie EGL disponibili, è possibile eseguire dei test usando la riga di comando parametro: --deqp-gl-context-type=egl

Build Android

La build Android utilizza gli script di build CMake per la creazione del codice di test nativo. le parti Java, ovvero Test Execution Server e Test Application Stub, vengono compilate con gli strumenti di build Android standard.

Per compilare programmi di test Deqp per Android con la build fornita sono necessari:

L'ultima versione di Android NDK il file android/scripts/common.py elenca la versione richiesta
SDK Android standalone con API 13, SDK Tools, SDK Platform-tools e SDK Pacchetti di strumenti di creazione installati
Apache Ant 1.9.4 (richiesto dalla build di codice Java)
CMake 2.8.12 o versioni successive
Python 2.6 o versioni successive della serie 2.x; Python 3.x non è supportato
Per Windows: NMake o JOM in PATH
- JOM consente build più veloci
(Facoltativo) La marca ninja è supportata anche su Linux

I file binari Ant e SDK si trovano in base alla variabile di ambiente PATH con alcune impostazioni predefinite che eseguono l'override. La logica è controllata da android/scripts/common.py.

La directory NDK deve essere ~/android-ndk-VERSION o C:/android/android-ndk-VERSION o definiti tramite ANDROID_NDK_PATH variabile di ambiente.

I componenti sul dispositivo, il servizio di esecuzione dei test e i programmi di test sono creato eseguendo lo script android/scripts/build.py. Il file .apk finale viene creato in android/package/bin e può essere installata tramite lo script install.py. Se esecutore a riga di comando, viene avviato ExecService con lo script launch.py sul dispositivo tramite ADB. Gli script possono essere eseguiti da qualsiasi directory.

Build Linux

È possibile creare file binari di test e utilità della riga di comando per Linux generando makefile utilizzando CMake. Esistono più target di build predefiniti che sono utili durante la creazione per Linux.

Target build	Descrizione
`default`	Target predefinito che utilizza l'introspezione della piattaforma CMake per determinare il supporto di varie API.
`x11_glx`	Utilizza GLX per creare contesti OpenGL (ES).
`x11_egl`	Utilizza EGL per creare contesti OpenGL (ES).
`x11_egl_glx`	Supporta GLX ed EGL con X11.

Usa sempre -DCMAKE_BUILD_TYPE=<Debug|Release> per definire il tipo di build. Release è un buon valore predefinito. In caso contrario, viene creata una build di release predefinita e non ottimizzata.

Gli argomenti della riga di comando -DCMAKE_C_FLAGS e -DCMAKE_CXX_FLAGS possono essere utilizzato per passare argomenti aggiuntivi al compilatore. Ad esempio, la build a 32 o 64 bit può essere eseguita impostando -DCMAKE_C(XX)_FLAGS="-m32" o "-m64" rispettivamente. In caso contrario specificata, viene utilizzata l’architettura nativa della toolchain, tipicamente a 64 bit sulla toolchain a 64 bit.

Puoi utilizzare gli argomenti -DCMAKE_LIBRARY_PATH e -DCMAKE_INCLUDE_PATH per fornire a CMake una libreria aggiuntiva o includere percorsi di ricerca.

Esempio di una riga di comando completa utilizzata per eseguire una build di debug a 32 bit su intestazioni e librerie dei driver in una posizione personalizzata sono le seguenti:

cmake <path to src>/deqp -DDEQP_TARGET=x11_egl -DCMAKE_C_FLAGS="-m32"
-DCMAKE_CXX_FLAGS="-m32" -DCMAKE_BUILD_TYPE=Debug
-DCMAKE_LIBRARY_PATH="PATH_TO_DRIVER/lib"
-DCMAKE_INCLUDE_PATH="PATH_TO_DRIVER/inc"
make -j4

Compilazione incrociata

La compilazione incrociata può essere ottenuta utilizzando un file Toolchain CMake. La toolchain specifica il compilatore da utilizzare, oltre ai percorsi di ricerca personalizzati librerie e intestazioni. Diversi file toolchain per scenari comuni sono incluso nel pacchetto di release nella directory framework/delibs/cmake.

Oltre alle variabili CMake standard, sono disponibili le seguenti variabili specifiche per deqp può essere impostato dal file toolchain. Solitamente, CMake riesce a rilevare DE_OS e DE_COMPILER e DE_PTR_SIZE correttamente, ma DE_CPU deve essere impostato dal file toolchain.

Variabile	Descrizione
`DE_OS`	Sistema operativo. I valori supportati sono: `DE_OS_WIN32, DE_OS_UNIX, DE_OS_WINCE, DE_OS_OSX, DE_OS_ANDROID, DE_OS_SYMBIAN, DE_OS_IOS`
`DE_COMPILER`	Tipo di compilatore. I valori supportati sono: `DE_COMPILER_GCC, DE_COMPILER_MSC, DE_COMPILER_CLANG`
`DE_CPU`	Tipo di CPU. I valori supportati sono: `DE_CPU_ARM, DE_CPU_X86`.
`DE_PTR_SIZE`	sizeof(void*) sulla piattaforma. I valori supportati sono 4 e 8

Il file toolchain può essere selezionato utilizzando il parametro di build CMAKE_TOOLCHAIN_FILE. Ad esempio, quanto segue consente di creare makefile per una build utilizzando il crosscompilatore CodeSourcery per ARM/Linux:

cmake PATH_TO_SRC/deqp –DDEQP_BUILD_TYPE="Release"
–DCMAKE_TOOLCHAIN_FILE=PATH_TO_SRC/delibs/cmake/toolchain-arm-cs.cmake
–DARM_CC_BASE=PATH_TO_CC_DIRECTORY

Collegamento runtime di librerie GLES ed EGL

La deqp non ha bisogno di entry point dell'API sottoposti a test durante il collegamento. La il codice di test accede sempre alle API tramite puntatori di funzione. Gli entry point possono possono essere caricati dinamicamente in fase di esecuzione oppure la porta della piattaforma può fornirli l'ora del collegamento.

Se il supporto per un'API è attivato nelle impostazioni di build e nelle librerie di link, se non viene fornito, deqp caricherà gli entry point necessari in fase di esecuzione. Se se si vuole creare un collegamento statico, fornisci le librerie di link necessarie nel DEQP_<API>_LIBRARIES la variabile di configurazione di compilazione.

Porta il framework di test

Il trasferimento di deqp prevede tre passaggi: adattamento delle librerie di portabilità di base, implementare le interfacce di integrazione delle piattaforme del framework di test e di esecuzione dei carichi di lavoro.

Nella tabella seguente sono elencate le località in cui potrebbero essere apportate probabili modifiche al trasferimento. Qualsiasi cosa al di là potrebbero risultare esotiche.

Posizione	Descrizione
`framework/delibs/debase framework/delibs/dethread framework/delibs/deutil`	Eventuali implementazioni necessarie di codice specifico del sistema operativo.
`framework/qphelper/qpCrashHandler.c`	(Facoltativo) Implementazione per il tuo sistema operativo.
`framework/qphelper/qpWatchDog.c`	Implementazione per il tuo sistema operativo. Quello attuale è basato su `dethread` e sulla libreria C standard.
`framework/platform`	È possibile implementare una nuova porta della piattaforma e uno stub dell'applicazione come descritto in Porta della piattaforma del framework di test.

Librerie di portabilità di base

Le librerie di portabilità di base supportano già Windows, la maggior parte delle varianti Linux, Mac OS iOS e Android. Se il target di test viene eseguito su uno di questi sistemi operativi, molto probabilmente non c'è alcun bisogno di toccare le librerie di portabilità di base.

Porta della piattaforma del framework di test

La porta della piattaforma del framework di test deqp richiede due componenti: un'applicazione un punto di ingresso e un'implementazione di un'interfaccia di piattaforma.

Il punto di ingresso dell'applicazione è responsabile della creazione dell'oggetto Platform, creazione di un oggetto della riga di comando (tcu::CommandLine), apertura di un log di test (tcu::TestLog) ed eseguire l'iterazione dell'applicazione di test (tcu::App). Se il sistema operativo di destinazione supporta un punto di ingresso main() standard, ma è possibile utilizzare tcuMain.cpp come implementazione del punto di ingresso.

L'API deqp platform è descritta in dettaglio nei file seguenti.

File	Descrizione
`framework/common/tcuPlatform.hpp`	Classe base per tutte le porte della piattaforma
`framework/opengl/gluPlatform.hpp`	Interfaccia della piattaforma OpenGL
`framework/egl/egluPlatform.hpp`	Interfaccia della piattaforma EGL
`framework/platform/tcuMain.cpp`	Punto di ingresso dell'applicazione standard

La classe base per tutte le porte della piattaforma è tcu::Platform. La porta della piattaforma supportano facoltativamente interfacce specifiche GL ed EGL. Consulta la tabella seguente per una panoramica di ciò che deve essere implementato eseguire i test.

Modulo	Interfaccia
Moduli di test OpenGL (ES)	Interfaccia della piattaforma GL
Modulo di test EGL	Interfaccia della piattaforma EGL

Istruzioni dettagliate per l'implementazione delle porte della piattaforma sono disponibili nel delle intestazioni degli strati di portabilità.

Servizio di esecuzione del test

Per utilizzare l'infrastruttura di esecuzione dei test deqp o l'esecutore a riga di comando, deve essere disponibile nella destinazione. Un C++ portatile del servizio viene fornita nella directory execserver. L'architettura indipendente il file binario è costruito come parte del modulo di test deqp per obiettivi basati su PC. Puoi modificare execserver/CMakeLists.txt per abilitare una build su altri obiettivi.

La versione C++ del servizio di esecuzione di test accetta due righe di comando parametri:

--port=<port> imposterà la porta TCP su cui il server rimane in ascolto. Il valore predefinito è 50016.
--single interromperà il processo del server alla disconnessione del client. Per impostazione predefinita, il processo server rimarrà attivo per gestire ulteriori richieste di esecuzione del test.

Esegui i test

Questa pagina fornisce istruzioni per eseguire test deqp in Linux e Windows ambienti, utilizzando argomenti della riga di comando e lavorando con pacchetto dell'applicazione.

Ambienti Linux e Windows

Inizia copiando i file e le directory seguenti nella destinazione.

Modulo	Directory	Target
Server di esecuzione	`build/execserver/execserver`	`<dst>/execserver`
Modulo EGL	`build/modules/egl/deqp-egl`	`<dst>/deqp-egl`
Modulo GLES2	`build/modules/gles2/deqp-gles2`	`<dst>/deqp-gles2`
Modulo GLES2	`data/gles2`	`<dst>/gles2`
Modulo GLES3	`build/modules/gles3/deqp-gles3`	`<dst>/deqp-gles3`
Modulo GLES3	`data/gles3`	`<dst>/gles3`
Modulo GLES3.1	`build/modules/gles31/deqp-gles31`	`<dst>/deqp-gles31`
Modulo GLES3.1	`data/gles31`	`<dst>/gles31`
Modulo GLES3.2	`build/modules/gles32/deqp-gles32`	`<dst>/deqp-gles32`
Modulo GLES3.2	`data/gles32`	`<dst>/gles32`

Puoi eseguire il deployment del servizio di esecuzione e testare i file binari in qualsiasi punto della destinazione file system; tuttavia, i file binari di test si aspettano di trovare le directory di dati nella directory di lavoro attuale. Quando è tutto pronto, avvia Test Execution Service sulla dispositivo di destinazione. Per maggiori dettagli su come avviare il servizio, consulta Prova di esecuzione del codice.

Argomenti della riga di comando

La tabella seguente elenca gli argomenti della riga di comando che influiscono sull'esecuzione di tutti gli programmi di test.

Argomento	Descrizione
`--deqp-case=<casename>`	Esegui richieste che corrispondono a un determinato pattern. Il carattere jolly (*) è supportato.
`--deqp-log-filename=<filename>`	Scrivi i risultati del test nel file di cui fornisci il nome. L'esecuzione del test imposterà il nome file all'avvio di un test.
`--deqp-stdin-caselist --deqp-caselist=<caselist> --deqp-caselist-file=<filename>`	Leggi l'elenco di richieste da stdin o da un determinato argomento. L'esecuzione del test servizio imposterà l'argomento in base alla richiesta di esecuzione ricevuta. Consulta nella sezione successiva per una descrizione del formato dell'elenco di richieste.
`--deqp-test-iteration-count=<count>`	Esegui l'override del conteggio delle iterazioni per i test che supportano un numero variabile di di Google Cloud.
`--deqp-base-seed=<seed>`	Seed di base per gli scenari di test che utilizzano la randomizzazione.

Argomenti specifici per GLES2 e GLES3

Nella tabella seguente sono elencati gli argomenti specifici per GLES2 e GLES3.

Argomento	Descrizione
`--deqp-gl-context-type=<type>`	Tipo di contesto OpenGL. I tipi di contesto disponibili dipendono dalla piattaforma. Attivato piattaforme che supportano EGL, è possibile utilizzare il valore `egl` per selezionare contesto EGL.
`--deqp-gl-config-id=<id>`	Esegui i test per l'ID configurazione GL fornito. L'interpretazione è dipende dalla piattaforma. Sulla piattaforma EGL, questo è l'ID configurazione EGL.
`--deqp-gl-config-name=<name>`	Esegui test per una configurazione GL denominata. L'interpretazione è dipende dalla piattaforma. Per EGL, il formato è `rgb(a)<bits>d<bits>s<bits>`. Ad esempio, un il valore `rgb888s8` selezionerà la prima configurazione in cui il buffer di colore è RGB888 e il buffer dello stencil ha 8 bit.
`--deqp-gl-context-flags=<flags>`	Crea un contesto. Specifica `robust` o `debug`.
`--deqp-surface-width=<width> --deqp-surface-height=<height>`	Prova a creare una superficie con determinate dimensioni. Il supporto in questo campo è facoltativo.
`--deqp-surface-type=<type>`	Utilizza un determinato tipo di superficie come target di rendering principale di prova. Possibile tipi sono `window`, `pixmap`, `pbuffer`, e `fbo`.
`--deqp-screen-rotation=<rotation>`	Orientamento dello schermo in incrementi di 90 gradi per piattaforme che supportarlo.

Formato dell'elenco di scenari di test

L'elenco degli scenari di test può essere fornito in due formati. La prima è elencare il nome completo di ogni test su una riga separata in un file ASCII standard. Come crescono, i prefissi ripetitivi possono risultare complessi. Per evitare di ripetere i prefissi, utilizza la sintassi trie (nota anche come struttura ad albero dei prefissi) mostrata di seguito.

{nodeName{firstChild{…},…lastChild{…}}}

Ad esempio:

{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}

Viene tradotto nei seguenti due scenari di test:

dEQP-EGL.config_list
dEQP-EGL.create_context.rgb565_depth_stencil

Android

Il pacchetto dell'app Android contiene tutti i componenti necessari, inclusi il servizio di esecuzione del test, i programmi binari di test e i file di dati. L'attività di test è un NativeActivity che utilizza EGL (richiede Android 3.2 o versioni successive).

Il pacchetto dell'applicazione può essere installato con il seguente comando (nome mostrato è il nome dell'APK nel pacchetto Android CTS; da quale nome dipende la build):

adb –d install –r com.drawelements.deqp.apk

Per avviare il servizio di esecuzione del test e configurare il port forwarding, utilizza seguenti:

adb –d forward tcp:50016 tcp:50016
adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter

Le stampe di debug possono essere abilitate eseguendo questo comando prima di avviare Test:

adb –d shell setprop log.tag.dEQP DEBUG

Esegui test su Android senza CTS di Android

Per avviare manualmente l'attività di esecuzione del test, crea un intent Android che ha come target android.app.NativeActivity. Le attività possono essere presente nel pacchetto com.drawelements.deqp. La riga di comando deve come stringa aggiuntiva con la chiave "cmdLine" nell'intent.

Un log di test viene scritto in /sdcard/dEQP-log.qpa. Se il test viene eseguito non si avvia normalmente, nel dispositivo sono disponibili ulteriori informazioni di debug log.

Puoi avviare un'attività dalla riga di comando utilizzando l'am utilità. Ad esempio, per eseguire dEQP-GLES2.info test su una piattaforma che supportano NativeActivity, usano i seguenti comandi.

adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e \
'cmdLine "deqp --deqp-case=dEQP-GLES2.info.* --deqp-log-filename=/sdcard/dEQP-Log.qpa"'

Debug su Android

Per eseguire i test nel debugger GDB su Android, devi prima compilare e installare la build di debug eseguendo i due script seguenti:

python android/scripts/build.py --native-build-type=Debug
python android/scripts/install.py

Dopo aver installato la build di debug sul dispositivo, per avviare i test in GDB in esecuzione sull'host, esegui questo comando:

python android/scripts/debug.py \
--deqp-commandline="--deqp-log-filename=/sdcard/TestLog.qpa --deqp-case=dEQP-GLES2.functional.*"

La riga di comando deqp dipende dagli scenari di test da eseguire e da altre parametri obbligatori. Lo script aggiunge un punto di interruzione predefinito all'inizio l'esecuzione deqp (tcu::App::App).

Lo script debug.py accetta più argomenti della riga di comando per azioni come l'impostazione di punti di interruzione per il debug, la connessione gdbserver parametri e percorsi di ulteriori programmi binari di cui eseguire il debug (utilizza debug.py --help per tutti gli argomenti e le spiegazioni). Lo script copia anche librerie predefinite dal dispositivo di destinazione per recuperare elenchi di simboli.

Per analizzare il codice del driver (ad esempio quando il GDB deve conoscere le posizioni dei file binari con informazioni di debug complete), aggiungi altre librerie tramite Parametri della riga di comando debug.py. Questo script scrive un per il GDB a partire dalla riga 132 del file di script. Tu può fornire percorsi aggiuntivi ai file binari, ecc., ma fornendo il comando corretto di riga di comando dovrebbero essere sufficienti.

Nota: su Windows, il file binario GDB richiede libpython2.7.dll. Prima di avviare debug.py, aggiungi <path-to-ndk>/prebuilt/windows/bin alla variabile PATH.

Nota: il debug nativo del codice non funziona Android 4.3; per conoscere le soluzioni alternative, consulta l'articolo di questo bug pubblico. Android 4.4 e versioni successive non contengono questo bug.

Automatizza i test

I moduli di test Deqp possono essere integrati nei sistemi di test automatizzati in diversi modi. L'approccio migliore dipende dall'infrastruttura di test esistente e dal target completamente gestito di Google Cloud.

L'output principale di un'esecuzione di test è sempre il file di log del test, ovvero il file con un postfisso .qpa. I risultati completi del test possono essere analizzati dal log di test. L'output della console è solo informazioni di debug e potrebbero non essere disponibili su tutte le piattaforme.

I file binari di test possono essere richiamati direttamente da un sistema di automazione di test. Il test binario può essere avviato per un caso specifico, per un set di test o disponibili. Se si verifica un errore irreversibile durante l'esecuzione (ad esempio, una determinata API errori o un arresto anomalo), l'esecuzione del test verrà interrotta. Per i test di regressione, l'approccio migliore consiste nel richiamare i file binari di test per casi singoli o per piccoli test vengono impostati separatamente, in modo da avere risultati parziali disponibili anche nel caso di problemi gravi.

Deqp include strumenti di esecuzione dei test a riga di comando che possono essere utilizzati la combinazione con il servizio di esecuzione per ottenere un'integrazione più solida. L'esecutore rileva la terminazione del processo di test e riprenderà l'esecuzione il giorno la prossima richiesta disponibile. Dal test completo viene generato un singolo file di log durante la sessione. Questa configurazione è ideale per sistemi di test leggeri che non offrono servizi di ripristino di emergenza.

Strumenti di esecuzione dei test a riga di comando

Il set di strumenti a riga di comando corrente include uno strumento di esecuzione di test generatore di confronto tra log per l'analisi di regressione, un convertitore da test-log-to-CSV un convertitore test-log-to-XML e un convertitore testlog-to-JUnit.

Il codice sorgente di questi strumenti si trova nella directory executor e i file binari sono nella directory <builddir>/executor.

Esecutore test riga di comando

L'esecutore di test della riga di comando è uno strumento C++ portatile per avviare un'esecuzione di test su un dispositivo e raccogliendo i log risultanti da quest'ultimo tramite TCP/IP. L'esecutore comunica con il servizio di esecuzione (execserver) sul dispositivo di destinazione. Insieme offrono funzionalità quali il ripristino da arresti anomali dei processi di test. I seguenti esempi mostrano come utilizzare Test Executor della riga di comando (utilizza --help per ulteriori dettagli):

Esempio 1: eseguire test di funzionamento GLES2 su un dispositivo Android

executor --connect=127.0.0.1 --port=50016 --binaryname=
com.drawelements.deqp/android.app.NativeActivity
--caselistdir=caselists
--testset=dEQP-GLES2.* --out=BatchResult.qpa
--cmdline="--deqp-crashhandler=enable --deqp-watchdog=enable
--deqp-gl-config-name=rgba8888d24s8"

Esempio 2: continuare un'esecuzione parziale di un test OpenGL ES 2 in locale

executor --start-server=execserver/execserver --port=50016
--binaryname=deqp-gles2 --workdir=modules/opengl
--caselistdir=caselists
--testset=dEQP-GLES2.* --exclude=dEQP-GLES2.performance.* --in=BatchResult.qpa
--out=BatchResult.qpa

Testa l'esportazione in formato CSV dei log di test e confronta

Il deqp dispone di uno strumento per convertire i log di test (file .qpa) in file CSV. Il file CSV l'output contiene un elenco di scenari di test e le relative che consentono di analizzare i dati e visualizzare i risultati. Lo strumento può anche confrontare due o più risultati in batch ed elencare solo i scenari di test con codici di stato diversi nei risultati del batch di input. La verrà stampato anche il numero di richieste corrispondenti.

L'output in formato CSV è molto pratico per l'ulteriore elaborazione con utilità a riga di comando o con un editor di fogli di lavoro. Un'aggiunta aggiuntiva, leggibile il formato di testo normale può essere selezionato utilizzando il seguente argomento della riga di comando: --format=text

Esempio 1: esportare il log di test in formato CSV

testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csv
testlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv

Esempio 2: elencare le differenze dei risultati dei test tra due log di test

testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa

Nota: l'argomento --value=code restituisce il test codice risultato, ad esempio "Superato" o "Non superato". L'argomento --value=details seleziona l'ulteriore Spiegazione del risultato o del valore numerico prodotto da un test di prestazioni, capacità o accuratezza.

Test dell'esportazione XML dei log

I file di log di test possono essere convertiti in documenti XML validi utilizzando l'testlog-to-xml utilità. Sono supportate due modalità di output:

Modalità documenti separati, in cui ogni scenario di test e il riepilogo caselist.xml i documenti sono scritti in una directory di destinazione
Modalità file singolo, in cui tutti i risultati nel file .qpa vengono scritti in un unico documento XML.

I file dei log di test esportati possono essere visualizzati in un browser utilizzando un foglio di stile XML. Vengono forniti documenti di esempio del foglio di stile (testlog.xsl e testlog.css) nella directory doc/testlog-stylesheet. Per eseguire il rendering dei file di log in un browser, copia di due fogli di stile nella stessa directory in cui si trovano i documenti XML esportati.

Se utilizzi Google Chrome, è necessario che l'accesso ai file avvenga tramite HTTP come Chrome limita l'accesso ai file in locale per motivi di sicurezza. L'installazione Python standard include un server HTTP di base che può essere avviato per pubblicare lo stato con il comando python –m SimpleHTTPServer 8000. Dopo aver avviato il server, Apri il browser Chrome su http://localhost:8000 per visualizzare il log del test.

Conversione in un log di test JUnit

Molti sistemi di automazione dei test possono generare report sui risultati dei test dalla JUnit come output. I file di log di test deqp possono essere convertiti nel formato di output JUnit usando lo strumento testlog-to-junit.

Al momento lo strumento supporta solo la traduzione dell'esito dello scenario di test. Come JUnit supporta solo "pass" e "fail" dei risultati, un risultato positivo di deqp viene mappato a "JUnit pass" mentre altri sono considerati errori. Il deqp originale sia disponibile il codice risultato nell'output JUnit. Altri dati, ad esempio i messaggi di log e le immagini dei risultati non vengono conservate nella conversione.

Utilizza gruppi di test speciali

Alcuni gruppi di test potrebbero richiedere o supportare opzioni speciali della riga di comando particolare attenzione se utilizzata in determinati sistemi.

Stress test per l'allocazione della memoria

Gli stress test relativi all'allocazione della memoria si esercitano in condizioni di esaurimento della memoria ripetutamente l'allocazione di determinate risorse finché il driver segnala un errore di memoria insufficiente.

Su alcune piattaforme, come Android e la maggior parte delle varianti Linux, quanto segue: che possono verificarsi: il sistema operativo potrebbe terminare il processo di test anziché consentire o fornire un errore di esaurimento della memoria. In corrispondenza di tali piattaforme, i test progettati per causare errori di esaurimento della memoria sono disattivati per impostazione predefinita e deve essere abilitato utilizzando l'argomento della riga di comando --deqp-test-oom=enable. Ti consigliamo di eseguire questi test manualmente per verifica se il sistema funziona correttamente sotto la pressione delle risorse. Tuttavia, in tali una situazione, un arresto anomalo del processo di test dovrebbe essere interpretato come una riuscita.

Gruppi di test

dEQP-GLES2.stress.memory.*
dEQP-GLES3.stress.memory.*

Test di stress del rendering di lunga durata

I test di stress del rendering sono progettati per rivelare problemi di robustezza in caso di carico di rendering. Per impostazione predefinita i test vengono eseguiti solo poche iterazioni, possono essere configurati per l'esecuzione a tempo indeterminato fornendo il valore --deqp-test-iteration-count=-1 dall'argomento della riga di comando. Il watchdog di test deve essere disattivato (--deqp-watchdog=disable) quando esegui questi test per un lungo periodo di tempo.

Gruppi di test

dEQP-GLES2.stress.long.*
dEQP-GLES3.stress.long.*