Pruebas del programa de calidad de drawElements

AOSP incluye el conjunto de pruebas de GPU del programa de calidad de drawElements (deqp) en https://android.googlesource.com/platform/external/deqp. En esta página, se detalla cómo implementar el paquete de pruebas de deqp en un entorno nuevo.

Para trabajar con el código enviado más reciente, usa la rama deqp-dev. Para el código que coincida con una versión específica de CTS de Android, usa la rama release-code-name-release (p.ej., para Android 6.0, usa la rama marshmallow-release).

Diseño de la fuente

El diseño del código fuente de los módulos de prueba de deqp y las bibliotecas compatibles se muestra en la siguiente tabla (la lista no es exhaustiva, pero destaca los directorios más importantes).

Componentes de código abierto

El deqp usa libpng y zlib, que se pueden recuperar con la secuencia de comandos platform/external/deqp/external/fetch_sources.py o a través de git desde platform/external/[libpng,zlib].

Compila programas de prueba

El framework de pruebas se diseñó teniendo en cuenta la portabilidad. Los únicos requisitos obligatorios son la compatibilidad total con C++ y las bibliotecas del sistema estándar para E/S, subprocesos y sockets.

Sistema de compilación de CMake

Las fuentes de deqp tienen secuencias de comandos de compilación para CMake, que es la herramienta preferida para compilar los programas de prueba.

CMake es un sistema de compilación de código abierto que admite varias plataformas y cadenas de herramientas. CMake genera archivos de proyecto de IDE o archivos de makefile nativos a partir de archivos de configuración independientes del destino. Para obtener más información sobre CMake, consulta la documentación de CMake.

CMake admite y recomienda compilaciones fuera del árbol de fuentes, es decir, siempre debes crear archivos de make o de proyecto en un directorio de compilación independiente fuera del árbol de fuentes. CMake no tiene ningún tipo de destino "distclean", por lo que la eliminación de los archivos que genera CMake se debe hacer de forma manual.

Las opciones de configuración se proporcionan a CMake con la sintaxis -DOPTION_NAME=VALUE. A continuación, se enumeran algunas opciones de uso general para deqp.

Crea un archivo de compilación de destino

El sistema de compilación de deqp se configura para destinos nuevos con archivos de compilación de destino. Un archivo de compilación de destino define qué funciones admite la plataforma y qué bibliotecas o rutas de inclusión adicionales se requieren. Los nombres de los archivos de destino siguen el formato targets/NAME/NAME.cmake, y el destino se selecciona con el parámetro de compilación DEQP_TARGET.

Las rutas de acceso de los archivos de destino son relativas al directorio deqp base, no al directorio targets/NAME. Las siguientes variables estándar se pueden establecer mediante el archivo de compilación de destino.

El archivo de compilación de destino puede agregar rutas de acceso de inclusión o vinculación adicionales con las funciones include_directories() y link_directories() de CMake.

Compilación de Win32

La forma más sencilla de compilar módulos de deqp para Windows es usar el sistema de compilación de CMake. Necesitarás CMake 2.6.12 o una versión posterior y el compilador Microsoft Visual C/C++. El deqp se probó con Visual Studio 2013.

Los archivos de proyecto de Visual Studio se pueden generar con el siguiente comando:

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

Para crear una compilación de 64 bits, selecciona "Visual Studio VERSION Win64" como generador de compilaciones:

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

También puedes generar archivos de configuración de NMake con la opción -G "NMake Makefiles", así como el tipo de compilación (-DCMAKE_BUILD_TYPE="Debug" o "Release").

Creación de contexto de renderización

El contexto de renderización se puede crear con WGL o con EGL en Windows.

Compatibilidad con WGL

Todos los objetos binarios de Win32 admiten la creación de contextos GL con WGL, ya que solo requieren bibliotecas estándar. El contexto de WGL se puede seleccionar con el argumento de línea de comandos --deqp-gl-context-type=wgl. En el modo WGL, el deqp usa la extensión WGL_EXT_create_context_es_profile para crear contextos de OpenGL ES. Se probó que funciona con los controladores más recientes de NVIDIA e Intel. Los controladores AMD no admiten la extensión requerida.

