Tests im Rahmen des drawElements-Qualitätsprogramms

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

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 neuesten eingereichten Code arbeiten möchten, verwenden Sie den Branch deqp-dev. Verwenden Sie für Code, der mit einer bestimmten Android CTS-Version übereinstimmt, den Branch release-code-name-release (z.B. marshmallow-release für Android 6.0).

Quelllayout

Das Quellcode-Layout für die deqp-Testmodule und die zugehörigen Bibliotheken ist in der folgenden Tabelle dargestellt. Die Liste ist nicht vollständig, enthält aber die wichtigsten Verzeichnisse.

Open-Source-Komponenten

Für deqp werden libpng und zlib verwendet, die mit dem Script 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 Portabilität entwickelt. Die einzigen obligatorischen Anforderungen sind vollständige C++-Unterstützung und Standardsystembibliotheken für I/O, Threads und Sockets.

CMake-Buildsystem

Die deqp-Quellen enthalten Build-Scripts für CMake, das bevorzugte Tool zum Kompilieren der Testprogramme.

CMake ist ein Open-Source-Buildsystem, 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. Sie sollten also immer Makefiles oder Projektdateien in einem separaten Build-Verzeichnis außerhalb des Quellbaums erstellen. CMake hat kein „distclean“-Ziel. Daher müssen alle von CMake generierten Dateien manuell entfernt werden.

Konfigurationsoptionen werden CMake mithilfe der -DOPTION_NAME=VALUE-Syntax übergeben. Im Folgenden sind einige häufig verwendete Optionen für deqp aufgeführt.

Ziel-Builddatei erstellen

Das deqp-Build-System wird mithilfe von Ziel-Build-Dateien für neue Ziele konfiguriert. In einer Ziel-Builddatei wird festgelegt, 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 in der Ziel-Builddatei festgelegt werden.

Der Ziel-Builddatei können mit den CMake-Funktionen include_directories() und link_directories() zusätzliche Include- oder Linkpfade 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. Der 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"

Wenn Sie einen 64-Bit-Build erstellen möchten, wählen Sie „Visual Studio VERSION Win64“ als Build-Generator aus:

cmake path\to\src\deqp -G "Visual Studio 12 Win64"

Sie können auch NMake-Makefiles mit der Option -G "NMake Makefiles" und dem Buildtyp (-DCMAKE_BUILD_TYPE="Debug" oder "Release") generieren.

Renderkontext 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 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. Die Funktion 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 dynamischer Auslagerung für EGL unter Windows erstellt, wenn DEQP_SUPPORT_EGL aktiviert ist. Dies ist die Standardeinstellung für die meisten Ziele. Wenn der Host EGL-Bibliotheken verfügbar hat, können Sie mit dem Befehlszeilenparameter --deqp-gl-context-type=egl Tests mit ihnen ausführen.

Android-Build

Für den Android-Build werden CMake-Buildscripts zum Erstellen des nativen Testcodes verwendet. Java-Teile, d.h. der Testausführungsserver und der Test-Anwendungs-Stub, werden mit den standardmäßigen Android-Build-Tools kompiliert.

Um deqp-Testprogramme für Android mit den bereitgestellten Build-Scripts zu kompilieren, benötigen Sie Folgendes:

• Die neueste Version des Android NDK. In der Datei android/scripts/common.py ist die erforderliche Version aufgeführt.
• Eigenständiges Android SDK mit API 13, installierte SDK-Tools, SDK-Plattformtools und SDK-Buildtools-Pakete
• 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: NMake oder JOM in PATH
  • JOM ermöglicht schnellere Builds
• Optional: Ninja Make wird auch unter Linux unterstützt.

Ant- und SDK-Binärprogramme werden anhand der Umgebungsvariablen PATH mit bestimmten überschreibenden Standardwerten ermittelt. 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-Scripts erstellt. Die endgültige .apk wird in android/package/bin erstellt und kann mit dem install.py-Script installiert werden. Wenn der Befehlszeilen-Executor verwendet wird, wird der ExecService über ADB mit dem launch.py-Script auf dem Gerät gestartet. Die Scripts können von jedem beliebigen Verzeichnis aus ausgeführt werden.

Linux-Build

Test-Binä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.

Verwenden Sie immer -DCMAKE_BUILD_TYPE=<Debug|Release>, um den Buildtyp 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 dem Compiler zusätzliche Argumente übergeben. So können Sie beispielsweise einen 32-Bit- oder 64-Bit-Build ausführen, indem Sie -DCMAKE_C(XX)_FLAGS="-m32" bzw. "-m64" festlegen. Wenn nicht angegeben, wird die native Architektur der Toolchain verwendet, in der Regel 64-Bit bei der 64-Bit-Toolchain.

