AOSP include la suite di test GPU drawElements Quality Program (deqp) all'indirizzo https://android.googlesource.com/platform/external/deqp . Questa pagina descrive in dettaglio come distribuire la suite di test deqp in un nuovo ambiente.
Per lavorare con l'ultimo codice inviato, utilizzare il ramo deqp-dev . Per il codice che corrisponde a una specifica versione di Android CTS, utilizzare il ramo release-code-name -release (ad esempio, per Android 6.0, utilizzare il ramo marshmallow-release ).
Disposizione della sorgente
Il layout del codice sorgente per i moduli di test deqp e le librerie di supporto è mostrato nella tabella seguente (l'elenco non è completo ma evidenzia le directory più importanti).
| Direttorio | Descrizione |
|---|---|
android | Origini dei tester Android e script di creazione |
data | Testare i file di dati |
modules | Testare le sorgenti dei moduli |
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 della build specifici della destinazione |
framework | framework e utilità del modulo di test deqp |
framework/delibs | Portabilità di base e creazione di librerie |
framework/platform | Porte della piattaforma |
framework/qphelper | Libreria di integrazione del programma di test (C) |
framework/common | Quadro Deqp (C++) |
framework/opengl, framework/egl | Utilità specifiche dell'API |
execserver | Origine ExecServer lato dispositivo |
executor | Strumento e utilità per la shell dell'esecutore di test lato host |
external | Crea la directory stub per le librerie esterne libpng e zlib |
Componenti open source
Il 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] .
Costruisci programmi di test
Il framework di test è stato progettato pensando alla portabilità. Gli unici requisiti obbligatori sono il supporto completo di C++ e le librerie di sistema standard per I/O, thread e socket.
Sistema di compilazione CMake
I sorgenti deqp dispongono di script di build per CMake, che è lo strumento preferito per compilare i programmi di test.
CMake è un sistema di compilazione open source che supporta più piattaforme e toolchain. CMake genera makefile nativi o file di progetto IDE da file di configurazione indipendenti dalla destinazione. Per ulteriori informazioni su CMake, vedere la documentazione di CMake .
CMake supporta e consiglia build fuori dall'albero dei sorgenti, ovvero dovresti sempre creare makefile o file di progetto in una directory di build separata all'esterno dell'albero dei sorgenti. CMake non ha alcun tipo di destinazione "distclean", quindi la rimozione di tutti i file generati da CMake deve essere eseguita manualmente.
Le opzioni di configurazione vengono fornite a CMake utilizzando la sintassi -D OPTION_NAME = VALUE . Di seguito sono elencate alcune opzioni comunemente utilizzate per deqp.
| Opzione di configurazione | Descrizione |
|---|---|
DEQP_TARGET | Nome di destinazione, ad esempio: "android" Gli script deqp CMake includeranno il file |
CMAKE_TOOLCHAIN_FILE | Percorso del file della toolchain per CMake. Utilizzato per la compilazione incrociata. |
CMAKE_BUILD_TYPE | Tipo di build per destinazioni makefile. I valori validi sono: "Debug" e "Release" Tieni presente che l'interpretazione e il tipo predefinito dipendono dal sistema di compilazione di destinazione. Consulta la documentazione di CMake per i dettagli. |
Crea un file di build di destinazione
Il sistema di build deqp è configurato per nuove destinazioni utilizzando i file di build di destinazione. Un file di build di destinazione definisce quali funzionalità supporta la piattaforma e quali librerie o percorsi di inclusione aggiuntivi sono richiesti. I nomi dei file di destinazione seguono il formato targets/ NAME / NAME .cmake e la destinazione viene selezionata 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 del target (verrà incluso nei registri dei 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 (lasciare 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 (lasciare vuoto se non supportato o se viene utilizzato il caricamento dinamico) |
DEQP_PLATFORM_LIBRARIES | Librerie aggiuntive specifiche della piattaforma necessarie per il collegamento |
DEQP_PLATFORM_COPY_LIBRARIES | Elenco delle librerie copiate in ciascuna directory di compilazione del binario di test. Può essere utilizzato per copiare le librerie necessarie per l'esecuzione dei test ma non presenti nel percorso di ricerca predefinito. |
TCUTIL_PLATFORM_SRCS | Elenco delle origini delle porte della piattaforma. Le origini predefinite vengono determinate in base alle funzionalità e al sistema operativo. Nota: i percorsi sono relativi a: |
Il file di build di destinazione può aggiungere ulteriori percorsi di inclusione o collegamento utilizzando le funzioni CMake include_directories() e link_directories() .
Compilazione Win32
Il modo più semplice per creare moduli deqp per Windows è utilizzare il sistema di compilazione CMake. Avrai bisogno di CMake 2.6.12 o versione successiva e del compilatore Microsoft Visual C/C++. Il deqp è stato testato con Visual Studio 2013.
I file di progetto di Visual Studio possono essere generati con il seguente comando:
cmake path\to\src\deqp -G "Visual Studio 12"
È possibile creare una build a 64 bit selezionando "Visual Studio VERSION Win64" come generatore di build:
cmake path\to\src\deqp -G "Visual Studio 12 Win64"
Puoi anche generare makefile NMake con l'opzione -G "NMake Makefiles" così come il 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 binari Win32 supportano la creazione del contesto GL con WGL poiché richiede solo librerie standard. Il contesto WGL può essere selezionato utilizzando l'argomento della riga di comando --deqp-gl-context-type=wgl . Nella modalità WGL, deqp utilizza l'estensione WGL_EXT_create_context_es_profile per creare contesti OpenGL ES. Questo è stato testato per funzionare con i driver più recenti di NVIDIA e Intel. I driver AMD non supportano l'estensione richiesta.
Supporto EGL
Il deqp è creato con caricamento dinamico per EGL su Windows se DEQP_SUPPORT_EGL è ON. Questa è l'impostazione predefinita nella maggior parte dei target. Quindi, se l'host ha a disposizione le librerie EGL, è possibile eseguire dei test con esse con il parametro della riga di comando: --deqp-gl-context-type=egl
Costruzione Android
La build Android utilizza gli script di build CMake per creare il codice di test nativo. Le parti Java, ovvero il Test Execution Server e lo Stub dell'applicazione di test, vengono compilate utilizzando gli strumenti di build Android standard.
Per compilare programmi di test deqp per Android con gli script di build forniti, avrai bisogno di:
- L'ultima versione di Android NDK ; il file
android/scripts/common.pyelenca la versione richiesta - SDK autonomo Android con API 13, strumenti SDK, strumenti della piattaforma SDK e pacchetti di strumenti di creazione SDK installati
- Apache Ant 1.9.4 (richiesto dalla build del codice Java)
- CMake 2.8.12 o versione successiva
- Python 2.6 o successivo nella serie 2.x; Python 3.x non è supportato
- Per Windows: NMake o JOM in
PATH- JOM consente build più veloci
- Opzionale: Ninja make è supportato anche su Linux
I file binari Ant e SDK si trovano in base alla variabile di ambiente PATH con alcune impostazioni predefinite prioritarie. La logica è controllata da android/scripts/common.py .
La directory NDK deve essere ~/android-ndk- VERSION o C:/android/android-ndk- VERSION o definita tramite la variabile di ambiente ANDROID_NDK_PATH .
I componenti Deqp sul dispositivo, il servizio di esecuzione dei test e i programmi di test vengono creati eseguendo lo script android/scripts/build.py . Il file .apk finale viene creato in android/package/bin e può essere installato tramite lo script install.py . Se viene utilizzato l' eseguitore della riga di comando , ExecService viene avviato con lo script launch.py sul dispositivo tramite ADB. Gli script possono essere eseguiti da qualsiasi directory.
Compilazione di Linux
È possibile creare file binari di test e utilità della riga di comando per Linux generando makefile utilizzando CMake. Esistono più destinazioni di compilazione predefinite utili durante la compilazione per Linux.
| Costruisci obiettivo | Descrizione |
|---|---|
default | Destinazione predefinita che utilizza l'introspezione della piattaforma CMake per determinare il supporto per varie API. |
x11_glx | Utilizza GLX per creare contesti OpenGL (ES). |
x11_egl | Utilizza EGL per creare contesti OpenGL (ES). |
x11_egl_glx | Supporta sia GLX che EGL con X11. |
Utilizzare sempre -DCMAKE_BUILD_TYPE=<Debug|Release> per definire il tipo di build. Release è una buona impostazione predefinita. Senza di essa, viene creata una build di rilascio predefinita e non ottimizzata.
Gli argomenti della riga di comando -DCMAKE_C_FLAGS e -DCMAKE_CXX_FLAGS possono essere utilizzati per passare argomenti aggiuntivi al compilatore. Ad esempio, la build a 32 o 64 bit può essere eseguita impostando rispettivamente -DCMAKE_C(XX)_FLAGS="-m32" o "-m64" . Se non specificato, viene utilizzata l'architettura nativa della toolchain, in genere a 64 bit sulla toolchain a 64 bit.
Gli argomenti -DCMAKE_LIBRARY_PATH e -DCMAKE_INCLUDE_PATH possono essere utilizzati per CMake per fornire a CMake una libreria aggiuntiva o includere percorsi di ricerca.
Un esempio di riga di comando completa utilizzata per eseguire una build di debug a 32 bit rispetto alle intestazioni e alle librerie dei driver in una posizione personalizzata è il seguente:
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 della toolchain CMake. Il file della toolchain specifica il compilatore da utilizzare, insieme ai percorsi di ricerca personalizzati per librerie e intestazioni. Diversi file della toolchain per scenari comuni sono inclusi nel pacchetto di rilascio nella directory framework/delibs/cmake .
Oltre alle variabili CMake standard, le seguenti variabili specifiche di deqp possono essere impostate dal file della toolchain. CMake in genere può rilevare correttamente DE_OS , DE_COMPILER e DE_PTR_SIZE ma DE_CPU deve essere impostato dal file della toolchain.
| Variabile | Descrizione |
|---|---|
DE_OS | Sistema operativo. I valori supportati sono: |
DE_COMPILER | Tipo di compilatore. I valori supportati sono: |
DE_CPU | Tipo di CPU. I valori supportati sono: |
DE_PTR_SIZE | sizeof(void*) sulla piattaforma. I valori supportati sono: 4 e 8 |
Il file della toolchain può essere selezionato utilizzando il parametro di build CMAKE_TOOLCHAIN_FILE . Ad esempio, quanto segue creerebbe makefile per una build utilizzando il compilatore incrociato 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 delle librerie GLES ed EGL
Il deqp non necessita di punti di ingresso dell'API sotto test durante il collegamento. Il codice di test accede sempre alle API tramite puntatori a funzione. I punti di ingresso possono quindi essere caricati dinamicamente in fase di esecuzione oppure la porta della piattaforma può fornirli in fase di collegamento.
Se il supporto per un'API è attivato nelle impostazioni di build e le librerie di collegamento non vengono fornite, deqp caricherà i punti di ingresso necessari in fase di esecuzione. Se si desidera il collegamento statico, fornire le librerie di collegamento necessarie nella variabile di configurazione della build DEQP_<API>_LIBRARIES .
Portare il framework di test
Il porting del deqp prevede tre passaggi: adattamento delle librerie di portabilità di base, implementazione delle interfacce di integrazione della piattaforma del framework di test e porting del servizio di esecuzione.
La tabella seguente elenca le posizioni per le probabili modifiche al porting. Tutto ciò che va oltre è probabile che sia esotico.
| Posizione | Descrizione |
|---|---|
framework/delibs/debase | Eventuali implementazioni necessarie del 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 |
framework/platform | La nuova porta della piattaforma e lo stub dell'applicazione possono essere implementati 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 la destinazione del test viene eseguita su uno di questi sistemi operativi, molto probabilmente non è necessario toccare le librerie di portabilità di base.
Porta della piattaforma del framework di test
Il port della piattaforma del framework di test deqp richiede due componenti: un punto di ingresso dell'applicazione e un'implementazione dell'interfaccia della piattaforma.
Il punto di ingresso dell'applicazione è responsabile della creazione dell'oggetto piattaforma, della creazione di un oggetto della riga di comando ( tcu::CommandLine ), dell'apertura di un log di test ( tcu::TestLog ) e dell'iterazione dell'applicazione di test ( tcu::App ). Se il sistema operativo di destinazione supporta un punto di ingresso main() standard, tcuMain.cpp può essere utilizzato come implementazione del punto di ingresso.
L'API della piattaforma deqp è descritta in dettaglio nei seguenti file.
| 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 può facoltativamente supportare interfacce specifiche GL ed EGL. Vedere la tabella seguente per una panoramica di ciò che è necessario implementare per eseguire i test.
| Modulo | Interfaccia |
|---|---|
Moduli di test OpenGL (ES). | Interfaccia della piattaforma GL |
Modulo di prova EGL | Interfaccia della piattaforma EGL |
Istruzioni dettagliate per l'implementazione delle porte della piattaforma si trovano nelle intestazioni del livello di porting.
Servizio di esecuzione dei test
Per utilizzare l'infrastruttura di esecuzione del test deqp o l'esecutore della riga di comando, il servizio di esecuzione del test deve essere disponibile sulla destinazione. Un'implementazione C++ portatile del servizio viene fornita nella directory execserver . Il file binario autonomo è creato come parte del modulo di test deqp creato per target PC. È possibile modificare execserver/CMakeLists.txt per abilitare una compilazione su altre destinazioni.
La versione C++ del servizio di esecuzione del test accetta due parametri della riga di comando:
-
--port=<port>imposterà la porta TCP su cui è in ascolto il server. Il valore predefinito è 50016. -
--singleterminerà il processo del server quando il client si disconnette. Per impostazione predefinita, il processo del server rimarrà attivo per soddisfare ulteriori richieste di esecuzione del test.
Esegui i test
Questa pagina fornisce istruzioni per eseguire test deqp in ambienti Linux e Windows, utilizzando argomenti della riga di comando e lavorando con il pacchetto dell'applicazione Android.
Ambienti Linux e Windows
Inizia copiando i seguenti file e directory nella destinazione.
| Modulo | Direttorio | Bersaglio |
|---|---|---|
| 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 |
data/gles2 | <dst>/gles2 | |
| Modulo GLES3 | build/modules/gles3/deqp-gles3 | <dst>/deqp-gles3 |
data/gles3 | <dst>/gles3 | |
| Modulo GLES3.1 | build/modules/gles31/deqp-gles31 | <dst>/deqp-gles31 |
data/gles31 | <dst>/gles31 | |
| Modulo GLES3.2 | build/modules/gles32/deqp-gles32 | <dst>/deqp-gles32 |
data/gles32 | <dst>/gles32 |
È possibile distribuire il servizio di esecuzione e testare i file binari ovunque nel file system di destinazione; tuttavia, i file binari di test si aspettano di trovare le directory dei dati nella directory di lavoro corrente. Quando sei pronto, avvia il servizio di esecuzione test sul dispositivo di destinazione. Per dettagli sull'avvio del servizio, vedere Servizio di esecuzione del test .
Argomenti della riga di comando
La seguente tabella elenca gli argomenti della riga di comando che influiscono sull'esecuzione di tutti i programmi di test.
| Discussione | Descrizione |
|---|---|
--deqp-case=<casename> | Esegui casi che corrispondono a un determinato modello. Il carattere jolly (*) è supportato. |
--deqp-log-filename=<filename> | Scrivi i risultati del test nel file di cui fornisci il nome. Il servizio di esecuzione del test imposterà il nome del file all'avvio di un test. |
--deqp-stdin-caselist | Leggi l'elenco dei casi da stdin o da un determinato argomento. Il servizio di esecuzione del test imposterà l'argomento in base alla richiesta di esecuzione ricevuta. Vedere la sezione successiva per una descrizione del formato dell'elenco dei casi. |
--deqp-test-iteration-count=<count> | Sostituisci il conteggio delle iterazioni per i test che supportano un numero variabile di iterazioni. |
--deqp-base-seed=<seed> | Seme di base per i casi di test che utilizzano la randomizzazione. |
Argomenti specifici di GLES2 e GLES3
La seguente tabella elenca gli argomenti specifici di GLES2 e GLES3.| Discussione | Descrizione |
|---|---|
--deqp-gl-context-type=<type> | Tipo di contesto OpenGL. I tipi di contesto disponibili dipendono dalla piattaforma. Sulle piattaforme che supportano EGL, il valore egl può essere utilizzato per selezionare il contesto EGL. |
--deqp-gl-config-id=<id> | Esegui test per l'ID di configurazione GL fornito. L'interpretazione dipende dalla piattaforma. Sulla piattaforma EGL, questo è l'ID di 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 valore di rgb888s8 selezionerà la prima configurazione in cui il buffer del colore è RGB888 e il buffer dello stencil ha 8 bit. |
--deqp-gl-context-flags=<flags> | Crea un contesto. Specificare robust o debug . |
--deqp-surface-width=<width> | Prova a creare una superficie con una determinata dimensione. Il supporto per questo è facoltativo. |
--deqp-surface-type=<type> | Utilizzare un determinato tipo di superficie come destinazione principale del rendering del test. I tipi possibili sono window , pixmap , pbuffer e fbo . |
--deqp-screen-rotation=<rotation> | Orientamento dello schermo con incrementi di 90 gradi per le piattaforme che lo supportano. |
Formato dell'elenco dei casi di test
L'elenco dei casi di test può essere fornito in due formati. La prima opzione è elencare il nome completo di ciascun test su una riga separata in un file ASCII standard. Man mano che i set di test crescono, i prefissi ripetitivi possono diventare ingombranti. Per evitare di ripetere i prefissi, utilizzare la sintassi trie (nota anche come albero dei prefissi) mostrata di seguito.
{nodeName{firstChild{…},…lastChild{…}}}
Per esempio:
{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}
Si traduce nei seguenti due casi di test:
dEQP-EGL.config_list dEQP-EGL.create_context.rgb565_depth_stencil
Androide
Il pacchetto dell'applicazione Android contiene tutti i componenti richiesti, incluso il servizio di esecuzione dei test, i file binari dei test e i file di dati. L'attività di test è una NativeActivity che utilizza EGL (richiede Android 3.2 o versione successiva).
Il pacchetto dell'applicazione può essere installato con il seguente comando (il nome mostrato è il nome dell'APK nel pacchetto Android CTS; il cui nome dipende dalla build):
adb –d install –r com.drawelements.deqp.apk
Per avviare il servizio di esecuzione del test e impostare il port forwarding, utilizzare quanto segue:
adb –d forward tcp:50016 tcp:50016adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter
Le stampe di debug possono essere abilitate eseguendo quanto segue prima di iniziare i test:
adb –d shell setprop log.tag.dEQP DEBUG
Esegui test su Android senza Android CTS
Per avviare manualmente l'attività di esecuzione del test, costruisci un intento Android destinato a android.app.NativeActivity . Le attività possono essere trovate nel pacchetto com.drawelements.deqp . La riga di comando deve essere fornita come stringa aggiuntiva con la chiave "cmdLine" nell'intento.
Un registro di test viene scritto in /sdcard/dEQP-log.qpa . Se l'esecuzione del test non si avvia normalmente, nel registro del dispositivo sono disponibili ulteriori informazioni di debug.
È possibile avviare un'attività dalla riga di comando utilizzando l'utilità am . Ad esempio, per eseguire i test dEQP-GLES2.info su una piattaforma che supporta NativeActivity, utilizzare 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, prima compila e installa la build di debug eseguendo i due script seguenti:
python android/scripts/build.py --native-build-type=Debugpython android/scripts/install.py
Dopo aver installato la build di debug sul dispositivo, per avviare i test in GDB in esecuzione sull'host, esegui il comando seguente:
python android/scripts/debug.py \ --deqp-commandline="--deqp-log-filename=/sdcard/TestLog.qpa --deqp-case=dEQP-GLES2.functional.*"
La riga di comando deqp dipende dai casi di test da eseguire e da altri parametri richiesti. Lo script aggiunge un punto di interruzione predefinito all'inizio dell'esecuzione di 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, parametri di connessione a gdbserver e percorsi per file binari aggiuntivi per il debug (usa debug.py --help per tutti gli argomenti e le spiegazioni). Lo script copia anche alcune librerie predefinite dal dispositivo di destinazione per ottenere elenchi di simboli.
Per scorrere il codice del driver (ad esempio quando il GDB ha bisogno di conoscere le posizioni dei file binari con informazioni di debug complete), aggiungi più librerie tramite i parametri della riga di comando debug.py . Questo script scrive un file di configurazione per GDB a partire dalla riga 132 del file di script. È possibile fornire percorsi aggiuntivi ai file binari, ecc., ma fornire i parametri corretti della riga di comando dovrebbe essere sufficiente.
Nota: su Windows, il binario GDB richiede libpython2.7.dll . Prima di avviare debug.py , aggiungi <path-to-ndk>/prebuilt/windows/bin alla variabile PATH.
Nota: il debug del codice nativo non funziona su Android 4.3 stock; per soluzioni alternative, fare riferimento a questo bug pubblico . Android 4.4 e versioni successive non contengono questo bug.
Automatizzare i test
I moduli di test Deqp possono essere integrati in sistemi di test automatizzati in diversi modi. L'approccio migliore dipende dall'infrastruttura di test esistente e dall'ambiente di destinazione.
L'output principale di un'esecuzione di test è sempre il file di registro del test, ovvero il file con suffisso .qpa . I risultati completi del test possono essere analizzati dal registro del test. L'output della console contiene solo informazioni di debug e potrebbe non essere disponibile su tutte le piattaforme.
I binari di test possono essere richiamati direttamente da un sistema di automazione dei test. Il binario di test può essere avviato per un caso specifico, per un set di test o per tutti i test disponibili. Se si verifica un errore irreversibile durante l'esecuzione (come alcuni errori API o un arresto anomalo), l'esecuzione del test verrà interrotta. Per i test di regressione, l'approccio migliore è quello di invocare separatamente i binari di test per casi individuali o piccoli set di test, in modo da avere risultati parziali disponibili anche in caso di errore grave.
Il deqp viene fornito con strumenti di esecuzione dei test da riga di comando che possono essere utilizzati in combinazione con il servizio di esecuzione per ottenere un'integrazione più solida. L'esecutore rileva la conclusione del processo di test e riprenderà l'esecuzione del test nel successivo caso disponibile. Dall'intera sessione di test viene prodotto un singolo file di registro. Questa configurazione è ideale per sistemi di test leggeri che non forniscono funzionalità di ripristino in caso di arresto anomalo.
Strumenti per l'esecuzione dei test da riga di comando
L'attuale set di strumenti da riga di comando include uno strumento per l'esecuzione di test in remoto, un generatore di confronto dei log di test per l'analisi di regressione, un convertitore da log di test a CSV, un convertitore da log di test a XML e un convertitore da log di test a JUnit .
Il codice sorgente per questi strumenti si trova nella directory executor e i file binari sono integrati nella directory <builddir>/executor .
Esecutore di test da riga di comando
L'eseguitore di test della riga di comando è uno strumento C++ portatile per avviare un'esecuzione di test su un dispositivo e raccogliere i log risultanti da esso tramite TCP/IP. L'Esecutore comunica con il servizio di esecuzione (execserver) sul dispositivo di destinazione. Insieme forniscono funzionalità come il ripristino da arresti anomali del processo di test. I seguenti esempi dimostrano come utilizzare la riga di comando Test Executor (usa --help per maggiori dettagli):
Esempio 1: eseguire test funzionali 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 test parziale di OpenGL ES 2 eseguito localmente
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
Esportazione CSV del registro di prova e confronto
Il deqp dispone di uno strumento per convertire i registri dei test (file . qpa ) in file CSV. L'output CSV contiene un elenco di casi di test e i relativi risultati. Lo strumento può anche confrontare due o più risultati batch ed elencare solo i casi di test che hanno codici di stato diversi nei risultati batch di input. Il confronto stamperà anche il numero di casi corrispondenti.
L'output in formato CSV è molto pratico per l'ulteriore elaborazione con le utilità standard della riga di comando o con un editor di fogli di calcolo. È possibile selezionare un formato di testo semplice aggiuntivo, leggibile dall'uomo, utilizzando il seguente argomento della riga di comando: --format=text
Esempio 1: esportazione del registro dei test in formato CSV
testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csvtestlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv
Esempio 2: elencare le differenze dei risultati del test tra due registri di test
testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa
Nota: l'argomento --value=code restituisce il codice del risultato del test, ad esempio "Pass" o "Fail". L'argomento --value=details seleziona l'ulteriore spiegazione del risultato o del valore numerico prodotto da un test di prestazione, capacità o accuratezza.
Esportazione XML del registro di prova
I file di registro dei test possono essere convertiti in documenti XML validi utilizzando l'utilità testlog-to-xml . Sono supportate due modalità di output:
- Modalità documenti separati, in cui ogni caso di test e il documento di riepilogo
caselist.xmlvengono scritti in una directory di destinazione - Modalità file singolo, in cui tutti i risultati nel file
.qpavengono scritti in un singolo documento XML.
I file di registro dei test esportati possono essere visualizzati in un browser utilizzando un foglio di stile XML. Documenti di fogli di stile di esempio ( testlog.xsl e testlog.css ) sono forniti nella directory doc/testlog-stylesheet . Per visualizzare i file di registro in un browser, copiare i due file di fogli di stile nella stessa directory in cui si trovano i documenti XML esportati.
Se utilizzi Google Chrome, è necessario accedere ai file tramite HTTP poiché Chrome limita l'accesso ai file locali per motivi di sicurezza. L'installazione standard di Python include un server HTTP di base che può essere avviato per servire la directory corrente con il comando python –m SimpleHTTPServer 8000 . Dopo aver avviato il server, basta puntare il browser Chrome su http://localhost:8000 per visualizzare il registro del test.
Conversione in un registro di test JUnit
Molti sistemi di automazione dei test possono generare report sui risultati dell'esecuzione dei test dall'output JUnit. I file di registro del test deqp possono essere convertiti nel formato di output JUnit utilizzando lo strumento testlog-to-junit.
Lo strumento attualmente supporta solo la traduzione del verdetto del test case. Poiché JUnit supporta solo i risultati "pass" e "fail", un risultato positivo di deqp viene mappato su "JUnit pass" e gli altri risultati sono considerati fallimenti. Il codice risultato deqp originale è disponibile nell'output JUnit. Altri dati, come i messaggi di registro e le immagini dei risultati, non vengono conservati nella conversione.
Utilizzare gruppi di test speciali
Alcuni gruppi di test potrebbero richiedere o supportare opzioni speciali della riga di comando o richiedere cure speciali se utilizzati su determinati sistemi.
Test di stress sull'allocazione della memoria
Gli stress test di allocazione della memoria esercitano condizioni di memoria insufficiente allocando ripetutamente determinate risorse finché il driver non segnala un errore di memoria insufficiente.
Su alcune piattaforme, come Android e la maggior parte delle varianti Linux, può verificarsi quanto segue: Il sistema operativo potrebbe interrompere il processo di test invece di consentire a un driver di gestire o fornire in altro modo un errore di memoria insufficiente. Su tali piattaforme, i test progettati per causare errori di memoria insufficiente sono disabilitati per impostazione predefinita e devono essere abilitati utilizzando l'argomento della riga di comando --deqp-test-oom=enable . Si consiglia di eseguire tali test manualmente per verificare se il sistema si comporta correttamente sotto pressione delle risorse. Tuttavia, in una situazione del genere, un arresto anomalo del processo di test dovrebbe essere interpretato come un superamento.
Gruppi di prova
dEQP-GLES2.stress.memory.* dEQP-GLES3.stress.memory.*
Test di stress di rendering a lunga esecuzione
Gli stress test di rendering sono progettati per rivelare problemi di robustezza in caso di carico di rendering sostenuto. Per impostazione predefinita, i test eseguiranno solo poche iterazioni, ma possono essere configurati per essere eseguiti indefinitamente fornendo l'argomento della riga di comando --deqp-test-iteration-count=-1 . Il watchdog del test dovrebbe essere disabilitato ( --deqp-watchdog=disable ) quando si eseguono questi test per un lungo periodo di tempo.
Gruppi di prova
dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.*
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2024-03-18 UTC.