AOSP incluye el conjunto de pruebas de GPU drawElements Quality Program (deqp) en https://android.googlesource.com/platform/external/deqp. En esta página, se detalla cómo implementar el conjunto de pruebas 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 coincide con una versión específica del 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 para los módulos de prueba de deqp y las bibliotecas de asistencia se muestra en la siguiente tabla (la lista no es exhaustiva, pero destaca los directorios más importantes).
| Directorio | Descripción |
|---|---|
android |
Fuentes y secuencias de comandos de compilación del verificador de Android |
data |
Archivos de datos de prueba |
modules |
Fuentes de módulos de prueba |
modules/egl |
Módulo de EGL |
modules/gles2 |
Módulo GLES2 |
modules/gles3 |
Módulo GLES3 |
modules/gles31 |
Módulo de GLES3.1 |
modules/gles32 |
Módulo de GLES3.2 |
targets |
Archivos de configuración de compilación específicos para el destino |
framework |
Marco de trabajo y utilidades del módulo de pruebas de deqp |
framework/delibs |
Bibliotecas de compilación y portabilidad base |
framework/platform |
Puertos de la plataforma |
framework/qphelper |
Biblioteca de integración del programa de pruebas (C) |
framework/common |
Framework de deqp (C++) |
framework/opengl, framework/egl |
Utilidades específicas de la API |
execserver |
Fuente de ExecServer del dispositivo |
executor |
Herramientas y utilidades de shell del ejecutor de pruebas del host |
external |
Compila el directorio de stubs para las bibliotecas externas libpng y zlib |
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ñó pensando en 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 múltiples plataformas y cadenas de herramientas. CMake genera archivos make nativos o archivos de proyecto de IDE 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 origen, es decir, siempre debes crear archivos makefile o archivos de proyecto en un directorio de compilación independiente fuera del árbol de origen. CMake no tiene ningún tipo de destino "distclean", por lo que la eliminación de los archivos generados por CMake debe realizarse de forma manual.
Las opciones de configuración se proporcionan a CMake con la sintaxis -DOPTION_NAME=VALUE. A continuación, se indican algunas opciones de uso común para deqp.
| Opción de configuración | Descripción |
|---|---|
DEQP_TARGET |
Nombre del objetivo, por ejemplo, "android" Las secuencias de comandos de CMake de deqp incluirán el archivo |
CMAKE_TOOLCHAIN_FILE |
Ruta de acceso al archivo de la cadena de herramientas para CMake. Se usa para la compilación cruzada. |
CMAKE_BUILD_TYPE |
Es el tipo de compilación para los destinos de makefile. Los valores válidos son "Debug" y "Release". Ten en cuenta que la interpretación y el tipo predeterminado dependen del sistema de compilación objetivo. Consulta la documentación de CMake para obtener más detalles. |
Crea un archivo de compilación de destino
El sistema de compilación de deqp se configura para nuevos destinos 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 archivos en los archivos de destino son relativas al directorio base deqp, no al directorio targets/NAME. El archivo de compilación de destino puede establecer las siguientes variables estándar.
| Variable | Descripción |
|---|---|
DEQP_TARGET_NAME |
Nombre del objetivo (se incluirá en los registros de prueba) |
DEQP_SUPPORT_GLES2 |
Indica si se admite GLES2 (valor predeterminado: OFF). |
DEQP_GLES2_LIBRARIES |
Bibliotecas de GLES2 (deja este campo vacío si no se admiten o si se usa la carga dinámica) |
DEQP_SUPPORT_GLES3 |
Indica si se admite GLES3.x (valor predeterminado: OFF). |
DEQP_GLES3_LIBRARIES |
Bibliotecas de GLES3.x (deja este campo vacío si no se admiten o si se usa la carga dinámica) |
DEQP_SUPPORT_VG |
Indica si se admite OpenVG (valor predeterminado: OFF). |
DEQP_OPENVG_LIBRARIES |
Bibliotecas de OpenVG (deja este campo vacío si no se admiten o si se usa la carga dinámica) |
DEQP_SUPPORT_EGL |
Indica si se admite EGL (predeterminado: OFF). |
DEQP_EGL_LIBRARIES |
Bibliotecas de EGL (deja este campo vacío si no se admiten o si se usa la carga dinámica) |
DEQP_PLATFORM_LIBRARIES |
Se requieren bibliotecas adicionales específicas de la plataforma para la vinculación |
DEQP_PLATFORM_COPY_LIBRARIES |
Es la lista de bibliotecas que se copian en el directorio de compilación de cada objeto binario de prueba. Se puede usar para copiar bibliotecas que son necesarias para ejecutar pruebas, pero que no están en la ruta de búsqueda predeterminada. |
TCUTIL_PLATFORM_SRCS |
Es la lista de fuentes de puertos de la plataforma. Las fuentes predeterminadas se determinan en función de las capacidades y el SO. Nota: Las rutas de acceso son relativas a: |
El archivo de compilación de destino puede agregar rutas 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 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 de Microsoft Visual C/C++. El deqp se probó con Visual Studio 2013.
Los archivos del 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 el generador de compilación:
cmake path\to\src\deqp -G "Visual Studio 12 Win64"
También puedes generar archivos makefile de NMake con la opción -G "NMake Makefiles", así como el tipo de compilación (-DCMAKE_BUILD_TYPE="Debug" o "Release").
Creación del contexto de renderización
El contexto de renderización se puede crear con WGL o con EGL en Windows.
Compatibilidad con WGL
Todos los archivos binarios de Win32 admiten la creación de contextos de 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, 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 de 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. Este es el valor predeterminado 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.pyenumera la versión requerida. - SDK independiente de Android con los paquetes de API 13, SDK Tools, SDK Platform-tools y SDK Build-tools instalados
- Apache Ant 1.9.4 (requerido por la compilación de código Java)
- CMake 2.8.12 o una versión posterior
- Python 2.6 o una versión posterior 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 del SDK se ubican según la variable de entorno PATH con ciertos valores predeterminados de anulación. 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.
Los componentes de deqp en el dispositivo, el servicio de ejecución de pruebas y los programas de prueba se compilan ejecutando la secuencia de comandos android/scripts/build.py. El archivo .apk final se crea en android/package/bin y se puede instalar con la secuencia de comandos install.py. Si se usa el ejecutor de línea de comandos, se inicia ExecService con el script launch.py en el dispositivo a través de ADB. Las secuencias de comandos se pueden ejecutar desde cualquier directorio.
Compilación de Linux
Los archivos binarios de prueba y las utilidades de línea de comandos se pueden compilar para Linux generando archivos makefile con CMake. Existen varios destinos de compilación predefinidos que son útiles cuando se compila para Linux.
| Objetivo de compilación | Descripción |
|---|---|
default |
Es el objetivo predeterminado que usa la introspección de la plataforma de CMake para determinar la compatibilidad con varias APIs. |
x11_glx |
Usa GLX para crear contextos de OpenGL (ES). |
x11_egl |
Usa EGL para crear contextos de OpenGL (ES). |
x11_egl_glx |
Admite GLX y EGL con X11. |
Siempre usa -DCMAKE_BUILD_TYPE=<Debug|Release> para definir el tipo de compilación.
Release es un buen valor predeterminado. 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 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 proporcione rutas de búsqueda adicionales de bibliotecas o de inclusión.
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 relación con 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 la cadena de herramientas especifica el compilador que se usará, junto con rutas de búsqueda personalizadas para bibliotecas y encabezados. En el paquete de lanzamiento, se incluyen varios archivos de la cadena de herramientas para situaciones comunes en el directorio framework/delibs/cmake.
Además de las variables estándar de CMake, el archivo de la cadena de herramientas puede establecer las siguientes variables específicas de deqp. Por lo general, CMake puede detectar DE_OS, DE_COMPILER y DE_PTR_SIZE correctamente, pero DE_CPU debe establecerse en el archivo de la cadena de herramientas.
| Variable | Descripción |
|---|---|
DE_OS |
Sistema operativo Los valores admitidos son: |
DE_COMPILER |
Es el tipo de compilador. Los valores admitidos son: |
DE_CPU |
Tipo de CPU. Los valores admitidos son: |
DE_PTR_SIZE |
sizeof(void*) en la plataforma. Los valores admitidos son 4 y 8. |
El archivo de la 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 cruzado 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 en tiempo de ejecución de las bibliotecas de 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 en el tiempo de ejecución, o bien el puerto de la plataforma puede proporcionarlos en el tiempo de vinculación.
Si se activa la compatibilidad con una API en la configuración de compilación y no se proporcionan bibliotecas de vínculos, deqp cargará los puntos de entrada necesarios en el tiempo de ejecución. Si deseas la vinculación estática, proporciona las bibliotecas de vínculos necesarias en la variable de configuración de compilación DEQP_<API>_LIBRARIES.
Porta el framework de pruebas
La adaptación de deqp implica tres pasos: adaptar las bibliotecas de portabilidad básicas, implementar las interfaces de integración de la plataforma del framework de pruebas y adaptar el servicio de ejecución.
En la siguiente tabla, se indican las ubicaciones de los posibles cambios de portabilidad. Todo lo que vaya más allá de ellos probablemente sea exótico.
| Ubicación | Descripción |
|---|---|
framework/delibs/debase |
Implementaciones necesarias de código específico del SO |
framework/qphelper/qpCrashHandler.c |
Opcional: Implementación para tu SO. |
framework/qphelper/qpWatchDog.c |
Implementación para tu SO El actual se basa en |
framework/platform |
El nuevo puerto de la plataforma y el stub de la aplicación se pueden implementar como se describe en Puerto de la plataforma del framework de pruebas. |
Bibliotecas de portabilidad base
Las bibliotecas de portabilidad básicas ya admiten Windows, la mayoría de las variantes de Linux, Mac OS, iOS y Android. Si el destino de la prueba se ejecuta en uno de esos sistemas operativos, lo más probable es que no sea necesario modificar las bibliotecas de portabilidad base.
Puerto de la plataforma del framework de pruebas
El port de la plataforma del framework de pruebas de deqp requiere dos componentes: un punto de entrada de la aplicación y una implementación de la interfaz de la 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 realizar iteraciones en 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 implementación del punto de entrada.
La API de la plataforma de deqp se describe en detalle en los siguientes archivos.
| Archivo | Descripción |
|---|---|
framework/common/tcuPlatform.hpp |
Clase base para todos los puertos de la plataforma |
framework/opengl/gluPlatform.hpp |
Interfaz de la plataforma OpenGL |
framework/egl/egluPlatform.hpp |
Interfaz de la plataforma EGL |
framework/platform/tcuMain.cpp |
Punto de entrada estándar de la aplicación |
La clase base para todos los puertos de la plataforma es tcu::Platform. Opcionalmente, el port 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.
| Módulo | Interfaz |
|---|---|
Módulos de prueba de OpenGL (ES) |
Interfaz de la plataforma GL |
Módulo de prueba de EGL |
Interfaz de la plataforma EGL |
En los encabezados de la capa de portabilidad, se incluyen instrucciones detalladas para implementar los puertos de la plataforma.
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 en C++ del servicio. El ejecutable independiente se compila como parte de la compilación del módulo de prueba de deqp para 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 escucha el servidor. El valor predeterminado es 50016. -
--singlefinalizará el proceso del servidor cuando el cliente se desconecte. De forma predeterminada, el proceso del servidor permanecerá activo para atender más solicitudes de ejecución de pruebas.
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 para Android.
Entornos de Linux y Windows
Comienza por copiar los siguientes archivos y directorios en el destino.
| Módulo | Directorio | Target |
|---|---|---|
| Servidor de ejecución | build/execserver/execserver |
<dst>/execserver |
| Módulo EGL | build/modules/egl/deqp-egl |
<dst>/deqp-egl |
| Módulo GLES2 | build/modules/gles2/deqp-gles2 |
<dst>/deqp-gles2 |
data/gles2 |
<dst>/gles2 |
|
| Módulo de GLES3 | build/modules/gles3/deqp-gles3 |
<dst>/deqp-gles3 |
data/gles3 |
<dst>/gles3 |
|
| Módulo de GLES3.1 | build/modules/gles31/deqp-gles31 |
<dst>/deqp-gles31 |
data/gles31 |
<dst>/gles31 |
|
| Módulo GLES3.2 | build/modules/gles32/deqp-gles32 |
<dst>/deqp-gles32 |
data/gles32 |
<dst>/gles32 |
Puedes implementar el servicio de ejecución y probar los archivos binarios en cualquier lugar del sistema de archivos de destino. Sin embargo, los archivos binarios de prueba esperan encontrar directorios de datos en el directorio de trabajo actual. Cuando esté todo listo, inicia el servicio de ejecución de pruebas en el dispositivo de destino. Para obtener detalles sobre cómo iniciar el servicio, consulta Servicio de ejecución de pruebas.
Argumentos de la línea de comandos
En la siguiente tabla, se enumeran los argumentos de la línea de comandos que afectan la ejecución de todos los programas de prueba.
| Argumento | Descripción |
|---|---|
--deqp-case=<casename> |
Ejecuta los casos que coincidan con un patrón determinado. Se admite el comodín (*). |
--deqp-log-filename=<filename> |
Escribe los resultados de la prueba en el archivo cuyo nombre proporcionas. El servicio de ejecución de pruebas establecerá el nombre de archivo cuando inicie una prueba. |
--deqp-stdin-caselist |
Lee la lista de casos desde stdin o desde un argumento determinado. El servicio de ejecución de pruebas establecerá el argumento según la solicitud de ejecución recibida. Consulta la siguiente sección para obtener una descripción del formato de la lista de casos. |
--deqp-test-iteration-count=<count> |
Anula el recuento de iteraciones para las pruebas que admiten una cantidad variable de iteraciones. |
--deqp-base-seed=<seed> |
Es la semilla base para los casos de prueba que usan aleatorización. |
Argumentos específicos de GLES2 y GLES3
En la siguiente tabla, se enumeran los argumentos específicos de GLES2 y GLES3.| Argumento | Descripción |
|---|---|
--deqp-gl-context-type=<type> |
Es el tipo de contexto de OpenGL. Los tipos de contexto disponibles dependen de la plataforma. En las plataformas que admiten EGL, se puede usar el valor egl para seleccionar el contexto de EGL. |
--deqp-gl-config-id=<id> |
Ejecuta pruebas para el ID de configuración de GL proporcionado. La interpretación depende de la plataforma. En la plataforma de EGL, este es el ID de configuración de EGL. |
--deqp-gl-config-name=<name> |
Ejecuta pruebas para una configuración de GL con nombre. La interpretación depende de la plataforma. En el caso de EGL, el formato es rgb(a)<bits>d<bits>s<bits>. Por ejemplo, un valor de rgb888s8 seleccionará la primera configuración en la que el búfer de color sea RGB888 y el búfer de stencil tenga 8 bits. |
--deqp-gl-context-flags=<flags> |
Crea un contexto. Especifica robust o debug. |
--deqp-surface-width=<width> |
Intenta crear una superficie con un tamaño determinado. El soporte para esta opción es opcional. |
--deqp-surface-type=<type> |
Usar un tipo de superficie determinado como el objetivo principal de la renderización de prueba Los tipos posibles son window, pixmap, pbuffer y fbo. |
--deqp-screen-rotation=<rotation> |
Es la orientación de la pantalla en incrementos de 90 grados para las plataformas que la admiten. |
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 crecen los conjuntos de prueba, los prefijos repetitivos pueden ser engorrosos. Para evitar repetir los prefijos, usa una sintaxis de trie (también conocida como árbol de prefijos) como se muestra a continuación.
{nodeName{firstChild{…},…lastChild{…}}}
Por ejemplo:
{dEQP-EGL{config-list,create_context{rgb565_depth_stencil}}}
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 archivos 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 el reenvío de puertos, usa lo siguiente:
adb –d forward tcp:50016 tcp:50016adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter
Puedes habilitar las impresiones de depuración ejecutando lo siguiente antes de iniciar las pruebas:
adb –d shell setprop log.tag.dEQP DEBUG
Cómo ejecutar pruebas en Android sin el CTS de Android
Para iniciar manualmente la actividad de ejecución de pruebas, crea un intent de Android que apunte 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 la prueba no se inicia normalmente, 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 admite 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"'
Depura en Android
Para ejecutar las pruebas con el depurador de GDB en Android, primero compila e instala la compilación de depuración ejecutando los siguientes dos secuencias de comandos:
python android/scripts/build.py --native-build-type=Debugpython 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 obligatorios. 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 archivos 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 listados de símbolos.
Para ejecutar el código del controlador paso a paso (por ejemplo, cuando GDB necesita conocer las ubicaciones de los archivos binarios con información de depuración completa), agrega más bibliotecas a través de los parámetros de la 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 de acceso adicionales a archivos binarios, etc., pero debería ser suficiente con proporcionar los parámetros de línea de comandos correctos.
Nota: En Windows, el archivo 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 estándar. Para conocer 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 en sistemas de prueba automatizados de varias maneras. El mejor enfoque depende de la infraestructura de pruebas 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 a partir del registro de la prueba. La salida de la consola solo contiene información de depuración y es posible que no esté disponible en todas las plataformas.
Los ejecutables de prueba se pueden invocar directamente desde un sistema de automatización de pruebas. El archivo 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 anulará la ejecución de la prueba. Para las pruebas de regresión, el mejor enfoque es invocar los archivos binarios de prueba para casos individuales o conjuntos de pruebas pequeños por separado, de modo que los resultados parciales estén disponibles incluso en caso de una falla grave.
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 livianos que no proporcionan funciones de recuperación ante fallas.
Herramientas de ejecución de pruebas de línea de comandos
El conjunto actual de herramientas de línea de comandos incluye una herramienta de ejecución de pruebas remotas, un generador de comparación de registros de pruebas para el análisis de regresión, un convertidor de registros de pruebas a CSV, un convertidor de registros de pruebas a XML y un convertidor de registros de pruebas a JUnit.
El código fuente de estas herramientas se encuentra en el directorio executor, y los archivos binarios 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 Executor se comunica con el servicio de ejecución (execserver) en el dispositivo de destino.
Juntos, proporcionan funcionalidades como la recuperación de fallas en el 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: Cómo continuar una ejecución parcial de pruebas de OpenGL ES 2 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
Exporta y compara el registro de prueba en formato CSV
El deqp tiene una herramienta para convertir los registros de prueba (archivos .qpa) en archivos CSV. El resultado en formato CSV contiene una lista de casos de prueba y sus resultados. La herramienta también puede comparar dos o más resultados de lotes y enumerar solo los casos de prueba que tienen códigos de estado diferentes en los resultados de lotes de entrada. La comparación también imprimirá la cantidad de casos coincidentes.
El resultado en formato CSV es muy práctico para su posterior procesamiento con utilidades de línea de comandos estándar o con un editor de hojas de cálculo. Se puede seleccionar un formato de texto sin formato adicional y legible 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.csvtestlog-to-csv --value=details BatchResult.qpa > Result_statusdetails.csv
Ejemplo 2: Enumera las diferencias de los resultados de la prueba entre 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 del resultado de la prueba, como "Aprobada" o "Reprobada". 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.
Exportación de XML del registro de prueba
Los archivos de registro de pruebas 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 de
caselist.xmlse escriben en un directorio de destino - Modo de archivo único, en el que todos los resultados del archivo
.qpase escriben en un solo documento XML.
Los archivos de registro de pruebas exportados se pueden ver en un navegador con una hoja de estilo XML.
En el directorio doc/testlog-stylesheet, se proporcionan documentos de hojas de estilo de ejemplo (testlog.xsl y testlog.css). 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 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, solo apunta 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 ejecución de pruebas a partir de la salida de JUnit. Los archivos de registro de pruebas 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 de "aprobado" y "reprobado", un resultado de aprobación de deqp se asigna a "aprobado de JUnit", 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 prueba especiales
Es posible que algunos grupos de prueba necesiten o admitan opciones especiales de línea de comandos, o bien que requieran un cuidado especial cuando se usan en ciertos sistemas.
Pruebas de esfuerzo de asignación de memoria
Las pruebas de estrés de asignación de memoria ejercitan las condiciones de memoria insuficiente asignando ciertos recursos de forma repetida 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 detener el proceso de prueba en lugar de permitir que un controlador controle o proporcione un error de memoria insuficiente. En estas plataformas, las pruebas diseñadas para provocar errores de memoria insuficiente están inhabilitadas de forma predeterminada y se deben habilitar con el argumento de línea de comandos --deqp-test-oom=enable.
Te recomendamos que ejecutes estas pruebas de forma manual para verificar si el sistema se comporta correctamente bajo presión de recursos. Sin embargo, en tal situación, una falla en el proceso de prueba debe interpretarse como un éxito.
Grupos de prueba
dEQP-GLES2.stress.memory.* dEQP-GLES3.stress.memory.*
Pruebas de esfuerzo de renderización de larga duración
Las pruebas de estrés de renderización están diseñadas para revelar problemas de robustez bajo una carga de renderización sostenida. De forma predeterminada, las pruebas solo ejecutarán 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 inhabilitarse (--deqp-watchdog=disable) cuando se ejecuten estas pruebas durante un período prolongado.
Grupos de prueba
dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.*