Compatibilidad con EGL

El deqp se compila con carga dinámica para EGL en Windows si DEQP_SUPPORT_EGL está activado. Esta es la opción predeterminada en la mayoría de los destinos. Luego, si el host tiene bibliotecas de EGL disponibles, es posible ejecutar pruebas con ellas con el parámetro de línea de comandos --deqp-gl-context-type=egl.

Compilación de Android

La compilación de Android usa secuencias de comandos de compilación de CMake para compilar el código de prueba nativo. Las partes de Java, es decir, el servidor de ejecución de pruebas y el stub de la aplicación de prueba, se compilan con las herramientas de compilación estándar de Android.

Para compilar programas de prueba de deqp para Android con las secuencias de comandos de compilación proporcionadas, necesitarás lo siguiente:

• La versión más reciente del NDK de Android. El archivo android/scripts/common.py muestra la versión requerida.
• SDK independiente de Android con API 13, herramientas del SDK, herramientas de la plataforma del SDK y paquetes de herramientas de compilación del SDK instalados
• Apache Ant 1.9.4 (obligatorio para la compilación del código de Java)
• CMake 2.8.12 o una versión posterior
• Python 2.6 o versiones posteriores de la serie 2.x (no se admite Python 3.x)
• Para Windows: NMake o JOM en PATH
  • JOM permite compilaciones más rápidas.
• Opcional: Ninja make también es compatible con Linux

Los archivos binarios de Ant y SDK se ubican según la variable de entorno PATH con ciertos valores predeterminados anulados. android/scripts/common.py controla la lógica.

El directorio del NDK debe ser ~/android-ndk-VERSION o C:/android/android-ndk-VERSION, o bien definirse a través de la variable de entorno ANDROID_NDK_PATH.

Para compilar los componentes integrados en el dispositivo de Deqp, el servicio de ejecución de pruebas y los programas de prueba, se ejecuta la secuencia de comandos android/scripts/build.py. El .apk final se crea en android/package/bin y la secuencia de comandos install.py puede instalarlo. Si se usa el ejecutor de línea de comandos, se inicia ExecService con la secuencia de comandos launch.py en el dispositivo a través de ADB. Las secuencias de comandos se pueden ejecutar desde cualquier directorio.

Compilación de Linux

Para compilar objetos binarios de prueba y utilidades de línea de comandos para Linux, genera archivos de configuración con CMake. Existen varios destinos de compilación predefinidos que son útiles cuando se compila para Linux.

Usa siempre -DCMAKE_BUILD_TYPE=<Debug|Release> para definir el tipo de compilación. Release es una buena opción predeterminada. Sin él, se crea una compilación de lanzamiento predeterminada y no optimizada.

Los argumentos de línea de comandos -DCMAKE_C_FLAGS y -DCMAKE_CXX_FLAGS se pueden usar para pasar argumentos adicionales al compilador. Por ejemplo, la compilación de 32 bits o 64 bits se puede realizar configurando -DCMAKE_C(XX)_FLAGS="-m32" o "-m64", respectivamente. Si no se especifica, se usa la arquitectura nativa de la cadena de herramientas, que suele ser de 64 bits en la cadena de herramientas de 64 bits.

Los argumentos -DCMAKE_LIBRARY_PATH y -DCMAKE_INCLUDE_PATH se pueden usar para que CMake le proporcione una biblioteca adicional o incluya rutas de búsqueda.

El siguiente es un ejemplo de una línea de comandos completa que se usa para realizar una compilación de depuración de 32 bits en los encabezados y las bibliotecas del controlador en una ubicación personalizada:

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

Compilación cruzada

La compilación cruzada se puede lograr con un archivo de cadena de herramientas de CMake. El archivo de cadena de herramientas especifica el compilador que se usará, junto con las rutas de búsqueda personalizadas para las bibliotecas y los encabezados. En el paquete de lanzamiento del directorio framework/delibs/cmake, se incluyen varios archivos de cadena de herramientas para situaciones comunes.

