AOSP incluye el conjunto de pruebas de GPU drawElements Quality Program (deqp) en https://android.googlesource.com/platform/external/deqp . Esta página detalla cómo implementar el conjunto de pruebas deqp en un nuevo entorno.
Para trabajar con el último código enviado, utilice la rama deqp-dev . Para el código que coincida con una versión específica de Android CTS, utilice la rama release-code-name -release (por ejemplo, para Android 6.0, utilice la rama marshmallow-release ).
Diseño de fuente
El diseño del código fuente para los módulos de prueba deqp y las bibliotecas de soporte se muestra en la siguiente tabla (la lista no es completa pero destaca los directorios más importantes).
| Directorio | Descripción |
|---|---|
android | Fuentes de prueba de Android y scripts de compilación |
data | Archivos de datos de prueba |
modules | Fuentes del módulo de prueba |
modules/egl | módulo EGL |
modules/gles2 | módulo GLES2 |
modules/gles3 | módulo GLES3 |
modules/gles31 | Módulo GLES3.1 |
modules/gles32 | Módulo GLES3.2 |
targets | Archivos de configuración de compilación específicos del objetivo |
framework | Marco y utilidades del módulo de prueba deqp. |
framework/delibs | Portabilidad básica y bibliotecas de compilación. |
framework/platform | Puertos de plataforma |
framework/qphelper | Biblioteca de integración del programa de prueba (C) |
framework/common | Marco deqp (C++) |
framework/opengl, framework/egl | Utilidades específicas de API |
execserver | Fuente ExecServer del lado del dispositivo |
executor | Utilidades y herramientas de shell del ejecutor de pruebas del lado del host |
external | Cree un directorio auxiliar para bibliotecas externas libpng y zlib |
Componentes de código abierto
El deqp usa libpng y zlib , que se pueden obtener usando el script platform/external/deqp/external/fetch_sources.py o mediante git desde platform/external/[libpng,zlib] .
Crear programas de prueba
El marco de prueba se ha diseñado teniendo en cuenta la portabilidad. Los únicos requisitos obligatorios son soporte completo de C++ y bibliotecas de sistema estándar para E/S, subprocesos y sockets.
Sistema de compilación CMake
Las fuentes deqp tienen scripts 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 IDE a partir de archivos de configuración independientes del destino. Para obtener más información sobre CMake, consulte la documentación de CMake .
CMake admite y recomienda compilaciones fuera del árbol fuente, es decir, siempre debe crear archivos MAKE o archivos de proyecto en un directorio de compilación separado fuera del árbol fuente. CMake no tiene ningún tipo de objetivo "distclean", por lo que la eliminación de cualquier archivo generado por CMake debe realizarse manualmente.
Las opciones de configuración se brindan a CMake usando la sintaxis -D OPTION_NAME = VALUE . Algunas opciones comúnmente utilizadas para deqp se enumeran a continuación.
| Opción de configuración | Descripción |
|---|---|
DEQP_TARGET | Nombre del destino, por ejemplo: "android" Los scripts deqp CMake incluirán el archivo |
CMAKE_TOOLCHAIN_FILE | Ruta al archivo de cadena de herramientas para CMake. Se utiliza para compilación cruzada. |
CMAKE_BUILD_TYPE | Tipo de compilación para objetivos de archivos MAKE. Los valores válidos son: "Depurar" y "Liberar" Tenga en cuenta que la interpretación y el tipo predeterminado dependen del sistema de compilación de destino. Consulte la documentación de CMake para obtener más detalles. |
Crear un archivo de compilación de destino
El sistema de compilación deqp está configurado para nuevos objetivos utilizando 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 utilizando el parámetro de compilación DEQP_TARGET .
Las rutas de los archivos de destino son relativas al directorio base deqp , no al directorio targets/ NAME . Las siguientes variables estándar se pueden configurar mediante el archivo de compilación de destino.
| Variable | Descripción |
|---|---|
DEQP_TARGET_NAME | Nombre del objetivo (se incluirá en los registros de prueba) |
DEQP_SUPPORT_GLES2 | Si se admite GLES2 (predeterminado: APAGADO) |
DEQP_GLES2_LIBRARIES | Bibliotecas GLES2 (déjelas vacías si no son compatibles o si se utiliza carga dinámica) |
DEQP_SUPPORT_GLES3 | Si se admite GLES3.x (predeterminado: APAGADO) |
DEQP_GLES3_LIBRARIES | Bibliotecas GLES3.x (déjelas vacías si no son compatibles o si se utiliza carga dinámica) |
DEQP_SUPPORT_VG | Si OpenVG es compatible (predeterminado: APAGADO) |
DEQP_OPENVG_LIBRARIES | Bibliotecas OpenVG (déjelas vacías si no son compatibles o si se utiliza carga dinámica) |
DEQP_SUPPORT_EGL | Si se admite EGL (predeterminado: APAGADO) |
DEQP_EGL_LIBRARIES | Bibliotecas EGL (déjelas vacías si no son compatibles o si se utiliza carga dinámica) |
DEQP_PLATFORM_LIBRARIES | Se requieren bibliotecas adicionales específicas de la plataforma para vincular |
DEQP_PLATFORM_COPY_LIBRARIES | Lista de bibliotecas que se copian en cada directorio de compilación binaria de prueba. Se puede utilizar para copiar bibliotecas necesarias para ejecutar pruebas pero que no se encuentran en la ruta de búsqueda predeterminada. |
TCUTIL_PLATFORM_SRCS | Lista de fuentes de puertos de plataforma. Las fuentes predeterminadas se determinan en función de las capacidades y el sistema operativo. Nota: Las rutas son relativas a: |
El archivo de compilación de destino puede agregar rutas de inclusión o vínculo adicionales utilizando las funciones CMake include_directories() y link_directories() .
compilación win32
La forma más sencilla de crear módulos deqp para Windows es utilizar el sistema de compilación CMake. Necesitará CMake 2.6.12 o posterior y el compilador Microsoft Visual C/C++. El deqp ha sido probado 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"
Se puede realizar una compilación de 64 bits seleccionando "Visual Studio VERSION Win64" como generador de compilación:
cmake path\to\src\deqp -G "Visual Studio 12 Win64"
También puede generar archivos MAKE 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 renderizado
El contexto de renderizado se puede crear con WGL o con EGL en Windows.
soporte WGL
Todos los archivos binarios de Win32 admiten la creación de contexto GL con WGL, ya que solo requiere bibliotecas estándar. El contexto WGL se puede seleccionar usando el argumento de línea de comando --deqp-gl-context-type=wgl . En el modo WGL, el deqp utiliza la extensión WGL_EXT_create_context_es_profile para crear contextos OpenGL ES. Se ha probado que funciona con los controladores más recientes de NVIDIA e Intel. Los controladores AMD no admiten la extensión requerida.
Soporte EGL
El deqp está creado 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 EGL disponibles, es posible ejecutar pruebas con ellas con el parámetro de línea de comando: --deqp-gl-context-type=egl
compilación de Android
La compilación de Android utiliza scripts de compilación de CMake para crear el código de prueba nativo. Las partes de Java, es decir, Test Execution Server y Test Application Stub, se compilan utilizando las herramientas de compilación estándar de Android.
Para compilar programas de prueba deqp para Android con los scripts de compilación proporcionados, necesitará:
- La última versión del NDK de Android ; el archivo
android/scripts/common.pyenumera la versión requerida - SDK independiente de Android con paquetes API 13, SDK Tools, SDK Platform-tools y SDK Build-tools instalados
- Apache Ant 1.9.4 (requerido por la compilación del código Java)
- CMake 2.8.12 o más reciente
- Python 2.6 o posterior en la serie 2.x; Python 3.x no es compatible
- 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 primordiales. La lógica está controlada por android/scripts/common.py .
El directorio NDK debe ser ~/android-ndk- VERSION o C:/android/android-ndk- VERSION o estar definido mediante 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 crean ejecutando el script android/scripts/build.py . El .apk final se crea en android/package/bin y se puede instalar mediante el script install.py . Si se utiliza el ejecutor de línea de comando , ExecService se inicia con el script launch.py en el dispositivo a través de ADB. Los scripts se pueden ejecutar desde cualquier directorio.
compilación de Linux
Se pueden crear archivos binarios de prueba y utilidades de línea de comandos para Linux generando archivos MAKE usando CMake. Existen varios objetivos de compilación predefinidos que son útiles al compilar para Linux.
| Objetivo de construcción | Descripción |
|---|---|
default | Destino predeterminado que utiliza la introspección de la plataforma CMake para determinar la compatibilidad con varias API. |
x11_glx | Utiliza GLX para crear contextos OpenGL (ES). |
x11_egl | Utiliza EGL para crear contextos OpenGL (ES). |
x11_egl_glx | Admite GLX y EGL con X11. |
Utilice siempre -DCMAKE_BUILD_TYPE=<Debug|Release> para definir el tipo de compilación. Release es un buen valor predeterminado. Sin él, se crea una versión de lanzamiento predeterminada y no optimizada.
Los argumentos de línea de comando -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 utiliza la arquitectura nativa de la cadena de herramientas, normalmente 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 una biblioteca adicional a CMake o incluya rutas de búsqueda.
Un ejemplo de una línea de comando completa utilizada para realizar una compilación de depuración de 32 bits en bibliotecas y encabezados de controladores en una ubicación personalizada es el siguiente:
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 utilizando un archivo de cadena de herramientas CMake. El archivo de cadena de herramientas especifica el compilador que se utilizará, junto con rutas de búsqueda personalizadas para bibliotecas y encabezados. Se incluyen varios archivos de cadena de herramientas para escenarios comunes en el paquete de lanzamiento en el directorio framework/delibs/cmake .
Además de las variables estándar de CMake, el archivo de cadena de herramientas puede configurar las siguientes variables específicas de deqp. CMake generalmente puede detectar DE_OS , DE_COMPILER y DE_PTR_SIZE correctamente, pero DE_CPU debe configurarse mediante el archivo de cadena de herramientas.
| Variable | Descripción |
|---|---|
DE_OS | Sistema operativo. Los valores admitidos son: |
DE_COMPILER | 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 cadena de herramientas se puede seleccionar utilizando el parámetro de compilación CMAKE_TOOLCHAIN_FILE . Por ejemplo, lo siguiente crearía archivos MAKE para una compilación utilizando 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
Enlace en tiempo de ejecución de bibliotecas GLES y EGL
El deqp no necesita puntos de entrada de la API bajo prueba durante la vinculación. El código de prueba siempre accede a las API a través de punteros de función. Luego, los puntos de entrada se pueden cargar dinámicamente en tiempo de ejecución o el puerto de la plataforma puede proporcionarlos en tiempo de enlace.
Si la compatibilidad con una API está activada en la configuración de compilación y no se proporcionan bibliotecas de enlaces, el deqp cargará los puntos de entrada necesarios en tiempo de ejecución. Si se desea el enlace estático, proporcione las bibliotecas de enlaces necesarias en la variable de configuración de compilación DEQP_<API>_LIBRARIES .
Portar el marco de prueba
La migración del deqp implica tres pasos: adaptar las bibliotecas de portabilidad base, implementar interfaces de integración de plataforma de marco de prueba y transferir el servicio de ejecución.
La siguiente tabla enumera las ubicaciones para posibles cambios de portabilidad. Todo lo que esté más allá de ellos probablemente resulte exótico.
| Ubicación | Descripción |
|---|---|
framework/delibs/debase | Cualquier implementación necesaria de código específico del sistema operativo. |
framework/qphelper/qpCrashHandler.c | Opcional: Implementación para su SO. |
framework/qphelper/qpWatchDog.c | Implementación para su SO. El actual se basa en |
framework/platform | Se pueden implementar un nuevo puerto de plataforma y código auxiliar de aplicación como se describe en Puerto de plataforma del marco de prueba . |
Bibliotecas de portabilidad base
Las bibliotecas de portabilidad base ya son compatibles con Windows, la mayoría de las variantes de Linux, Mac OS, iOS y Android. Si el objetivo de la prueba se ejecuta en uno de esos sistemas operativos, lo más probable es que no sea necesario tocar las bibliotecas de portabilidad base en absoluto.
Puerto de plataforma de marco de prueba
El puerto de plataforma del marco de prueba 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 plataforma, crear un objeto de línea de comando ( tcu::CommandLine ), abrir un registro de prueba ( tcu::TestLog ) e iterar la aplicación de prueba ( tcu::App ). Si el sistema operativo de destino admite un punto de entrada main() estándar, tcuMain.cpp se puede utilizar como implementación del punto de entrada.
La API de la plataforma deqp se describe en detalle en los siguientes archivos.
| Archivo | Descripción |
|---|---|
framework/common/tcuPlatform.hpp | Clase base para todos los puertos de plataforma |
framework/opengl/gluPlatform.hpp | Interfaz de plataforma OpenGL |
framework/egl/egluPlatform.hpp | Interfaz de plataforma EGL |
framework/platform/tcuMain.cpp | Punto de entrada de la aplicación estándar |
La clase base para todos los puertos de plataforma es tcu::Platform . El puerto de la plataforma puede admitir opcionalmente interfaces específicas de GL y EGL. Consulte 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 OpenGL (ES) | Interfaz de plataforma GL |
Módulo de prueba EGL | Interfaz de plataforma EGL |
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 utilizar 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. Se proporciona una implementación C++ portátil del servicio en el directorio execserver . El binario independiente se crea como parte del módulo de prueba deqp para objetivos de PC. Puede modificar execserver/CMakeLists.txt para habilitar una compilación en otros objetivos.
La versión C++ del servicio de ejecución de pruebas acepta dos parámetros de línea de comando:
-
--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.
ejecutar las pruebas
Esta página proporciona instrucciones para ejecutar pruebas de deqp en entornos Linux y Windows, utilizar argumentos de línea de comandos y trabajar con el paquete de aplicaciones de Android.
Entornos Linux y Windows
Comience copiando los siguientes archivos y directorios al destino.
| Módulo | Directorio | Objetivo |
|---|---|---|
| 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 GLES3 | build/modules/gles3/deqp-gles3 | <dst>/deqp-gles3 |
data/gles3 | <dst>/gles3 | |
| Módulo 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 |
Puede implementar el servicio de ejecución y probar los binarios en cualquier lugar del sistema de archivos de destino; sin embargo, los binarios de prueba esperan encontrar directorios de datos en el directorio de trabajo actual. Cuando esté listo, inicie el servicio de ejecución de pruebas en el dispositivo de destino. Para obtener detalles sobre cómo iniciar el servicio, consulte Servicio de ejecución de pruebas .
Argumentos de la línea de comando
La siguiente tabla enumera los argumentos de la línea de comando que afectan la ejecución de todos los programas de prueba.
| Argumento | Descripción |
|---|---|
--deqp-case=<casename> | Ejecute casos que coincidan con un patrón determinado. Se admite el comodín (*). |
--deqp-log-filename=<filename> | Escriba los resultados de la prueba en el archivo cuyo nombre proporcione. El servicio de ejecución de pruebas establecerá el nombre del archivo al iniciar una prueba. |
--deqp-stdin-caselist | Lea la lista de casos de la entrada estándar o de un argumento determinado. El servicio de ejecución de prueba establecerá el argumento según la solicitud de ejecución recibida. Consulte la siguiente sección para obtener una descripción del formato de lista de casos. |
--deqp-test-iteration-count=<count> | Anule el recuento de iteraciones para las pruebas que admiten un número variable de iteraciones. |
--deqp-base-seed=<seed> | Semilla base para los casos de prueba que utilizan aleatorización. |
Argumentos específicos de GLES2 y GLES3
La siguiente tabla enumera los argumentos específicos de GLES2 y GLES3.| Argumento | Descripción |
|---|---|
--deqp-gl-context-type=<type> | Tipo de contexto OpenGL. Los tipos de contexto disponibles dependen de la plataforma. En plataformas que admiten EGL, el valor egl se puede utilizar para seleccionar el contexto EGL. |
--deqp-gl-config-id=<id> | Ejecute pruebas para el ID de configuración GL proporcionado. La interpretación depende de la plataforma. En la plataforma EGL, este es el ID de configuración de EGL. |
--deqp-gl-config-name=<name> | Ejecute pruebas para una configuración GL con nombre. La interpretación depende de la plataforma. Para EGL, el formato es rgb(a)<bits>d<bits>s<bits> . Por ejemplo, un valor de rgb888s8 seleccionará la primera configuración donde el búfer de color es RGB888 y el búfer de plantilla tiene 8 bits. |
--deqp-gl-context-flags=<flags> | Crea un contexto. Especifique robust o debug . |
--deqp-surface-width=<width> | Intenta crear una superficie con un tamaño determinado. El soporte para esto es opcional. |
--deqp-surface-type=<type> | Utilice un tipo de superficie determinado como objetivo principal de renderizado de la prueba. Los tipos posibles son window , pixmap , pbuffer y fbo . |
--deqp-screen-rotation=<rotation> | Orientación de la pantalla en incrementos de 90 grados para plataformas que la admitan. |
Formato de lista de casos de prueba
La lista de casos de prueba se puede presentar 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 resultar engorrosos. Para evitar repetir los prefijos, utilice la sintaxis trie (también conocida como árbol de prefijos) que 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
Androide
El paquete de la aplicación de Android contiene todos los componentes necesarios, incluido el servicio de ejecución de pruebas, los archivos binarios de prueba y los archivos de datos. La actividad de prueba es una NativeActivity que usa EGL (requiere Android 3.2 o superior).
El paquete de la aplicación se puede instalar con el siguiente comando (el nombre que se muestra es el nombre del APK en el paquete CTS de Android; cuyo nombre depende de la compilación):
adb –d install –r com.drawelements.deqp.apk
Para iniciar el servicio de ejecución de prueba y configurar el reenvío de puertos, utilice lo siguiente:
adb –d forward tcp:50016 tcp:50016adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter
Las impresiones de depuración se pueden habilitar ejecutando lo siguiente antes de comenzar las pruebas:
adb –d shell setprop log.tag.dEQP DEBUG
Ejecutar pruebas en Android sin Android CTS
Para iniciar manualmente la actividad de ejecución de prueba, cree una intención de Android dirigida a android.app.NativeActivity . Las actividades se pueden encontrar en el paquete com.drawelements.deqp . La línea de comando debe proporcionarse 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 comienza normalmente, hay información de depuración adicional disponible en el registro del dispositivo.
Puede iniciar una actividad desde la línea de comando usando la utilidad am . Por ejemplo, para ejecutar pruebas dEQP-GLES2.info en una plataforma que admita NativeActivity, utilice 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"'
Depurar en Android
Para ejecutar las pruebas bajo el depurador GDB en Android, primero compile e instale la compilación de depuración ejecutando los dos scripts siguientes:
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 ejecutándose en el host, ejecute 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 comando deqp depende de los casos de prueba que se ejecutarán y otros parámetros requeridos. El script agrega un punto de interrupción predeterminado al comienzo de la ejecución de deqp ( tcu::App::App ).
El script debug.py acepta múltiples argumentos de línea de comando para acciones como establecer puntos de interrupción para la depuración, parámetros de conexión de gdbserver y rutas a archivos binarios adicionales para depurar (use debug.py --help para todos los argumentos y explicaciones). El script también copia algunas bibliotecas predeterminadas del dispositivo de destino para obtener listados de símbolos.
Para recorrer el código del controlador (por ejemplo, cuando el GDB necesita conocer las ubicaciones de los archivos binarios con información de depuración completa), agregue más bibliotecas a través de los parámetros de la línea de comando debug.py . Este script escribe un archivo de configuración para GDB a partir de la línea 132 del archivo de script. Puede proporcionar rutas adicionales a archivos binarios, etc., pero proporcionar los parámetros correctos de la línea de comando debería ser suficiente.
Nota: En Windows, el binario GDB requiere libpython2.7.dll . Antes de iniciar debug.py , agregue <path-to-ndk>/prebuilt/windows/bin a la variable PATH.
Nota: la depuración de código nativo no funciona en Android 4.3; Para encontrar soluciones alternativas, consulte este error público . Android 4.4 y superiores no contienen este error.
Automatizar las pruebas
Los módulos de prueba de Deqp se pueden integrar a sistemas de prueba automatizados de múltiples 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 es siempre 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 prueba. La salida de la consola es solo información de depuración y es posible que no esté disponible en todas las plataformas.
Los binarios de prueba se pueden invocar directamente desde un sistema de automatización de pruebas. El 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 fatal durante la ejecución (como ciertos errores de API o un bloqueo), la ejecución de la prueba se cancelará. Para las pruebas de regresión, el mejor enfoque es invocar los binarios de prueba para casos individuales o pequeños conjuntos de pruebas por separado, para tener resultados parciales disponibles incluso en caso de una falla grave.
El deqp viene con 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 terminación del proceso de prueba y reanudará la ejecución de la prueba en el siguiente caso disponible. Se genera un único archivo de registro a partir de la sesión de prueba completa. Esta configuración es ideal para sistemas de prueba livianos que no brindan funciones de recuperación ante fallas.
Herramientas de ejecución de pruebas de línea de comando
El conjunto de herramientas de línea de comandos actual incluye una herramienta de ejecución remota de pruebas, un generador de comparación de registros de pruebas para análisis de regresión, un conversor de registros de pruebas a CSV, un conversor de registros de pruebas a XML y un conversor de registros de pruebas a JUnit. .
El código fuente de estas herramientas está en el directorio executor y los binarios están integrados en el directorio <builddir>/executor .
Ejecutor de prueba de línea de comando
El ejecutor de prueba de línea de comando 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 (servidor ejecutivo) en el dispositivo de destino. Juntos proporcionan funcionalidades como la recuperación de fallas en el proceso de prueba. Los siguientes ejemplos demuestran cómo usar la línea de comando Test Executor (use --help para más detalles):
Ejemplo 1: ejecutar 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: continuar ejecutando una prueba parcial de OpenGL ES 2 localmente
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
Registro de prueba, exportación CSV y comparación
El deqp tiene una herramienta para convertir registros de prueba (archivos qpa ) en archivos CSV. La salida 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 del lote de entrada. La comparación también imprimirá el número de casos coincidentes.
La salida en formato CSV es muy práctica 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 plano adicional, legible por humanos, utilizando el siguiente argumento de línea de comando: --format=text
Ejemplo 1: exportar 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: enumerar las diferencias de los resultados de las pruebas entre dos registros de pruebas
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 "Pasa" o "Falla". El argumento --value=details selecciona la explicación adicional del resultado o valor numérico producido por una prueba de rendimiento, capacidad o precisión.
Exportación XML del registro de prueba
Los archivos de registro de prueba se pueden convertir en documentos XML válidos utilizando la utilidad testlog-to-xml . Se admiten dos modos de salida:
- Modo de documentos separados, donde cada caso de prueba y el documento de resumen
caselist.xmlse escriben en un directorio de destino - Modo de archivo único, donde todos los resultados del archivo
.qpase escriben en un único documento XML.
Los archivos de registro de pruebas exportados se pueden ver en un navegador utilizando 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 representar los archivos de registro en un navegador, copie los dos archivos de hojas de estilo en el mismo directorio donde se encuentran los documentos XML exportados.
Si está utilizando Google Chrome, se debe acceder a los archivos a través de HTTP, ya que Chrome limita el acceso a los archivos locales por razones de seguridad. La instalación estándar de Python incluye un servidor HTTP básico que se puede iniciar para servir el directorio actual con el comando python –m SimpleHTTPServer 8000 . Después de iniciar el servidor, simplemente apunte el navegador Chrome a http://localhost:8000 para ver el registro de prueba.
Conversión a un registro de prueba 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 prueba de deqp se pueden convertir al formato de salida JUnit utilizando la herramienta testlog-to-junit.
Actualmente, la herramienta solo admite la traducción del veredicto del caso de prueba. Como JUnit solo admite resultados "aprobado" y "reprobado", un resultado aprobado del deqp se asigna a "aprobado JUnit" y otros resultados se consideran fallidos. El código de resultado de deqp original está disponible en la salida de JUnit. Otros datos, como mensajes de registro e imágenes de resultados, no se conservan en la conversión.
Utilice grupos de prueba especiales
Algunos grupos de prueba pueden necesitar o admitir opciones especiales de línea de comandos, o requerir cuidados especiales cuando se usan en ciertos sistemas.
Pruebas de estrés de asignación de memoria
Las pruebas de estrés de asignación de memoria ejercitan condiciones de falta de memoria asignando repetidamente ciertos recursos hasta que el controlador informa un error de falta de memoria.
En determinadas 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 maneje o proporcione un error de falta de memoria. En dichas plataformas, las pruebas diseñadas para causar errores de falta de memoria están deshabilitadas de forma predeterminada y deben habilitarse usando el argumento de línea de comando --deqp-test-oom=enable . Se recomienda ejecutar dichas pruebas manualmente para comprobar si el sistema se comporta correctamente bajo presión de recursos. Sin embargo, en tal situación, una falla del proceso de prueba debe interpretarse como un paso.
Grupos de prueba
dEQP-GLES2.stress.memory.* dEQP-GLES3.stress.memory.*
Pruebas de estrés de renderizado de larga duración
Las pruebas de estrés de renderizado están diseñadas para revelar problemas de robustez bajo una carga de renderizado sostenida. De forma predeterminada, las pruebas ejecutarán solo unas pocas iteraciones, pero se pueden configurar para que se ejecuten indefinidamente proporcionando el argumento de línea de comando --deqp-test-iteration-count=-1 . El mecanismo de vigilancia de pruebas debe estar deshabilitado ( --deqp-watchdog=disable ) cuando se ejecutan estas pruebas durante un período de tiempo prolongado.
Grupos de prueba
dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.*
El contenido y el código de ejemplo de esta página están sujetos a las licencias que se describen en la licencia de contenido. Java y OpenJDK son marcas registradas de Oracle o sus entidades asociadas.
Última actualización: 2024-03-18 (UTC).