Die Argumente -DCMAKE_LIBRARY_PATH und -DCMAKE_INCLUDE_PATH können für CMake verwendet werden, um CMake zusätzliche Bibliotheks- oder Include-Suchpfade anzugeben.

Hier ein Beispiel für eine vollständige Befehlszeile, mit der ein 32-Bit-Debug-Build für Treiber-Header und ‑Bibliotheken an einem benutzerdefinierten Speicherort ausgeführt wird:

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

Die Cross-Kompilierung kann mit einer CMake-Toolchain-Datei erfolgen. In der Toolchain-Datei wird der zu verwendende Compiler sowie benutzerdefinierte Suchpfade für Bibliotheken und Header angegeben. Im Release-Paket im Verzeichnis framework/delibs/cmake sind mehrere toolchain-Dateien für gängige Szenarien enthalten.

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 richtig erkennen, DE_CPU muss jedoch in der Toolchain-Datei festgelegt werden.

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

Der deqp benötigt während der Verknüpfung keine Einstiegspunkte der zu testenden API. Der Testcode greift immer über Funktionszeiiger auf die APIs zu. Einstiegspunkte können dann zur Laufzeit dynamisch geladen oder vom Plattform-Port zur Linkzeit bereitgestellt werden.

Wenn die Unterstützung für eine API in den Build-Einstellungen aktiviert ist und keine Linkbibliotheken angegeben werden, lädt deqp die erforderlichen Einstiegspunkte zur Laufzeit. Wenn die statische Verknüpfung gewünscht ist, geben Sie die erforderlichen Verknüpfungsbibliotheken in der Build-Konfigurationsvariablen DEQP_<API>_LIBRARIES an.

Test-Framework portieren

Die Portierung von deqp umfasst drei Schritte: Anpassung der Basisbibliotheken für die Portabilität, Implementierung von Plattformintegrationsschnittstellen für das Test-Framework und Portierung des Ausführungsdiensts.

In der folgenden Tabelle sind Standorte aufgeführt, an denen es wahrscheinlich zu Änderungen bei der Portierung kommt. Alles darüber hinaus ist wahrscheinlich exotisch.

Basisbibliotheken für Portabilität

Die Basisbibliotheken für die Portabilität 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 Basisbibliotheken für die Portabilität höchstwahrscheinlich gar nicht ändern.

Port der Test-Framework-Plattform

Der Plattform-Port des deqp-Test-Frameworks erfordert zwei Komponenten: einen Anwendungseingabepunkt und eine Plattform-Schnittstellenimplementierung.

Der Anwendungs-Einstiegspunkt ist für das Erstellen des Plattformobjekts, das Erstellen eines Befehlszeilenobjekts (tcu::CommandLine), das Öffnen eines Testlogs (tcu::TestLog) und die Iteration der Testanwendung (tcu::App) verantwortlich. Wenn das Zielbetriebssystem einen standardmäßigen main()-Einstiegspunkt unterstützt, kann tcuMain.cpp als Implementierung des Einstiegspunkts verwendet werden.

Die deqp-Plattform-API wird in den folgenden Dateien ausführlich beschrieben.

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 für die Ausführung der Tests implementiert werden muss.

Detaillierte Anleitungen zur Implementierung von Plattformports finden Sie in den Überschriften der Portierungsebene.

Testausführungsdienst

Wenn Sie die deqp-Testausführungsinfrastruktur oder den Befehlszeilenausführer verwenden möchten, muss der Testausführungsdienst auf dem Ziel verfügbar sein. Im Verzeichnis execserver finden Sie eine portable C++-Implementierung des Dienstes. Das eigenständige Binärprogramm wird als Teil des deqp-Testmoduls für PC-Ziele erstellt. Sie können execserver/CMakeLists.txt ändern, um einen Build für andere Ziele zu aktivieren.

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.
• --single beendet den Serverprozess, wenn der Client die Verbindung trennt. Standardmäßig bleibt der Serverprozess aktiv, um weitere Anfragen zur Testausführung zu bearbeiten.

Tests ausführen

Auf dieser Seite finden Sie eine Anleitung 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 zuerst die folgenden Dateien und Verzeichnisse in das Ziel.

Sie können den Ausführungsdienst und Testbinärdateien überall im Zieldateisystem bereitstellen. Testbinärdateien erwarten jedoch Datenverzeichnisse im aktuellen Arbeitsverzeichnis. Starten Sie den Testausführungsdienst auf dem Zielgerät. 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.

GLES2- und GLES3-spezifische Argumente

Format der Testfallliste

Die Liste der Testfälle kann in zwei Formaten angegeben werden. Die erste Option besteht darin, den vollständigen Namen jedes Tests in einer Standard-ASCII-Datei in einer separaten Zeile aufzulisten. Wenn die Testsätze wachsen, können sich die sich wiederholenden Präfixe als umständlich erweisen. Um Wiederholungen von Präfixen zu vermeiden, verwenden Sie die unten gezeigte Syntax für einen Trie (auch als Präfixbaum bezeichnet).