Además de las variables estándar de CMake, el archivo de cadena de herramientas puede configurar las siguientes variables específicas de deqp. Por lo general, CMake puede detectar DE_OS, DE_COMPILER y DE_PTR_SIZE correctamente, pero el archivo de la cadena de herramientas debe configurar DE_CPU.

El archivo de cadena de herramientas se puede seleccionar con el parámetro de compilación CMAKE_TOOLCHAIN_FILE. Por ejemplo, el siguiente comando crearía archivos make para una compilación con el compilador multiplataforma CodeSourcery para 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

Vinculación del entorno de ejecución de las bibliotecas GLES y EGL

El deqp no necesita puntos de entrada de la API en prueba durante la vinculación. El código de prueba siempre accede a las APIs a través de punteros de función. Luego, los puntos de entrada se pueden cargar de forma dinámica durante el tiempo de ejecución, o el puerto de la plataforma puede proporcionarlos durante el tiempo de vinculación.

Si la compatibilidad con una API está activada en la configuración de compilación y no se proporcionan bibliotecas de vínculos, el deqp cargará los puntos de entrada necesarios en el tiempo de ejecución. Si se desea la vinculación estática, proporciona las bibliotecas de vinculación necesarias en la variable de configuración de compilación DEQP_<API>_LIBRARIES.

Cómo portar el framework de pruebas

La portabilidad de deqp implica tres pasos: adaptar las bibliotecas de portabilidad básicas, implementar interfaces de integración de plataformas de frameworks de prueba y portar el servicio de ejecución.

En la siguiente tabla, se muestran las ubicaciones de los posibles cambios de portabilidad. Es probable que cualquier valor más allá de ellos sea exótico.

Bibliotecas de portabilidad básicas

Las bibliotecas de portabilidad básicas ya admiten Windows, la mayoría de las variantes de Linux, macOS, iOS y Android. Si el destino de prueba se ejecuta en uno de esos sistemas operativos, lo más probable es que no sea necesario tocar las bibliotecas de portabilidad básicas.

Puerto de la plataforma del framework de pruebas

El puerto de plataforma del framework de pruebas de deqp requiere dos componentes: un punto de entrada de la aplicación y una implementación de interfaz de plataforma.

El punto de entrada de la aplicación es responsable de crear el objeto de la plataforma, crear un objeto de línea de comandos (tcu::CommandLine), abrir un registro de prueba (tcu::TestLog) y iterar la aplicación de prueba (tcu::App). Si el SO de destino admite un punto de entrada main() estándar, se puede usar tcuMain.cpp como la implementación del punto de entrada.

La API de la plataforma de deqp se describe en detalle en los siguientes archivos.

La clase base para todos los puertos de plataforma es tcu::Platform. De manera opcional, el puerto de la plataforma puede admitir interfaces específicas de GL y EGL. Consulta la siguiente tabla para obtener una descripción general de lo que se debe implementar para ejecutar las pruebas.

Las instrucciones detalladas para implementar puertos de plataforma se encuentran en los encabezados de la capa de portabilidad.

Servicio de ejecución de pruebas

Para usar la infraestructura de ejecución de pruebas de deqp o el ejecutor de línea de comandos, el servicio de ejecución de pruebas debe estar disponible en el destino. En el directorio execserver, se proporciona una implementación portátil del servicio en C++. El objeto binario independiente se compila como parte de la compilación del módulo de prueba de deqp para los destinos de PC. Puedes modificar execserver/CMakeLists.txt para habilitar una compilación en otros destinos.

La versión en C++ del servicio de ejecución de pruebas acepta dos parámetros de línea de comandos:

• --port=<port> establecerá el puerto TCP en el que el servidor escucha. El valor predeterminado es 50016.
• --single finalizará el proceso del servidor cuando el cliente se desconecte. De forma predeterminada, el proceso del servidor permanecerá activo para entregar más solicitudes de ejecución de prueba.

Ejecuta las pruebas

En esta página, se proporcionan instrucciones para ejecutar pruebas de deqp en entornos de Linux y Windows, usar argumentos de línea de comandos y trabajar con el paquete de aplicación de Android.

