AOSP enthält die GPU-Testsuite „drawElements Quality Program“ (deqp) unter https://android.googlesource.com/platform/external/deqp. Auf dieser Seite wird beschrieben, wie Sie die DEQP-Testsuite in einer neuen Umgebung bereitstellen.
Wenn Sie mit dem zuletzt eingereichten Code arbeiten möchten, verwenden Sie den deqp-dev-Branch.
Verwenden Sie für Code, der einem bestimmten Android CTS-Release entspricht, den release-code-name-release-Branch (z.B. für Android 6.0 den marshmallow-release-Branch).
Quelllayout
Das Quellcodelayout für die DEQP-Testmodule und unterstützenden Bibliotheken ist in der folgenden Tabelle dargestellt. Die Auflistung ist nicht vollständig, sondern enthält nur die wichtigsten Verzeichnisse.
| Verzeichnis | Beschreibung |
|---|---|
android |
Android-Testerquellen und Build-Scripts |
data |
Testdatendateien |
modules |
Quellen für Testmodule |
modules/egl |
EGL-Modul |
modules/gles2 |
GLES2-Modul |
modules/gles3 |
GLES3-Modul |
modules/gles31 |
GLES3.1-Modul |
modules/gles32 |
GLES3.2-Modul |
targets |
Zielgerätspezifische Build-Konfigurationsdateien |
framework |
deqp-Testmodul-Framework und ‑Dienstprogramme |
framework/delibs |
Portabilität und Build-Bibliotheken |
framework/platform |
Plattformanschlüsse |
framework/qphelper |
Testprogramm-Integrationsbibliothek (C) |
framework/common |
Deqp-Framework (C++) |
framework/opengl, framework/egl |
API-spezifische Dienstprogramme |
execserver |
Geräteseitige ExecServer-Quelle |
executor |
Hostseitiges Shell-Tool und Dienstprogramme für die Ausführung von Tests |
external |
Stub-Verzeichnis für die externen Bibliotheken libpng und zlib erstellen |
Open-Source-Komponenten
Das deqp verwendet libpng und zlib, die mit dem Skript
platform/external/deqp/external/fetch_sources.py oder über Git von platform/external/[libpng,zlib] abgerufen werden können.
Testprogramme erstellen
Das Test-Framework wurde mit Blick auf die Portabilität entwickelt. Die einzigen obligatorischen Anforderungen sind die vollständige C++-Unterstützung und Standard-Systembibliotheken für E/A, Threads und Sockets.
CMake-Build-System
Die DEQP-Quellen enthalten Build-Skripts für CMake, das bevorzugte Tool zum Kompilieren der Testprogramme.
CMake ist ein Open-Source-Build-System, das mehrere Plattformen und Toolchains unterstützt. CMake generiert native Makefiles oder IDE-Projektdateien aus zielunabhängigen Konfigurationsdateien. Weitere Informationen zu CMake finden Sie in der CMake-Dokumentation.
CMake unterstützt und empfiehlt Builds außerhalb des Quellbaums. Das bedeutet, dass Sie Makefiles oder Projektdateien immer in einem separaten Build-Verzeichnis außerhalb des Quellbaums erstellen sollten. CMake hat kein „distclean“-Ziel. Alle von CMake generierten Dateien müssen also manuell entfernt werden.
Konfigurationsoptionen werden an CMake übergeben, indem die -DOPTION_NAME=VALUE-Syntax verwendet wird. Im Folgenden sind einige häufig verwendete Optionen für deqp aufgeführt.
| Konfigurationsoption | Beschreibung |
|---|---|
DEQP_TARGET |
Zielname, z. B. „android“ Die DEQP-CMake-Skripts enthalten die Datei |
CMAKE_TOOLCHAIN_FILE |
Pfad zur Toolchain-Datei für CMake. Wird für die Cross-Compilation verwendet. |
CMAKE_BUILD_TYPE |
Build-Typ für Makefile-Ziele. Gültige Werte sind „Debug“ und „Release“. Die Interpretation und der Standardtyp hängen vom Ziel-Buildsystem ab. Weitere Informationen finden Sie in der CMake-Dokumentation. |
Ziel-Build-Datei erstellen
Das DEQP-Build-System wird für neue Ziele mit Ziel-Build-Dateien konfiguriert.
In einer Ziel-Build-Datei wird definiert, welche Funktionen die Plattform unterstützt und welche Bibliotheken oder zusätzlichen Include-Pfade erforderlich sind. Zieldateinamen folgen dem Format targets/NAME/NAME.cmake und das Ziel wird mit dem Build-Parameter DEQP_TARGET ausgewählt.
Dateipfade in Zieldateien beziehen sich auf das Basisverzeichnis deqp, nicht auf das Verzeichnis targets/NAME. Die folgenden Standardvariablen können durch die Ziel-Build-Datei festgelegt werden.
| Variable | Beschreibung |
|---|---|
DEQP_TARGET_NAME |
Zielname (wird in Testprotokolle aufgenommen) |
DEQP_SUPPORT_GLES2 |
Gibt an, ob GLES2 unterstützt wird (Standard: AUS) |
DEQP_GLES2_LIBRARIES |
GLES2-Bibliotheken (leer lassen, wenn nicht unterstützt oder dynamisches Laden verwendet wird) |
DEQP_SUPPORT_GLES3 |
Gibt an, ob GLES3.x unterstützt wird (Standard: AUS). |
DEQP_GLES3_LIBRARIES |
GLES3.x-Bibliotheken (leer lassen, wenn nicht unterstützt oder dynamisches Laden verwendet wird) |
DEQP_SUPPORT_VG |
Gibt an, ob OpenVG unterstützt wird (Standard: AUS). |
DEQP_OPENVG_LIBRARIES |
OpenVG-Bibliotheken (leer lassen, wenn nicht unterstützt oder dynamisches Laden verwendet wird) |
DEQP_SUPPORT_EGL |
Gibt an, ob EGL unterstützt wird (Standard: AUS). |
DEQP_EGL_LIBRARIES |
EGL-Bibliotheken (leer lassen, wenn nicht unterstützt oder dynamisches Laden verwendet wird) |
DEQP_PLATFORM_LIBRARIES |
Zusätzliche plattformspezifische Bibliotheken für die Verknüpfung erforderlich |
DEQP_PLATFORM_COPY_LIBRARIES |
Liste der Bibliotheken, die in das Build-Verzeichnis jeder Testbinärdatei kopiert werden. Kann verwendet werden, um Bibliotheken zu kopieren, die zum Ausführen von Tests erforderlich sind, sich aber nicht im Standardsuchpfad befinden. |
TCUTIL_PLATFORM_SRCS |
Liste der Plattformportquellen. Die Standardquellen werden basierend auf den Funktionen und dem Betriebssystem bestimmt. Hinweis:Pfade sind relativ zu: |
In der Ziel-Build-Datei können mit den CMake-Funktionen include_directories() und link_directories() zusätzliche Include- oder Link-Pfade hinzugefügt werden.
Win32-Build
Am einfachsten lassen sich deqp-Module für Windows mit dem CMake-Buildsystem erstellen. Sie benötigen CMake 2.6.12 oder höher und den Microsoft Visual C/C++-Compiler. Die deqp wurde mit Visual Studio 2013 getestet.
Visual Studio-Projektdateien können mit dem folgenden Befehl generiert werden:
cmake path\to\src\deqp -G "Visual Studio 12"
Eine 64-Bit-Version kann erstellt werden, indem Sie „Visual Studio VERSION Win64“ als Build-Generator auswählen:
cmake path\to\src\deqp -G "Visual Studio 12 Win64"
Sie können auch NMake-Makefiles mit der Option -G "NMake Makefiles" sowie dem Build-Typ (-DCMAKE_BUILD_TYPE="Debug" oder "Release") generieren.
Kontext für das Rendern erstellen
Der Rendering-Kontext kann unter Windows entweder mit WGL oder mit EGL erstellt werden.
WGL-Unterstützung
Alle Win32-Binärdateien unterstützen die Erstellung von GL-Kontexten mit WGL, da dafür nur Standardbibliotheken erforderlich sind. Der WGL-Kontext kann mit dem Befehlszeilenargument --deqp-gl-context-type=wgl ausgewählt werden. Im WGL-Modus verwendet deqp die WGL_EXT_create_context_es_profile-Erweiterung, um OpenGL ES-Kontexte zu erstellen. Dies wurde mit den neuesten Treibern von NVIDIA und Intel getestet. AMD-Treiber unterstützen die erforderliche Erweiterung nicht.
EGL-Unterstützung
Die deqp wird mit dynamischem Laden für EGL unter Windows erstellt, wenn DEQP_SUPPORT_EGL auf ON gesetzt ist. Dies ist die Standardeinstellung für die meisten Ziele. Wenn auf dem Host EGL-Bibliotheken verfügbar sind, können Sie Tests mit dem Befehlszeilenparameter --deqp-gl-context-type=egl ausführen.
Android-Build
Beim Android-Build werden CMake-Build-Skripts zum Erstellen des nativen Testcodes verwendet. Java-Teile, d.h. der Test Execution Server und der Test Application Stub, werden mit den Standard-Android-Build-Tools kompiliert.
Um DEQP-Testprogramme für Android mit den bereitgestellten Build-Skripten zu kompilieren, benötigen Sie Folgendes:
- Die aktuelle Version des
Android NDK. Die erforderliche Version ist in der Datei
android/scripts/common.pyaufgeführt. - Eigenständiges Android-SDK mit API 13, SDK-Tools, SDK-Plattformtools und SDK-Build-Tools installiert
- Apache Ant 1.9.4 (für den Java-Code-Build erforderlich)
- CMake 2.8.12 oder höher
- Python 2.6 oder höher in der 2.x-Reihe; Python 3.x wird nicht unterstützt
- Für Windows: Entweder NMake oder JOM in
PATH- JOM ermöglicht schnellere Builds
- Optional: Ninja Make wird auch unter Linux unterstützt.
Ant- und SDK-Binärdateien werden anhand der Umgebungsvariable PATH mit bestimmten überschreibenden Standardeinstellungen gesucht. Die Logik wird von android/scripts/common.py gesteuert.
Das NDK-Verzeichnis muss entweder ~/android-ndk-VERSION oder C:/android/android-ndk-VERSION sein oder über die Umgebungsvariable ANDROID_NDK_PATH definiert werden.
Die On-Device-Komponenten von DEQP, der Testausführungsdienst und die Testprogramme werden durch Ausführen des android/scripts/build.py-Skripts erstellt. Die endgültige APK-Datei wird in android/package/bin erstellt und kann mit dem Skript install.py installiert werden. Wenn der Befehlszeilen-Executor verwendet wird, wird der ExecService mit dem launch.py-Script auf dem Gerät über ADB gestartet. Die Skripts können aus einem beliebigen Verzeichnis ausgeführt werden.
Linux-Build
Testbinärdateien und Befehlszeilenprogramme können für Linux erstellt werden, indem Makefiles mit CMake generiert werden. Es gibt mehrere vordefinierte Build-Ziele, die beim Erstellen für Linux nützlich sind.
| Ziel erstellen | Beschreibung |
|---|---|
default |
Standardziel, das die CMake-Plattform-Introspektion verwendet, um die Unterstützung für verschiedene APIs zu ermitteln. |
x11_glx |
Verwendet GLX zum Erstellen von OpenGL-Kontexten (ES). |
x11_egl |
Verwendet EGL zum Erstellen von OpenGL-(ES-)Kontexten. |
x11_egl_glx |
Unterstützt sowohl GLX als auch EGL mit X11. |
Verwenden Sie immer -DCMAKE_BUILD_TYPE=<Debug|Release>, um den Build-Typ zu definieren.
Release ist ein guter Standardwert. Andernfalls wird ein standardmäßiger, nicht optimierter Release-Build erstellt.
Mit den Befehlszeilenargumenten -DCMAKE_C_FLAGS und -DCMAKE_CXX_FLAGS können Sie zusätzliche Argumente an den Compiler übergeben. Der 32-Bit- oder 64-Bit-Build kann beispielsweise durch Festlegen von -DCMAKE_C(XX)_FLAGS="-m32" bzw. "-m64" erfolgen. Wenn nichts angegeben ist, wird die native Architektur der Toolchain verwendet, in der Regel 64-Bit bei der 64-Bit-Toolchain.
Mit den Argumenten -DCMAKE_LIBRARY_PATH und -DCMAKE_INCLUDE_PATH können Sie CMake zusätzliche Bibliotheks- oder Include-Suchpfade angeben.
Ein Beispiel für eine vollständige Befehlszeile, die zum Erstellen eines 32-Bit-Debug-Build anhand von Treiberheadern und ‑bibliotheken an einem benutzerdefinierten Speicherort verwendet wird, ist das Folgende:
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-Kompilierung
Cross-Compiling kann mit einer CMake-Toolchain-Datei erreicht werden. In der Toolchain-Datei wird der zu verwendende Compiler zusammen mit benutzerdefinierten Suchpfaden für Bibliotheken und Headern angegeben. Das Release-Paket enthält mehrere Toolchain-Dateien für gängige Szenarien im Verzeichnis framework/delibs/cmake.
Zusätzlich zu den standardmäßigen CMake-Variablen können die folgenden deqp-spezifischen Variablen in der Toolchain-Datei festgelegt werden. CMake kann DE_OS, DE_COMPILER und DE_PTR_SIZE in der Regel korrekt erkennen, DE_CPU muss jedoch von der Toolchain-Datei festgelegt werden.
| Variable | Beschreibung |
|---|---|
DE_OS |
Betriebssystem Unterstützte Werte: |
DE_COMPILER |
Compilertyp. Unterstützte Werte: |
DE_CPU |
CPU-Typ. Unterstützte Werte: |
DE_PTR_SIZE |
sizeof(void*) auf der Plattform. Unterstützte Werte: 4 und 8 |
Die Toolchain-Datei kann mit dem Build-Parameter CMAKE_TOOLCHAIN_FILE ausgewählt werden.
Mit dem folgenden Befehl werden beispielsweise Makefiles für einen Build mit dem CodeSourcery-Cross-Compiler für ARM/Linux erstellt:
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
Laufzeitverknüpfung von GLES- und EGL-Bibliotheken
Für das Linken benötigt deqp keine Einstiegspunkte der zu testenden API. Der Testcode greift immer über Funktionszeiger auf die APIs zu. Einstiegspunkte können dann zur Laufzeit dynamisch geladen werden oder der Plattformport kann sie zur Linkzeit bereitstellen.
Wenn die Unterstützung für eine API in den Buildeinstellungen aktiviert ist und keine Link-Bibliotheken bereitgestellt werden, lädt DEQP die erforderlichen Einstiegspunkte zur Laufzeit. Wenn die statische Verknüpfung gewünscht ist, geben Sie die erforderlichen Linkbibliotheken in der Build-Konfigurationsvariablen DEQP_<API>_LIBRARIES an.
Test-Framework portieren
Das Portieren von deqp umfasst drei Schritte: Anpassen der grundlegenden Portierungsbibliotheken, Implementieren von Schnittstellen für die Plattformintegration des Test-Frameworks und Portieren des Ausführungsdienstes.
In der folgenden Tabelle sind Orte aufgeführt, an denen wahrscheinlich Änderungen bei der Portierung vorgenommen werden müssen. Alles darüber hinaus ist wahrscheinlich exotisch.
| Standort | Beschreibung |
|---|---|
framework/delibs/debase |
Alle erforderlichen Implementierungen von betriebssystemspezifischem Code. |
framework/qphelper/qpCrashHandler.c |
Optional: Implementierung für Ihr Betriebssystem. |
framework/qphelper/qpWatchDog.c |
Implementierung für Ihr Betriebssystem Die aktuelle Version basiert auf |
framework/platform |
Der neue Plattformport und der Anwendungs-Stub können wie unter Testframework-Plattformport beschrieben implementiert werden. |
Basispotabilitätsbibliotheken
Die grundlegenden Portabilitätsbibliotheken unterstützen bereits Windows, die meisten Linux-Varianten, Mac OS, iOS und Android. Wenn das Testziel auf einem dieser Betriebssysteme ausgeführt wird, müssen Sie die grundlegenden Portabilitätsbibliotheken höchstwahrscheinlich überhaupt nicht ändern.
Plattformport des Testframeworks
Der Plattformport des DEQP-Testframeworks erfordert zwei Komponenten: einen Anwendungseinstiegspunkt und eine Implementierung der Plattformschnittstelle.
Der Anwendungseinstiegspunkt ist für das Erstellen des Plattformobjekts, das Erstellen eines Befehlszeilenobjekts (tcu::CommandLine), das Öffnen eines Testlogs (tcu::TestLog) und das Durchlaufen der Testanwendung (tcu::App) verantwortlich. Wenn das Zielbetriebssystem einen Standardeinstiegspunkt (main()) unterstützt, kann tcuMain.cpp als Einstiegspunktimplementierung verwendet werden.
Die DEQP-Plattform-API wird in den folgenden Dateien ausführlich beschrieben.
| Datei | Beschreibung |
|---|---|
framework/common/tcuPlatform.hpp |
Basisklasse für alle Plattformports |
framework/opengl/gluPlatform.hpp |
OpenGL-Plattformschnittstelle |
framework/egl/egluPlatform.hpp |
EGL-Plattformschnittstelle |
framework/platform/tcuMain.cpp |
Standardanwendungseinstiegspunkt |
Die Basisklasse für alle Plattformports ist tcu::Platform. Der Plattformport kann optional GL- und EGL-spezifische Schnittstellen unterstützen. In der folgenden Tabelle finden Sie eine Übersicht darüber, was implementiert werden muss, um die Tests auszuführen.
| Modul | Schnittstelle |
|---|---|
OpenGL (ES)-Testmodule |
GL-Plattformschnittstelle |
EGL-Testmodul |
EGL-Plattformschnittstelle |
Eine detaillierte Anleitung zur Implementierung von Plattform-Ports finden Sie in den Headern der Portierungsebene.
Dienst zur Testausführung
Wenn Sie die DEQP-Testausführungsinfrastruktur oder den Befehlszeilen-Executor verwenden möchten, muss der Testausführungsdienst auf dem Ziel verfügbar sein. Eine portable C++-Implementierung des Dienstes ist im Verzeichnis execserver verfügbar. Das eigenständige Binärprogramm wird im Rahmen des Builds des DEQP-Testmoduls für PC-Ziele erstellt. Sie können execserver/CMakeLists.txt ändern, um einen Build für andere Ziele zu ermöglichen.
Die C++-Version des Testausführungsdienstes akzeptiert zwei Befehlszeilenparameter:
- Mit
--port=<port>wird der TCP-Port festgelegt, den der Server überwacht. Der Standardwert ist 50016. -
--singlebeendet den Serverprozess, wenn die Verbindung zum Client getrennt wird. Standardmäßig bleibt der Serverprozess aktiv, um weitere Testausführungsanfragen zu bearbeiten.
Tests ausführen
Auf dieser Seite finden Sie Anleitungen zum Ausführen von DEQP-Tests in Linux- und Windows-Umgebungen mit Befehlszeilenargumenten und zum Arbeiten mit dem Android-Anwendungspaket.
Linux- und Windows-Umgebungen
Kopieren Sie zuerst die folgenden Dateien und Verzeichnisse auf das Zielgerät.
| Modul | Verzeichnis | Target |
|---|---|---|
| Ausführungsserver | build/execserver/execserver |
<dst>/execserver |
| EGL-Modul | build/modules/egl/deqp-egl |
<dst>/deqp-egl |
| GLES2-Modul | build/modules/gles2/deqp-gles2 |
<dst>/deqp-gles2 |
data/gles2 |
<dst>/gles2 |
|
| GLES3-Modul | build/modules/gles3/deqp-gles3 |
<dst>/deqp-gles3 |
data/gles3 |
<dst>/gles3 |
|
| GLES3.1-Modul | build/modules/gles31/deqp-gles31 |
<dst>/deqp-gles31 |
data/gles31 |
<dst>/gles31 |
|
| GLES3.2-Modul | build/modules/gles32/deqp-gles32 |
<dst>/deqp-gles32 |
data/gles32 |
<dst>/gles32 |
Sie können den Ausführungsdienst und die Testbinärdateien an einem beliebigen Ort im Zieldateisystem bereitstellen. Die Testbinärdateien erwarten jedoch, dass sich die Datenverzeichnisse im aktuellen Arbeitsverzeichnis befinden. Starten Sie den Test Execution Service auf dem Zielgerät, wenn Sie bereit sind. Weitere Informationen zum Starten des Dienstes finden Sie unter Testausführungsdienst.
Befehlszeilenargumente
In der folgenden Tabelle sind Befehlszeilenargumente aufgeführt, die sich auf die Ausführung aller Testprogramme auswirken.
| Argument | Beschreibung |
|---|---|
--deqp-case=<casename> |
Führen Sie Testläufe aus, die einem bestimmten Muster entsprechen. Platzhalter (*) werden unterstützt. |
--deqp-log-filename=<filename> |
Schreibt die Testergebnisse in die Datei, deren Namen Sie angeben. Der Dienst für die Testausführung legt den Dateinamen beim Starten eines Tests fest. |
--deqp-stdin-caselist |
Liest die Fallliste aus stdin oder aus einem angegebenen Argument. Der Testausführungsdienst legt das Argument entsprechend der empfangenen Ausführungsanfrage fest. Eine Beschreibung des Formats der Fallliste finden Sie im nächsten Abschnitt. |
--deqp-test-iteration-count=<count> |
Überschreibt die Anzahl der Iterationen für Tests, die eine variable Anzahl von Iterationen unterstützen. |
--deqp-base-seed=<seed> |
Basisausgangswert für die Testläufe, bei denen Randomisierung verwendet wird. |
GLES2- und GLES3-spezifische Argumente
In der folgenden Tabelle sind die GLES2- und GLES3-spezifischen Argumente aufgeführt.| Argument | Beschreibung |
|---|---|
--deqp-gl-context-type=<type> |
OpenGL-Kontexttyp. Welche Kontexttypen verfügbar sind, hängt von der Plattform ab. Auf Plattformen, die EGL unterstützen, kann der Wert egl verwendet werden, um den EGL-Kontext auszuwählen. |
--deqp-gl-config-id=<id> |
Führen Sie Tests für die angegebene GL-Konfigurations-ID aus. Die Interpretation ist plattformabhängig. Auf der EGL-Plattform ist dies die EGL-Konfigurations-ID. |
--deqp-gl-config-name=<name> |
Tests für eine benannte GL-Konfiguration ausführen Die Interpretation ist plattformabhängig. Für EGL lautet das Format rgb(a)<bits>d<bits>s<bits>. Bei einem Wert von rgb888s8 wird beispielsweise die erste Konfiguration ausgewählt, bei der der Farbpuffer RGB888 und der Schablonenpuffer 8 Bit hat. |
--deqp-gl-context-flags=<flags> |
Erstellt einen Kontext. Geben Sie robust oder debug an. |
--deqp-surface-width=<width> |
Versuchen Sie, eine Oberfläche mit einer bestimmten Größe zu erstellen. Die Unterstützung dafür ist optional. |
--deqp-surface-type=<type> |
Verwenden Sie einen bestimmten Oberflächentyp als primäres Ziel für das Testrendering. Mögliche Typen sind window, pixmap, pbuffer und fbo. |
--deqp-screen-rotation=<rotation> |
Bildschirmausrichtung in 90‑Grad-Schritten für Plattformen, die dies unterstützen. |
Format der Testlaufliste
Die Testfallliste kann in zwei Formaten angegeben werden. Bei der ersten Option wird der vollständige Name jedes Tests in einer separaten Zeile in einer Standard-ASCII-Datei aufgeführt. Wenn die Testsets größer werden, können die sich wiederholenden Präfixe umständlich sein. Um die Präfixe nicht zu wiederholen, verwenden Sie die unten gezeigte Trie-Syntax (auch als Präfixbaum bezeichnet).
{nodeName{firstChild{…},…lastChild{…}}}
Beispiel:
{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}
Das führt zu den folgenden beiden Testläufen:
dEQP-EGL.config_list dEQP-EGL.create_context.rgb565_depth_stencil
Android
Das Android-Anwendungspaket enthält alle erforderlichen Komponenten, einschließlich des Testausführungsdienstes, der Testbinärdateien und der Datendateien. Die Testaktivität ist ein NativeActivity, der EGL verwendet (erfordert Android 3.2 oder höher).
Das Anwendungspaket kann mit dem folgenden Befehl installiert werden. Der angezeigte Name ist der Name des APK im Android CTS-Paket. Dieser Name hängt vom Build ab:
adb –d install –r com.drawelements.deqp.apk
Verwenden Sie Folgendes, um den Dienst für die Testausführung zu starten und die Portweiterleitung einzurichten:
adb –d forward tcp:50016 tcp:50016adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter
Debug-Ausgaben können aktiviert werden, indem Sie vor dem Starten der Tests Folgendes ausführen:
adb –d shell setprop log.tag.dEQP DEBUG
Tests auf Android ohne Android CTS ausführen
Wenn Sie die Aktivität zur Testausführung manuell starten möchten, erstellen Sie eine Android-Intention, die auf android.app.NativeActivity ausgerichtet ist. Die Aktivitäten sind im com.drawelements.deqp-Paket enthalten. Die Befehlszeile muss als zusätzlicher String mit dem Schlüssel "cmdLine" im Intent angegeben werden.
Ein Test-Log wird in /sdcard/dEQP-log.qpa geschrieben. Wenn der Testlauf nicht normal startet, sind zusätzliche Debugging-Informationen im Geräteprotokoll verfügbar.
Sie können eine Aktivität über die Befehlszeile mit dem Tool am starten. Wenn Sie beispielsweise dEQP-GLES2.info-Tests auf einer Plattform ausführen möchten, die NativeActivity, unterstützt, verwenden Sie die folgenden Befehle.
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"'
Auf Android debuggen
Wenn Sie die Tests unter dem GDB-Debugger auf Android ausführen möchten, müssen Sie zuerst den Debug-Build kompilieren und installieren, indem Sie die folgenden beiden Skripts ausführen:
python android/scripts/build.py --native-build-type=Debugpython android/scripts/install.py
Nachdem der Debug-Build auf dem Gerät installiert wurde, führen Sie den folgenden Befehl aus, um die Tests unter GDB auf dem Host zu starten:
python android/scripts/debug.py \ --deqp-commandline="--deqp-log-filename=/sdcard/TestLog.qpa --deqp-case=dEQP-GLES2.functional.*"
Die DEQP-Befehlszeile hängt von den auszuführenden Testläufen und anderen erforderlichen Parametern ab. Mit dem Skript wird am Anfang der DEQP-Ausführung (tcu::App::App) ein Standard-Haltepunkt hinzugefügt.
Das debug.py-Skript akzeptiert mehrere Befehlszeilenargumente für Aktionen wie das Festlegen von Haltepunkten für das Debugging, gdbserver-Verbindungsparameter und Pfade zu zusätzlichen zu debuggenden Binärdateien (verwenden Sie debug.py
--help für alle Argumente und Erklärungen). Das Skript kopiert auch einige Standardbibliotheken vom Zielgerät, um Symbollisten zu erhalten.
Wenn Sie den Treibercode durchgehen möchten (z. B. wenn GDB die Speicherorte der Binärdateien mit vollständigen Debugging-Informationen kennen muss), fügen Sie weitere Bibliotheken über die debug.py-Befehlszeilenparameter hinzu. Dieses Skript schreibt ab Zeile 132 der Skriptdatei eine Konfigurationsdatei für den GDB. Sie können zusätzliche Pfade zu Binärdateien usw. angeben, aber die Angabe der richtigen Befehlszeilenparameter sollte ausreichen.
Hinweis:Unter Windows ist für die GDB-Binärdatei libpython2.7.dll erforderlich. Fügen Sie vor dem Starten von debug.py die Variable <path-to-ndk>/prebuilt/windows/bin zur PATH-Variablen hinzu.
Hinweis:Das Debugging von nativem Code funktioniert nicht unter Android 4.3. Informationen zu Workarounds finden Sie in diesem öffentlichen Fehler. In Android 4.4 und höher tritt dieser Fehler nicht auf.
Tests automatisieren
DEQP-Testmodule können auf verschiedene Arten in automatisierte Testsysteme eingebunden werden. Der beste Ansatz hängt von der vorhandenen Testinfrastruktur und der Zielumgebung ab.
Die primäre Ausgabe eines Testlaufs ist immer die Testprotokolldatei, d.h. die Datei mit dem Suffix .qpa. Die vollständigen Testergebnisse können aus dem Testlog geparst werden. Die Konsolenausgabe enthält nur Debugging-Informationen und ist möglicherweise nicht auf allen Plattformen verfügbar.
Testbinärdateien können direkt über ein Testautomatisierungssystem aufgerufen werden. Das Test-Binärprogramm kann für einen bestimmten Fall, für einen Testsatz oder für alle verfügbaren Tests gestartet werden. Wenn während der Ausführung ein schwerwiegender Fehler auftritt (z. B. bestimmte API-Fehler oder ein Absturz), wird die Testausführung abgebrochen. Für Regressionstests ist es am besten, die Testbinärdateien für einzelne Fälle oder kleine Testsätze separat aufzurufen, um auch bei einem schwerwiegenden Fehler Teilergebnisse zu erhalten.
Das DEQP enthält Befehlszeilentools für die Testausführung, die in Kombination mit dem Ausführungsservice für eine robustere Integration verwendet werden können. Der Executor erkennt das Beenden des Testprozesses und setzt die Testausführung mit dem nächsten verfügbaren Testfall fort. Aus der gesamten Testsitzung wird eine einzige Protokolldatei erstellt. Diese Einrichtung ist ideal für einfache Testsysteme, die keine Funktionen zur Wiederherstellung nach Abstürzen bieten.
Befehlszeilentools für die Testausführung
Das aktuelle Befehlszeilentoolset umfasst ein Tool zur Remote-Testausführung, einen Generator für den Vergleich von Testlogs für die Regressionsanalyse, einen Testlog-zu-CSV-Konverter, einen Testlog-zu-XML-Konverter und einen Testlog-zu-JUnit-Konverter.
Der Quellcode für diese Tools befindet sich im Verzeichnis executor und die Binärdateien werden im Verzeichnis <builddir>/executor erstellt.
Befehlszeilen-Testausführung
Der Befehlszeilen-Test-Executor ist ein portables C++-Tool zum Starten eines Testlaufs auf einem Gerät und zum Erfassen der resultierenden Logs über TCP/IP. Der Executor kommuniziert mit dem Ausführungsdienst (execserver) auf dem Zielgerät.
Zusammen bieten sie Funktionen wie die Wiederherstellung nach Abstürzen des Testprozesses.
Die folgenden Beispiele veranschaulichen die Verwendung des Befehlszeilen-Test-Executors (weitere Informationen finden Sie unter --help):
Beispiel 1: GLES2-Funktionstests auf einem Android-Gerät ausführen
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"
Beispiel 2: Einen teilweisen OpenGL ES 2-Testlauf lokal fortsetzen
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
Testprotokoll als CSV-Datei exportieren und vergleichen
Das DEQP-Tool enthält ein Tool zum Konvertieren von Testprotokollen (.qpa-Dateien) in CSV-Dateien. Die CSV-Ausgabe enthält eine Liste der Testläufe und ihrer Ergebnisse. Das Tool kann auch zwei oder mehr Batch-Ergebnisse vergleichen und nur die Testläufe auflisten, die in den eingegebenen Batch-Ergebnissen unterschiedliche Statuscodes haben. Beim Vergleich wird auch die Anzahl der übereinstimmenden Fälle ausgegeben.
Die Ausgabe im CSV-Format ist sehr praktisch für die Weiterverarbeitung mit Standard-Befehlszeilenprogrammen oder mit einem Tabellenkalkulationsprogramm. Mit dem folgenden Befehlszeilenargument können Sie ein zusätzliches, menschenlesbares Nur-Text-Format auswählen: --format=text
Beispiel 1: Testprotokoll im CSV-Format exportieren
testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csvtestlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv
Beispiel 2: Unterschiede zwischen den Testergebnissen zweier Testlogs auflisten
testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa
Hinweis:Das Argument --value=code gibt den Testergebniscode aus, z. B. „Bestanden“ oder „Nicht bestanden“. Mit dem Argument --value=details wird die weitere Erläuterung des Ergebnisses oder numerischen Werts ausgewählt, der durch einen Leistungs-, Funktions- oder Genauigkeitstest generiert wird.
XML-Export von Testprotokollen
Testprotokolldateien können mit dem testlog-to-xml-Dienstprogramm in gültige XML-Dokumente konvertiert werden. Es werden zwei Ausgabemodi unterstützt:
- Modus „Separate Dokumente“, in dem jeder Testlauf und das
caselist.xml-Zusammenfassungsdokument in ein Zielverzeichnis geschrieben werden - Modus mit einer einzelnen Datei, in dem alle Ergebnisse in der Datei
.qpain ein einzelnes XML-Dokument geschrieben werden.
Exportierte Testprotokolldateien können in einem Browser mit einem XML-Stylesheet angezeigt werden.
Beispieldokumente für Stylesheets (testlog.xsl und testlog.css) sind im Verzeichnis doc/testlog-stylesheet verfügbar. Wenn Sie die Logdateien in einem Browser rendern möchten, kopieren Sie die beiden Stylesheet-Dateien in dasselbe Verzeichnis, in dem sich die exportierten XML-Dokumente befinden.
Wenn Sie Google Chrome verwenden, muss über HTTP auf die Dateien zugegriffen werden, da Chrome aus Sicherheitsgründen den Zugriff auf lokale Dateien einschränkt. Die Standard-Python-Installation enthält einen einfachen HTTP-Server, der mit dem Befehl python –m SimpleHTTPServer 8000 gestartet werden kann, um das aktuelle Verzeichnis bereitzustellen. Nach dem Starten des Servers müssen Sie nur noch mit dem Chrome-Browser auf http://localhost:8000 zugreifen, um das Testprotokoll aufzurufen.
Konvertierung in ein JUnit-Testprotokoll
Viele Testautomatisierungssysteme können Testlaufberichte aus der JUnit-Ausgabe generieren. Die DEQP-Testlogdateien können mit dem Tool „testlog-to-junit“ in das JUnit-Ausgabeformat konvertiert werden.
Derzeit unterstützt das Tool nur die Übersetzung des Testfallurteils. Da JUnit nur die Ergebnisse „Bestanden“ und „Fehler“ unterstützt, wird ein bestandenes Ergebnis des deqp auf „JUnit-Bestanden“ abgebildet und andere Ergebnisse werden als Fehler betrachtet. Der ursprüngliche deqp-Ergebniscode ist in der JUnit-Ausgabe verfügbar. Andere Daten wie Log-Meldungen und Ergebnisbilder bleiben bei der Konvertierung nicht erhalten.
Spezielle Testgruppen verwenden
Für einige Testgruppen sind möglicherweise spezielle Befehlszeilenoptionen erforderlich oder werden unterstützt. Bei der Verwendung auf bestimmten Systemen ist besondere Vorsicht geboten.
Stresstests für die Arbeitsspeicherzuweisung
Bei Speichertests werden Bedingungen für fehlenden Speicherplatz simuliert, indem bestimmte Ressourcen wiederholt zugewiesen werden, bis der Treiber einen Fehler aufgrund von fehlendem Speicherplatz meldet.
Auf bestimmten Plattformen wie Android und den meisten Linux-Varianten kann Folgendes passieren: Das Betriebssystem beendet den Testprozess möglicherweise, anstatt einem Treiber zu erlauben, einen Fehler aufgrund von zu wenig Arbeitsspeicher zu beheben oder anderweitig zu behandeln. Auf solchen Plattformen sind Tests, die darauf ausgelegt sind, Out-of-Memory-Fehler zu verursachen, standardmäßig deaktiviert und müssen mit dem Befehlszeilenargument --deqp-test-oom=enable aktiviert werden.
Es wird empfohlen, solche Tests manuell auszuführen, um zu prüfen, ob sich das System bei Ressourcenengpässen richtig verhält. In einer solchen Situation sollte ein Absturz des Testprozesses jedoch als bestanden interpretiert werden.
Testgruppen
dEQP-GLES2.stress.memory.* dEQP-GLES3.stress.memory.*
Langzeit-Rendering-Stresstests
Rendering-Stresstests sollen Robustheitsprobleme bei anhaltender Rendering-Last aufdecken. Standardmäßig werden die Tests nur wenige Male ausgeführt. Sie können jedoch so konfiguriert werden, dass sie unbegrenzt ausgeführt werden, indem Sie das Befehlszeilenargument --deqp-test-iteration-count=-1 angeben. Der Test-Watchdog sollte deaktiviert werden (--deqp-watchdog=disable), wenn diese Tests über einen längeren Zeitraum ausgeführt werden.
Testgruppen
dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.*