{nodeName{firstChild{…},…lastChild{…}}}

Beispiel:

{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}

Das entspricht den folgenden beiden Testfällen:

dEQP-EGL.config_list
dEQP-EGL.create_context.rgb565_depth_stencil

Android

Das Android-Anwendungspaket enthält alle erforderlichen Komponenten, einschließlich des Testausführungsdiensts, Test-Binä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. Dieser Name hängt vom Build ab:

adb –d install –r com.drawelements.deqp.apk

So starten Sie den Dienst zur Testausführung und richten die Portweiterleitung ein:

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 Sie vor Beginn 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 „Testausführung“ manuell starten möchten, erstellen Sie ein Android-Intent, das auf android.app.NativeActivity ausgerichtet ist. Die Aktivitäten finden Sie im com.drawelements.deqp-Paket. Die Befehlszeile muss im Intent als zusätzlicher String mit dem Schlüssel "cmdLine" angegeben werden.

Ein Testprotokoll wird in /sdcard/dEQP-log.qpa geschrieben. Wenn der Test nicht normal gestartet wird, finden Sie im Geräteprotokoll weitere Informationen zur Fehlerbehebung.

Sie können eine Aktivität über die Befehlszeile mit dem am-Dienstprogramm 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"'

Unter Android debuggen

Wenn Sie die Tests unter dem GDB-Debugger auf Android ausführen möchten, kompilieren und installieren Sie zuerst den Debug-Build, indem Sie die folgenden beiden Scripts 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 ist, führen Sie den folgenden Befehl aus, um die Tests unter GDB auszuführen, das 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 Parametern ab. Das Script fügt am Anfang der deqp-Ausführung (tcu::App::App) einen Standard-Bruchpunkt hinzu.

Das debug.py-Script akzeptiert mehrere Befehlszeilenargumente für Aktionen wie das Setzen von Haltepunkten für die Fehlerbehebung, GDB-Server-Verbindungsparameter und Pfade zu zusätzlichen Binärdateien zur Fehlerbehebung. Verwenden Sie debug.py --help für alle Argumente und Erläuterungen. Das Script kopiert auch einige Standardbibliotheken vom Zielgerät, um Symbollisten zu erhalten.

Wenn Sie den Treibercode Schritt für Schritt durchgehen möchten (z. B. wenn GDB die Speicherorte der Binärdateien mit vollständigen Informationen zur Fehlerbehebung kennen muss), fügen Sie über debug.py-Befehlszeilenparameter weitere Bibliotheken hinzu. Dieses Script schreibt ab Zeile 132 der Scriptdatei eine Konfigurationsdatei für GDB aus. 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 der PATH-Variablen <path-to-ndk>/prebuilt/windows/bin hinzu.

Hinweis:Das Debugging von Native Code funktioniert nicht mit der Standardversion von Android 4.3. Informationen zu Umgehungslösungen finden Sie in diesem öffentlichen Fehlerbericht. Android 4.4 und höher enthalten diesen Fehler nicht.

Tests automatisieren

Deqp-Testmodule können auf unterschiedliche Weise 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 .qpa-Suffix. Die vollständigen Testergebnisse können aus dem Testprotokoll geparst werden. Die Konsolenausgabe enthält nur Informationen zur Fehlerbehebung und ist möglicherweise nicht auf allen Plattformen verfügbar.

Test-Binärdateien können direkt über ein Testautomatisierungssystem aufgerufen werden. Das Test-Binary 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, damit auch bei einem schweren Fehler Teilergebnisse verfügbar sind.

Der deqp enthält Befehlszeilentools zur Testausführung, die in Kombination mit dem Ausführungsdienst verwendet werden können, um eine robustere Integration zu erreichen. Der Executor erkennt das Ende des Testprozesses und setzt die Testausführung mit dem nächsten verfügbaren Fall fort. Aus der gesamten Testsession wird eine einzelne Protokolldatei erstellt. Diese Konfiguration eignet sich ideal für einfache Testsysteme, die keine Funktionen zur Wiederherstellung nach Abstürzen bieten.

Befehlszeilentools zur Testausführung

Das aktuelle Befehlszeilentool-Set umfasst ein Tool zur Remote-Testausführung, 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 Verzeichnis executor und die Binärdateien sind im Verzeichnis <builddir>/executor eingebunden.

Befehlszeilen-Testausführer

Der Befehlszeilen-Testausführer ist ein portables C++-Tool zum Starten eines Testlaufs auf einem Gerät und zum Erfassen der 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 Abstürzen des Testprozesses. In den folgenden Beispielen wird die Verwendung des Befehlszeilen-Testausführers veranschaulicht. 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: 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

