AOSP umfasst die GPU-Testsuite des drawElements Quality Program (deqp) unter https://android.googlesource.com/platform/external/deqp . Auf dieser Seite erfahren Sie, wie Sie die Deqp-Testsuite in einer neuen Umgebung bereitstellen.
Um mit dem zuletzt übermittelten Code zu arbeiten, verwenden Sie den Zweig deqp-dev
. Für Code, der einer bestimmten Android CTS-Version entspricht, verwenden Sie den Zweig release-code-name -release
(verwenden Sie beispielsweise für Android 6.0 den Zweig marshmallow-release
“).
Quelllayout
Das Quellcode-Layout für die DEQP-Testmodule und unterstützenden Bibliotheken ist in der folgenden Tabelle dargestellt (die Auflistung erhebt keinen Anspruch auf Vollständigkeit, hebt jedoch die wichtigsten Verzeichnisse hervor).
Verzeichnis | Beschreibung |
---|---|
android | Android-Testquellen und Build-Skripte |
data | Testdatendateien |
modules | Testmodulquellen |
modules/egl | EGL-Modul |
modules/gles2 | GLES2-Modul |
modules/gles3 | GLES3-Modul |
modules/gles31 | GLES3.1-Modul |
modules/gles32 | GLES3.2-Modul |
targets | Zielspezifische Build-Konfigurationsdateien |
framework | DEQP-Testmodul-Framework und Dienstprogramme |
framework/delibs | Basisportabilität und Build-Bibliotheken |
framework/platform | Plattformports |
framework/qphelper | Testprogramm-Integrationsbibliothek (C) |
framework/common | Deqp-Framework (C++) |
framework/opengl, framework/egl | API-spezifische Dienstprogramme |
execserver | Geräteseitige ExecServer-Quelle |
executor | Hostseitiges Test-Executor-Shell-Tool und Dienstprogramme |
external | Erstellen Sie ein Stub-Verzeichnis für die externen Bibliotheken libpng und zlib |
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.
Erstellen Sie Testprogramme
Das Test-Framework wurde im Hinblick auf Portabilität entwickelt. Die einzigen zwingenden Anforderungen sind vollständige C++-Unterstützung und Standardsystembibliotheken für I/O, Threads und Sockets.
CMake-Build-System
Die DEQP-Quellen verfügen über Build-Skripte 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, dh Sie sollten Makefiles oder Projektdateien immer in einem separaten Build-Verzeichnis außerhalb des Quellbaums erstellen. CMake verfügt über kein „distclean“-Ziel, daher muss das Entfernen aller von CMake generierten Dateien manuell erfolgen.
Konfigurationsoptionen werden CMake mithilfe der Syntax -D OPTION_NAME = VALUE
übergeben. Einige häufig verwendete Optionen für deqp sind unten aufgeführt.
Konfigurationsoption | Beschreibung |
---|---|
DEQP_TARGET | Zielname, zum Beispiel: „android“ Die deqp-CMake-Skripte enthalten die Datei |
CMAKE_TOOLCHAIN_FILE | Pfad zur Toolchain-Datei für CMake. Wird für die Cross-Kompilierung verwendet. |
CMAKE_BUILD_TYPE | Build-Typ für Makefile-Ziele. Gültige Werte sind: „Debug“ und „Release“ Beachten Sie, dass die Interpretation und der Standardtyp vom Ziel-Build-System abhängen. Weitere Informationen finden Sie in der CMake-Dokumentation. |
Erstellen Sie eine Ziel-Build-Datei
Das DEQP-Build-System wird mithilfe von Ziel-Build-Dateien für neue Ziele konfiguriert. Eine Ziel-Build-Datei 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 mithilfe des Build-Parameters DEQP_TARGET
ausgewählt.
Dateipfade in Zieldateien beziehen sich auf das Basisverzeichnis deqp
, nicht auf das Verzeichnis targets/ NAME
. Die folgenden Standardvariablen können je nach Ziel-Build-Datei festgelegt werden.
Variable | Beschreibung |
---|---|
DEQP_TARGET_NAME | Zielname (wird in Testprotokolle aufgenommen) |
DEQP_SUPPORT_GLES2 | Ob GLES2 unterstützt wird (Standard: AUS) |
DEQP_GLES2_LIBRARIES | GLES2-Bibliotheken (leer lassen, wenn sie nicht unterstützt werden oder dynamisches Laden verwendet wird) |
DEQP_SUPPORT_GLES3 | Ob GLES3.x unterstützt wird (Standard: AUS) |
DEQP_GLES3_LIBRARIES | GLES3.x-Bibliotheken (leer lassen, wenn sie nicht unterstützt werden oder dynamisches Laden verwendet wird) |
DEQP_SUPPORT_VG | Ob OpenVG unterstützt wird (Standard: AUS) |
DEQP_OPENVG_LIBRARIES | OpenVG-Bibliotheken (leer lassen, wenn sie nicht unterstützt werden oder dynamisches Laden verwendet wird) |
DEQP_SUPPORT_EGL | Ob EGL unterstützt wird (Standard: AUS) |
DEQP_EGL_LIBRARIES | EGL-Bibliotheken (leer lassen, wenn sie nicht unterstützt werden oder dynamisches Laden verwendet wird) |
DEQP_PLATFORM_LIBRARIES | Für die Verlinkung sind zusätzlich plattformspezifische Bibliotheken erforderlich |
DEQP_PLATFORM_COPY_LIBRARIES | Liste der Bibliotheken, die in jedes Testbinär-Build-Verzeichnis kopiert werden. Kann zum Kopieren von Bibliotheken verwendet werden, die zum Ausführen von Tests benötigt werden, sich aber nicht im Standardsuchpfad befinden. |
TCUTIL_PLATFORM_SRCS | Liste der Plattformportquellen. Standardquellen werden basierend auf den Funktionen und dem Betriebssystem bestimmt. Hinweis: Pfade sind relativ zu: |
Die Ziel-Build-Datei kann mithilfe der CMake-Funktionen include_directories()
und link_directories()
zusätzliche Include- oder Linkpfade hinzufügen.
Win32-Build
Der einfachste Weg, Deqp-Module für Windows zu erstellen, ist die Verwendung des CMake-Build-Systems. Sie benötigen CMake 2.6.12 oder neuer und den Microsoft Visual C/C++-Compiler. Das 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"
Ein 64-Bit-Build kann erstellt werden, indem als Build-Generator „Visual Studio VERSION Win64“ ausgewählt wird:
cmake path\to\src\deqp -G "Visual Studio 12 Win64"
Sie können NMake-Makefiles auch mit der Option -G "NMake Makefiles"
sowie dem Build-Typ ( -DCMAKE_BUILD_TYPE="Debug"
oder "Release"
) generieren.
Erstellung von Renderkontexten
Der Rendering-Kontext kann entweder mit WGL oder mit EGL unter Windows erstellt werden.
WGL-Unterstützung
Alle Win32-Binärdateien unterstützen die GL-Kontexterstellung mit WGL, da hierfür nur Standardbibliotheken erforderlich sind. Der WGL-Kontext kann mit dem Befehlszeilenargument --deqp-gl-context-type=wgl
ausgewählt werden. Im WGL-Modus verwendet der Deqp die Erweiterung WGL_EXT_create_context_es_profile
, um OpenGL ES-Kontexte zu erstellen. Es wurde getestet, dass es mit den neuesten Treibern von NVIDIA und Intel funktioniert. AMD-Treiber unterstützen die erforderliche Erweiterung nicht.
EGL-Unterstützung
Der DEQP wird mit dynamischem Laden für EGL unter Windows erstellt, wenn DEQP_SUPPORT_EGL aktiviert ist. Dies ist bei den meisten Zielen die Standardeinstellung. Wenn der Host dann über EGL-Bibliotheken verfügt, ist es möglich, mit ihnen Tests mit dem Befehlszeilenparameter --deqp-gl-context-type=egl
auszuführen
Android-Build
Der Android-Build verwendet CMake-Build-Skripte zum Erstellen des nativen Testcodes. Java-Teile, also 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:
- Die neueste Version des Android NDK ; Die Datei
android/scripts/common.py
listet die erforderliche Version auf - Eigenständiges Android-SDK mit installierten API 13-, SDK-Tools-, SDK-Plattform-Tools- und SDK-Build-Tools- Paketen
- Apache Ant 1.9.4 (erforderlich für den Java-Code-Build)
- CMake 2.8.12 oder neuer
- Python 2.6 oder neuer in der 2.x-Serie; 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 basierend auf der Umgebungsvariablen PATH mit bestimmten vorrangigen Standardwerten gefunden. 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.
Deqp-Komponenten auf dem Gerät, der Testausführungsdienst und Testprogramme werden durch Ausführen des Skripts android/scripts/build.py
erstellt. Die endgültige APK-Datei wird in android/package/bin
erstellt und kann mit dem install.py
Skript installiert werden. Wenn der Befehlszeilen-Executor verwendet wird, wird der ExecService mit dem Skript launch.py
auf dem Gerät über ADB gestartet. Die Skripte können von jedem Verzeichnis aus ausgeführt werden.
Linux-Build
Testbinärdateien und Befehlszeilen-Dienstprogramme 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 aufbauen | Beschreibung |
---|---|
default | Standardziel, das die Introspektion der CMake-Plattform verwendet, um die Unterstützung für verschiedene APIs zu ermitteln. |
x11_glx | Verwendet GLX zum Erstellen von OpenGL (ES)-Kontexten. |
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 eine gute Standardeinstellung. Ohne sie wird ein standardmäßiger, nicht optimierter Release-Build erstellt.
Die Befehlszeilenargumente -DCMAKE_C_FLAGS
und -DCMAKE_CXX_FLAGS
können verwendet werden, um zusätzliche Argumente an den Compiler zu übergeben. Beispielsweise kann der 32-Bit- oder 64-Bit-Build durch Setzen -DCMAKE_C(XX)_FLAGS="-m32"
bzw. "-m64"
erfolgen. Wenn nicht angegeben, wird die native Architektur der Toolchain verwendet, normalerweise 64-Bit in der 64-Bit-Toolchain.
Die Argumente -DCMAKE_LIBRARY_PATH
und -DCMAKE_INCLUDE_PATH
können für CMake verwendet werden, um CMake zusätzliche Bibliothek bereitzustellen oder Suchpfade einzuschließen.
Ein Beispiel für eine vollständige Befehlszeile, die zum Ausführen eines 32-Bit-Debug-Builds für Treiberheader 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 durch die Verwendung einer CMake-Toolchain-Datei erreicht werden. Die Toolchain-Datei gibt den zu verwendenden Compiler sowie benutzerdefinierte Suchpfade für Bibliotheken und Header an. Mehrere Toolchain-Dateien für gängige Szenarien sind im Release-Paket im Verzeichnis framework/delibs/cmake
enthalten.
Zusätzlich zu den standardmäßigen CMake-Variablen können die folgenden deqp-spezifischen Variablen durch die Toolchain-Datei festgelegt werden. CMake kann DE_OS
, DE_COMPILER
und DE_PTR_SIZE
normalerweise korrekt erkennen, DE_CPU
muss jedoch durch die Toolchain-Datei festgelegt werden.
Variable | Beschreibung |
---|---|
DE_OS | Betriebssystem. Unterstützte Werte sind: |
DE_COMPILER | Compilertyp. Unterstützte Werte sind: |
DE_CPU | CPU-Typ. Unterstützte Werte sind: |
DE_PTR_SIZE | sizeof(void*) auf der Plattform. Unterstützte Werte sind: 4 und 8 |
Die Toolchain-Datei kann über den Build-Parameter CMAKE_TOOLCHAIN_FILE
ausgewählt werden. Folgendes würde beispielsweise Makefiles für einen Build mit dem CodeSourcery-Cross-Compiler für ARM/Linux erstellen:
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
Der DEQP benötigt während der Verknüpfung 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 Plattform-Port kann sie zur Linkzeit bereitstellen.
Wenn die Unterstützung für eine API in den Build-Einstellungen aktiviert ist und keine Linkbibliotheken bereitgestellt werden, lädt der Deqp die erforderlichen Einstiegspunkte zur Laufzeit. Wenn die statische Verknüpfung gewünscht ist, stellen Sie die erforderlichen Linkbibliotheken in der Build-Konfigurationsvariablen DEQP_<API>_LIBRARIES
bereit.
Portieren Sie das Testframework
Die Portierung des DeQP umfasst drei Schritte: Anpassung der Basisportabilitätsbibliotheken, Implementierung von Test-Framework-Plattform-Integrationsschnittstellen und Portierung des Ausführungsdienstes.
In der folgenden Tabelle sind die Standorte für wahrscheinliche Portierungsänderungen aufgeführt. Alles, was darüber hinausgeht, dürfte exotisch sein.
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 | Ein neuer Plattform-Port und ein neuer Anwendungs-Stub können wie unter Test-Framework-Plattform-Port beschrieben implementiert werden. |
Basisportabilitätsbibliotheken
Die Basisportabilitätsbibliotheken unterstützen bereits Windows, die meisten Linux-Varianten, Mac OS, iOS und Android. Wenn das Testziel auf einem dieser Betriebssysteme läuft, besteht höchstwahrscheinlich überhaupt keine Notwendigkeit, die Basisportabilitätsbibliotheken zu berühren.
Test-Framework-Plattform-Port
Der Plattformport des DEQP-Testframeworks erfordert zwei Komponenten: einen Anwendungseinstiegspunkt und eine Plattformschnittstellenimplementierung.
Der Anwendungseinstiegspunkt ist für die Erstellung des Plattformobjekts, die Erstellung eines Befehlszeilenobjekts ( tcu::CommandLine
), das Öffnen eines Testprotokolls ( tcu::TestLog
) und die Iteration der Testanwendung ( tcu::App
) verantwortlich. Wenn das Zielbetriebssystem einen standardmäßigen main()
Einstiegspunkt 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 | Standard-Einstiegspunkt für Anwendungen |
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 einen Überblick darüber, was zum Ausführen der Tests implementiert werden muss.
Modul | Schnittstelle |
---|---|
OpenGL (ES)-Testmodule | GL-Plattformschnittstelle |
EGL-Testmodul | EGL-Plattformschnittstelle |
Detaillierte Anweisungen zur Implementierung von Plattformports finden Sie in den Headern der Portierungsschicht.
Testdurchführungsservice
Um die Testausführungsinfrastruktur von deqp oder den Befehlszeilen-Executor verwenden zu können, muss der Testausführungsdienst auf dem Ziel verfügbar sein. Eine portable C++-Implementierung des Dienstes wird im Verzeichnis execserver
bereitgestellt. Die eigenständige Binärdatei wird als Teil des Deqp-Testmodul-Builds für PC-Ziele erstellt. Sie können execserver/CMakeLists.txt
ändern, um einen Build auf anderen Zielen zu ermöglichen.
Die C++-Version des Testausführungsdienstes akzeptiert zwei Befehlszeilenparameter:
-
--port=<port>
legt den TCP-Port fest, auf dem der Server lauscht. Der Standardwert ist 50016. -
--single
beendet den Serverprozess, wenn der Client die Verbindung trennt. Standardmäßig bleibt der Serverprozess aktiv, um weitere Testausführungsanforderungen zu bearbeiten.
Führen Sie die Tests durch
Auf dieser Seite finden Sie Anweisungen zum Ausführen von Deqp-Tests in Linux- und Windows-Umgebungen, zum Verwenden von Befehlszeilenargumenten und zum Arbeiten mit dem Android-Anwendungspaket.
Linux- und Windows-Umgebungen
Kopieren Sie zunächst die folgenden Dateien und Verzeichnisse auf das Ziel.
Modul | Verzeichnis | Ziel |
---|---|---|
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 bereitstellen und Binärdateien überall im Zieldateisystem testen. Testbinärdateien erwarten jedoch, dass Datenverzeichnisse im aktuellen Arbeitsverzeichnis gefunden werden. Wenn Sie bereit sind, starten Sie den Testausführungsdienst auf dem Zielgerät. Einzelheiten zum Starten des Dienstes finden Sie unter Testausführungsdienst .
Kommandozeilenargumente
In der folgenden Tabelle sind Befehlszeilenargumente aufgeführt, die sich auf die Ausführung aller Testprogramme auswirken.
Streit | Beschreibung |
---|---|
--deqp-case=<casename> | Führen Sie Fälle aus, die einem bestimmten Muster entsprechen. Platzhalter (*) wird unterstützt. |
--deqp-log-filename=<filename> | Schreiben Sie die Testergebnisse in die Datei, deren Namen Sie angeben. Der Testausführungsdienst legt den Dateinamen fest, wenn ein Test gestartet wird. |
--deqp-stdin-caselist | Fallliste aus stdin oder einem bestimmten Argument lesen. Der Testausführungsdienst legt das Argument entsprechend der empfangenen Ausführungsanforderung fest. Eine Beschreibung des Falllistenformats finden Sie im nächsten Abschnitt. |
--deqp-test-iteration-count=<count> | Überschreiben Sie die Iterationsanzahl für Tests, die eine variable Anzahl von Iterationen unterstützen. |
--deqp-base-seed=<seed> | Basis-Seed für die Testfälle, die Randomisierung verwenden. |
GLES2- und GLES3-spezifische Argumente
In der folgenden Tabelle sind die GLES2- und GLES3-spezifischen Argumente aufgeführt.Streit | Beschreibung |
---|---|
--deqp-gl-context-type=<type> | OpenGL-Kontexttyp. Die verfügbaren Kontexttypen hängen von der Plattform ab. Auf Plattformen, die EGL unterstützen, kann der Wert egl zur Auswahl des EGL-Kontexts verwendet werden. |
--deqp-gl-config-id=<id> | Führen Sie Tests für die bereitgestellte GL-Konfigurations-ID durch. Die Interpretation ist plattformabhängig. Auf der EGL-Plattform ist dies die EGL-Konfigurations-ID. |
--deqp-gl-config-name=<name> | Führen Sie Tests für eine benannte GL-Konfiguration durch. Die Interpretation ist plattformabhängig. Für EGL lautet das Format rgb(a)<bits>d<bits>s<bits> . Beispielsweise wählt der Wert rgb888s8 die erste Konfiguration aus, bei der der Farbpuffer RGB888 ist 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 hierfür ist optional. |
--deqp-surface-type=<type> | Verwenden Sie einen bestimmten Oberflächentyp als Haupttest-Rendering-Ziel. 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. |
Testfalllistenformat
Die Testfallliste kann in zwei Formaten angegeben werden. Die erste Möglichkeit besteht darin, den vollständigen Namen jedes Tests in einer separaten Zeile in einer Standard-ASCII-Datei aufzulisten. Wenn die Testsätze wachsen, können sich wiederholende Präfixe umständlich sein. Um eine Wiederholung der Präfixe zu vermeiden, verwenden Sie die unten gezeigte Trie-Syntax (auch als Präfixbaum bezeichnet).
{nodeName{firstChild{…},…lastChild{…}}}
Zum Beispiel:
{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}
Übersetzt in die folgenden zwei Testfälle:
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, Testbinärdateien und Datendateien. Die Testaktivität ist eine NativeActivity
, die 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; der Name hängt vom Build ab):
adb –d install –r com.drawelements.deqp.apk
Um den Testausführungsdienst zu starten und die Portweiterleitung einzurichten, verwenden Sie Folgendes:
adb –d forward tcp:50016 tcp:50016
adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter
Debug-Drucke können aktiviert werden, indem vor Beginn der Tests Folgendes ausgeführt wird:
adb –d shell setprop log.tag.dEQP DEBUG
Führen Sie Tests auf Android ohne Android CTS durch
Um die Testausführungsaktivität manuell zu starten, erstellen Sie eine Android-Absicht, die auf android.app.NativeActivity
abzielt. Die Aktivitäten finden Sie im Paket com.drawelements.deqp
. Die Befehlszeile muss als zusätzlicher String mit dem Schlüssel "cmdLine"
im Intent bereitgestellt werden.
Ein Testprotokoll wird in /sdcard/dEQP-log.qpa
geschrieben. Sollte der Testlauf nicht normal starten, stehen im Geräteprotokoll zusätzliche Debug-Informationen zur Verfügung.
Sie können eine Aktivität über die Befehlszeile mit dem Dienstprogramm am
starten. Um beispielsweise dEQP-GLES2.info
Tests auf einer Plattform auszuführen, die NativeActivity,
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"'
Debuggen Sie auf Android
Um die Tests unter dem GDB-Debugger auf Android auszuführen, kompilieren und installieren Sie zunächst den Debug-Build, indem Sie die folgenden zwei Skripte ausführen:
python android/scripts/build.py --native-build-type=Debug
python 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 zu starten, die auf dem Host ausgeführt werden:
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 Testfällen und anderen erforderlichen Parametern ab. Das Skript fügt zu Beginn der Deqp-Ausführung einen Standardhaltepunkt hinzu ( tcu::App::App
).
Das debug.py
Skript akzeptiert mehrere Befehlszeilenargumente für Aktionen wie das Festlegen von Haltepunkten für das Debuggen, 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 außerdem einige Standardbibliotheken vom Zielgerät, um Symbollisten abzurufen.
Um den Treibercode schrittweise durchzugehen (z. B. wenn die GDB die Speicherorte der Binärdateien mit vollständigen Debug-Informationen kennen muss), fügen Sie über die Befehlszeilenparameter debug.py
weitere Bibliotheken hinzu. Dieses Skript schreibt ab Zeile 132 der Skriptdatei eine Konfigurationsdatei für die GDB. Sie können zusätzliche Pfade zu Binärdateien usw. angeben, aber die Angabe korrekter Befehlszeilenparameter sollte ausreichen.
Hinweis: Unter Windows erfordert die GDB-Binärdatei libpython2.7.dll
. Fügen Sie vor dem Starten debug.py
<path-to-ndk>/prebuilt/windows/bin
zur PATH-Variablen hinzu.
Hinweis: Das Debuggen von nativem Code funktioniert nicht auf Standard-Android 4.3; Informationen zu Problemumgehungen finden Sie in diesem öffentlichen Fehler . Android 4.4 und höher enthalten diesen Fehler nicht.
Automatisieren Sie die Tests
Deqp-Testmodule können auf verschiedene Weise in automatisierte Testsysteme integriert werden. Der beste Ansatz hängt von der vorhandenen Testinfrastruktur und Zielumgebung ab.
Die primäre Ausgabe eines Testlaufs ist immer die Testprotokolldatei, also die Datei mit einem .qpa
Postfix. Vollständige Testergebnisse können aus dem Testprotokoll analysiert werden. Die Konsolenausgabe dient lediglich der Fehlerbehebung und ist möglicherweise nicht auf allen Plattformen verfügbar.
Testbinärdateien können direkt von einem Testautomatisierungssystem aufgerufen werden. Die Testbinärdatei 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 besteht der beste Ansatz darin, die Testbinärdateien für einzelne Fälle oder kleine Testmengen separat aufzurufen, um auch bei hartem Scheitern Teilergebnisse zur Verfügung zu haben.
Das deqp verfügt über Befehlszeilen-Testausführungstools, die in Kombination mit dem Ausführungsdienst verwendet werden können, um eine robustere Integration zu erreichen. Der Ausführende erkennt die Beendigung des Testprozesses und setzt die Testausführung beim nächsten verfügbaren Fall fort. Von der gesamten Testsitzung wird eine einzelne Protokolldatei erstellt. Dieses Setup ist ideal für leichte Testsysteme, die keine Wiederherstellungsfunktionen nach einem Absturz bieten.
Tools zur Ausführung von Befehlszeilentests
Das aktuelle Befehlszeilen-Toolset umfasst ein Remote-Testausführungstool, einen Testprotokoll-Vergleichsgenerator für die Regressionsanalyse, einen Testprotokoll-zu-CSV-Konverter, einen Testprotokoll-zu-XML-Konverter und einen Testprotokoll-zu-JUnit-Konverter .
Der Quellcode für diese Tools befindet sich im executor
Verzeichnis und die Binärdateien sind im Verzeichnis <builddir>/executor
integriert.
Befehlszeilentest-Ausführer
Der Befehlszeilen-Test-Executor ist ein portables C++-Tool zum Starten eines Testlaufs auf einem Gerät und zum Sammeln der daraus resultierenden Protokolle über TCP/IP. Der Executor kommuniziert mit dem Ausführungsdienst (Execserver) auf dem Zielgerät. Zusammen bieten sie Funktionen wie die Wiederherstellung nach Testprozessabstürzen. Die folgenden Beispiele veranschaulichen die Verwendung des Befehlszeilen-Test-Executors (verwenden Sie --help
für weitere Details):
Beispiel 1: Führen Sie GLES2-Funktionstests auf einem Android-Gerät aus
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: Setzen Sie einen teilweisen OpenGL ES 2-Testlauf lokal fort
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 CSV-Export und Vergleich
Das deqp verfügt über ein Tool zum Konvertieren von Testprotokollen ( qpa
Dateien) in CSV-Dateien. Die CSV-Ausgabe enthält eine Liste von Testfällen und deren Ergebnissen. Das Tool kann auch zwei oder mehr Batch-Ergebnisse vergleichen und nur die Testfälle auflisten, die in den Eingabe-Batch-Ergebnissen unterschiedliche Statuscodes haben. Beim Vergleich wird auch die Anzahl der übereinstimmenden Fälle gedruckt.
Die Ausgabe im CSV-Format ist sehr praktisch für die Weiterverarbeitung mit Standard-Befehlszeilenprogrammen oder mit einem Tabellenkalkulationseditor. Ein zusätzliches, für Menschen lesbares Klartextformat kann mit dem folgenden Befehlszeilenargument ausgewählt werden: --format=text
Beispiel 1: Testprotokoll im CSV-Format exportieren
testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csv
testlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv
Beispiel 2: Unterschiede der Testergebnisse zwischen zwei Testprotokollen 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“. Das Argument --value=details
wählt die weitere Erklärung des Ergebnisses oder numerischen Werts aus, der durch einen Leistungs-, Fähigkeits- oder Genauigkeitstest erzeugt wird.
Testprotokoll-XML-Export
Testprotokolldateien können mit dem Dienstprogramm testlog-to-xml
in gültige XML-Dokumente konvertiert werden. Es werden zwei Ausgabemodi unterstützt:
- Separater Dokumentenmodus, bei dem jeder Testfall und das zusammenfassende Dokument
caselist.xml
in ein Zielverzeichnis geschrieben werden - Einzeldateimodus, bei dem alle Ergebnisse in der
.qpa
Datei in ein einzelnes XML-Dokument geschrieben werden.
Exportierte Testprotokolldateien können mithilfe eines XML-Stylesheets in einem Browser angezeigt werden. Beispiel-Stylesheet-Dokumente ( testlog.xsl
und testlog.css
) werden im Verzeichnis doc/testlog-stylesheet
bereitgestellt. Um die Protokolldateien in einem Browser darzustellen, kopieren Sie die beiden Stylesheet-Dateien in dasselbe Verzeichnis, in dem sich die exportierten XML-Dokumente befinden.
Wenn Sie Google Chrome verwenden, muss auf die Dateien über HTTP zugegriffen werden, da Chrome aus Sicherheitsgründen den Zugriff auf lokale Dateien einschränkt. Die Standard-Python-Installation umfasst einen einfachen HTTP-Server, der gestartet werden kann, um das aktuelle Verzeichnis mit dem Befehl python –m SimpleHTTPServer 8000
bereitzustellen. Richten Sie nach dem Starten des Servers einfach den Chrome-Browser auf http://localhost:8000
, um das Testprotokoll anzuzeigen.
Konvertierung in ein JUnit-Testprotokoll
Viele Testautomatisierungssysteme können Testlauf-Ergebnisberichte aus der JUnit-Ausgabe generieren. Die Deqp-Testprotokolldateien können mit dem Tool testlog-to-junit in das JUnit-Ausgabeformat konvertiert werden.
Das Tool unterstützt derzeit nur die Übersetzung des Testfallurteils. Da JUnit nur „bestanden“- und „nicht bestanden“-Ergebnisse unterstützt, wird ein bestandenes Ergebnis des Deqp auf „JUnit-bestanden“ abgebildet und andere Ergebnisse werden als Fehlschläge betrachtet. Der ursprüngliche Deqp-Ergebniscode ist in der JUnit-Ausgabe verfügbar. Andere Daten wie Protokollmeldungen und Ergebnisbilder bleiben bei der Konvertierung nicht erhalten.
Nutzen Sie spezielle Testgruppen
Einige Testgruppen benötigen oder unterstützen möglicherweise spezielle Befehlszeilenoptionen oder erfordern bei der Verwendung auf bestimmten Systemen besondere Sorgfalt.
Stresstests zur Speicherzuordnung
Bei Belastungstests für die Speicherzuordnung werden Bedingungen wegen unzureichendem Arbeitsspeicher überprüft, indem bestimmte Ressourcen wiederholt zugewiesen werden, bis der Treiber einen Fehler wegen unzureichendem Arbeitsspeicher meldet.
Auf bestimmten Plattformen wie Android und den meisten Linux-Varianten kann Folgendes auftreten: Das Betriebssystem bricht möglicherweise den Testprozess ab, anstatt einem Treiber die Behandlung oder anderweitige Bereitstellung eines Fehlers wegen unzureichendem Arbeitsspeicher zu ermöglichen. Auf solchen Plattformen sind Tests, die Fehler wegen unzureichendem Arbeitsspeicher verursachen sollen, standardmäßig deaktiviert und müssen mit dem Befehlszeilenargument --deqp-test-oom=enable
aktiviert werden. Es wird empfohlen, solche Tests manuell durchzuführen, um zu überprüfen, ob sich das System unter Ressourcendruck korrekt verhält. In einer solchen Situation sollte ein Absturz des Testprozesses jedoch als bestanden gewertet werden.
Testgruppen
dEQP-GLES2.stress.memory.* dEQP-GLES3.stress.memory.*
Lang andauernde Rendering-Stresstests
Rendering-Stresstests sollen Robustheitsprobleme bei anhaltender Rendering-Belastung aufdecken. Standardmäßig führen die Tests nur wenige Iterationen aus. 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 sein ( --deqp-watchdog=disable
), wenn diese Tests über einen längeren Zeitraum ausgeführt werden.
Testgruppen
dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.*
Alle Inhalte und Codebeispiele auf dieser Seite unterliegen den Lizenzen wie im Abschnitt Inhaltslizenz beschrieben. Java und OpenJDK sind Marken oder eingetragene Marken von Oracle und/oder seinen Tochtergesellschaften.
Zuletzt aktualisiert: 2024-04-29 (UTC).