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, use la rama deqp-dev . Para el código que coincida con una versión específica de Android CTS, use la rama release-code-name -release (por ejemplo, para Android 6.0, use 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 apoyo se muestra en la siguiente tabla (la lista no es exhaustiva 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 de destino |
framework | framework y utilidades del módulo de prueba deqp |
framework/delibs | Portabilidad básica y compilar bibliotecas |
framework/platform | Puertos de plataforma |
framework/qphelper | Biblioteca de integración de programas de prueba (C) |
framework/common | Marco Deqp (C++) |
framework/opengl, framework/egl | Utilidades específicas de la API |
execserver | Fuente ExecServer del lado del dispositivo |
executor | Herramientas y utilidades de shell del ejecutor de pruebas del lado del host |
external | Cree el directorio stub 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 a través de git desde platform/external/[libpng,zlib] .
Creación de programas de prueba
El marco de prueba se ha diseñado pensando en la portabilidad. Los únicos requisitos obligatorios son compatibilidad total con C++ y bibliotecas de sistema estándar para E/S, subprocesos y sockets.
Sistema de compilación CMake
Las fuentes de 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 de código fuente, es decir, siempre debe crear archivos MAKE o archivos de proyecto en un directorio de compilación separado fuera del árbol de código fuente. CMake no tiene ningún tipo de objetivo de "limpieza de disco", por lo que la eliminación de cualquier archivo generado por CMake debe realizarse manualmente.
Las opciones de configuración se dan a CMake usando -D OPTION_NAME = VALUE . Algunas opciones de uso común para deqp se enumeran a continuación.
| Opción de configuración | Descripción |
|---|---|
DEQP_TARGET | Nombre de destino, por ejemplo: "android" Los scripts de deqp CMake incluirán el archivo |
CMAKE_TOOLCHAIN_FILE | Ruta al archivo de la cadena de herramientas para CMake. Se utiliza para la 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 información. |
Creación de un archivo de compilación de destino
El sistema de compilación deqp se configura para nuevos destinos mediante 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 mediante el parámetro de compilación DEQP_TARGET .
Las rutas de archivo en los archivos de destino son relativas al directorio base deqp , no al directorio de targets/ NAME . Las siguientes variables estándar se pueden establecer 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 en blanco si no se admiten o si se utiliza la carga dinámica) |
DEQP_SUPPORT_GLES3 | Si se admite GLES3.x (predeterminado: APAGADO) |
DEQP_GLES3_LIBRARIES | Bibliotecas GLES3.x (déjelas en blanco si no se admiten o si se utiliza la carga dinámica) |
DEQP_SUPPORT_VG | Si se admite OpenVG (predeterminado: APAGADO) |
DEQP_OPENVG_LIBRARIES | Bibliotecas OpenVG (déjelas en blanco si no se admiten o si se utiliza la carga dinámica) |
DEQP_SUPPORT_EGL | Si se admite EGL (predeterminado: APAGADO) |
DEQP_EGL_LIBRARIES | Bibliotecas EGL (déjelas en blanco si no se admiten o si se utiliza la 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 binario de prueba. Se puede usar para copiar bibliotecas que se necesitan para ejecutar pruebas pero que no están en la ruta de búsqueda predeterminada. |
TCUTIL_PLATFORM_SRCS | Lista de fuentes de puertos de plataforma. Las fuentes predeterminadas se determinan según las capacidades y el sistema operativo. Nota: las rutas son relativas a: |
El archivo de compilación de destino puede agregar rutas de enlace o de inclusión adicionales mediante las funciones de CMake include_directories() y link_directories() .
compilación Win32
La forma más fácil de compilar módulos deqp para Windows es usar 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 makefiles 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 representación
El contexto de representación se puede crear con WGL o con EGL en Windows.
soporte WGL
Todos los 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 mediante el argumento de línea de comando --deqp-gl-context-type=wgl . En el modo WGL, el deqp usa 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 de AMD no admiten la extensión necesaria.
soporte EGL
El deqp está construido 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 compilar el código de prueba nativo. Las partes de Java, es decir, el servidor de ejecución de pruebas y el código auxiliar de la aplicación de prueba, 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 de Android NDK ; el archivo
android/scripts/common.pyenumera la versión requerida - SDK independiente de Android con API 13, SDK Tools, SDK Platform-tools y SDK Build-tools paquetes 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 en función de la variable de entorno PATH con ciertos valores predeterminados anulados. 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 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 crean mediante la ejecución de la android/scripts/build.py . El .apk final se crea en android/package/bin y puede instalarse mediante el script install.py . Si se utiliza el ejecutor de la línea de comandos , 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
Los binarios de prueba y las utilidades de línea de comandos se pueden crear para Linux generando archivos MAKE con CMake. Hay múltiples objetivos de compilación predefinidos que son útiles al compilar para Linux.
| Objetivo de compilació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 tanto GLX como 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 realiza una compilación de versión 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 hacer una compilación de depuración de 32 bits contra encabezados y bibliotecas 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 mediante el uso de un archivo de cadena de herramientas de CMake. El archivo de cadena de herramientas especifica el compilador a usar, junto con rutas de búsqueda personalizadas para bibliotecas y encabezados. Varios archivos de cadena de herramientas para escenarios comunes se incluyen 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 establecer 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 cadena de herramientas debe configurar DE_CPU .
| 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 la cadena de herramientas se puede seleccionar mediante 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
Vinculación en tiempo de ejecución de las 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. Los puntos de entrada se pueden cargar dinámicamente en tiempo de ejecución o el puerto de la plataforma puede proporcionarlos en el momento del 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 enlace necesarias en la variable de configuración de compilación DEQP_<API>_LIBRARIES .
Portar el marco de prueba
Portar el deqp implica tres pasos: adaptar las bibliotecas de portabilidad base, implementar interfaces de integración de plataforma de marco de prueba y portar el servicio de ejecución.
La siguiente tabla enumera las ubicaciones de los posibles cambios de portabilidad. Es probable que cualquier cosa más allá de ellos sea exótico.
| Ubicación | Descripción |
|---|---|
framework/delibs/debase | Cualquier implementación necesaria del código específico del sistema operativo. |
framework/qphelper/qpCrashHandler.c | Opcional: Implementación para su sistema operativo. |
framework/qphelper/qpWatchDog.c | Implementación para su sistema operativo. El actual se basa en |
framework/platform | El nuevo puerto de plataforma y el código auxiliar de la aplicación se pueden implementar 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 prueba se ejecuta en uno de esos sistemas operativos, lo más probable es que no haya necesidad de tocar las bibliotecas de portabilidad base en absoluto.
Puerto de la plataforma del marco de prueba
El puerto de la plataforma del marco de prueba 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 plataforma, crear un objeto de línea de comandos ( 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 usar como implementación del punto de entrada.
La API de la plataforma deqp se describe en detalle en los siguientes archivos.
| Expediente | 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 de la aplicación estándar |
La clase base para todos los puertos de la 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 debe implementarse para ejecutar las pruebas.
| Módulo | Interfaz |
|---|---|
Módulos de prueba OpenGL (ES) | interfaz de la plataforma GL |
Módulo de prueba EGL | Interfaz de la plataforma EGL |
Las instrucciones detalladas para implementar puertos de plataforma se encuentran en los encabezados de la capa de puertos.
Servicio de ejecución de pruebas
Para utilizar la infraestructura de ejecución de pruebas 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 de la compilación del módulo de prueba deqp para objetivos de PC. Puede modificar execserver/CMakeLists.txt para habilitar una compilación en otros destinos.
La versión 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. -
--singleterminará 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.
Ejecutando las pruebas
Esta página proporciona instrucciones para ejecutar pruebas deqp en entornos Linux y Windows, usar 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 en el 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 archivos binarios en cualquier parte 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 línea de comando
La siguiente tabla enumera 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> | 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 de archivo al iniciar una prueba. |
--deqp-stdin-caselist | Lee la lista de casos desde stdin o desde un argumento dado. El servicio de ejecución de prueba establecerá el argumento de acuerdo con la solicitud de ejecución recibida. Consulte la siguiente sección para obtener una descripción del formato de la 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 la 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 compatibles con 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 de 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 de 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> | Use un tipo de superficie dado como el principal objetivo de renderizado de prueba. Los tipos posibles son window , pixmap , pbuffer y fbo . |
--deqp-screen-rotation=<rotation> | Orientación de 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 dar en dos formatos. La primera opción es listar 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
Ejecución de pruebas en Android sin Android CTS
Para iniciar manualmente la actividad de ejecución de la prueba, crea una intención de Android que se dirija 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 la prueba no se inicia normalmente, hay información de depuración adicional disponible en el registro del dispositivo.
Puede iniciar una actividad desde la línea de comandos utilizando la utilidad am . Por ejemplo, para ejecutar pruebas de dEQP-GLES2.info en una plataforma compatible con NativeActivity, use 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"'
Depuración en Android
Para ejecutar las pruebas con el depurador GDB en Android, primero compile e instale la compilación de depuración ejecutando los siguientes dos scripts:
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 ejecutan 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 a ejecutar 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 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 a 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 listas de símbolos.
Para recorrer el código del controlador (como cuando el GDB necesita conocer las ubicaciones de los archivos binarios con información completa de depuración), agregue más bibliotecas a través de los parámetros de la línea de comandos 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 de línea de comando correctos 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 estándar; para obtener soluciones, consulte este error público . Android 4.4 y versiones posteriores no contienen este error.
Automatización de las pruebas
Los módulos de prueba de Deqp se pueden integrar a los sistemas de prueba automatizados de varias maneras. El mejor enfoque depende de la infraestructura de prueba existente y el 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 prueba o para todas las pruebas disponibles. Si ocurre 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 prueba por separado, para tener disponibles resultados parciales incluso en caso de falla grave.
El deqp viene con herramientas de ejecución de prueba 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 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 instalaciones 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 prueba remota, un generador de comparación de registro de prueba para análisis de regresión, un convertidor de registro de prueba a CSV, un convertidor de registro de prueba a XML y un convertidor de registro de prueba a JUnit .
El código fuente de estas herramientas está en el directorio del executor y los archivos binarios están integrados en el <builddir>/executor .
Ejecutor de prueba de línea de comando
La línea de comandos Test Executor 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, brindan funciones 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 obtener más detalles):
Ejemplo 1: Ejecutar pruebas funcionales 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úe con una ejecución de 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
Pruebe la exportación de CSV del registro y compare
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 diferentes códigos de estado en los resultados de lotes 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 adicional de texto sin formato, legible por humanos, utilizando el siguiente argumento de línea de comando: --format=text
Ejemplo 1: exportar 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 de resultado de la prueba, como "Pass" o "Fail". 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 de registro de prueba
Los archivos de registro de prueba se pueden convertir en documentos XML válidos mediante la 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 en el archivo
.qpase escriben en un único documento XML.
Los archivos de registro de prueba exportados se pueden ver en un navegador utilizando una hoja de estilo XML. Los documentos de hoja de estilo de muestra ( testlog.xsl y testlog.css ) se proporcionan 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 atender 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 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 de "aprobación" y "falla", un resultado de aprobación de deqp se asigna a "Junit pass" y otros resultados se consideran fallas. 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.
Uso de grupos de prueba especiales
Algunos grupos de prueba pueden necesitar o admitir opciones de línea de comando especiales, o requieren un cuidado especial cuando se usan en ciertos sistemas.
Pruebas de estrés de asignación de memoria
Las pruebas de esfuerzo de asignación de memoria ejercen condiciones de falta de memoria mediante la asignación repetida de ciertos recursos hasta que el controlador informa un error de falta de memoria.
En ciertas plataformas, como Android y la mayoría de las variantes de Linux, puede ocurrir lo siguiente: El sistema operativo puede eliminar 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 que están diseñadas para causar errores de falta de memoria están deshabilitadas de forma predeterminada y deben habilitarse mediante el argumento de línea de comando --deqp-test-oom=enable . Se recomienda ejecutar dichas pruebas manualmente para verificar si el sistema se comporta correctamente bajo la presión de los recursos. Sin embargo, en tal situación, un bloqueo del proceso de prueba debe interpretarse como una aprobación.
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 perro guardián de la prueba debe estar deshabilitado ( --deqp-watchdog=disable ) cuando se ejecutan estas pruebas durante un largo período de tiempo.
Grupos de prueba
dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.*
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2022-08-03 (UTC)