Entornos de Linux y Windows

Comienza por copiar los siguientes archivos y directorios en el destino.

Puedes implementar el servicio de ejecución y probar los objetos binarios en cualquier parte del sistema de archivos de destino. Sin embargo, los objetos binarios de prueba esperan encontrar directorios de datos en el directorio de trabajo actual. Cuando todo esté listo, inicia el servicio de ejecución de pruebas en el dispositivo de destino. Para obtener detalles sobre cómo iniciar el servicio, consulta Cómo probar el servicio de ejecución.

Argumentos de la línea de comandos

En la siguiente tabla, se muestran los argumentos de línea de comandos que afectan la ejecución de todos los programas de prueba.

Argumentos específicos de GLES2 y GLES3

Formato de la lista de casos de prueba

La lista de casos de prueba se puede proporcionar en dos formatos. La primera opción es enumerar el nombre completo de cada prueba en una línea separada en un archivo ASCII estándar. A medida que los conjuntos de pruebas aumentan, los prefijos repetitivos pueden ser engorrosos. Para evitar repetir los prefijos, usa la sintaxis de un trie (también conocido como árbol de prefijos) que se muestra a continuación.

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

Por ejemplo:

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

Esto se traduce en los siguientes dos casos de prueba:

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

Android

El paquete de aplicación para Android contiene todos los componentes necesarios, incluidos el servicio de ejecución de pruebas, los objetos binarios de prueba y los archivos de datos. La actividad de prueba es un NativeActivity que usa EGL (requiere Android 3.2 o versiones posteriores).

El paquete de la aplicación se puede instalar con el siguiente comando (el nombre que se muestra es el del APK en el paquete de CTS de Android, que depende de la compilación):

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

Para iniciar el servicio de ejecución de pruebas y configurar la redirección de puertos, usa lo siguiente:

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

Para habilitar las impresiones de depuración, ejecuta lo siguiente antes de iniciar las pruebas:

adb –d shell setprop log.tag.dEQP DEBUG

Ejecuta pruebas en Android sin CTS de Android

Para iniciar de forma manual la actividad de ejecución de prueba, crea un intent de Android que se oriente a android.app.NativeActivity. Las actividades se pueden encontrar en el paquete com.drawelements.deqp. La línea de comandos se debe proporcionar como una cadena adicional con la clave "cmdLine" en el intent.

Se escribe un registro de prueba en /sdcard/dEQP-log.qpa. Si la ejecución de prueba no se inicia de forma normal, hay información de depuración adicional disponible en el registro del dispositivo.

Puedes iniciar una actividad desde la línea de comandos con la utilidad am. Por ejemplo, para ejecutar pruebas de dEQP-GLES2.info en una plataforma que admita NativeActivity,, usa los siguientes comandos.

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

Cómo depurar en Android

Para ejecutar las pruebas en el depurador GDB en Android, primero compila y, luego, instala la compilación de depuración mediante la ejecución de las siguientes dos secuencias de comandos:

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

Después de instalar la compilación de depuración en el dispositivo, para iniciar las pruebas en GDB que se ejecuta en el host, ejecuta el siguiente comando:

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

La línea de comandos de deqp depende de los casos de prueba que se ejecutarán y de otros parámetros necesarios. La secuencia de comandos agrega un punto de interrupción predeterminado al comienzo de la ejecución de deqp (tcu::App::App).

La secuencia de comandos debug.py acepta varios argumentos de línea de comandos para acciones como establecer puntos de interrupción para la depuración, parámetros de conexión de gdbserver y rutas de acceso a objetos binarios adicionales para depurar (usa debug.py --help para todos los argumentos y explicaciones). La secuencia de comandos también copia algunas bibliotecas predeterminadas del dispositivo de destino para obtener listas de símbolos.

Para recorrer el código del controlador (por ejemplo, cuando GDB necesita conocer las ubicaciones de los objetos binarios con información de depuración completa), agrega más bibliotecas a través de los parámetros de línea de comandos debug.py. Esta secuencia de comandos escribe un archivo de configuración para GDB a partir de la línea 132 del archivo de secuencia de comandos. Puedes proporcionar rutas adicionales a objetos binarios, etcétera, pero proporcionar los parámetros correctos de la línea de comandos debería ser suficiente.

