AOSP umfasst die GPU-Testsuite für dasdrawElements 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.
Verwenden Sie den deqp-dev-Zweig, um mit dem zuletzt gesendeten Code zu arbeiten.
Verwende für Code, der einer bestimmten Android CTS-Version entspricht, die
release-code-name-release-Branch (z.B. für Android 6.0,
Verwenden Sie den Zweig marshmallow-release).
Quelllayout
Das Quellcode-Layout für die DEQP-Testmodule und unterstützenden Bibliotheken ist (Die Auflistung ist nicht vollständig, wichtigsten Verzeichnissen).
| Verzeichnis | Beschreibung |
|---|---|
android |
Android-Testerquellen und Build-Skripts |
data |
Datendateien testen |
modules |
Modulquellen testen |
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 |
Grundlegende Portabilität und Build-Bibliotheken |
framework/platform |
Plattformports |
framework/qphelper |
Testprogrammintegrationsbibliothek (C) |
framework/common |
DEQP-Framework (C++) |
framework/opengl, framework/egl |
API-spezifische Dienstprogramme |
execserver |
Geräteseitige ExecServer-Quelle |
executor |
Shell-Tool und Dienstprogramme für das Host-Side-Test-Executor |
external |
Build-Stub-Verzeichnis für die externen Bibliotheken libpng und zlib |
Open-Source-Komponenten
Die Abfrage verwendet libpng und zlib, die abgerufen werden können
mit dem Skript
platform/external/deqp/external/fetch_sources.py oder über Git
von platform/external/[libpng,zlib].
Testprogramme erstellen
Bei der Entwicklung des Test-Frameworks wurde auf Portabilität geachtet. Die einzige obligatorische Anforderungen sind vollständiger C++-Support 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 für das Kompilieren der Testprogramme.
CMake ist ein Open-Source-Build-System, das mehrere Plattformen und Toolchains. CMake generiert native Makefiles oder IDE-Projektdateien aus zielunabhängige Konfigurationsdateien. Weitere Informationen zu CMake finden Sie in der CMake-Dokumentation
CMake unterstützt und empfiehlt Out-of-Source-Tree-Builds. Das heißt, Sie sollten Erstellen Sie Makefiles oder Projektdateien immer in einem separaten Build-Verzeichnis. außerhalb der Quellstruktur. CMaker enthält keine Art von „distclean“ Ziel ist, sodass Entfernen Sie alle von CMake generierten Dateien manuell.
Konfigurationsoptionen werden CMake mithilfe von -DOPTION_NAME=VALUE zugewiesen
Syntax. Einige häufig verwendete DEQP-Optionen sind unten aufgeführt.
| Konfigurationsoption | Beschreibung |
|---|---|
DEQP_TARGET |
Name des Ziels, z. B. „android“ Die deqp CMake-Skripts enthalten die Datei
|
CMAKE_TOOLCHAIN_FILE |
Pfad zur Toolchain-Datei für CMake. Wird für die Kreuzkompilierung verwendet. |
CMAKE_BUILD_TYPE |
Build-Typ für Makefile-Ziele. Gültige Werte: „Debug“ und „Release“ Beachten Sie, dass Interpretation und Standardtyp vom jeweiligen Build-System abhängen. Weitere Informationen finden Sie in der CMake-Dokumentation. |
Ziel-Build-Datei erstellen
Das DEQP-Build-System wird mithilfe von Ziel-Build-Dateien für neue Ziele konfiguriert.
Eine Ziel-Build-Datei definiert, welche Features die Plattform unterstützt und welche Bibliotheken oder
zusätzliche Einschließen-Pfade sind erforderlich. Namen von Zieldateien folgen dem targets/NAME/NAME.cmake
Format und das Ziel wird mit dem Build-Parameter DEQP_TARGET ausgewählt.
Dateipfade in Zieldateien beziehen sich auf das Basisverzeichnis deqp, nicht auf das
targets/NAME-Verzeichnis. Die folgenden Standardvariablen können in der 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 (Standardeinstellung: AUS) |
DEQP_GLES2_LIBRARIES |
GLES2-Bibliotheken (leer lassen, wenn dies nicht unterstützt wird oder dynamisches Laden verwendet wird) |
DEQP_SUPPORT_GLES3 |
Gibt an, ob GLES3.x unterstützt wird (Standardeinstellung: AUS) |
DEQP_GLES3_LIBRARIES |
GLES3.x-Bibliotheken (leer lassen, wenn dies nicht unterstützt wird oder dynamisches Laden verwendet wird) |
DEQP_SUPPORT_VG |
Gibt an, ob OpenVG unterstützt wird (Standardeinstellung: AUS) |
DEQP_OPENVG_LIBRARIES |
OpenVG-Bibliotheken (leer lassen, wenn dies nicht unterstützt wird oder dynamisches Laden verwendet wird) |
DEQP_SUPPORT_EGL |
Gibt an, ob EGL unterstützt wird (Standardeinstellung: AUS) |
DEQP_EGL_LIBRARIES |
EGL-Bibliotheken (leer lassen, wenn dies nicht unterstützt wird oder dynamisches Laden verwendet wird) |
DEQP_PLATFORM_LIBRARIES |
Zusätzliche plattformspezifische Bibliotheken, die für die Verknüpfung erforderlich sind |
DEQP_PLATFORM_COPY_LIBRARIES |
Liste der Bibliotheken, die in jedes binäre Testverzeichnis für den Build kopiert werden. Kann sein zum Kopieren von Bibliotheken, die zum Ausführen von Tests benötigt werden, aber nicht standardmäßig sind Suchpfads angeben. |
TCUTIL_PLATFORM_SRCS |
Liste der Plattformportquellen. Standardquellen werden anhand der und Betriebssystem. Hinweis: Pfade sind relativ zu: |
In der Ziel-Build-Datei können mithilfe der Methode
include_directories()- und link_directories()-CMake-Funktionen.
Win32-Build
Die einfachste Methode zum Erstellen von DEQP-Modulen für Windows ist die Verwendung des CMake-Builds System. 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"
Ein 64-Bit-Build kann durch Auswahl von „Visual Studio VERSION Win64“ erstellt werden während der Build Generator:
cmake path\to\src\deqp -G "Visual Studio 12 Win64"
Sie können NMake-Makefiles auch mit der Option -G "NMake Makefiles" generieren
als Build-Typ aus (-DCMAKE_BUILD_TYPE="Debug" oder "Release").
Erstellung des Renderingkontexts
Renderingkontext 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 dies nur
Standardbibliotheken. WGL-Kontext kann mit --deqp-gl-context-type=wgl ausgewählt werden
Befehlszeilenargument. Im WGL-Modus verwendet „deqp“ den WGL_EXT_create_context_es_profile
Erweiterung zum Erstellen von OpenGL ES-Kontexten. Dies wurde für die Verwendung mit
die neuesten Treiber von NVIDIA und Intel. AMD-Treiber unterstützen nicht die erforderlichen
.
EGL-Unterstützung
Die DEQP wird mit dynamischem Laden für EGL unter Windows erstellt, wenn DEQP_SUPPORT_EGL
ist AN. Dies ist bei den meisten Zielen die Standardeinstellung. Wenn der Host über EGL-Bibliotheken verfügt,
können Sie Tests über die Befehlszeile ausführen,
Parameter: --deqp-gl-context-type=egl
Android-Build
Der Android-Build verwendet CMake-Build-Skripts zum Erstellen des nativen Testcodes. Java-Komponenten, d.h. der Testausführungsserver und das Testanwendungs-Stub, die mit den standardmäßigen Android-Build-Tools kompiliert wurden.
Kompilieren von DEQP-Testprogrammen für Android mit dem bereitgestellten Build Skripte benötigen Sie Folgendes:
- Die neueste Version von
Android NDK In der Datei
android/scripts/common.pyist die erforderliche Version - Eigenständiges Android-SDK mit API 13, SDK Tools, SDK Platform-Tools und SDK Build-Tools-Pakete 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-Serie; Python 3.x wird nicht unterstützt.
- Für Windows: entweder NMake oder JOM in
PATH<ph type="x-smartling-placeholder">- </ph>
- JOM ermöglicht schnellere Builds
- Optional: „Ninja Make“ wird auch unter Linux unterstützt.
Die Binärdateien von Ant und SDK basieren auf der Umgebungsvariable PATH,
bestimmte überschreibende Standardeinstellungen. Die Logik wird von android/scripts/common.py gesteuert.
Das NDK-Verzeichnis muss entweder ~/android-ndk-VERSION oder
C:/android/android-ndk-VERSION oder definiert über ANDROID_NDK_PATH
Umgebungsvariable ein.
Die deqp-On-Device-Komponenten, der Testausführungsdienst und die Testprogramme
das durch Ausführen des Skripts android/scripts/build.py erstellt wurde. Die finale APK-Datei wird in
android/package/bin und kann mit dem Skript install.py installiert werden. Wenn die
command line executor verwendet, wird ExecService gestartet
mit launch.py-Script auf dem Gerät über ADB. Die Skripts können von jedem Verzeichnis aus ausgeführt werden.
Linux-Build
Testbinärprogramme und Befehlszeilendienstprogramme können für Linux erstellt werden, indem Makefiles mit CMake. Es gibt mehrere vordefinierte Build-Ziele, die beim Erstellen für Linux nützlich sind.
| Ziel erstellen | Beschreibung |
|---|---|
default |
Standardziel, bei dem die CMake-Plattform selbstprüfung verwendet wird, um die Unterstützung verschiedener APIs zu ermitteln. |
x11_glx |
Verwendet GLX zum Erstellen von OpenGL-Kontexten (ES). |
x11_egl |
Verwendet EGL zum Erstellen von OpenGL-Kontexten (ES). |
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 nicht optimierter Standard-Release-Build erstellt.
Die Befehlszeilenargumente -DCMAKE_C_FLAGS und -DCMAKE_CXX_FLAGS können
wird verwendet, um zusätzliche Argumente an den Compiler zu übergeben. Die 32-Bit- oder 64-Bit-Version kann beispielsweise
Dabei wird -DCMAKE_C(XX)_FLAGS="-m32" bzw. "-m64" festgelegt. Falls nicht
wird die native Toolchain-Architektur verwendet, in der Regel 64-Bit in der 64-Bit-Toolchain.
Die Argumente -DCMAKE_LIBRARY_PATH und -DCMAKE_INCLUDE_PATH können verwendet werden,
für CMake, um CMake eine zusätzliche Bibliothek bereitzustellen oder Suchpfade einzubeziehen.
Beispiel für eine vollständige Befehlszeile, mit der ein 32-Bit-Build für die Fehlerbehebung ausgeführt wird für Treiber-Header und -Bibliotheken an einem benutzerdefinierten Speicherort Folgendes sind:
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-Compiling
Eine Kreuzkompilierung kann mithilfe einer CMake-Toolchain-Datei erfolgen. Die Toolchain
-Datei gibt den zu verwendenden Compiler mit benutzerdefinierten Suchpfaden für
Bibliotheken und Headern. Mehrere Toolchain-Dateien für häufige Szenarien
im Release-Paket im Verzeichnis framework/delibs/cmake enthalten.
Neben den standardmäßigen CMake-Variablen werden die folgenden deqp-spezifischen Variablen
kann von der Toolchain-Datei festgelegt werden. CMake kann in der Regel DE_OS und DE_COMPILER erkennen
und DE_PTR_SIZE korrekt, aber DE_CPU muss 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.
Im folgenden Beispiel würden 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
Der DEQP benötigt während der Verknüpfung keine Einstiegspunkte der zu testenden API. Die Testcode greift immer über Funktionszeiger auf die APIs zu. Einstiegspunkte können werden dann zur Laufzeit dynamisch geladen oder über den Plattformport Zeit der Verknüpfung.
Wenn die Unterstützung für eine API in den Build-Einstellungen und den Linkbibliotheken aktiviert ist
nicht angegeben ist, lädt die DEQP die erforderlichen Einstiegspunkte zur Laufzeit. Wenn die
Eine statische Verknüpfung ist erwünscht. Stellen Sie die erforderlichen Linkbibliotheken in der DEQP_<API>_LIBRARIES bereit.
Build-Konfigurationsvariable.
Test-Framework portieren
Die Portierung der Abfragen umfasst drei Schritte: die Anpassung grundlegender Portabilitätsbibliotheken, Implementierung von Schnittstellen zur Plattformintegration (Test-Framework) und Portieren der ausgeführt werden soll.
In der folgenden Tabelle sind die Orte aufgeführt, an denen die Mitnahme wahrscheinlich Änderungen vornehmen kann. Alles, was darüber hinausgeht sind sie wahrscheinlich exotisch.
| Standort | Beschreibung |
|---|---|
framework/delibs/debase |
Erforderliche 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 basiert auf |
framework/platform |
Ein neuer Plattformport und ein neuer Anwendungs-Stub können implementiert werden, wie unter Testen Sie den Port der Framework-Plattform. |
Grundlegende Portabilitä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, ist es höchstwahrscheinlich nicht nötig, die Basisbibliotheken für die Portabilität zu berühren.
Port der Framework-Plattform testen
Der Port der DEQP-Test-Framework-Plattform erfordert zwei Komponenten: eine Anwendung und eine Plattformschnittstellen-Implementierung.
Der Anwendungseinstiegspunkt
ist für die Erstellung des Plattformobjekts
Befehlszeilenobjekt (tcu::CommandLine) erstellen, Testlog öffnen
(tcu::TestLog) und Iterieren der Testanwendung (tcu::App). Wenn die
Zielbetriebssystem unterstützt einen standardmäßigen main()-Einstiegspunkt, tcuMain.cpp kann verwendet werden
als Einstiegspunktimplementierung verwendet werden.
Die DEQP-Plattform-API wird in den folgenden Dateien detailliert beschrieben.
| Datei | Beschreibung |
|---|---|
framework/common/tcuPlatform.hpp |
Basisklasse für alle Plattformports |
framework/opengl/gluPlatform.hpp |
OpenGL-Plattformoberfläche |
framework/egl/egluPlatform.hpp |
Schnittstelle der EGL-Plattform |
framework/platform/tcuMain.cpp |
Standard-Einstiegspunkt für Anwendungen |
Die Basisklasse für alle Plattformports ist tcu::Platform. Der Plattformport kann
unterstützen optional GL- und EGL-spezifische Schnittstellen. Weitere Informationen finden Sie unter
sehen Sie in der folgenden Tabelle, was implementiert werden muss, um
führen Sie die Tests durch.
| Modul | Benutzeroberfläche |
|---|---|
OpenGL (ES)-Testmodule |
GL-Plattformschnittstelle |
EGL-Testmodul |
Schnittstelle der EGL-Plattform |
Eine ausführliche Anleitung zur Implementierung von Plattformports finden Sie in der Portierung von Layer-Headern.
Testausführungsdienst
Um die Infrastruktur für die Testausführung deqp oder den Befehlszeilen-Executor zu verwenden,
Der Testausführungsdienst muss für das Ziel verfügbar sein. Eine mobile C++-
Die Implementierung des Dienstes wird im Verzeichnis execserver bereitgestellt. Die eigenständige
Die Binärdatei wird als Teil des DEQP-Testmoduls erstellt
für PC-Ziele erstellen. Sie können execserver/CMakeLists.txt ändern, um einen Build zu aktivieren
anderen Zielen.
Die C++ Version des Testausführungsdienstes akzeptiert zwei Befehlszeilen Parameter:
-
--port=<port>legt den TCP-Port fest, den der Server überwacht. Der Standardwert ist 50016. -
--singlebeendet den Serverprozess, wenn die Verbindung zum Client getrennt wird. Standardmäßig enthält der Parameter um weitere Testausführungsanfragen zu verarbeiten.
Tests ausführen
Diese Seite enthält Anleitungen zum Ausführen von DEQP-Tests unter Linux und Windows Umgebungen, Befehlszeilenargumente und die Arbeit mit Android Application-Paket.
Linux- und Windows-Umgebungen
Kopieren Sie zuerst die folgenden Dateien und Verzeichnisse in das Ziel.
| 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 bereitstellen und die Binärdateien überall im Ziel testen Dateisystem; Test-Binärdateien erwarten jedoch Datenverzeichnisse in der im aktuellen Arbeitsverzeichnis. Wenn Sie bereit sind, starten Sie den Testausführungsdienst auf der Zielgerät Einzelheiten zum Starten des Dienstes finden Sie unter Testen Ausführungsdienst.
Befehlszeilenargumente
In der folgenden Tabelle sind Befehlszeilenargumente aufgeführt, die die Ausführung aller Programme testen können.
| Argumentation | Beschreibung |
|---|---|
--deqp-case=<casename> |
Führt 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. Testausführung legt der Dienst den Dateinamen fest, wenn ein Test gestartet wird. |
--deqp-stdin-caselist |
Fallliste aus stdin oder einem bestimmten Argument lesen. Testausführung Der Dienst legt das Argument entsprechend der empfangenen Ausführungsanfrage fest. Weitere Informationen finden Sie unter finden Sie im nächsten Abschnitt eine Beschreibung des Formats der Fallliste. |
--deqp-test-iteration-count=<count> |
Iterationsanzahl für Tests überschreiben, die eine variable Anzahl von Iterationen vor. |
--deqp-base-seed=<seed> |
Basis-Seed für Testfälle mit Randomisierung. |
GLES2- und GLES3-spezifische Argumente
In der folgenden Tabelle sind die GLES2- und GLES3-spezifischen Argumente aufgeführt.| Argumentation | Beschreibung |
|---|---|
--deqp-gl-context-type=<type> |
OpenGL-Kontexttyp. Die verfügbaren Kontexttypen hängen von der Plattform ab. An
Plattformen, die EGL unterstützen, können Sie mit dem Wert egl
aus dem EGL-Kontext. |
--deqp-gl-config-id=<id> |
Führen Sie Tests für die bereitgestellte GL-Konfigurations-ID aus. Interpretation: plattformabhängig ist. 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 aus. Interpretation:
plattformabhängig ist. Für EGL lautet das Format
rgb(a)<bits>d<bits>s<bits> Beispiel:
wird mit dem Wert von rgb888s8 die erste Konfiguration ausgewählt, bei der der
Der Farbzwischenspeicher ist RGB888 und der Schablonenpuffer verfügt über 8 Bit. |
--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> |
Einen bestimmten Oberflächentyp als wichtigstes Test-Renderingziel verwenden Möglich
Typen sind window, pixmap, pbuffer,
und fbo. |
--deqp-screen-rotation=<rotation> |
Bildschirmausrichtung in 90-Grad-Schritten für Plattformen, die die sie unterstützen. |
Format der Testlaufliste
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. Da die wachsen, können die sich wiederholenden Präfixe umständlich sein. Um Wiederholungen zu vermeiden Präfixe verwenden, verwenden Sie die unten gezeigte Trie-Syntax (auch Präfixstruktur genannt).
{nodeName{firstChild{…},…lastChild{…}}}
Beispiel:
{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}
Dies wird in die folgenden beiden Testfälle übersetzt:
dEQP-EGL.config_list dEQP-EGL.create_context.rgb565_depth_stencil
Android
Das Android-Anwendungspaket enthält alle erforderlichen Komponenten, einschließlich
Testausführungsdienst, Testbinärdateien und Datendateien. Die Testaktivität ist
ein NativeActivity mit EGL (erfordert Android 3.2 oder höher).
Das Anwendungspaket kann mit dem folgenden Befehl (name wird der Name des APK im Android CTS-Paket angezeigt. welcher Name von der des Builds):
adb –d install –r com.drawelements.deqp.apk
Um den Testausführungsdienst zu starten und die Portweiterleitung einzurichten, verwenden Sie den Folgendes:
adb –d forward tcp:50016 tcp:50016adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter
Sie können Debug-Drucke aktivieren, indem Sie vor dem Start der Tests:
adb –d shell setprop log.tag.dEQP DEBUG
Tests unter Android ohne Android CTS ausführen
Erstellen Sie einen Android-Intent, um die Testausführungsaktivität manuell zu starten
mit Targeting auf android.app.NativeActivity. Die Aktivitäten können
com.drawelements.deqp-Paket enthalten ist. Die Befehlszeile muss
als zusätzlicher String mit dem Schlüssel "cmdLine" im Intent bereitgestellt werden.
Ein Testlog wird in /sdcard/dEQP-log.qpa geschrieben. Wenn der Testlauf
startet nicht normal, auf dem Gerät sind zusätzliche Informationen zur Fehlerbehebung verfügbar.
Protokoll.
Mit dem am können Sie über die Befehlszeile eine Aktivität starten
Dienstprogramm. Beispiel: Zum Ausführen von dEQP-GLES2.info-Tests auf einer Plattform
Verwenden Sie die folgenden Befehle, um NativeActivity, zu unterstützen.
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"'
Fehler auf Android beheben
Um die Tests im GDB-Debugger unter Android auszuführen, müssen Sie zuerst kompilieren und installieren. den Debug-Build aus, 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, können Sie die Tests starten unter Führen Sie den folgenden Befehl aus, der auf dem Host ausgeführt wird:
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 Parameter. Das Skript fügt einen Standard-Haltepunkt am Anfang
Die DEQP-Ausführung (tcu::App::App)
Das Skript debug.py akzeptiert mehrere Befehlszeilenargumente für
Aktionen wie das Festlegen von Haltepunkten für das Debugging, die gdbserver-Verbindung
Parameter und Pfade zu zusätzlichen Binärdateien für die Fehlerbehebung (verwenden Sie debug.py
--help für alle Argumente und Erläuterungen). Das Skript kopiert auch
Standardbibliotheken vom Zielgerät verwenden, um Symbollisten abzurufen.
Um den Treibercode durchzugehen (z. B. wenn GDB die Standorte von
mit vollständigen Debug-Informationen), fügen Sie weitere Bibliotheken über
debug.py-Befehlszeilenparameter. Dieses Skript erstellt eine
Konfigurationsdatei für die GDB beginnend bei Zeile 132 der Skriptdatei. Ich
kann zusätzliche Pfade zu Binärdateien usw. bereitstellen, aber mit dem richtigen Befehl
Zeilenparameter ausreichen.
Hinweis: Unter Windows benötigt die GDB-Binärdatei
libpython2.7.dll Füge vor dem Starten von debug.py
<path-to-ndk>/prebuilt/windows/bin in die Variable PATH ein.
Hinweis:Native Code-Debugging funktioniert nicht auf Stock-Android 4.3; Behelfslösungen finden Sie unter . diesen öffentlichen Fehler. In Android 4.4 und höher ist dieser Fehler nicht enthalten.
Tests automatisieren
Deqp-Testmodule können auf verschiedene Weise in automatisierte Testsysteme integriert werden. Der beste Ansatz hängt von der vorhandenen Testinfrastruktur und dem Ziel ab zu verbessern.
Die primäre Ausgabe eines Testlaufs ist immer die Testprotokolldatei, d.h. die Datei
mit einem .qpa-Postfix. Die vollständigen Testergebnisse können über das Testprotokoll geparst werden. Die Konsolenausgabe ist
und sind möglicherweise nicht auf allen Plattformen verfügbar.
Testbinärdateien können direkt aus einem Testautomatisierungssystem aufgerufen werden. Der Test Binärprogramm kann für einen bestimmten Fall, für ein Test-Dataset oder für alle verfügbaren Tests. Wenn während der Ausführung ein schwerwiegender Fehler auftritt (z. B. Fehler oder einen Absturz), wird die Testausführung abgebrochen. Bei Regressionstests Die beste Vorgehensweise besteht darin, die Testbinärdateien für einzelne Fälle oder kleine Tests aufzurufen. werden separat festgelegt, damit auch bei einem Ereignis Teilergebnisse eines harten Versagens.
Der DEQP verfügt über Befehlszeilentools für die Testausführung, die in mit dem Ausführungsdienst kombinieren, um eine robustere Integration zu erreichen. Der Executor erkennt die Beendigung des Testprozesses und setzt die Testausführung am nächsten verfügbaren Fall. Aus dem vollständigen Test wird eine einzelne Protokolldatei erstellt. Sitzung. Diese Einrichtung ist ideal für einfache Testsysteme geeignet, die keine Anlagen zur Wiederherstellung nach einem Absturz.
Befehlszeilen-Tools für die Testausführung
Das aktuelle Befehlszeilen-Tool beinhaltet ein Remote-Testausführungstool, einen Test Log-Vergleichsgenerator für Regressionsanalysen, ein Test-Log-zu-CSV-Konverter, einen Testlog-zu-XML-Konverter und einen testlog-zu-JUnit-Converter.
Der Quellcode für diese Tools befindet sich im Verzeichnis executor und die Binärdateien sind
im Verzeichnis <builddir>/executor eingebunden.
Befehlszeilen-Test-Executor
Das Befehlszeilen-Test-Executor ist ein portables C++ Tool zum Starten eines Testlaufs.
und die daraus resultierenden Protokolle
über TCP/IP erfassen. 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 Befehlszeilentools „Test Executor“
(Weitere Informationen erhalten Sie mit --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-Test 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
CSV-Export und Vergleich von Testprotokollen
Der DEQP verfügt über ein Tool zum Konvertieren von Testprotokollen (qpa-Dateien) in CSV-Dateien. Die CSV-Datei
die Ausgabe eine Liste von Testfällen und deren
Ergebnisse. Das Tool kann auch zwei oder mehr Batch-Ergebnisse vergleichen und nur die
Testläufe mit unterschiedlichen Statuscodes in den Eingabe-Batch-Ergebnissen. Die
wird auch die Anzahl der übereinstimmenden Fälle ausgegeben.
Die Ausgabe im CSV-Format ist sehr praktisch für die weitere Verarbeitung mit Standard-
oder mit einem Tabellenkalkulationsprogramm
verwenden können. Ein zusätzlicher, visuell lesbarer
Das Nur-Text-Format 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.csvtestlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv
Beispiel 2: Unterschiede von Testergebnissen zwischen zwei Testlogs auflisten
testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa
Hinweis:Das Argument --value=code gibt den Test
Ergebniscode wie „Pass“ oder „Nicht bestanden“. Das Argument --value=details wählt die weitere
Erläuterung des Ergebnisses oder des numerischen Werts eines Leistungs-, Funktions- oder Genauigkeitstests
XML-Export des Testprotokolls
Testprotokolldateien können mithilfe des testlog-to-xml in gültige XML-Dokumente konvertiert werden
Dienstprogramm. Es werden zwei Ausgabemodi unterstützt:
- Modus für separate Dokumente, in dem jeder Testlauf und die
caselist.xml-Zusammenfassung Dokumente 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 in einem Browser mithilfe eines XML-Stylesheets angezeigt werden.
Es werden Beispiel-Style-Sheet-Dokumente (testlog.xsl und testlog.css) zur Verfügung gestellt.
im Verzeichnis doc/testlog-stylesheet. Um die Protokolldateien in einem Browser zu rendern, kopieren Sie die
in dem Verzeichnis gespeichert werden,
in dem sich die exportierten XML-Dokumente befinden.
Wenn Sie Google Chrome verwenden, muss der Zugriff auf die Dateien wie Chrome über HTTP erfolgen.
der den lokalen Dateizugriff aus Sicherheitsgründen einschränkt. Python-Standardinstallation
einen einfachen HTTP-Server beinhaltet, der gestartet werden kann, um den aktuellen
mit dem Befehl python –m SimpleHTTPServer 8000. Nach dem Start des Servers
Rufen Sie im Chrome-Browser einfach http://localhost:8000 auf, um das Testprotokoll aufzurufen.
Konvertierung in ein JUnit-Testprotokoll
Viele Testautomatisierungssysteme können Berichte zu Testergebnissen über JUnit generieren . Die DEQP-Testprotokolldateien können in das JUnit-Ausgabeformat konvertiert werden. mithilfe des Tools "testlog-to-junit".
Das Tool unterstützt derzeit nur die Übersetzung des Ergebnisses des Testlaufs. Als JUnit unterstützt nur „Pass“ und „fehlgeschlagen“ wird ein übergebenes Ergebnis der DEQP-Abfrage zugeordnet. zu „JUnit Pass“ und andere Ergebnisse als Misserfolge betrachtet. Ursprüngliche Abfrage Ergebniscode steht in der JUnit-Ausgabe zur Verfügung. Andere Daten, wie z. B. Logeinträge und Ergebnisbilder, bleiben bei der Konvertierung nicht erhalten.
Spezielle Testgruppen verwenden
Einige Testgruppen benötigen oder unterstützen möglicherweise spezielle Befehlszeilenoptionen oder erfordern wenn sie auf bestimmten Systemen verwendet werden.
Belastungstests für die Arbeitsspeicherzuweisung
Bei Stresstests der Arbeitsspeicherzuweisung wird zu wenig Arbeitsspeicher wiederholt Zuweisen bestimmter Ressourcen, bis der Treiber einen Fehler aufgrund von unzureichendem Arbeitsspeicher meldet.
Auf bestimmten Plattformen wie Android und den meisten Linux-Varianten gilt Folgendes:
kann auftreten: Das Betriebssystem beendet möglicherweise den Testprozess,
Treiber für die Verarbeitung oder anderweitige Bereitstellung eines
Nicht genügend Arbeitsspeichers-Fehlers. Auf solchen
Plattformen, sind Tests, die auf Fehler aufgrund mangelnden Arbeitsspeichers abzielen, deaktiviert.
und muss mit dem Befehlszeilenargument --deqp-test-oom=enable aktiviert werden.
Es wird empfohlen, solche Tests manuell auszuführen,
Prüfen Sie, ob sich das System unter Ressourcendruck richtig verhält. In solchen
in einer Situation sollte ein Absturz eines Testprozesses als bestanden interpretiert werden.
Testgruppen
dEQP-GLES2.stress.memory.* dEQP-GLES3.stress.memory.*
Lang andauernde Rendering-Belastungstests
Rendering-Stresstests sind so konzipiert, dass Robustheitsprobleme bei anhaltenden
zu laden. Standardmäßig führen die Tests nur
wenige Iterationen aus, aber
Sie können so konfiguriert werden, dass sie auf unbestimmte Zeit ausgeführt werden, indem sie den --deqp-test-iteration-count=-1 bereitstellen.
Befehlszeilenargument. Der Test-Watchdog sollte deaktiviert sein (--deqp-watchdog=disable)
wenn Sie diese Tests über einen längeren Zeitraum durchführen.
Testgruppen
dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.*