AOSP inclut la suite de tests GPU drawElements Quality Program (deqp) à l'adresse https://android.googlesource.com/platform/external/deqp . Cette page explique comment déployer la suite de tests deqp dans un nouvel environnement.
Pour travailler avec le dernier code soumis, utilisez la branche deqp-dev . Pour le code qui correspond à une version spécifique d'Android CTS, utilisez la branche release-code-name -release (par exemple pour Android 6.0, utilisez la branche marshmallow-release ).
Disposition des sources
La disposition du code source des modules de test deqp et des bibliothèques de support est présentée dans le tableau ci-dessous (la liste n'est pas exhaustive mais met en évidence les répertoires les plus importants).
| Annuaire | Description |
|---|---|
android | Sources de testeur Android et scripts de construction |
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 GLES3.1 |
modules/gles32 | Module GLES3.2 |
targets | Fichiers de configuration de build spécifiques à la cible |
framework | cadre et utilitaires du module de test deqp |
framework/delibs | Portabilité de base et bibliothèques de construction |
framework/platform | Ports de plateforme |
framework/qphelper | Bibliothèque d'intégration de programmes de test (C) |
framework/common | Cadre Deqp (C++) |
framework/opengl, framework/egl | Utilitaires spécifiques à l'API |
execserver | Source ExecServer côté appareil |
executor | Outil et utilitaires shell de l'exécuteur de test côté hôte |
external | Créer un répertoire stub pour les bibliothèques externes libpng et zlib |
Composants open source
Le 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 depuis platform/external/[libpng,zlib] .
Construire des programmes de test
Le cadre de test a été conçu dans un souci de portabilité. Les seules exigences obligatoires sont la prise en charge complète du C++ et les bibliothèques système standard pour les E/S, les threads et les sockets.
Système de construction CMake
Les sources deqp contiennent des scripts de build pour CMake, qui est l'outil préféré pour compiler les programmes de test.
CMake est un système de build open source qui prend en charge plusieurs plates-formes et chaînes d'outils. CMake génère des makefiles natifs ou des fichiers de projet IDE à partir de fichiers de configuration indépendants de la cible. Pour plus d'informations sur CMake, veuillez consulter la documentation CMake .
CMake prend en charge et recommande les builds hors arborescence source, c'est-à-dire que vous devez toujours créer des makefiles ou des fichiers de projet dans un répertoire de construction distinct en dehors de l'arborescence source. CMake n'a aucun type de cible "distclean", donc la suppression de tous les fichiers générés par CMake doit être effectuée manuellement.
Les options de configuration sont données à CMake en utilisant la syntaxe -D OPTION_NAME = VALUE . Certaines options couramment utilisées pour deqp sont répertoriées ci-dessous.
| Option de configuration | Description |
|---|---|
DEQP_TARGET | Nom de la cible, par exemple : "android" Les scripts deqp CMake incluront le fichier |
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 build pour les cibles makefile. Les valeurs valides sont : "Debug" et "Release" Notez que l'interprétation et le type par défaut dépendent du système de build ciblé. Consultez la documentation CMake pour plus de détails. |
Créer un fichier de build cible
Le système de build deqp est configuré pour les nouvelles cibles à l'aide des fichiers de build cibles. Un fichier de build cible définit les fonctionnalités prises en charge par la plate-forme et les bibliothèques ou chemins d'inclusion supplémentaires requis. Les noms de fichiers cibles suivent le format targets/ NAME / NAME .cmake et la cible est sélectionnée à l'aide du paramètre de construction DEQP_TARGET .
Les chemins de fichiers dans les fichiers cibles sont relatifs au répertoire deqp de base, et non au répertoire targets/ NAME . Les variables standard suivantes peuvent être définies par le fichier de build cible.
| Variable | Description |
|---|---|
DEQP_TARGET_NAME | Nom de la cible (sera inclus dans les journaux de test) |
DEQP_SUPPORT_GLES2 | Si GLES2 est pris en charge (par défaut : OFF) |
DEQP_GLES2_LIBRARIES | Bibliothèques GLES2 (laissez vide si elles ne sont pas prises en charge ou si le chargement dynamique est utilisé) |
DEQP_SUPPORT_GLES3 | Si GLES3.x est pris en charge (par défaut : OFF) |
DEQP_GLES3_LIBRARIES | Bibliothèques GLES3.x (laissez vide si elles ne sont pas prises en charge ou si le chargement dynamique est utilisé) |
DEQP_SUPPORT_VG | Si OpenVG est pris en charge (par défaut : OFF) |
DEQP_OPENVG_LIBRARIES | Bibliothèques OpenVG (laissez vide si elles ne sont pas prises en charge ou si le chargement dynamique est utilisé) |
DEQP_SUPPORT_EGL | Si EGL est pris en charge (par défaut : OFF) |
DEQP_EGL_LIBRARIES | Bibliothèques EGL (laissez vide si elles ne sont pas prises en charge ou si le chargement dynamique est utilisé) |
DEQP_PLATFORM_LIBRARIES | Bibliothèques supplémentaires spécifiques à la plate-forme requises pour la liaison |
DEQP_PLATFORM_COPY_LIBRARIES | Liste des bibliothèques copiées dans chaque répertoire de construction binaire de test. Peut être utilisé pour copier les bibliothèques nécessaires à l'exécution des tests mais qui ne figurent pas dans le chemin de recherche par défaut. |
TCUTIL_PLATFORM_SRCS | Liste des sources des ports de plateforme. Les sources par défaut sont déterminées en fonction des capacités et du système d'exploitation. Remarque : Les chemins sont relatifs à : |
Le fichier de construction cible peut ajouter des chemins d'inclusion ou de lien supplémentaires à l'aide des fonctions CMake include_directories() et link_directories() .
Version Win32
Le moyen le plus simple de créer des modules deqp pour Windows consiste à utiliser le système de construction CMake. Vous aurez besoin de CMake 2.6.12 ou plus récent et du compilateur Microsoft Visual C/C++. Le deqp a été testé avec Visual Studio 2013.
Les fichiers de projet Visual Studio peuvent être générés avec la commande suivante :
cmake path\to\src\deqp -G "Visual Studio 12"
Une build 64 bits peut être réalisée en sélectionnant « Visual Studio VERSION Win64 » comme générateur de build :
cmake path\to\src\deqp -G "Visual Studio 12 Win64"
Vous pouvez également générer des makefiles NMake avec l'option -G "NMake Makefiles" ainsi que le type de build ( -DCMAKE_BUILD_TYPE="Debug" ou "Release" ).
Création de contexte de rendu
Le contexte de rendu peut être créé soit avec WGL, soit avec EGL sous Windows.
Prise en charge du WGL
Tous les binaires Win32 prennent en charge la création de contexte GL avec WGL car ils ne nécessitent que des bibliothèques standard. Le contexte WGL peut être sélectionné à l'aide de l'argument de ligne de commande --deqp-gl-context-type=wgl . En mode WGL, le deqp utilise l'extension 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 prennent pas en charge l'extension requise.
Prise en charge de l'EGL
Le deqp est construit avec un chargement dynamique pour EGL sous Windows si DEQP_SUPPORT_EGL est activé. Il s'agit de la valeur par défaut dans la plupart des cibles. Ensuite, si l'hôte dispose de bibliothèques EGL, il est possible de lancer des tests avec celles-ci avec le paramètre de ligne de commande : --deqp-gl-context-type=egl
Version Android
La version Android utilise des scripts de génération CMake pour créer le code de test natif. Les parties Java, c'est-à-dire le Test Execution Server et le Test Application Stub, sont compilées à l'aide des outils de construction Android standard.
Pour compiler les programmes de test deqp pour Android avec les scripts de build fournis, vous aurez besoin de :
- La dernière version du NDK Android ; le fichier
android/scripts/common.pyrépertorie la version requise - SDK autonome Android avec les packages API 13, SDK Tools, SDK Platform-tools et SDK Build-tools installés
- Apache Ant 1.9.4 (requis par la construction du 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 pris en charge
- Pour Windows : soit NMake, soit JOM dans
PATH- JOM permet des builds plus rapides
- Facultatif : Ninja make est également pris en charge sous Linux
Les binaires Ant et SDK sont localisé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 soit ~/android-ndk- VERSION ou C:/android/android-ndk- VERSION ou défini via la variable d'environnement ANDROID_NDK_PATH .
Les composants Deqp sur l'appareil, le service d'exécution de tests et les programmes de test sont créés en exécutant le script android/scripts/build.py . Le .apk final est créé dans android/package/bin et peut être installé par le script install.py . Si l' exécuteur de ligne de commande est utilisé, 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.
Version Linux
Des binaires de test et des utilitaires de ligne de commande peuvent être créés pour Linux en générant des makefiles à l'aide de CMake. Il existe plusieurs cibles de build prédéfinies qui sont utiles lors de la build pour Linux.
| Construire la cible | Description |
|---|---|
default | Cible par défaut qui utilise l'introspection de la plateforme CMake pour déterminer la prise en charge de diverses 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 | Prend en charge GLX et EGL avec X11. |
Utilisez toujours -DCMAKE_BUILD_TYPE=<Debug|Release> pour définir le type de build. Release est une bonne valeur par défaut. Sans cela, une version par défaut non optimisée est créée.
Les arguments de ligne de commande -DCMAKE_C_FLAGS et -DCMAKE_CXX_FLAGS peuvent être utilisés pour transmettre des arguments supplémentaires au compilateur. Par exemple, la construction 32 bits ou 64 bits peut être effectuée en définissant respectivement -DCMAKE_C(XX)_FLAGS="-m32" ou "-m64" . Si elle n'est pas 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 pour donner à CMake une bibliothèque supplémentaire ou 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 les en-têtes de pilotes et les bibliothèques dans un emplacement personnalisé est le suivant :
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. Le fichier de chaîne d'outils spécifie le compilateur à utiliser, ainsi que les chemins de recherche personnalisés pour les bibliothèques et les en-têtes. Plusieurs fichiers de chaîne d'outils pour des scénarios courants sont inclus dans le package de version dans le répertoire framework/delibs/cmake .
En plus des variables CMake standard, les variables suivantes spécifiques à deqp peuvent être définies par le fichier de chaîne d'outils. CMake peut généralement détecter correctement DE_OS , DE_COMPILER et DE_PTR_SIZE mais DE_CPU doit être défini par le fichier de la chaîne d'outils.
| Variable | Description |
|---|---|
DE_OS | Système opérateur. Les valeurs prises en charge sont : |
DE_COMPILER | Type de compilateur. Les valeurs prises en charge sont : |
DE_CPU | Type de processeur. Les valeurs prises en charge sont : |
DE_PTR_SIZE | sizeof(void*) sur la plateforme. Les valeurs prises en charge sont : 4 et 8 |
Le fichier de chaîne d'outils peut être sélectionné à l'aide du paramètre de construction CMAKE_TOOLCHAIN_FILE . Par exemple, ce qui suit créerait des makefiles pour une build à 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
Liaison d'exécution des bibliothèques GLES et EGL
Le deqp n'a pas besoin des points d'entrée de l'API testée lors de la liaison. Le code de test accède toujours aux API via des pointeurs de fonction. Les points d'entrée peuvent ensuite être chargés dynamiquement au moment de l'exécution ou le port de la plateforme peut les fournir au moment de la liaison.
Si la prise en charge d'une API est activée dans les paramètres de construction et que les bibliothèques de liens ne sont pas fournies, le deqp chargera les points d'entrée nécessaires au moment de l'exécution. Si la liaison statique est souhaitée, fournissez les bibliothèques de liens nécessaires dans la variable de configuration de build DEQP_<API>_LIBRARIES .
Portez le framework de test
Le portage du deqp implique trois étapes : l'adaptation des bibliothèques de portabilité de base, la mise en œuvre des interfaces d'intégration de la plate-forme du cadre de test et le portage du service d'exécution.
Le tableau ci-dessous répertorie les emplacements pour les modifications de portage probables. Tout ce qui les dépasse est susceptible d'être exotique.
| Emplacement | Description |
|---|---|
framework/delibs/debase | Toutes les implémentations nécessaires du 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'actuel est basé sur |
framework/platform | Un nouveau port de plate-forme et un nouveau stub d'application peuvent être implémentés comme décrit dans Port de plate-forme du cadre de test . |
Bibliothèques de portabilité de base
Les bibliothèques de portabilité de base prennent déjà en charge Windows, la plupart des variantes de Linux, Mac OS, iOS et Android. Si la cible de test s'exécute sur l'un de ces systèmes d'exploitation, il n'est probablement pas nécessaire de toucher aux bibliothèques de portabilité de base.
Port de la plate-forme du cadre de test
Le port de la plate-forme du cadre de test deqp nécessite deux composants : un point d'entrée d'application et une implémentation d'interface de plate-forme.
Le point d'entrée de l'application est responsable de la création de l'objet plateforme, de la création d'un objet de ligne de commande ( tcu::CommandLine ), de l'ouverture d'un journal de test ( tcu::TestLog ) et de l'itération de l'application de test ( tcu::App ). Si le système d'exploitation cible prend en charge un point d'entrée main() standard, tcuMain.cpp peut être utilisé comme implémentation du point d'entrée.
L'API de la plateforme deqp est décrite en détail dans les fichiers suivants.
| Déposer | Description |
|---|---|
framework/common/tcuPlatform.hpp | Classe de base pour tous les ports de plateforme |
framework/opengl/gluPlatform.hpp | Interface de la plateforme OpenGL |
framework/egl/egluPlatform.hpp | Interface de la plateforme EGL |
framework/platform/tcuMain.cpp | Point d’entrée d’application standard |
La classe de base pour tous les ports de plateforme est tcu::Platform . Le port de la plate-forme peut éventuellement prendre en charge les interfaces spécifiques GL et EGL. Consultez le tableau suivant pour un aperçu de ce qui doit être implémenté pour exécuter les tests.
| Module | Interface |
|---|---|
Modules de tests OpenGL (ES) | Interface de la plateforme GL |
Module de test EGL | Interface de la plateforme EGL |
Des instructions détaillées pour la mise en œuvre des ports de plate-forme se trouvent dans les en-têtes de la couche de portage.
Service d'exécution de tests
Pour utiliser l'infrastructure d'exécution de tests deqp ou l'exécuteur de ligne de commande, le service d'exécution de tests doit être disponible sur la cible. Une implémentation C++ portable du service est fournie dans le répertoire execserver . Le binaire autonome est construit dans le cadre du module de test deqp construit pour les cibles PC. Vous pouvez modifier execserver/CMakeLists.txt pour activer une build sur d'autres cibles.
La version C++ du service d'exécution de tests accepte deux paramètres de ligne de commande :
-
--port=<port>définira le port TCP sur lequel le serveur écoute. La valeur par défaut est 50016. -
--singlemettra fin au processus serveur lorsque le client se déconnectera. Par défaut, le processus serveur restera actif pour répondre à d'autres demandes d'exécution de tests.
Exécutez les tests
Cette page fournit des instructions pour exécuter des tests deqp dans des environnements Linux et Windows, à l'aide d'arguments de ligne de commande et pour utiliser le package d'application Android.
Environnements Linux et Windows
Commencez par copier les fichiers et répertoires suivants sur la cible.
| Module | Annuaire | Cible |
|---|---|---|
| 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 GLES3.1 | build/modules/gles31/deqp-gles31 | <dst>/deqp-gles31 |
data/gles31 | <dst>/gles31 | |
| Module GLES3.2 | build/modules/gles32/deqp-gles32 | <dst>/deqp-gles32 |
data/gles32 | <dst>/gles32 |
Vous pouvez déployer le service d'exécution et tester les binaires n'importe où dans le système de fichiers cible ; cependant, les binaires de test s'attendent à trouver des répertoires de données dans le répertoire de travail actuel. Lorsque vous êtes prêt, démarrez le service d'exécution de tests sur l'appareil cible. Pour plus de détails sur le démarrage du service, consultez Service d'exécution de tests .
Arguments de ligne de commande
Le tableau suivant répertorie les arguments de ligne de commande qui affectent l'exécution de tous les programmes de test.
| Argument | Description |
|---|---|
--deqp-case=<casename> | Exécutez des cas qui correspondent à un modèle donné. Le caractère générique (*) est pris en charge. |
--deqp-log-filename=<filename> | Écrivez les résultats des tests dans le fichier dont vous fournissez le nom. Le service d'exécution de tests définira le nom de fichier lors du démarrage d'un test. |
--deqp-stdin-caselist | Lire la liste des cas depuis stdin ou depuis un argument donné. Le service d'exécution de tests définira l'argument en fonction de la demande d'exécution reçue. Voir la section suivante pour une description du format de liste de cas. |
--deqp-test-iteration-count=<count> | Remplacez le nombre d’itérations pour les tests prenant en charge un nombre variable d’itérations. |
--deqp-base-seed=<seed> | Graine de base pour les cas 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 contexte disponibles dépendent de la plateforme. Sur les plateformes prenant en charge EGL, la valeur egl peut être utilisée 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 dépend de la plateforme. Sur la plateforme 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 dépend de la plateforme. Pour EGL, le format est rgb(a)<bits>d<bits>s<bits> . Par exemple, une valeur de rgb888s8 sélectionnera la première configuration où le tampon de couleur est RGB888 et le tampon de pochoir a 8 bits. |
--deqp-gl-context-flags=<flags> | Crée un contexte. Spécifiez robust ou debug . |
--deqp-surface-width=<width> | Essayez de créer une surface avec une taille donnée. La prise en charge de ceci est facultative. |
--deqp-surface-type=<type> | Utilisez un type de surface donné comme cible principale de rendu de test. Les types possibles sont window , pixmap , pbuffer et fbo . |
--deqp-screen-rotation=<rotation> | Orientation de l'écran par incréments de 90 degrés pour les plates-formes qui le prennent en charge. |
Format de liste de cas de test
La liste des cas de test peut être donnée sous deux formats. La première option consiste à répertorier le nom complet de chaque test sur une ligne distincte dans un fichier ASCII standard. À mesure que les ensembles de tests grandissent, les préfixes répétitifs peuvent devenir fastidieux. Pour éviter de répéter les préfixes, utilisez une syntaxe trie (également appelée arbre de préfixes) présentée ci-dessous.
{nodeName{firstChild{…},…lastChild{…}}}
Par exemple:
{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}
Se traduit par les deux cas de test suivants :
dEQP-EGL.config_list dEQP-EGL.create_context.rgb565_depth_stencil
Android
Le package d'application Android contient tous les composants requis, notamment le service d'exécution de tests, 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 supérieur).
Le package d'application peut être installé avec la commande suivante (le nom affiché est le nom de l'APK dans le package Android CTS ; ce nom dépend de la version) :
adb –d install –r com.drawelements.deqp.apk
Pour lancer le service d'exécution de tests et configurer la redirection de port, utilisez ce qui suit :
adb –d forward tcp:50016 tcp:50016adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter
Les impressions de débogage peuvent être activées en exécutant ce qui suit avant de démarrer les tests :
adb –d shell setprop log.tag.dEQP DEBUG
Exécuter des tests sur Android sans Android CTS
Pour démarrer manuellement l'activité d'exécution de test, créez une intention Android qui cible android.app.NativeActivity . Les activités peuvent être trouvées dans le package com.drawelements.deqp . La ligne de commande doit être fournie sous forme de chaîne supplémentaire avec la clé "cmdLine" dans l'intention.
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 le journal du périphérique.
Vous pouvez lancer une activité depuis la ligne de commande à l'aide de l'utilitaire am . Par exemple, pour exécuter des tests dEQP-GLES2.info sur une plateforme prenant en charge 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 sous 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=Debugpython android/scripts/install.py
Une fois la version de débogage installée sur l'appareil, pour lancer les tests sous GDB exécutés 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 cas de test à exécuter et d'autres paramètres requis. 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, les paramètres de connexion au serveur gdb et les chemins vers des binaires supplémentaires à déboguer (utilisez debug.py --help pour tous les arguments et explications). Le script copie également certaines bibliothèques par défaut du périphérique cible pour obtenir des listes de symboles.
Pour parcourir le code du pilote (par exemple lorsque le GDB a besoin de connaître les emplacements des binaires avec des informations de débogage complètes), ajoutez plus de bibliothèques via les paramètres de ligne de commande debug.py . Ce script écrit un fichier de configuration pour le GDB à partir de la ligne 132 du fichier de script. Vous pouvez fournir des chemins supplémentaires vers les binaires, etc., mais fournir des paramètres de ligne de commande corrects devrait 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 d'origine ; pour des solutions de contournement, reportez-vous à ce bug public . Android 4.4 et supérieur ne contient pas ce bug.
Automatisez 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 l'environnement cible.
La sortie principale d'une exécution de test est toujours le fichier journal de test, c'est-à-dire le fichier avec le suffixe .qpa . Les résultats complets des tests peuvent être analysés à partir du journal de test. La sortie de la console contient uniquement des informations de débogage et peut ne pas être disponible sur toutes les plates-formes.
Les binaires de test peuvent être invoqués directement à partir d'un système d'automatisation de tests. Le binaire de test peut être lancé pour un cas spécifique, pour un ensemble de tests ou pour tous les tests disponibles. Si une erreur fatale survient lors de l'exécution (comme certaines erreurs d'API ou un crash), l'exécution du test sera abandonnée. Pour les tests de régression, la meilleure approche consiste à appeler séparément les binaires de test pour des cas individuels ou de petits ensembles de tests, afin de disposer de résultats partiels même en cas de panne matérielle.
Le deqp est livré avec des outils d'exécution de tests en ligne de commande qui peuvent être utilisés en combinaison avec le service d'exécution pour réaliser une intégration plus robuste. L'exécuteur détecte la fin du processus de test et reprendra l'exécution du test au prochain cas disponible. Un seul fichier journal est généré à partir de la session de test complète. Cette configuration est idéale pour les systèmes de test légers qui ne fournissent pas de fonctionnalités de récupération après incident.
Outils d'exécution de tests en ligne de commande
L'ensemble d'outils de ligne de commande actuel comprend un outil d'exécution de tests à distance, un générateur de comparaison de journaux de test pour l'analyse de régression, un convertisseur de journal de test en CSV, un convertisseur de journal de test en XML et un convertisseur de journal de test en JUnit. .
Le code source de ces outils se trouve dans le répertoire executor et les binaires sont intégrés dans le répertoire <builddir>/executor .
Exécuteur de test en ligne de commande
L'exécuteur de test en ligne de commande est un outil C++ portable permettant de lancer un test sur un appareil et de collecter les journaux résultants 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 pannes de processus de test. Les exemples suivants montrent comment utiliser la ligne de commande Test Executor (utilisez --help pour plus de détails) :
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 un test partiel OpenGL ES 2 exécuté localement
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
Tester l'exportation CSV du journal et comparer
Le deqp dispose d'un outil pour convertir les journaux de test (fichiers qpa ) en fichiers CSV. La sortie CSV contient une liste de cas de test et leurs résultats. L'outil peut également comparer deux résultats de lots ou plus et répertorier uniquement les scénarios de test qui ont des codes d'état différents dans les résultats du lot d'entrée. La comparaison imprimera é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 standards ou avec un éditeur de feuille de calcul. Un format de texte brut supplémentaire, lisible par l'homme, peut être sélectionné à l'aide de l'argument de ligne de commande suivant : --format=text
Exemple 1 : Exporter le journal de test au format CSV
testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csvtestlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv
Exemple 2 : Répertorier 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 code du résultat du test, tel que "Réussite" ou "Échec". L'argument --value=details sélectionne l'explication plus détaillée du résultat ou de la valeur numérique produite par un test de performance, de capacité ou de précision.
Exportation XML du journal de test
Les fichiers journaux de test peuvent être convertis en documents XML valides à l'aide de l'utilitaire testlog-to-xml . Deux modes de sortie sont pris en charge :
- Mode documents séparés, dans lequel chaque scénario de test et le document récapitulatif
caselist.xmlsont écrits dans un répertoire de destination - Mode fichier unique, où tous les résultats du fichier
.qpasont écrits dans un seul document XML.
Les fichiers journaux de test exportés peuvent être visualisés dans un navigateur à l'aide d'une feuille de style XML. Des exemples de documents de feuille 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 les deux fichiers de feuille de style dans le même répertoire où se trouvent les documents XML exportés.
Si vous utilisez Google Chrome, les fichiers doivent être accessibles via HTTP car Chrome limite l'accès aux fichiers locaux pour des raisons de sécurité. L'installation standard de Python comprend un serveur HTTP de base qui peut être lancé pour servir le répertoire actuel avec la commande python –m SimpleHTTPServer 8000 . Après avoir lancé le serveur, pointez simplement le navigateur Chrome sur http://localhost:8000 pour afficher le journal de test.
Conversion en journal de test JUnit
De nombreux systèmes d'automatisation de tests peuvent générer des rapports sur les résultats des tests à partir de la sortie JUnit. Les fichiers journaux de test deqp peuvent être convertis au format de sortie JUnit à l'aide de l'outil testlog-to-junit.
L'outil prend actuellement en charge uniquement la traduction du verdict du scénario de test. Comme JUnit ne prend en charge que les résultats « réussite » et « échec », un résultat réussi du deqp est mappé sur « réussite JUnit » et les autres résultats sont considérés comme des échecs. Le code de résultat deqp original est disponible dans la sortie JUnit. Les 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 tests spéciaux
Certains groupes de tests peuvent nécessiter ou prendre en charge des options de ligne de commande spéciales, ou nécessiter une attention particulière lorsqu'ils sont utilisés sur certains systèmes.
Tests de stress d'allocation de mémoire
Les tests de contrainte d'allocation de mémoire exercent des conditions de manque de mémoire en allouant à plusieurs reprises certaines ressources jusqu'à ce que le pilote signale une erreur de manque de mémoire.
Sur certaines plates-formes, telles qu'Android et la plupart des variantes de Linux, les événements suivants peuvent se produire : Le système d'exploitation peut arrêter le processus de test au lieu de permettre à un pilote de gérer ou de fournir une erreur de mémoire insuffisante. Sur ces plates-formes, les tests conçus pour provoquer des erreurs de mémoire insuffisante sont désactivés par défaut et doivent être activés à l'aide de l'argument de ligne de commande --deqp-test-oom=enable . Il est recommandé d'exécuter ces tests manuellement pour vérifier si le système se comporte correctement sous la pression des ressources. Cependant, dans une telle situation, un crash du processus de test doit être interprété comme une réussite.
Groupes de tests
dEQP-GLES2.stress.memory.* dEQP-GLES3.stress.memory.*
Tests de résistance de rendu de longue durée
Les tests de contrainte de rendu sont conçus pour révéler les problèmes de robustesse sous une charge de rendu soutenue. Par défaut, les tests n'exécuteront que quelques itérations, mais ils peuvent être configurés pour s'exécuter indéfiniment en fournissant l'argument de ligne de commande --deqp-test-iteration-count=-1 . Le chien de garde des tests doit être désactivé ( --deqp-watchdog=disable ) lors de l'exécution de ces tests pendant une longue période.
Groupes de tests
dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.*
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2024/03/18 (UTC).