Nota: En Windows, el binario de GDB requiere libpython2.7.dll. Antes de iniciar debug.py, agrega <path-to-ndk>/prebuilt/windows/bin a la variable PATH.

Nota: La depuración de código nativo no funciona en Android 4.3 original. Para obtener soluciones alternativas, consulta este error público. Android 4.4 y versiones posteriores no contienen este error.

Automatiza las pruebas

Los módulos de prueba de Deqp se pueden integrar a sistemas de prueba automatizados de varias maneras. El mejor enfoque depende de la infraestructura de prueba existente y del entorno de destino.

El resultado principal de una ejecución de prueba siempre es el archivo de registro de prueba, es decir, el archivo con un sufijo .qpa. Los resultados completos de la prueba se pueden analizar desde el registro de la prueba. El resultado de la consola solo es información de depuración y es posible que no esté disponible en todas las plataformas.

Los objetos binarios de prueba se pueden invocar directamente desde un sistema de automatización de pruebas. El objeto binario de prueba se puede iniciar para un caso específico, para un conjunto de pruebas o para todas las pruebas disponibles. Si se produce un error grave durante la ejecución (como ciertos errores de API o una falla), se abortará la ejecución de la prueba. Para las pruebas de regresión, el mejor enfoque es invocar los objetos binarios de prueba para casos individuales o conjuntos de pruebas pequeños por separado, de modo que haya resultados parciales disponibles incluso en caso de fallas graves.

El deqp incluye herramientas de ejecución de pruebas de línea de comandos que se pueden usar en combinación con el servicio de ejecución para lograr una integración más sólida. El ejecutor detecta la finalización del proceso de prueba y reanudará la ejecución de la prueba en el siguiente caso disponible. Se produce un solo archivo de registro a partir de la sesión de prueba completa. Esta configuración es ideal para sistemas de prueba ligeros que no proporcionan servicios de recuperación de fallas.

Herramientas de ejecución de pruebas de línea de comandos

El conjunto de herramientas de línea de comandos actual incluye una herramienta de ejecución de pruebas remota, un generador de comparación de registros de prueba para el análisis de regresión, un convertidor de registros de prueba a CSV, un convertidor de registros de prueba a XML y un convertidor de registros de prueba a JUnit.

El código fuente de estas herramientas se encuentra en el directorio executor, y los ejecutables se compilan en el directorio <builddir>/executor.

Ejecutor de pruebas de línea de comandos

El ejecutor de pruebas de línea de comandos es una herramienta portátil de C++ para iniciar una ejecución de prueba en un dispositivo y recopilar los registros resultantes a través de TCP/IP. El ejecutor se comunica con el servicio de ejecución (execserver) en el dispositivo de destino. Juntos, proporcionan funciones como la recuperación de fallas del proceso de prueba. En los siguientes ejemplos, se muestra cómo usar el ejecutor de pruebas de línea de comandos (usa --help para obtener más detalles):

Ejemplo 1: Ejecuta pruebas funcionales de GLES2 en un dispositivo 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"

Ejemplo 2: Continúa una prueba parcial de OpenGL ES 2 que se ejecuta de forma local

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

Prueba la exportación de registros en CSV y realiza una comparación

El deqp tiene una herramienta para convertir registros de prueba (archivos .qpa) en archivos CSV. El resultado CSV contiene una lista de casos de prueba y sus resultados. La herramienta también puede comparar dos o más resultados por lotes y mostrar solo los casos de prueba que tienen códigos de estado diferentes en los resultados del lote de entrada. La comparación también imprimirá la cantidad de casos coincidentes.

El resultado en formato CSV es muy práctico para un procesamiento adicional con utilidades de línea de comandos estándar o con un editor de hojas de cálculo. Se puede seleccionar un formato adicional de texto sin formato legible por humanos con el siguiente argumento de línea de comandos: --format=text

Ejemplo 1: Exporta el registro de prueba en formato CSV

