Test du programme qualité de drawElements

AOSP inclut la suite de tests GPU du programme de qualité drawElements (deqp) à l'adresse https://android.googlesource.com/platform/external/deqp. Cette page explique en détail comment déployer la suite de tests deqp dans un nouvel environnement.

Pour utiliser le dernier code envoyé, utilisez la branche deqp-dev. Pour le code correspondant à une version spécifique d'Android CTS, utilisez le Branche release-code-name-release (par exemple, pour Android 6.0, utilisez la branche marshmallow-release).

Mise en page source

La mise en page du code source pour les modules de test deqp et les bibliothèques compatibles est dans le tableau ci-dessous. La liste n'est pas exhaustive, mais elle met en avant répertoires les plus importants).

Répertoire Description
android

Sources pour les testeurs Android et scripts de compilation
data

Fichiers de données de test
modules

Sources des modules de test
modules/egl

Module EGL
modules/gles2

Module GLES2
modules/gles3

Module GLES3
modules/gles31

Module GLES 3.1
modules/gles32

Module GLES 3.2
targets

Fichiers de configuration de compilation spécifiques à la cible
framework

Framework et utilitaires du module de test deqp
framework/delibs

Portabilité de base et bibliothèques de compilation
framework/platform

Ports de plate-forme
framework/qphelper

Bibliothèque d'intégration de programmes de test (C)
framework/common

Framework Deqp (C++)
framework/opengl, framework/egl

Utilitaires spécifiques aux API
execserver

Source ExecServer côté appareil
executor

Outil shell et utilitaires de l'exécuteur de test côté hôte
external

Création d'un répertoire de bouchon pour les bibliothèques externes libpng et zlib

Composants Open Source

La deqp utilise libpng et zlib, qui peuvent être récupérés à l'aide du script platform/external/deqp/external/fetch_sources.py ou via Git à partir de platform/external/[libpng,zlib].

Créer des programmes de test

Le framework de test a été conçu dans un souci de portabilité. La seule les exigences obligatoires sont la compatibilité totale avec C++ et les bibliothèques système standards pour les E/S, les threads et les sockets.

Système de compilation CMake

Les sources deqp ont des scripts de compilation pour CMake, l'outil privilégié pour la compilation des programmes de test.

CMake est un système de compilation Open Source compatible avec plusieurs plates-formes et ou des chaînes d'outils. CMake génère des fichiers makefile natifs ou des fichiers de projet IDE à partir de fichiers de configuration indépendants de la cible. Pour en savoir plus sur CMake, consultez le CMake.

CMake prend en charge et recommande des builds hors source. Autrement dit, vous devez Créez toujours des fichiers makefile ou des fichiers de projet dans un répertoire de compilation distinct. en dehors de l'arborescence source. CMake ne possède aucun type de "distclean" (nettoyage) cible : la suppression de tous les fichiers générés par CMake doit être effectuée manuellement.

Les options de configuration sont fournies à CMake à l'aide de -DOPTION_NAME=VALUE syntaxe. Certaines options couramment utilisées pour deqp sont listées ci-dessous.

Option de configuration Description
DEQP_TARGET

Nom de la cible, par exemple "android"

Les scripts deqp CMake incluront le fichier targets/DEQP_TARGET/DEQP_TARGET.cmake et vous attendez des options de compilation spécifiques à la cible.
CMAKE_TOOLCHAIN_FILE

Chemin d'accès au fichier de chaîne d'outils pour CMake. Utilisé pour la compilation croisée.
CMAKE_BUILD_TYPE

Type de compilation pour les cibles de fichiers makefile. Les valeurs valides sont : "Debug" et "Publier"

Notez que l'interprétation et le type par défaut dépendent du système de compilation ciblé. Pour en savoir plus, consultez la documentation de CMake.

Créer un fichier de compilation cible

Le système de compilation deqp est configuré pour les nouvelles cibles à l'aide de fichiers de compilation cibles. Un fichier de compilation cible définit les fonctionnalités compatibles avec la plate-forme et les bibliothèques ou des chemins d'inclusion supplémentaires sont requis. Les noms des fichiers cibles suivent le targets/NAME/NAME.cmake et la cible est sélectionnée à l'aide du paramètre de compilation DEQP_TARGET.

