AOSP incluye el paquete de pruebas de GPU del programa de calidaddrawElements (deqp), en https://android.googlesource.com/platform/external/deqp. En esta página, se detalla cómo implementar el paquete de pruebas de deqp en un entorno nuevo.
Para trabajar con el código enviado más reciente, usa la rama deqp-dev.
Para código que coincide con una versión específica del CTS de Android, usa el
Rama release-code-name-release (p.ej., para Android 6.0,
usa la rama marshmallow-release).
Diseño de origen
El diseño del código fuente para los módulos de prueba de deqp y las bibliotecas compatibles es se muestra en la siguiente tabla (la lista no es exhaustiva, pero destaca directorios más importantes).
| Directorio | Descripción |
|---|---|
android |
Fuentes de los verificadores de Android y secuencias de comandos de compilación |
data |
Cómo probar archivos de datos |
modules |
Fuentes de módulos 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 destino |
framework |
Utilidades y marco de trabajo del módulo de prueba de deqp |
framework/delibs |
Portabilidad base y bibliotecas de compilación |
framework/platform |
Puertos de plataforma |
framework/qphelper |
Biblioteca de integración de programas de prueba (C) |
framework/common |
Framework de deqp (C++) |
framework/opengl, framework/egl |
Utilidades específicas de API |
execserver |
Fuente ExecServer del dispositivo |
executor |
Utilidades y herramienta de shell del ejecutor de pruebas del lado del host |
external |
Directorio de stub de compilación para bibliotecas externas, libpng y zlib |
Componentes de código abierto
La deqp usa libpng y zlib, que se pueden recuperar.
usando la secuencia de comandos
platform/external/deqp/external/fetch_sources.py o con Git
desde platform/external/[libpng,zlib].
Crea programas de prueba
El framework de prueba se diseñó teniendo en cuenta la portabilidad. El único obligatorios son la compatibilidad total con C++ y las bibliotecas de sistema estándar para E/S, subprocesos y sockets.
Sistema de compilación de CMake
Las fuentes deqp tienen secuencias de comandos de compilación para CMake, que es la herramienta recomendada para compilando los programas de prueba.
CMake es un sistema de compilación de código abierto que admite varias plataformas y cadenas de herramientas. CMake genera archivos makefile nativos o de proyecto IDE desde archivos de configuración independientes del destino. Para obtener más información sobre CMake, consulta la CMake.
CMake admite y recomienda compilaciones de árbol de origen, es decir, debes Siempre debes crear archivos makefile o de proyecto en un directorio de compilación independiente. fuera del árbol de fuentes. CMake no tiene ningún tipo de "limpieza" objetivo, por lo que quitar cualquier archivo generado por CMake debe realizarse de forma manual.
Se proporcionan opciones de configuración a CMake mediante -DOPTION_NAME=VALUE.
sintaxis. A continuación, se enumeran algunas opciones de uso general para deqp.
| Opción de configuración | Descripción |
|---|---|
DEQP_TARGET |
Nombre del destino (por ejemplo, "android") Las secuencias de comandos de deqp de CMake incluirán el archivo
|
CMAKE_TOOLCHAIN_FILE |
Es la ruta de acceso al archivo de la cadena de herramientas para CMake. Se usa para compilación cruzada. |
CMAKE_BUILD_TYPE |
Tipo de compilación para destinos del archivo Make. Los valores válidos son "Debug" y "Lanzar" Ten en cuenta que la interpretación y el tipo predeterminado dependen del sistema de compilación de destino. Consulta la documentación de CMake para obtener más información. |
Cómo crear un archivo de compilación de destino
El sistema de compilación deqp se configura para objetivos nuevos mediante archivos de compilación de destino.
Un archivo de compilación de destino define qué funciones admite la plataforma y qué bibliotecas o
se requieren rutas de inclusión adicionales. Los nombres de los archivos de destino siguen el targets/NAME/NAME.cmake
y el destino se selecciona con el parámetro de compilación DEQP_TARGET.
Las rutas de acceso a los archivos de destino son relativas al directorio base deqp, no al
targets/NAME. El archivo de compilación de destino puede establecer las siguientes variables estándar.
| Variable | Descripción |
|---|---|
DEQP_TARGET_NAME |
Nombre del destino (se incluirá en los registros de prueba) |
DEQP_SUPPORT_GLES2 |
Si se admite GLES2 (configuración predeterminada: OFF) |
DEQP_GLES2_LIBRARIES |
Bibliotecas GLES2 (dejar este campo vacío si no son compatibles o si se usa la carga dinámica) |
DEQP_SUPPORT_GLES3 |
Si se admite GLES3.x (configuración predeterminada: OFF) |
DEQP_GLES3_LIBRARIES |
Bibliotecas GLES3.x (dejar este campo vacío si no son compatibles o si se usa la carga dinámica) |
DEQP_SUPPORT_VG |
Si se admite OpenVG (configuración predeterminada: OFF) |
DEQP_OPENVG_LIBRARIES |
Bibliotecas OpenVG (dejar este campo vacío si no se admite o si se usa la carga dinámica) |
DEQP_SUPPORT_EGL |
Si EGL es compatible (configuración predeterminada: OFF) |
DEQP_EGL_LIBRARIES |
Bibliotecas EGL (dejar vacío si no son compatibles 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 |
Lista de bibliotecas que se copian en cada directorio de compilación de objeto binario de prueba. Puede ser se usan para copiar bibliotecas que son necesarias para ejecutar pruebas, pero que no están predeterminadas. ruta de búsqueda. |
TCUTIL_PLATFORM_SRCS |
Lista de orígenes de puertos de plataforma. Las fuentes predeterminadas se determinan según el capacidades y SO. Nota: Las rutas de acceso se relacionan con lo siguiente: |
El archivo de compilación de destino puede agregar rutas de inclusión o vínculos adicionales con el
Funciones de CMake include_directories() y link_directories()
Compilación de Win32
La forma más sencilla de compilar módulos deqp para Windows es usar la compilación de CMake en un sistema de archivos. Necesitarás CMake 2.6.12 o una versión más reciente y Microsoft Visual C/C++ compilador. La deqp se probó con Visual Studio 2013.
Los archivos de proyecto de Visual Studio se pueden generar con el siguiente comando:
cmake path\to\src\deqp -G "Visual Studio 12"
Para crear una compilación de 64 bits, selecciona “Visual Studio VERSION Win64”. que la compilación generador:
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".
como el tipo de compilación (-DCMAKE_BUILD_TYPE="Debug" o "Release").
Creación de contextos de renderización
El contexto de renderización se puede crear con WGL o con EGL en Windows.
Compatibilidad con WGL
Todos los binarios Win32 admiten la creación del contexto de GL con WGL, ya que solo se requiere
las bibliotecas estándar. El contexto WGL se puede seleccionar usando el --deqp-gl-context-type=wgl.
argumento de línea de comandos. En el modo WGL, la deqp usa el WGL_EXT_create_context_es_profile.
para crear contextos de OpenGL ES. Se probó que funciona con
los controladores más recientes de Intel y NVIDIA. Los controladores AMD no admiten
.
Compatibilidad con EGL
La deqp se compila con carga dinámica para EGL en Windows si DEQP_SUPPORT_EGL
está ACTIVADO. Esta es la configuración predeterminada en la mayoría de los destinos. Entonces, si el host tiene bibliotecas EGL
disponibles, es posible ejecutar pruebas con ellos con la línea de comandos
parámetro: --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 prueba y el código auxiliar de la aplicación de prueba, se compilada con las herramientas de compilación estándar de Android.
Puedes compilar programas de prueba de deqp para Android con la compilación proporcionada. secuencias de comandos, necesitarás lo siguiente:
- La versión más reciente del
NDK de Android; el archivo
android/scripts/common.pyenumera la versión requerida - El SDK independiente de Android con la API 13, las herramientas del SDK, las herramientas de la plataforma del SDK y el SDK Paquetes de herramientas de compilación instalados
- Apache Ant 1.9.4 (requerido por la compilación de código Java)
- CMake 2.8.12 o una versión 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: La marca Ninja también es compatible con Linux
Los objetos binarios Ant y SDK se ubican según la variable de entorno PATH con
determinados valores 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 definido a través de ANDROID_NDK_PATH
variable de entorno.
Los componentes de Deqp en el dispositivo, el servicio de ejecución de prueba y los programas de prueba
Se compila ejecutando la secuencia de comandos android/scripts/build.py. El .apk final se crea en
android/package/bin y se puede instalar con la secuencia de comandos install.py. Si el botón
ejecutador de línea de comandos, se inicia ExecService
con la secuencia de comandos launch.py en el dispositivo a través de ADB Las secuencias de comandos se pueden ejecutar desde cualquier directorio.
Compilación de Linux
Se pueden compilar objetos binarios de prueba y utilidades de línea de comandos para Linux mediante la generación de archivos makefile con CMake. Existen varios objetivos de compilación predefinidos que son útiles cuando se compila para Linux.
| Objetivo de compilación | Descripción |
|---|---|
default |
Destino predeterminado que usa la introspección de la plataforma 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 |
Es compatible con 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 ella, 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
que se usa para pasar argumentos adicionales al compilador. Por ejemplo, la compilación para 32 o 64 bits se puede realizar
configurando -DCMAKE_C(XX)_FLAGS="-m32" o "-m64", respectivamente. Si no es así
especificado, se usa la arquitectura nativa del conjunto de herramientas, generalmente de 64 bits en el de 64 bits.
Se pueden usar los argumentos -DCMAKE_LIBRARY_PATH y -DCMAKE_INCLUDE_PATH.
para CMake otorgar biblioteca adicional a CMake o incluir rutas de búsqueda.
Ejemplo de una línea de comandos completa que se usa para realizar una compilación de depuración de 32 bits en los encabezados y las bibliotecas del controlador en una ubicación personalizada es lo 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 realizar con un archivo de la cadena de herramientas de CMake. La cadena de herramientas
especifica el compilador que se debe usar, junto con rutas de búsqueda personalizadas para
bibliotecas y encabezados. Hay varios archivos de cadenas de herramientas para situaciones comunes:
Se incluye en el paquete de lanzamiento en el directorio framework/delibs/cmake.
Además de las variables estándar de CMake, las siguientes variables específicas de deqp
se puede establecer con el archivo de la cadena de herramientas. Por lo general, CMake puede detectar DE_OS y DE_COMPILER.
y DE_PTR_SIZE correctamente, pero DE_CPU debe configurarse a través del archivo de la cadena de herramientas.
| Variable | Descripción |
|---|---|
DE_OS |
Sistema operativo Los valores admitidos son los siguientes: |
DE_COMPILER |
Tipo de compilador. Los valores admitidos son los siguientes: |
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, lo siguiente crearía archivos makefile para una compilación mediante el compilador cruzado de CodeSourcery para ARM/Linux:
cmake PATH_TO_SRC/deqp –DDEQP_BUILD_TYPE="Release" –DCMAKE_TOOLCHAIN_FILE=PATH_TO_SRC/delibs/cmake/toolchain-arm-cs.cmake –DARM_CC_BASE=PATH_TO_CC_DIRECTORY
Vinculación del entorno de ejecución de bibliotecas GLES y EGL
La deqp no necesita puntos de entrada de la API que se está probando durante la vinculación. El El código de prueba siempre accede a las APIs a través de punteros de función. Los puntos de entrada pueden se cargan de forma dinámica en el tiempo de ejecución o el puerto de la plataforma puede hora de vinculación.
Si la compatibilidad para una API está activada en la configuración de la compilación y en las bibliotecas de vínculos,
Si no se proporciona, la deqp cargará los puntos de entrada necesarios en el tiempo de ejecución. Si el botón
la vinculación estática, proporciona las bibliotecas de vínculos necesarias en el archivo DEQP_<API>_LIBRARIES
de configuración de compilación.
Cómo migrar el framework de prueba
La portabilidad del deqp consta de tres pasos: adaptar las bibliotecas de portabilidad base implementar interfaces de integración de plataformas del framework de prueba y transferir el de ejecución de Google Cloud.
En la siguiente tabla, se enumeran las ubicaciones para los posibles cambios de portabilidad. Cualquier cosa más allá es probable que sean exóticos.
| Ubicación | Descripción |
|---|---|
framework/delibs/debase |
Cualquier implementación necesaria 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 |
Se puede implementar un nuevo puerto de plataforma y un stub de aplicación como se describe en Prueba el puerto de la plataforma del framework. |
Bibliotecas de portabilidad base
Las bibliotecas de portabilidad base ya admiten Windows, la mayoría de las variantes de Linux, macOS, iOS y Android. Si el destino de prueba se ejecuta en uno de esos sistemas operativos lo más probable es que no sea necesario tocar las bibliotecas de portabilidad base.
Puerto de plataforma del framework de prueba
El puerto de plataforma del framework de prueba de deqp requiere dos componentes: una aplicación y una interfaz de plataforma.
El punto de entrada de la aplicación es responsable de crear el objeto de la plataforma,
creando un objeto de línea de comandos (tcu::CommandLine), abriendo un registro de prueba
(tcu::TestLog) y, luego, iterar la aplicación de prueba (tcu::App). Si el botón
El SO de destino admite un punto de entrada main() estándar, se puede usar tcuMain.cpp
como la implementación del punto de entrada.
La API de la plataforma deqp se describe en detalle en los siguientes archivos.
| Archivo | Descripción |
|---|---|
framework/common/tcuPlatform.hpp |
Clase básica para todos los puertos de 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 plataforma es tcu::Platform. El puerto de la plataforma
De manera opcional, admite interfaces específicas de GL y EGL. Consulta
la siguiente tabla para obtener una descripción general de lo que debe implementarse para
ejecuta 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 |
Puedes encontrar instrucciones detalladas para implementar puertos de plataforma en el encabezados de capa de portabilidad.
Servicio de ejecución de pruebas
Para usar la infraestructura de ejecución de prueba deqp o el ejecutor de línea de comandos,
servicio de ejecución de prueba debe estar disponible en el destino. Un C++ portátil
del servicio se proporciona en el directorio execserver. El sistema independiente
El objeto binario se compila como parte del módulo de prueba de deqp
para PCs. Puedes modificar execserver/CMakeLists.txt para habilitar una compilación
otros objetivos.
La versión C++ del servicio de ejecución de prueba acepta dos líneas de comandos. parámetros:
-
--port=<port>configurará el puerto TCP en el que escucha el servidor. El valor predeterminado es 50016. -
--singlefinalizará el proceso del servidor cuando se desconecte el cliente. De forma predeterminada, el el proceso del servidor seguirá funcionando para entregar más solicitudes de ejecución de prueba.
Ejecuta las pruebas
En esta página, se proporcionan instrucciones para ejecutar pruebas de deqp en Linux y Windows entornos, usar argumentos de línea de comandos y trabajar con la consola paquete de aplicación.
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 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 |
Puedes implementar el servicio de ejecución y probar objetos binarios en cualquier parte del destino un sistema de archivos estándar, Sin embargo, los binarios de prueba esperan encontrar directorios de datos en el directorio de trabajo actual. Cuando tengas todo listo, inicia el servicio de ejecución de pruebas en la dispositivo de destino. Para obtener detalles sobre cómo iniciar el servicio, consulta Prueba de Google Cloud.
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 programas de prueba.
| Argumento | Descripción |
|---|---|
--deqp-case=<casename> |
Ejecuta 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 proporciones. La ejecución de prueba establecerá el nombre de archivo cuando comience una prueba. |
--deqp-stdin-caselist |
Lee la lista de casos desde stdin o desde un argumento determinado. La ejecución de prueba el servicio establecerá el argumento según la solicitud de ejecución recibida. Consulta en la siguiente sección para obtener una descripción del formato de la lista de casos. |
--deqp-test-iteration-count=<count> |
Anular el recuento de iteraciones para las pruebas que admiten un número variable de iteraciones. |
--deqp-base-seed=<seed> |
Valor inicial 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. Activada
plataformas compatibles con 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 es dependen de la plataforma. En la plataforma 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 es
dependen de la plataforma. Para EGL, el formato es
rgb(a)<bits>d<bits>s<bits> Por ejemplo, un
de rgb888s8 seleccionará la primera configuración en la que
el búfer de color es RGB888 y el búfer de la plantilla tiene 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. La compatibilidad con esto es opcional. |
--deqp-surface-type=<type> |
Usa un tipo de superficie determinado como el objetivo de renderización principal de la prueba. Posibles
los tipos son window, pixmap, pbuffer,
y fbo. |
--deqp-screen-rotation=<rotation> |
Orientación de la pantalla en incrementos de 90 grados para plataformas que para respaldarlo. |
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. Como crecen, los prefijos repetitivos pueden resultar engorrosos. Para evitar la repetición los prefijos, usa 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
Android
El paquete de aplicación de Android contiene todos los componentes necesarios, incluidos los siguientes:
el servicio de ejecución de prueba,
los objetos binarios de prueba y los archivos de datos. La actividad de prueba es
un objeto NativeActivity que use EGL (requiere Android 3.2 o una versión posterior)
El paquete de la aplicación se puede instalar con el siguiente comando (nombre se muestra el nombre del APK en el paquete del 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 la redirección de puertos, usa el lo siguiente:
adb –d forward tcp:50016 tcp:50016adb –d shell am start –n com.drawelements.deqp/.execserver.ServiceStarter
Para habilitar las impresiones de depuración, ejecuta el siguiente comando antes de iniciar pruebas:
adb –d shell setprop log.tag.dEQP DEBUG
Ejecuta pruebas en Android sin el CTS de Android
Para iniciar manualmente la actividad de ejecución de prueba, crea un intent de Android
que se orienta a android.app.NativeActivity. Las actividades pueden ser
que se encuentra en el paquete com.drawelements.deqp. La línea de comandos debe
Se debe proporcionar como una cadena adicional con la clave "cmdLine" en el intent.
Se escribe un registro de prueba en /sdcard/dEQP-log.qpa. Si la ejecución de prueba
no se inicia normalmente, hay información de depuración adicional disponible en el dispositivo.
registro.
Puedes iniciar una actividad desde la línea de comandos con am.
o de terceros. Por ejemplo, para ejecutar pruebas de dEQP-GLES2.info en una plataforma.
compatible con NativeActivity,, usa los siguientes comandos.
adb -d shell am start -n com.drawelements.deqp/android.app.NativeActivity -e \ 'cmdLine "deqp --deqp-case=dEQP-GLES2.info.* --deqp-log-filename=/sdcard/dEQP-Log.qpa"'
Cómo depurar en Android
Para ejecutar las pruebas bajo el depurador GDB en Android, primero compila e instala la compilación de depuración ejecutando las 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 Cuando se ejecute GDB 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 deqp depende de los casos de prueba que se ejecutarán y de otras
los 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 múltiples argumentos de línea de comandos para
acciones, como establecer interrupciones en la depuración, conexión con gdbserver
parámetros y rutas de acceso a objetos binarios adicionales para depurar (usa debug.py
--help para todos los argumentos y explicaciones). El script también copia algunas
las bibliotecas predeterminadas del dispositivo de destino
para obtener listas de símbolos.
Para revisar el código del conductor (por ejemplo, cuando GDB necesita conocer las ubicaciones)
de los objetos binarios con información de depuración completa), agrega más bibliotecas a través de
Parámetros de la línea de comandos de debug.py Esta secuencia de comandos escribe
de Terraform para GDB a partir de la línea 132 del archivo de secuencia de comandos. Tú
puede proporcionar rutas de acceso adicionales a objetos binarios, etc., pero proporcionar el comando correcto
los parámetros de línea deberían ser suficientes.
Nota: En Windows, el objeto 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 ver las soluciones alternativas, consulta este error público. Android 4.4 y las versiones posteriores no incluyen 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 prueba existente y el objetivo en un entorno de nube.
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 en el registro de pruebas. El resultado de la consola es
solo para información de depuración. Es posible que no esté disponible en todas las plataformas.
Los objetos binarios de prueba se pueden invocar directamente desde un sistema de automatización de pruebas. La prueba El objeto binario se puede iniciar para un caso específico, para un conjunto de prueba o para todos pruebas disponibles. Si se produce un error fatal durante la ejecución (como ciertas APIs o una falla), se anulará la ejecución de la prueba. Para las pruebas de regresión, el mejor enfoque es invocar los objetos binarios de prueba para casos individuales o pruebas pequeñas se establece por separado, para tener resultados parciales disponibles incluso en el evento de errores graves.
El deqp incluye herramientas de ejecución de prueba de línea de comandos que se pueden usar en 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 el el siguiente caso disponible. Se genera un solo archivo de registro a partir de la prueba completa. sesión. Esta configuración es ideal para sistemas de prueba ligeros que no proporcionan de recuperación ante fallas.
Herramientas para ejecutar pruebas en la línea de comandos
El conjunto actual de herramientas de línea de comandos incluye una herramienta de ejecución de prueba remota, una herramienta generador de comparación de registros para el análisis de regresión, un conversor de registro de prueba a CSV un conversor de registro de prueba a XML y un conversor de registro de prueba a JUnit.
El código fuente de estas herramientas se encuentra en el directorio executor, y los objetos binarios se encuentran
compilada en el directorio <builddir>/executor.
Ejecutor de prueba de la línea de comandos
El ejecutor de pruebas de línea de comandos es una herramienta de C++ portátil para iniciar una ejecución de prueba
en un dispositivo y recopila
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.
En conjunto, 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 la línea de comandos
(usa --help para obtener más información):
Ejemplo 1: Ejecuta pruebas funcionales de GLES2 en un dispositivo Android
executor --connect=127.0.0.1 --port=50016 --binaryname= com.drawelements.deqp/android.app.NativeActivity --caselistdir=caselists --testset=dEQP-GLES2.* --out=BatchResult.qpa --cmdline="--deqp-crashhandler=enable --deqp-watchdog=enable --deqp-gl-config-name=rgba8888d24s8"
Ejemplo 2: Continúa una prueba parcial de OpenGL ES 2 de manera 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
Exportar y comparar archivos CSV de registros
La deqp tiene una herramienta para convertir los registros de prueba (archivos .qpa) en archivos CSV. El archivo CSV
el resultado contiene una lista de casos de prueba y sus
resultados. La herramienta también puede comparar dos o más resultados por lotes y solo enumerar los
los casos de prueba que tienen códigos de estado diferentes en los resultados por lotes de entrada. El
comparación también imprimirá el número de casos coincidentes.
El resultado en formato CSV es muy práctico para el procesamiento posterior con
con utilidades de línea de comandos
o con un editor de hojas de cálculo. Un espacio de nombres adicional legible por humanos
El formato de texto sin formato se puede seleccionar con el siguiente argumento de línea de comandos: --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: Enumera las diferencias de los resultados de las pruebas entre dos registros de prueba
testlog-to-csv --mode=diff --format=text Device_v1.qpa Device_v2.qpa
Nota: El argumento --value=code genera la prueba
el código de resultado, como "Aprobado" o “Desaprobado”. El argumento --value=details selecciona
Es una explicación del resultado o el valor numérico producido por una prueba de rendimiento, capacidad o precisión.
Cómo probar la exportación de XML de registros
Los archivos de registro de prueba se pueden convertir en documentos XML válidos con el testlog-to-xml.
o de terceros. Se admiten dos modos de salida:
- Modo de documentos separados, en el que cada caso de prueba y el resumen de
caselist.xmldocumento se escriben en un directorio de destino - Modo de archivo único, en el que todos los resultados del archivo
.qpase escriben en un único documento XML.
Los archivos de registro de prueba exportados se pueden ver en un navegador con una hoja de estilo XML.
Se proporcionan documentos de hoja de estilo de muestra (testlog.xsl y testlog.css).
en el directorio doc/testlog-stylesheet. Para procesar los archivos de registro en un navegador, copia el
dos archivos de hojas 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 como Chrome
limita el acceso a los archivos locales por motivos de seguridad. La instalación estándar de Python
incluye un servidor HTTP básico que puede iniciarse para entregar el
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 ejecuciones de pruebas desde JUnit salida. Los archivos de registro de prueba de deqp se pueden convertir al formato de salida de JUnit usando la herramienta testlog-to-junit.
Actualmente, la herramienta solo admite traducir el veredicto del caso de prueba. Como JUnit solo admite el filtro "pass" y “falla” resultados, se asigna un resultado de pase de deqp a "pase JUnit" y otros resultados se consideran fracasos. La calidad original el código de resultado está disponible en el resultado de JUnit. Otros datos, como mensajes de registro y las imágenes de resultados, no se conservan en la conversión.
Cómo usar grupos de prueba especiales
Es posible que algunos grupos de prueba necesiten o admitan opciones de línea de comandos especiales, con especial cuidado cuando se usan en ciertos sistemas.
Pruebas de esfuerzo de asignación de memoria
Las pruebas de esfuerzo de la asignación de memoria ejecutan condiciones de falta de memoria al asignar ciertos recursos hasta que el controlador informe un error de memoria insuficiente.
En algunas plataformas, como Android y la mayoría de las variantes de Linux, puedes realizar las siguientes acciones:
puede ocurrir: el sistema operativo puede finalizar el proceso de prueba en lugar de permitir un
para manejar o proporcionar un error de memoria insuficiente. En tales
plataformas, las pruebas diseñadas para causar errores de memoria insuficiente se inhabilitan
De forma predeterminada, y debe habilitarse con el argumento de línea de comandos --deqp-test-oom=enable.
Se recomienda que ejecutes esas pruebas de forma manual para
comprobar si el sistema se comporta correctamente bajo la presión de los recursos. Sin embargo, en este tipo de
una situación específica, una falla en el proceso de prueba debe interpretarse como una aprobación.
Grupos de prueba
dEQP-GLES2.stress.memory.* dEQP-GLES3.stress.memory.*
Pruebas de esfuerzo de renderización de larga duración
La renderización de pruebas de esfuerzo está diseñada para revelar problemas de solidez en cargas
y procesamiento. De forma predeterminada, las pruebas ejecutarán solo unas pocas iteraciones, pero
se pueden configurar para que se ejecuten de forma indefinida si proporcionas --deqp-test-iteration-count=-1
argumento de línea de comandos. Se debe inhabilitar el perro guardián de prueba (--deqp-watchdog=disable).
cuando se ejecutan estas pruebas durante un período prolongado.
Grupos de prueba
dEQP-GLES2.stress.long.* dEQP-GLES3.stress.long.*