testlog-to-csv --value=code BatchResult.qpa > Result_statuscodes.csv
testlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv

Ejemplo 2: Muestra las diferencias entre los resultados de las pruebas de dos registros de prueba

testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa

Nota: El argumento --value=code genera el código de resultado de la prueba, como “Aprobado” o “Reprobado”. El argumento --value=details selecciona la explicación adicional del resultado o el valor numérico que produce una prueba de rendimiento, capacidad o precisión.

Prueba la exportación de XML de registros

Los archivos de registro de prueba se pueden convertir en documentos XML válidos con la utilidad testlog-to-xml. Se admiten dos modos de salida:

• Modo de documentos separados, en el que cada caso de prueba y el documento de resumen caselist.xml se escriben en un directorio de destino
• Modo de archivo único, en el que todos los resultados del archivo .qpa se escriben en un solo documento XML.

Los archivos de registro de prueba exportados se pueden ver en un navegador con una hoja de estilo XML. Se proporcionan documentos de hoja de estilo de muestra (testlog.xsl y testlog.css) en el directorio doc/testlog-stylesheet. Para renderizar los archivos de registro en un navegador, copia los dos archivos de hoja de estilo en el mismo directorio en el que se encuentran los documentos XML exportados.

Si usas Google Chrome, se debe acceder a los archivos a través de HTTP, ya que Chrome limita el acceso a los archivos locales por motivos de seguridad. La instalación estándar de Python incluye un servidor HTTP básico que se puede iniciar para entregar el directorio actual con el comando python –m SimpleHTTPServer 8000. Después de iniciar el servidor, dirige el navegador Chrome a http://localhost:8000 para ver el registro de prueba.

Conversión a un registro de prueba de JUnit

Muchos sistemas de automatización de pruebas pueden generar informes de resultados de la ejecución de pruebas a partir de la salida de JUnit. Los archivos de registro de prueba de deqp se pueden convertir al formato de salida de JUnit con la herramienta testlog-to-junit.

Actualmente, la herramienta solo admite la traducción del veredicto del caso de prueba. Como JUnit solo admite resultados "pass" y "fail", un resultado aprobado de deqp se asigna a "JUnit pass" y otros resultados se consideran errores. El código de resultado de deqp original está disponible en el resultado de JUnit. Otros datos, como los mensajes de registro y las imágenes de resultados, no se conservan en la conversión.

Usa grupos de pruebas especiales

Es posible que algunos grupos de prueba necesiten opciones de línea de comandos especiales o admitan estas, o bien requieran cuidados especiales cuando se usen en ciertos sistemas.

Pruebas de esfuerzo de asignación de memoria

Las pruebas de esfuerzo de asignación de memoria ejercitan condiciones de memoria insuficiente asignando ciertos recursos de forma reiterada hasta que el controlador informa un error de memoria insuficiente.

En ciertas plataformas, como Android y la mayoría de las variantes de Linux, puede ocurrir lo siguiente: el sistema operativo puede finalizar el proceso de prueba en lugar de permitir que un controlador controle o proporcione un error de falta de memoria. En estas plataformas, las pruebas diseñadas para causar errores de falta de memoria están inhabilitadas de forma predeterminada y se deben habilitar con el argumento de línea de comandos --deqp-test-oom=enable. Se recomienda que ejecutes esas pruebas de forma manual para verificar si el sistema se comporta correctamente bajo presión de recursos. Sin embargo, en una situación así, una falla del proceso de prueba se debe interpretar como una prueba aprobada.

Grupos de prueba

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

Pruebas de esfuerzo de renderización de larga duración

Las pruebas de esfuerzo de renderización están diseñadas para revelar problemas de robustez con una carga de renderización sostenida. De forma predeterminada, las pruebas ejecutarán solo algunas iteraciones, pero se pueden configurar para que se ejecuten de forma indefinida si se proporciona el argumento de línea de comandos --deqp-test-iteration-count=-1. El supervisor de pruebas debe estar inhabilitado (--deqp-watchdog=disable) cuando se ejecutan estas pruebas durante un período prolongado.

Grupos de prueba

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