Les chemins d'accès aux fichiers cibles sont relatifs au répertoire deqp de base, et non au répertoire targets/NAME. Les variables standards suivantes peuvent être définies par le fichier de compilation cible.

Variable Description
DEQP_TARGET_NAME

Nom de la cible (qui sera inclus dans les journaux de test)
DEQP_SUPPORT_GLES2

Indique si GLES2 est compatible (par défaut: désactivé)
DEQP_GLES2_LIBRARIES

Bibliothèques GLES2 (laissez ce champ vide si ce n'est pas le cas ou si le chargement dynamique est utilisé)
DEQP_SUPPORT_GLES3

Indique si GLES3.x est pris en charge (par défaut: désactivé)
DEQP_GLES3_LIBRARIES

Bibliothèques GLES3.x (laisser vide si non pris en charge ou si le chargement dynamique est utilisé)
DEQP_SUPPORT_VG

Indique si OpenVG est compatible (par défaut: désactivé)
DEQP_OPENVG_LIBRARIES

Bibliothèques OpenVG (laissez les champs vides si ce n'est pas le cas ou si le chargement dynamique est utilisé)
DEQP_SUPPORT_EGL

Indique si le mode EGL est pris en charge (par défaut: désactivé)
DEQP_EGL_LIBRARIES

Bibliothèques EGL (laissez vides si elles ne sont pas prises en charge ou si le chargement dynamique est utilisé)
DEQP_PLATFORM_LIBRARIES

Des bibliothèques supplémentaires spécifiques à la plate-forme sont requises pour l'association
DEQP_PLATFORM_COPY_LIBRARIES

Liste des bibliothèques copiées dans chaque répertoire de compilation binaire de test. Peut être utilisés pour copier les bibliothèques nécessaires à l'exécution des tests, mais qui ne sont pas définies par défaut chemin de recherche.
TCUTIL_PLATFORM_SRCS

Liste des sources de ports de la plate-forme. Les sources par défaut sont déterminées en fonction les fonctionnalités et l'OS.

Remarque : Les chemins d'accès sont relatifs à framework/platform.

Le fichier de compilation cible peut ajouter des chemins d'inclusion ou de lien supplémentaires à l'aide de la méthode Fonctions CMake include_directories() et link_directories().

Build Win32

Le moyen le plus simple de créer des modules deqp pour Windows consiste à utiliser le build CMake du système d'exploitation. Vous devez disposer de CMake 2.6.12 ou d'une version ultérieure et du package Microsoft Visual C/C++ compilateur. Le fichier deqp a été testé avec Visual Studio 2013.

Les fichiers de projet Visual Studio peuvent être générés à l'aide de la commande suivante:

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

Vous pouvez créer un build 64 bits en sélectionnant "Visual Studio VERSION Win64" que la compilation générateur:

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

Vous pouvez aussi générer des fichiers makefile NMake avec l'option -G "NMake Makefiles". comme type de compilation (-DCMAKE_BUILD_TYPE="Debug" ou "Release").

Création du contexte de rendu

Le contexte de rendu peut être créé avec WGL ou EGL sous Windows.

Compatibilité avec WGL

Tous les binaires Win32 prennent en charge la création de contexte GL avec WGL, car cela ne nécessite bibliothèques standards. Le contexte WGL peut être sélectionné à l'aide de l'--deqp-gl-context-type=wgl un argument de ligne de commande. En mode WGL, deqp utilise WGL_EXT_create_context_es_profile. pour créer des contextes OpenGL ES. Cela a été testé pour fonctionner avec les derniers pilotes de NVIDIA et Intel. Les pilotes AMD ne sont pas compatibles .

Compatibilité EGL

Le fichier deqp est conçu avec le chargement dynamique pour EGL sous Windows si DEQP_SUPPORT_EGL. est activé. Il s'agit du paramètre par défaut pour la plupart des cibles. Si l'hôte possède des bibliothèques EGL, il est possible d'exécuter des tests avec eux à l'aide de la ligne de commande paramètre: --deqp-gl-context-type=egl

Build Android

Le build Android utilise des scripts de compilation CMake pour compiler le code de test natif. Les parties Java, c'est-à-dire le serveur d'exécution de test et le bouchon de l'application de test, sont compilé à l'aide des outils de compilation Android standards.

Pour compiler des programmes de test deqp pour Android avec le build fourni scripts, vous avez besoin des éléments suivants:

  • La dernière version de Android NDK Le fichier android/scripts/common.py indique la version requise
  • SDK Android autonome avec l'API 13, SDK Tools, SDK Platform-Tools et SDK Packages Build-Tools installés
  • Apache Ant 1.9.4 (requis par le build de code Java)
  • CMake 2.8.12 ou version ultérieure
  • Python 2.6 ou version ultérieure dans la série 2.x Python 3.x n'est pas compatible
  • Pour Windows: NMake ou JOM dans PATH <ph type="x-smartling-placeholder">
      </ph>
    • JOM accélère les compilations.
  • Facultatif: La marque Ninja est également compatible avec Linux.

Les binaires Ant et SDK sont situés en fonction de la variable d'environnement PATH avec certaines valeurs par défaut prioritaires. La logique est contrôlée par android/scripts/common.py.

Le répertoire NDK doit être ~/android-ndk-VERSION ou C:/android/android-ndk-VERSION ou défini via ANDROID_NDK_PATH variable d'environnement.

Les composants Deqp sur l'appareil, le service d'exécution de test et les programmes de test sont compilé à l'aide du script android/scripts/build.py. Le fichier .apk final est créé dans android/package/bin et peut être installé par le script install.py. Si le command line executor est utilisé, l'exécutable ExecService est lancé avec le script launch.py sur l'appareil via ADB. Les scripts peuvent être exécutés à partir de n'importe quel répertoire.

Build Linux

Vous pouvez créer des binaires de test et des utilitaires de ligne de commande pour Linux en générant des fichiers makefile à l'aide de CMake. Plusieurs cibles de compilation prédéfinies sont utiles lors de la compilation pour Linux.

Cible de build Description
default

Cible par défaut qui utilise l'introspection de la plate-forme CMake pour déterminer la compatibilité avec différentes API.
x11_glx

Utilise GLX pour créer des contextes OpenGL (ES).
x11_egl

Utilise EGL pour créer des contextes OpenGL (ES).
x11_egl_glx

Compatible avec GLX et EGL avec X11.

Utilisez toujours -DCMAKE_BUILD_TYPE=<Debug|Release> pour définir le type de compilation. Release est une valeur par défaut appropriée. Sans cela, un build par défaut non optimisé est créé.

Les arguments de ligne de commande -DCMAKE_C_FLAGS et -DCMAKE_CXX_FLAGS peuvent être utilisée pour transmettre des arguments supplémentaires au compilateur. Par exemple, la compilation 32 bits ou 64 bits peut être effectuée en en définissant -DCMAKE_C(XX)_FLAGS="-m32" ou "-m64" respectivement. Si ce n'est pas le cas spécifiée, l'architecture native de la chaîne d'outils, généralement 64 bits sur la chaîne d'outils 64 bits, est utilisée.

Les arguments -DCMAKE_LIBRARY_PATH et -DCMAKE_INCLUDE_PATH peuvent être utilisés pour CMake afin de fournir une bibliothèque supplémentaire à CMake ou d'inclure des chemins de recherche.

Un exemple de ligne de commande complète utilisée pour effectuer une version de débogage 32 bits sur dans un emplacement personnalisé se présente comme suit:

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

Compilation croisée

La compilation croisée peut être réalisée à l'aide d'un fichier de chaîne d'outils CMake. Chaîne d'outils spécifie le compilateur à utiliser, ainsi que des chemins de recherche personnalisés pour bibliothèques et en-têtes. Plusieurs fichiers de chaîne d'outils pour les scénarios courants sont inclus dans le package de version dans le répertoire framework/delibs/cmake.

En plus des variables CMake standards, les variables suivantes spécifiques à deqp sont les suivantes : peut être défini par le fichier de chaîne d'outils. CMake peut généralement détecter DE_OS et DE_COMPILER. et DE_PTR_SIZE correctement, mais DE_CPU doit être défini par le fichier de chaîne d'outils.

Variable Description
DE_OS

Système d'exploitation Valeurs acceptées: DE_OS_WIN32, DE_OS_UNIX, DE_OS_WINCE, DE_OS_OSX, DE_OS_ANDROID, DE_OS_SYMBIAN, DE_OS_IOS
DE_COMPILER

Type de compilateur. Valeurs acceptées: DE_COMPILER_GCC, DE_COMPILER_MSC, DE_COMPILER_CLANG
DE_CPU

Type de processeur. Les valeurs acceptées sont DE_CPU_ARM, DE_CPU_X86.
DE_PTR_SIZE

sizeof(void*) sur la plateforme. Valeurs acceptées: 4 et 8

Le fichier de chaîne d'outils peut être sélectionné à l'aide du paramètre de compilation CMAKE_TOOLCHAIN_FILE. Par exemple, le code suivant crée des fichiers makefiles pour une compilation à l'aide du compilateur croisé CodeSourcery pour ARM/Linux:

cmake PATH_TO_SRC/deqp –DDEQP_BUILD_TYPE="Release"
–DCMAKE_TOOLCHAIN_FILE=PATH_TO_SRC/delibs/cmake/toolchain-arm-cs.cmake
–DARM_CC_BASE=PATH_TO_CC_DIRECTORY

Association de l'environnement d'exécution des bibliothèques GLES et EGL

Le deqp n'a pas besoin de points d'entrée de l'API testée lors de l'association. La le code de test accède toujours aux API via des pointeurs de fonction. Les points d'entrée peuvent Ils sont ensuite chargés dynamiquement lors de l'exécution, ou le port de la plate-forme peut les fournir au moment de l'association.

Si la prise en charge d'une API est activée dans les paramètres de compilation et les bibliothèques de liens sont n'est pas fourni, le fichier deqp chargera les points d'entrée nécessaires au moment de l'exécution. Si le si une association statique est souhaitée, fournissez les bibliothèques de liens nécessaires dans DEQP_<API>_LIBRARIES variable de configuration de compilation.

Porter le framework de test

Le portage de deqp implique trois étapes: l'adaptation des bibliothèques de portabilité de base, la mise en œuvre d'interfaces d'intégration de plate-forme avec le framework de test, ainsi que le portage service d'exécution.

Le tableau ci-dessous indique les emplacements où il est probable que les transferts soient effectués. Au-delà sont probablement exotiques.

Position Description
framework/delibs/debase
framework/delibs/dethread
framework/delibs/deutil

Toutes les implémentations nécessaires de code spécifique au système d'exploitation.
framework/qphelper/qpCrashHandler.c

Facultatif: Implémentation pour votre système d'exploitation.
framework/qphelper/qpWatchDog.c

Implémentation pour votre système d'exploitation. L'application actuelle est basée sur dethread et la bibliothèque C standard.
framework/platform

Le nouveau port de plate-forme et le nouveau bouchon d'application peuvent être implémentés comme décrit dans la section Tester le port de la plate-forme du framework

Bibliothèques de portabilité de base

Les bibliothèques de portabilité de base prennent déjà en charge Windows, la plupart des variantes Linux, Mac OS, iOS et Android. Si la cible de test s'exécute sur l'un de ces systèmes d'exploitation, très probablement il n'est pas nécessaire de toucher les bibliothèques de portabilité de base.

Port de la plate-forme du framework de test

Le port de la plate-forme du framework de test deqp nécessite deux composants: une application point d'entrée et mise en œuvre d'une interface de plate-forme.

Le point d'entrée de l'application est chargé de créer l'objet de plate-forme, Création d'un objet de ligne de commande (tcu::CommandLine), ouverture d'un journal de test (tcu::TestLog) et l'itération de l'application de test (tcu::App). Si le L'OS cible prend en charge un point d'entrée main() standard, tcuMain.cpp peut être utilisé comme point d'entrée.

L'API de la plate-forme deqp est décrite en détail dans les fichiers suivants.

Fichier Description
framework/common/tcuPlatform.hpp

Classe de base pour tous les ports de la plate-forme
framework/opengl/gluPlatform.hpp

Interface de plate-forme OpenGL
framework/egl/egluPlatform.hpp

Interface de la plate-forme EGL
framework/platform/tcuMain.cpp

Point d'entrée d'application standard

La classe de base pour tous les ports de la plate-forme est tcu::Platform. Le port de la plateforme peut prennent en charge les interfaces spécifiques GL et EGL en option. Voir Le tableau suivant vous donne un aperçu de ce qui doit être mis en œuvre pour exécuter les tests.

Module interface

Modules de test OpenGL (ES)

Interface de la plate-forme GL

Module de test EGL

Interface de la plate-forme EGL

Vous trouverez des instructions détaillées sur la mise en œuvre des ports de la plate-forme dans les des en-têtes de couche de portage.

Service d'exécution de test

Pour utiliser l'infrastructure d'exécution de test deqp ou l'exécuteur de ligne de commande, le service d'exécution de test doit être disponible sur la cible. Un C++ portable du service est fournie dans le répertoire execserver. La solution est créé dans le cadre du module de test deqp pour les PC cibles. Vous pouvez modifier execserver/CMakeLists.txt pour activer une compilation sur d'autres cibles.

La version C++ du service d'exécution de test accepte deux lignes de commande paramètres:

  • --port=<port> définit le port TCP sur lequel le serveur écoute. La valeur par défaut est 50016.
  • --single met fin au processus serveur lorsque le client se déconnecte. Par défaut, le processus serveur reste actif pour traiter les demandes d'exécution de test supplémentaires.

Exécuter les tests

Cette page fournit des instructions pour exécuter des tests deqp sous Linux et Windows en utilisant des arguments de ligne de commande package d'application.

Environnements Linux et Windows

Commencez par copier les fichiers et répertoires suivants sur la cible.

Module Répertoire Target
Serveur d'exécution build/execserver/execserver <dst>/execserver
Module EGL build/modules/egl/deqp-egl <dst>/deqp-egl
Module GLES2 build/modules/gles2/deqp-gles2 <dst>/deqp-gles2
data/gles2 <dst>/gles2
Module GLES3 build/modules/gles3/deqp-gles3 <dst>/deqp-gles3
data/gles3 <dst>/gles3
Module GLES 3.1 build/modules/gles31/deqp-gles31 <dst>/deqp-gles31
data/gles31 <dst>/gles31
Module GLES 3.2 build/modules/gles32/deqp-gles32 <dst>/deqp-gles32
data/gles32 <dst>/gles32

Vous pouvez déployer le service d'exécution et les binaires de test n'importe où dans la cible Système de fichiers Toutefois, les binaires de test s'attendent à trouver des répertoires de données répertoire de travail actuel. Lorsque vous êtes prêt, démarrez le service d'exécution de test sur le appareil cible. Pour en savoir plus sur le démarrage du service, consultez Tester service d'exécution.

Arguments de ligne de commande

Le tableau suivant répertorie les arguments de ligne de commande qui affectent l'exécution de toutes des programmes de test.

Argument Description
--deqp-case=<casename> Exécute les cas correspondant à un modèle donné. Les caractères génériques (*) sont acceptés.
--deqp-log-filename=<filename> Écrivez les résultats du test dans le fichier dont vous indiquez le nom. L'exécution du test service définit le nom du fichier lors du démarrage d'un test.
--deqp-stdin-caselist
--deqp-caselist=<caselist>
--deqp-caselist-file=<filename>		 Lire la liste de cas à partir de stdin ou d'un argument donné. L'exécution du test service définira l'argument en fonction de la requête d'exécution reçue. Voir la section suivante pour une description du format de la liste des demandes.
--deqp-test-iteration-count=<count> Remplacez le nombre d'itérations pour les tests qui prennent en charge un nombre variable de itérations.
--deqp-base-seed=<seed> Valeur de base pour les scénarios de test qui utilisent la randomisation.

Arguments spécifiques à GLES2 et GLES3

Le tableau suivant répertorie les arguments spécifiques à GLES2 et GLES3.
Argument Description
--deqp-gl-context-type=<type> Type de contexte OpenGL. Les types de contextes disponibles dépendent de la plate-forme. Activé plates-formes compatibles avec EGL, vous pouvez utiliser la valeur egl pour sélectionner le contexte EGL.
--deqp-gl-config-id=<id> Exécutez des tests pour l'ID de configuration GL fourni. L'interprétation est selon la plate-forme. Sur la plate-forme EGL, il s'agit de l'ID de configuration EGL.
--deqp-gl-config-name=<name> Exécutez des tests pour une configuration GL nommée. L'interprétation est selon la plate-forme. Pour EGL, le format est rgb(a)<bits>d<bits>s<bits> Par exemple, un la valeur de rgb888s8 sélectionne la première configuration où le tampon de couleur est RVB888 et le tampon de pochoir contient 8 bits.
--deqp-gl-context-flags=<flags> Crée un contexte. Spécifiez robust ou debug.
--deqp-surface-width=<width>
--deqp-surface-height=<height>		 Essayez de créer une surface d'une taille donnée. La prise en charge de ce paramètre est facultative.
--deqp-surface-type=<type> Utilisez un type de surface donné comme cible de rendu de test principale. Possible types sont window, pixmap, pbuffer, et fbo.
--deqp-screen-rotation=<rotation> l'orientation de l'écran par incréments de 90 degrés pour les plates-formes qui le supporter.

Format de la liste des scénarios de test

La liste des scénarios de test peut être fournie sous deux formats. La première consiste à lister le nom complet de chaque test sur une ligne distincte dans un fichier ASCII standard. En tant que dans vos ensembles de test, les préfixes répétitifs peuvent s'avérer fastidieux. Pour éviter les répétitions les préfixes, utilisez la syntaxe trie (également appelée arborescence des préfixes) illustrée ci-dessous.

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

Exemple :

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

À traduire en deux scénarios de test:

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

Android

Le package d'application Android contient tous les composants requis, y compris le service d'exécution de test, les binaires de test et les fichiers de données. L'activité de test est Une NativeActivity qui utilise EGL (nécessite Android 3.2 ou version ultérieure).

Le package d'application peut être installé à l'aide de la commande suivante (nom est le nom de l'APK dans le package Android CTS. dont le nom dépend de la compilation):

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

Pour lancer le service d'exécution de test et configurer le transfert de port, utilisez la méthode suivantes:

adb –d forward tcp:50016 tcp:50016
adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter

Pour activer les impressions de débogage, exécutez la commande suivante avant de lancer la tests:

adb –d shell setprop log.tag.dEQP DEBUG

Exécuter des tests sur Android sans Android CTS

Pour lancer manuellement l'activité d'exécution de test, créez un intent Android ciblant android.app.NativeActivity. Ces activités peuvent être se trouvant dans le package com.drawelements.deqp. La ligne de commande être fournie en tant que chaîne supplémentaire avec la clé "cmdLine" dans l'intent.

Un journal de test est écrit dans /sdcard/dEQP-log.qpa. Si l'exécution du test ne démarre pas normalement, des informations de débogage supplémentaires sont disponibles dans l'appareil journal.

Vous pouvez lancer une activité à partir de la ligne de commande à l'aide de l'am utilitaire. Par exemple, pour exécuter des tests dEQP-GLES2.info sur une plate-forme compatible avec NativeActivity,, utilisez les commandes suivantes.

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"'

Déboguer sur Android

Pour exécuter les tests avec le débogueur GDB sur Android, commencez par compiler et installer la version de débogage en exécutant les deux scripts suivants:

python android/scripts/build.py --native-build-type=Debug
python android/scripts/install.py

Une fois la version de débogage installée sur l'appareil, lancez les tests sous En exécutant GDB sur l'hôte, exécutez la commande suivante:

python android/scripts/debug.py \
--deqp-commandline="--deqp-log-filename=/sdcard/TestLog.qpa --deqp-case=dEQP-GLES2.functional.*"

La ligne de commande deqp dépend des scénarios de test à exécuter et d'autres paramètres obligatoires. Le script ajoute un point d'arrêt par défaut au début de l'exécution de deqp (tcu::App::App).

Le script debug.py accepte plusieurs arguments de ligne de commande pour des actions telles que la définition de points d'arrêt pour le débogage, la connexion à gdbserver et les chemins d'accès aux binaires supplémentaires à déboguer (utilisez debug.py --help pour tous les arguments et explications). Le script copie également certaines les bibliothèques par défaut de l'appareil cible pour obtenir des listes de symboles.

Pour parcourir le code du pilote (par exemple, lorsque GDB doit connaître les emplacements des binaires avec toutes les informations de débogage), ajoutez d'autres bibliothèques via Paramètres de ligne de commande debug.py. Ce script écrit un pour le GDB, à partir de la ligne 132 du fichier de script. Toi peut fournir des chemins d'accès supplémentaires vers des binaires, etc., mais en fournissant une commande les paramètres de ligne devraient suffire.

Remarque:Sous Windows, le binaire GDB nécessite libpython2.7.dll Avant de lancer debug.py, ajoutez <path-to-ndk>/prebuilt/windows/bin à la variable PATH.

Remarque:Le débogage du code natif ne fonctionne pas sur Android 4.3 pour obtenir des solutions de contournement, reportez-vous à la page ce bug public. Android 4.4 et versions ultérieures ne contiennent pas ce bug.

Automatiser les tests

Les modules de test Deqp peuvent être intégrés aux systèmes de test automatisés de plusieurs manières. La meilleure approche dépend de l'infrastructure de test existante et de la cible environnement.

La sortie principale d'une exécution de test est toujours le fichier journal du test, c'est-à-dire le fichier avec un suffixe .qpa. Les résultats complets du test peuvent être analysés à partir du journal de test. La sortie de la console est aux informations de débogage uniquement. Il est possible qu'elles ne soient pas disponibles sur toutes les plates-formes.

Les binaires de test peuvent être appelés directement à partir d'un système d'automatisation des tests. Le test le binaire peut être lancé pour un cas spécifique, pour un ensemble de test disponibles. Si une erreur fatale se produit pendant l'exécution (comme certaines API ou un plantage), l'exécution du test s'interrompt. Pour les tests de régression, la meilleure approche consiste à appeler les binaires de test pour des cas individuels ou pour des petits tests séparément, afin d'obtenir des résultats partiels, même dans les cas de défaillance permanente.

Deqp est fourni avec des outils d'exécution de test en ligne de commande qui peuvent être utilisés dans avec le service d'exécution pour obtenir une intégration plus robuste. L'exécuteur détecte l'arrêt du processus de test et reprendra l'exécution du test le le prochain cas disponible. Un seul fichier journal est généré à partir du test complet. session. Cette configuration est idéale pour les systèmes de test légers de reprise après sinistre.

Outils d'exécution de tests en ligne de commande

L'ensemble actuel d'outils de ligne de commande inclut un outil d'exécution de test à distance, un générateur de comparaison de journaux pour l'analyse de régression, un convertisseur test-log-to-CSV, un convertisseur test-log-to-XML et un convertisseur testlog-vers-JUnit.

Le code source de ces outils se trouve dans le répertoire executor, et les binaires sont dans le répertoire <builddir>/executor.

Exécuteur de test en ligne de commande

L'exécuteur de test de ligne de commande est un outil C++ portable permettant de lancer une exécution de test sur un appareil et collecter les journaux qui en résultent via TCP/IP. L'exécuteur communique avec le service d’exécution (execserver) sur l’appareil cible. Ensemble, ils fournissent des fonctionnalités telles que la récupération après des plantages de processus de test. Les exemples suivants montrent comment utiliser l'exécuteur de test de la ligne de commande (utilisez --help pour en savoir plus):

Exemple 1: Exécuter des tests fonctionnels GLES2 sur un appareil Android
executor --connect=127.0.0.1 --port=50016 --binaryname=
com.drawelements.deqp/android.app.NativeActivity
--caselistdir=caselists
--testset=dEQP-GLES2.* --out=BatchResult.qpa
--cmdline="--deqp-crashhandler=enable --deqp-watchdog=enable
--deqp-gl-config-name=rgba8888d24s8"
Exemple 2: Poursuivre l'exécution locale d'un test OpenGL ES 2 partiel
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

Exporter et comparer les journaux de test au format CSV

Deqp dispose d'un outil permettant de convertir les journaux de test (fichiers .qpa) en fichiers CSV. Le fichier CSV contient une liste de scénarios de test et leurs résultats. L'outil peut également comparer plusieurs résultats par lot et ne répertorier que les scénarios de test ayant des codes d'état différents dans les résultats du lot d'entrée. La comparaison affichera également le nombre de cas correspondants.

La sortie au format CSV est très pratique pour un traitement ultérieur avec des utilitaires de ligne de commande ou avec un éditeur de feuille de calcul. Une couche supplémentaire, lisible par l'humain, le format texte brut peut être sélectionné à l'aide de l'argument de ligne de commande suivant: --format=text

Exemple 1: Exporter un journal de test au format CSV
testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csv
testlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv
Exemple 2: Lister les différences de résultats de test entre deux journaux de test
testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa

Remarque:L'argument --value=code génère le test un code de résultat, tel que "Pass" ou "Échec". L'argument --value=details sélectionne Explication du résultat ou de la valeur numérique produite par un test de performance, de capacité ou de justesse

Exportation au format XML des journaux de test

Les fichiers journaux de test peuvent être convertis en documents XML valides à l'aide de l'testlog-to-xml utilitaire. Deux modes de sortie sont acceptés:

  • Mode Documents distincts, où chaque scénario de test et le résumé caselist.xml documents sont écrits dans un répertoire de destination
  • Mode de fichier unique, où tous les résultats du fichier .qpa sont écrits dans un seul document XML.

Vous pouvez afficher les fichiers journaux de test exportés dans un navigateur à l'aide d'une feuille de style XML. Des exemples de feuilles de style (testlog.xsl et testlog.css) sont fournis dans le répertoire doc/testlog-stylesheet. Pour afficher les fichiers journaux dans un navigateur, copiez deux fichiers de feuille de style dans le même répertoire que les documents XML exportés.

Si vous utilisez Google Chrome, les fichiers doivent être accessibles via HTTP en tant que Chrome limite l'accès aux fichiers locaux pour des raisons de sécurité. L'installation Python standard comprend un serveur HTTP de base qui peut être lancé pour diffuser à l'aide de la commande python –m SimpleHTTPServer 8000. Après avoir lancé le serveur, il vous suffit de faire pointer le navigateur Chrome vers http://localhost:8000 pour afficher le journal de test.

Conversion en journal de test JUnit

De nombreux systèmes d'automatisation des tests peuvent générer des rapports sur les résultats des tests depuis JUnit de sortie. Les fichiers journaux de test deqp peuvent être convertis au format de sortie JUnit à l'aide de l'outil testlog-to-junit.

L'outil ne permet actuellement que de traduire les résultats du scénario de test. En tant que JUnit prend en charge uniquement "pass" et "échouer" un résultat de passage de deqp est mappé par "JUnit pass". et d'autres résultats sont considérés comme des échecs. La deqp d'origine le code de résultat est disponible dans la sortie JUnit. D'autres données, telles que les messages de journal et les images de résultats, ne sont pas conservées lors de la conversion.

Utiliser des groupes de test spéciaux

Certains groupes de test peuvent nécessiter ou prendre en charge des options de ligne de commande spéciales, ou nécessiter une attention particulière lorsqu’elle est utilisée sur certains systèmes.

Tests de contrainte sur l'allocation de mémoire

Les tests de contrainte sur l'allocation de mémoire mettent à l'épreuve les problèmes de saturation de la mémoire en alloue certaines ressources jusqu'à ce que le pilote signale une erreur de mémoire insuffisante.

Sur certaines plates-formes, comme Android et la plupart des variantes Linux, les attributs peut se produire: le système d'exploitation peut arrêter le processus de test au lieu d'autoriser pour gérer ou fournir une erreur de saturation de la mémoire. Sur ces plates-formes, les tests conçus pour provoquer des erreurs de saturation de la mémoire sont désactivés par défaut. Vous devez l'activer à l'aide de l'argument de ligne de commande --deqp-test-oom=enable. Nous vous recommandons d'exécuter ces tests manuellement vérifier si le système se comporte correctement en cas de pression sur les ressources. Toutefois, dans ces dans une situation donnée, le plantage d'un processus de test doit être interprété comme une réussite.

Groupes de test

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

Tests de contrainte sur le rendu de longue durée

Les tests de contrainte de rendu sont conçus pour déceler les problèmes de robustesse en cas de la charge de rendu. Par défaut, les tests n'exécutent que quelques itérations, mais vous pouvez les configurer pour qu'elles s'exécutent indéfiniment en fournissant le --deqp-test-iteration-count=-1 un argument de ligne de commande. Le watchdog de test doit être désactivé (--deqp-watchdog=disable) lorsque vous exécutez ces tests sur une longue période.

Groupes de test

dEQP-GLES2.stress.long.*
dEQP-GLES3.stress.long.*