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 eseguire il deployment della suite di test deqp in un nuovo ambiente.
Per lavorare con l'ultimo codice inviato, utilizza il ramo deqp-dev.
Per il codice che corrisponde a una versione specifica di Android CTS, utilizza il ramo release-code-name-release (ad es. per Android 6.0, utilizza il ramo marshmallow-release).
Layout 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 è esaustivo, ma evidenzia le directory più importanti).
| Directory | Descrizione |
|---|---|
android |
Origini dei test Android e script di build |
data |
File di dati di test |
modules |
Testare le origini del modulo |
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à del modulo di test deqp |
framework/delibs |
Librerie di base per la portabilità e la creazione |
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 |
Utilità e strumento shell di esecuzione dei test lato host |
external |
Crea una directory stub per le librerie esterne libpng e zlib |
Componenti open source
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à. 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
Le origini deqp hanno script di compilazione 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 saperne di più su CMake, consulta la documentazione di CMake.
CMake supporta e consiglia le build out-of-source-tree, ovvero devi sempre creare makefile o file di progetto in una directory di build separata al di fuori della struttura dei sorgenti. CMake non ha alcun tipo di target "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 -DOPTION_NAME=VALUE. Di seguito sono elencate alcune opzioni di uso comune per deqp.
| Opzione di configurazione | Descrizione |
|---|---|
DEQP_TARGET |
Nome del target, ad esempio "android" Gli script CMake deqp 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 i target makefile. I valori validi sono "Debug" e "Release". Tieni presente che l'interpretazione e il tipo predefinito dipendono dal sistema di compilazione di destinazione. Per ulteriori dettagli, consulta la documentazione di CMake. |
Crea un file di build di destinazione
Il sistema di build deqp è configurato per i nuovi target utilizzando i file di build di destinazione.
Un file di build di destinazione definisce le funzionalità supportate dalla piattaforma e le librerie o
i percorsi di inclusione aggiuntivi 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 target (verrà incluso nei log di test) |
DEQP_SUPPORT_GLES2 |
Se GLES2 è supportato (impostazione predefinita: OFF) |
DEQP_GLES2_LIBRARIES |
Librerie GLES2 (lascia vuoto se non supportate o se viene utilizzato il caricamento dinamico) |
DEQP_SUPPORT_GLES3 |
Se GLES3.x è supportato (impostazione predefinita: OFF) |
DEQP_GLES3_LIBRARIES |
Librerie GLES3.x (lascia vuoto se non supportate 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 supportate 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 supportate o se viene utilizzato il caricamento dinamico) |
DEQP_PLATFORM_LIBRARIES |
Librerie aggiuntive specifiche per la piattaforma richieste per il collegamento |
DEQP_PLATFORM_COPY_LIBRARIES |
Elenco delle librerie copiate in ogni directory di compilazione dei file binari di test. Può essere utilizzato per copiare le librerie necessarie per l'esecuzione dei test, ma non nel percorso di ricerca predefinito. |
TCUTIL_PLATFORM_SRCS |
Elenco delle origini delle porte della piattaforma. Le fonti 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().
Build Win32
Il modo più semplice per creare moduli deqp per Windows è utilizzare il sistema di build CMake. Avrai bisogno di CMake 2.6.12 o versioni successive e del compilatore Microsoft Visual C/C++. 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"
Per creare una build a 64 bit, seleziona "Visual Studio VERSION Win64" come generatore di build:
cmake path\to\src\deqp -G "Visual Studio 12 Win64"
Puoi anche generare file makefile NMake con l'opzione -G "NMake Makefiles" e 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 EGL su Windows.
Supporto WGL
Tutti i file binari Win32 supportano la creazione di contesti GL con WGL, in quanto richiedono 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. È stato testato per funzionare con
i driver più recenti di NVIDIA e Intel. I driver AMD non supportano l'estensione richiesta.
Supporto EGL
deqp è creato con il caricamento dinamico per EGL su Windows se DEQP_SUPPORT_EGL
è ON. Questa è l'impostazione predefinita nella maggior parte dei target. Se l'host dispone di librerie EGL, è possibile eseguire test con queste librerie con il parametro della riga di comando: --deqp-gl-context-type=egl
Build Android
La build Android utilizza script di build CMake per creare il codice di test nativo. Le parti Java, ovvero il server di esecuzione dei test e lo stub dell'applicazione di test, vengono compilate utilizzando gli strumenti di build Android standard.
Per compilare i programmi di test deqp per Android con gli script di build forniti, devi disporre di:
- L'ultima versione dell'
NDK Android; il file
android/scripts/common.pyelenca la versione richiesta - SDK Android autonomo con API 13, SDK Tools, SDK Platform-tools e SDK Build-tools pacchetti installati
- Apache Ant 1.9.4 (richiesto dalla build del 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) Ninja Make è supportato anche su Linux
I file binari di Ant e dell'SDK si trovano in base alla variabile di ambiente PATH con
determinati valori predefiniti di override. 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 on-device deqp, il servizio di esecuzione dei test e i programmi di test vengono
creati eseguendo lo script android/scripts/build.py. L'APK finale viene creato in
android/package/bin e può essere installato dallo script install.py. Se viene utilizzato l'executor della riga di comando, ExecService viene avviato con lo script launch.py sul dispositivo tramite ADB. Gli script possono essere eseguiti da qualsiasi directory.
Build Linux
I file binari di test e le utilità della riga di comando possono essere creati per Linux generando makefile utilizzando CMake. Esistono più target di build predefiniti utili per la creazione di build per Linux.
| Crea target | 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. |
Utilizza sempre -DCMAKE_BUILD_TYPE=<Debug|Release> per definire il tipo di build.
Release è un buon valore predefinito. Senza, viene creato un build di rilascio predefinito e non ottimizzato.
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 bit o 64 bit può essere eseguita
impostando rispettivamente -DCMAKE_C(XX)_FLAGS="-m32" o "-m64". Se non
specificata, 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 percorsi di ricerca aggiuntivi per librerie o inclusione.
Di seguito è riportato un esempio di riga di comando completa utilizzata per eseguire una build di debug a 32 bit rispetto a intestazioni e librerie del driver in una posizione personalizzata:
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
Cross-compilazione
La compilazione incrociata può essere eseguita utilizzando un file della toolchain CMake. Il file toolchain
specifica il compilatore da utilizzare, insieme ai percorsi di ricerca personalizzati per
librerie e intestazioni. Nel pacchetto di rilascio sono inclusi diversi file della toolchain per scenari comuni nella directory framework/delibs/cmake.
Oltre alle variabili CMake standard, il file della toolchain può impostare le seguenti variabili specifiche di deqp. CMake di solito rileva 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, il seguente comando creerebbe i makefile per una build utilizzando il cross-compiler 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 in fase di runtime delle librerie GLES ed EGL
Durante il collegamento, deqp non ha bisogno di punti di ingresso dell'API in fase di test. Il codice di test accede sempre alle API tramite puntatori a funzioni. I punti di ingresso possono 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 link non sono
fornite, deqp caricherà i punti di ingresso necessari in fase di runtime. Se è necessario il collegamento statico, fornisci le librerie di collegamento necessarie nella variabile di configurazione della build DEQP_<API>_LIBRARIES.
Portare il framework di test
Il porting di 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 riportata di seguito elenca le posizioni per le probabili modifiche al porting. Qualsiasi cosa al di fuori è probabilmente esotica.
| Posizione | Descrizione |
|---|---|
framework/delibs/debase |
Eventuali implementazioni necessarie di codice specifico per il sistema operativo. |
framework/qphelper/qpCrashHandler.c |
(Facoltativo) Implementazione per il tuo sistema operativo. |
framework/qphelper/qpWatchDog.c |
Implementazione per il tuo sistema operativo. Quella attuale si basa 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 base per la portabilità supportano già Windows, la maggior parte delle varianti di Linux, Mac OS, iOS e Android. Se il target di test viene eseguito su uno di questi sistemi operativi, molto probabilmente non è necessario intervenire sulle librerie di portabilità di base.
Porta della piattaforma del framework di test
Il porting 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 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 accesso standard dell'applicazione |
La classe base per tutte le porte della piattaforma è tcu::Platform. La porta della piattaforma può
supportare facoltativamente interfacce specifiche di GL ed EGL. Consulta
la tabella seguente per una panoramica di ciò che deve essere implementato per
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 nelle intestazioni del livello di porting.
Servizio di esecuzione dei test
Per utilizzare l'infrastruttura di esecuzione dei test deqp o l'executor della riga di comando, il
servizio di esecuzione dei test deve essere disponibile sulla destinazione. Nell'implementazione di C++
portatile del servizio è fornita nella directory execserver. Il binario autonomo
viene creato come parte della build del modulo di test deqp
per i target PC. Puoi modificare execserver/CMakeLists.txt per attivare una build su
altri target.
La versione C++ del servizio di esecuzione dei test accetta due parametri della riga di comando:
-
--port=<port>imposterà la porta TCP su cui il server è in ascolto. Il valore predefinito è 50016. -
--singleterminerà il processo del server quando il client si disconnette. Per impostazione predefinita, il processo del server rimane attivo per gestire ulteriori richieste di esecuzione dei test.
Esegui i test
Questa pagina fornisce istruzioni per l'esecuzione dei test deqp negli 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 | Directory | Target |
|---|---|---|
| Execution Server | build/execserver/execserver |
<dst>/execserver |
| Modulo EGL | build/modules/egl/deqp-egl |
<dst>/deqp-egl |
| GLES2 Module | 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 |
Puoi eseguire il deployment del servizio di esecuzione e testare i file binari in qualsiasi punto del file system di destinazione. Tuttavia, i file binari di test si aspettano di trovare le directory di dati nella directory di lavoro corrente. Quando è tutto pronto, avvia il servizio di esecuzione dei test sul dispositivo di destinazione. Per informazioni dettagliate sull'avvio del servizio, vedi Servizio di esecuzione dei test.
Argomenti della riga di comando
La tabella seguente elenca gli argomenti della riga di comando che influiscono sull'esecuzione di tutti i programmi di test.
| Argomento | Descrizione |
|---|---|
--deqp-case=<casename> |
Esegui scenari di test 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. Il servizio di esecuzione del test imposterà il nome del file all'avvio di un test. |
--deqp-stdin-caselist |
Legge 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. Consulta la sezione successiva per una descrizione del formato dell'elenco delle richieste. |
--deqp-test-iteration-count=<count> |
Esegui l'override del conteggio delle iterazioni per i test che supportano un numero variabile di iterazioni. |
--deqp-base-seed=<seed> |
Il seme di base per gli scenari di test che utilizzano la randomizzazione. |
Argomenti specifici per GLES2 e GLES3
La tabella seguente elenca gli argomenti specifici di GLES2 e GLES3.| Argomento | 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 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 valore di rgb888s8 selezionerà la prima configurazione in cui il buffer dei colori è 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> |
Prova a creare una superficie con una dimensione specifica. Il supporto è facoltativo. |
--deqp-surface-type=<type> |
Utilizza un determinato tipo di superficie come target di rendering principale 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 degli scenari di test
L'elenco degli scenari di test può essere fornito in due formati. La prima opzione consiste nell'elencare il nome completo di ogni test su una riga separata in un file ASCII standard. Man mano che i set di test crescono, i prefissi ripetitivi possono diventare scomodi. Per evitare di ripetere i prefissi, utilizza una sintassi trie (nota anche come albero dei prefissi) mostrata di seguito.
{nodeName{firstChild{…},…lastChild{…}}}
Ad esempio:
{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}
Si traduce nei seguenti due scenari di test:
dEQP-EGL.config_list dEQP-EGL.create_context.rgb565_depth_stencil
Android
Il pacchetto dell'applicazione Android contiene tutti i componenti richiesti, inclusi
il servizio di esecuzione dei test, i 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 (il nome mostrato è il nome dell'APK nel pacchetto Android CTS, che dipende dalla build):
adb –d install –r com.drawelements.deqp.apk
Per avviare il servizio di esecuzione dei test e configurare l'inoltro delle porte, utilizza 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 attivate eseguendo il seguente comando 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, crea un intent Android
che ha come target android.app.NativeActivity. Le attività si trovano nel pacchetto com.drawelements.deqp. La riga di comando deve
essere fornita come stringa aggiuntiva con la chiave "cmdLine" nell'intent.
Un log di test viene scritto in /sdcard/dEQP-log.qpa. Se l'esecuzione del test
non si avvia normalmente, nel log del dispositivo sono disponibili informazioni di debug aggiuntive.
Puoi 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,, utilizza 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"'
Eseguire il debug su Android
Per eseguire i test con il debugger GDB su Android, compila e installa prima 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 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 dai test case 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, i parametri di connessione gdbserver e i percorsi di altri file binari da eseguire il debug (utilizza debug.py
--help per tutti gli argomenti e le spiegazioni). Lo script copia anche alcune
librerie predefinite dal dispositivo di destinazione per ottenere gli elenchi dei simboli.
Per eseguire il passo passo del codice del driver (ad esempio quando GDB deve conoscere le posizioni
dei file binari con informazioni di debug complete), aggiungi altre 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. Puoi
fornire percorsi aggiuntivi a file binari e così via, ma dovrebbe essere sufficiente fornire parametri della riga di comando corretti.
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 le soluzioni alternative, consulta questo bug pubblico. Android 4.4 e versioni successive non contengono questo bug.
Automatizzare i test
I moduli di test Deqp possono essere integrati nei sistemi di test automatici 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 log di test, ovvero il file
con il suffisso .qpa. I risultati completi del test possono essere analizzati dal log di 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 test binario può essere avviato per un caso specifico, per un insieme di test o per tutti i test disponibili. Se si verifica un errore irreversibile durante l'esecuzione (ad esempio determinati errori API o un arresto anomalo), l'esecuzione del test viene interrotta. Per i test di regressione, l'approccio migliore è richiamare i file binari di test per singoli casi o piccoli set di test separatamente, in modo da avere risultati parziali disponibili anche in caso di errore irreversibile.
deqp include 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'executor rileva la terminazione del processo di test e riprende l'esecuzione del test nel caso successivo disponibile. Viene prodotto un unico file di log dall'intera sessione di test. Questa configurazione è ideale per i sistemi di test leggeri che non forniscono funzionalità di ripristino in caso di arresto anomalo.
Strumenti di esecuzione dei test da riga di comando
L'attuale set di strumenti da riga di comando include uno strumento di esecuzione di test remoti, 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 di questi strumenti si trova nella directory executor, mentre i file binari sono
integrati nella directory <builddir>/executor.
Esecutore di test da riga di comando
Lo strumento di esecuzione dei test da riga di comando è un'utilità C++ portatile per avviare un'esecuzione di test
su un dispositivo e raccogliere i log risultanti tramite TCP/IP. L'Executor
comunica con il servizio di esecuzione (execserver) sul dispositivo di destinazione.
Insieme forniscono funzionalità come il ripristino in caso di arresti anomali della procedura di test.
I seguenti esempi mostrano come utilizzare lo strumento di esecuzione dei test da riga di comando
(utilizza --help per maggiori dettagli):
Esempio 1: esegui 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: continua l'esecuzione parziale di un test OpenGL ES 2 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 e confronto dei file CSV del log dei test
deqp dispone di uno strumento per convertire i log di test (file .qpa) in file CSV. L'output
CSV contiene un elenco di scenari 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à a riga di comando standard o con un editor di fogli di lavoro. È possibile selezionare un formato aggiuntivo, leggibile,
in formato testo normale utilizzando il seguente argomento della riga di comando: --format=text
Esempio 1: esporta il log 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 tra i risultati dei test di due log 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 "Superato" o "Non superato". L'argomento --value=details seleziona l'ulteriore
spiegazione del risultato o del valore numerico prodotto da un test di rendimento, funzionalità o precisione.
Esportazione XML del log di test
I file di log 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 scenario di test e il documento di riepilogo
caselist.xmlvengono scritti in una directory di destinazione - Modalità a file singolo, in cui tutti i risultati nel file
.qpavengono scritti in un unico documento XML.
I file di log di test esportati possono essere visualizzati in un browser utilizzando un foglio di stile XML.
I documenti del foglio di stile di esempio (testlog.xsl e testlog.css) sono forniti
nella directory doc/testlog-stylesheet. Per eseguire il rendering dei file di log in un browser, copia 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, in quanto 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 pubblicare la directory corrente
con il comando python –m SimpleHTTPServer 8000. Dopo aver avviato il server,
basta indirizzare il browser Chrome a http://localhost:8000 per visualizzare il log di test.
Conversione in un log di test JUnit
Molti sistemi di automazione dei test possono generare report sui risultati dell'esecuzione dei test dall'output JUnit. I file di log dei test deqp possono essere convertiti nel formato di output JUnit utilizzando lo strumento testlog-to-junit.
Al momento, lo strumento supporta solo la traduzione del risultato dello scenario di test. Poiché JUnit supporta solo i risultati "superato" e "non superato", un risultato superato del test deqp viene mappato come "JUnit superato" e gli altri risultati vengono considerati non superati. Il codice risultato deqp originale è disponibile nell'output JUnit. Altri dati, come i messaggi di log e le immagini dei risultati, non vengono conservati nella conversione.
Utilizzare gruppi di test speciali
Alcuni gruppi di test potrebbero richiedere o supportare opzioni della riga di comando speciali oppure richiedere particolare attenzione se utilizzati su determinati sistemi.
Stress test di allocazione della memoria
I test di stress dell'allocazione della memoria esercitano condizioni di esaurimento della memoria allocando ripetutamente determinate risorse finché il driver non segnala un errore di esaurimento della memoria.
Su alcune piattaforme, come Android e la maggior parte delle varianti di Linux, può verificarsi quanto segue: il sistema operativo potrebbe interrompere il processo di test anziché consentire a un driver di gestire o fornire in altro modo un errore di memoria insufficiente. Su queste
piattaforme, i test progettati per causare errori di memoria insufficiente sono disattivati
per impostazione predefinita e devono essere attivati utilizzando l'argomento della riga di comando --deqp-test-oom=enable.
Ti consigliamo di eseguire questi test manualmente per
verificare se il sistema si comporta correttamente in condizioni di pressione delle risorse. Tuttavia, in una situazione del genere, un arresto anomalo della procedura di test deve essere interpretato come superamento.
Gruppi di test
dEQP-GLES2.stress.memory.* dEQP-GLES3.stress.memory.*
Test di stress del rendering a lunga esecuzione
I test di stress del rendering sono progettati per rivelare problemi di robustezza in condizioni di carico di rendering sostenuto. Per impostazione predefinita, i test eseguiranno solo poche iterazioni, ma
possono essere configurati per essere eseguiti all'infinito fornendo l'argomento della riga di comando --deqp-test-iteration-count=-1. Il watchdog di test deve essere disattivato (--deqp-watchdog=disable)
quando questi test vengono eseguiti per un lungo periodo di tempo.
Gruppi di test
dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.*