Testprotokoll als CSV-Datei exportieren und vergleichen

Das deqp-Tool kann Testprotokolle (qpa-Dateien) in CSV-Dateien konvertieren. Die CSV-Ausgabe enthält eine Liste der Testfälle und ihrer Ergebnisse. Das Tool kann auch zwei oder mehr Batchergebnisse vergleichen und nur die Testfälle auflisten, die in den Eingabe-Batchergebnissen unterschiedliche Statuscodes haben. Außerdem wird die Anzahl der übereinstimmenden Fälle ausgegeben.

Die Ausgabe im CSV-Format eignet sich sehr gut für die weitere Verarbeitung mit standardmäßigen Befehlszeilen-Dienstprogrammen oder mit einem Tabelleneditor. Mit dem folgenden Befehlszeilenargument kann ein zusätzliches, visuell lesbares Format für den Klartext 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 zwischen den Testergebnissen aus 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. „Pass“ oder „Fail“. Mit dem Argument --value=details wird die weitere Erklärung des Ergebnisses oder des numerischen Werts ausgewählt, der von einem Leistungs-, Funktions- oder Genauigkeitstest generiert wurde.

XML-Export von Testprotokollen

Testprotokolldateien können mit dem Dienstprogramm testlog-to-xml in gültige XML-Dokumente umgewandelt werden. Es werden zwei Ausgabemodi unterstützt:

• Modus für separate Dokumente, bei dem jeder Testfall und das caselist.xml-Zusammenfassungsdokument in ein Zielverzeichnis geschrieben werden
• Im Modus „Einzelne Datei“ werden alle Ergebnisse in der .qpa-Datei in ein einzelnes XML-Dokument geschrieben.

Exportierte Testprotokolldateien können mit einem XML-Stylesheet in einem Browser geöffnet werden. Im Verzeichnis doc/testlog-stylesheet finden Sie Beispieldokumente für Stylesheets (testlog.xsl und testlog.css). Wenn Sie die Protokolldateien 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 der Zugriff auf die Dateien über HTTP erfolgen, da Chrome den lokalen Dateizugriff aus Sicherheitsgründen einschränkt. Die Standardinstallation von Python enthält einen einfachen HTTP-Server, der mit dem Befehl python –m SimpleHTTPServer 8000 gestartet werden kann, um das aktuelle Verzeichnis bereitzustellen. Nachdem Sie den Server gestartet haben, rufen Sie einfach http://localhost:8000 im Chrome-Browser auf, um das Testprotokoll aufzurufen.

In ein JUnit-Testprotokoll konvertieren

Viele Testautomatisierungssysteme können Testlaufergebnisberichte aus 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 die Ergebnisse „Pass“ und „Fail“ unterstützt, wird ein erfolgreiches Ergebnis der deqp-Datei als „JUnit Pass“ zugeordnet und andere Ergebnisse gelten als Fehler. Der ursprüngliche deqp-Ergebniscode ist in der JUnit-Ausgabe verfügbar. Andere Daten wie Protokollmeldungen und Ergebnisbilder bleiben bei der Umwandlung nicht erhalten.

Spezielle Testgruppen verwenden

Einige Testgruppen erfordern möglicherweise spezielle Befehlszeilenoptionen oder unterstützen diese, oder sie erfordern bei der Verwendung auf bestimmten Systemen besondere Vorsicht.

Stresstests für die Arbeitsspeicherzuweisung

Bei Stresstests für die Arbeitsspeicherzuweisung werden Bedingungen für fehlenden Arbeitsspeicher simuliert, indem bestimmte Ressourcen wiederholt zugewiesen werden, bis der Treiber einen Fehler meldet.

Auf bestimmten Plattformen wie Android und den meisten Linux-Varianten kann Folgendes auftreten: Das Betriebssystem beendet möglicherweise den Testprozess, anstatt einem Treiber zu erlauben, einen Fehler wegen fehlenden Arbeitsspeichers zu verarbeiten oder anderweitig zu melden. Auf solchen Plattformen sind Tests, die dazu führen sollen, dass ein „Out-of-Memory“-Fehler auftritt, 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 Ressourcenknappheit richtig verhält. In einer solchen Situation sollte ein Absturz des Testprozesses jedoch als Erfolg gewertet werden.

Testgruppen

dEQP-GLES2.stress.memory.*
dEQP-GLES3.stress.memory.*

Lang andauernde Rendering-Stresstests

Mit Rendering-Stresstests können Sie Robustheitsprobleme bei anhaltender Rendering-Last aufdecken. Standardmäßig werden nur wenige Iterationen ausgeführt. Sie können die Tests jedoch so konfigurieren, dass sie unbegrenzt laufen, 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.*