Se usó la API de Cloud Translation para traducir esta página.

Plantillas de prueba

AOSP incluye plantillas de prueba para módulos de prueba que no son una subclase de Python del lado del host de BaseTest del corredor VTS.

Figura 1. Arquitectura de la plantilla de prueba.

Los desarrolladores pueden usar estas plantillas para minimizar el esfuerzo involucrado en la integración de dichas pruebas. Esta sección cubre la configuración y el uso de las plantillas de prueba (ubicadas en el directorio testcases/template de VTS) y proporciona ejemplos de plantillas de uso común.

Plantilla de prueba binaria

Utilice la plantilla BinaryTest para integrar pruebas que se ejecutan en el dispositivo de destino en VTS. Las pruebas del lado objetivo incluyen:

Pruebas basadas en C++ compiladas y enviadas al dispositivo
Pruebas de Python del lado del objetivo compiladas como binarios
Shell scripts ejecutables en dispositivos

Estas pruebas se pueden integrar en VTS con o sin la plantilla BinaryTest.

Integración de pruebas del lado del objetivo con la plantilla BinaryTest

La plantilla BinaryTest está diseñada para ayudar a los desarrolladores a integrar fácilmente las pruebas del lado objetivo. En la mayoría de los casos, puede agregar algunas líneas simples de configuración en AndroidTest.xml . Ejemplo de configuración de VtsDeviceTreeEarlyMountTest :

<configuration description="Config for VTS VtsDeviceTreeEarlyMountTest.">
  ...
<test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
<option name="test-module-name" value="VtsDeviceTreeEarlyMountTest"/>
<option name="binary-test-source" value="_32bit::DATA/nativetest/dt_early_mount_test/dt_early_mount_test" />
<option name="binary-test-source" value="_64bit::DATA/nativetest64/dt_early_mount_test/dt_early_mount_test" />
<option name="test-timeout" value="5m"/>
</test>
</configuration>

En esta configuración:

binary-test-source y binary-test-type son específicos de la plantilla.
La especificación de la ruta de host relativa de la fuente binaria de prueba permite que la plantilla maneje la preparación, el envío de archivos, la ejecución de la prueba, el análisis de resultados y la limpieza.
La plantilla contiene métodos relacionados con la creación de casos de prueba para que las subclases los anulen.
La plantilla asume un caso de prueba por módulo binario de prueba, y el nombre del archivo fuente binario se usa como nombre de caso de prueba de forma predeterminada.

Opciones de configuración

La plantilla BinaryTest admite las siguientes opciones de configuración:

Nombre de la opción	Tipo de valor	Descripción
fuente de prueba binaria	instrumentos de cuerda	Rutas de origen de prueba binaria relativas al directorio de caso de prueba vts en el host. Ejemplo: `DATA/nativetest/test`
directorio de trabajo de prueba binaria	instrumentos de cuerda	Directorios de trabajo (ruta del lado del dispositivo). Ejemplo: `/data/local/tmp/testing/`
prueba-binaria-envp	instrumentos de cuerda	Variables de entorno para binario. Ejemplo: `PATH=/new:$PATH`
argumentos de prueba binarios	instrumentos de cuerda	Probar argumentos o banderas. Ejemplo: `--gtest_filter=test1`
ruta-biblioteca-ld-prueba-binaria	instrumentos de cuerda	Variable de entorno `LD_LIBRARY_PATH` . Ejemplo: `/data/local/tmp/lib`
marco de desactivación de prueba binaria	booleano	Ejecute `adb stop` para desactivar Android Framework antes de la prueba. Ejemplo: `true`
prueba-binaria-para-servidores-nativos	booleano	Detenga todos los servidores nativos correctamente configurados durante la prueba. Ejemplo: `true`
tipo de prueba binaria	cuerda	Tipo de plantilla. Otros tipos de plantillas se extienden desde esta plantilla, pero no tiene que especificar esta opción para esta plantilla porque ya especificó `binary-test-source` .

Para las opciones con strings de tipo de valor, puede agregar varios valores repitiendo las opciones en la configuración. Por ejemplo, configure binary-test-source dos veces (como se muestra en el ejemplo VtsDeviceTreeEarlyMountTest ).

Etiquetas de prueba

Puede agregar etiquetas de prueba prefijándolas a las opciones con valores de strings y usando :: como delimitador. Las etiquetas de prueba son especialmente útiles cuando se incluyen fuentes binarias con el mismo nombre pero con diferente bitness o directorios principales. Por ejemplo, para evitar la inserción de archivos o la colisión de nombres de resultados para fuentes con el mismo nombre pero de diferentes directorios de fuentes, puede especificar diferentes etiquetas para estas fuentes.

Como se muestra en el ejemplo de VtsDeviceTreeEarlyMountTest con las dos fuentes dt_early_mount_test , las etiquetas de prueba son los _32bit:: y _64bit:: en binary-test-source . Las etiquetas que terminan en 32bit bits o 64bit marcan automáticamente las pruebas como disponibles para un valor de bits ABI; es decir, las pruebas con la etiqueta _32bit no se ejecutan en ABI de 64 bits. No especificar una etiqueta es igual a usar una etiqueta con una cadena vacía.

Las opciones con las mismas etiquetas se agrupan y aíslan de otras etiquetas. Por ejemplo, binary-test-args con la etiqueta _32bit se aplica solo a binary-test-source con la misma etiqueta y se ejecuta en binary-test-working-directory con la misma etiqueta. La opción binary-test-working-directory es opcional para las pruebas binarias, lo que le permite especificar un solo directorio de trabajo para una etiqueta. Cuando la opción binary-test-working-directory no se especifica, se utilizan directorios predeterminados para cada etiqueta.

El nombre de la etiqueta se agrega directamente al nombre del caso de prueba en el informe de resultados. Por ejemplo, el caso de prueba testcase1 con la etiqueta _32bit aparece como testcase1_32bit en el informe de resultados.

Integración de pruebas del lado objetivo sin plantilla BinaryTest

En VTS, el formato de prueba predeterminado son las pruebas de Python del lado del host extendidas desde BaseTest en el corredor de VTS. Para integrar las pruebas del lado del destino, primero debe enviar los archivos de prueba al dispositivo, ejecutar las pruebas con los comandos de shell y luego analizar los resultados con los scripts de Python del lado del host.

Empujando binarios de prueba

Recomendamos empujar archivos usando el preparador de destino VtsFilePusher . Ejemplo:

<target_preparer class="com.android.compatibility.common.tradefed.targetprep.VtsFilePusher">
        <option name="push" value="DATA/test->/data/local/tmp/test"/>
    </target_preparer>

El VtsFilePusher hace lo siguiente:

Comprueba la conectividad del dispositivo.
Determina la ruta absoluta del archivo de origen.
Empuja los archivos usando el comando adb push .
Elimina los archivos después de completar las pruebas.

Alternativamente, puede enviar archivos manualmente usando un script de prueba de Python del lado del host que sigue un procedimiento similar.

Ejecutando pruebas

Después de enviar los archivos al dispositivo, ejecute la prueba usando comandos de shell en un script de prueba de Python del lado del host. Ejemplo:

device = self.android_devices[0]
res = device.shell.Execute(["chmod a+x /data/local/tmp/test", "/data/local/tmp/test"])
asserts.AssertFalse(any(res[return_codes]))

Plantilla GtestBinaryTest

La plantilla GtestBinaryTest aloja archivos binarios de prueba GTest, cada uno de los cuales suele contener varios casos de prueba. Esta plantilla amplía la plantilla BinaryTest anulando la configuración, la creación de casos de prueba y los métodos de análisis de resultados, por lo que todas las configuraciones de BinaryTest se heredan.

GtestBinaryTest agrega la opción gtest-batch-mode :

Nombre de la opción	Tipo de valor	Descripción
tipo de prueba binaria	cuerda	Tipo de plantilla. Utiliza el valor `gtest` .
gtest-batch-mode	booleano	Ejecute los binarios de Gtest en modo por lotes. Ejemplo: `true`

En general, configurar gtest-batch-mode en true aumenta el rendimiento y reduce ligeramente la confiabilidad. En las pruebas de cumplimiento de VTS, muchos módulos utilizan el modo por lotes para mejorar el rendimiento. Sin embargo, para mayor confiabilidad, si el modo no se especifica, el valor predeterminado es sin lotes.

Modo no por lotes

El modo no por lotes realiza llamadas individuales al binario GTest para cada caso de prueba. Por ejemplo, si el binario GTest contiene 10 casos de prueba (después de filtrar por la configuración del lado del host), el binario se llama 10 veces en el shell del dispositivo cada vez con un filtro de prueba diferente. Para cada caso de prueba, la plantilla genera y analiza un XML de salida de resultado de GTest único.

Figura 2. Modo no por lotes.

Las ventajas de usar el modo no por lotes incluyen:

Aislamiento de casos de prueba . Un bloqueo o bloqueo en un caso de prueba no afecta a otros casos de prueba.
Granularidad . Más fácil de obtener perfilado por caso de prueba/medición de cobertura, systrace, bugreport, logcat, etc. Los resultados de las pruebas y los registros se recuperan inmediatamente después de que finaliza cada caso de prueba.

Las desventajas de usar el modo no por lotes incluyen:

Carga redundante . Cada vez que se llama al binario GTest, carga bibliotecas relacionadas y realiza configuraciones de clase iniciales.
Sobrecarga de comunicación . Una vez completada una prueba, el host y el dispositivo de destino se comunican para el análisis de resultados y los siguientes comandos (optimizaciones futuras posibles).

Por lotes

En el modo por lotes de GTest, el binario de prueba se llama solo una vez con un valor de filtro de prueba largo que contiene todos los casos de prueba filtrados por la configuración del lado del host (esto evita el problema de carga redundante en el modo sin lotes). Puede analizar los resultados de la prueba para GTest usando output.xml o usando la salida del terminal.

Al usar output.xml (predeterminado):

Figura 3. Modo por lotes, salida.xml.

Al igual que en el modo no por lotes, el resultado de la prueba se analiza a través del archivo xml de salida de GTest. Sin embargo, debido a que el xml de salida se genera después de que se completan todas las pruebas, si un caso de prueba bloquea el binario o el dispositivo, no se genera ningún archivo xml de resultado.

Al usar la salida de terminal:

Figura 4. Modo por lotes, salida de terminal.

Mientras se ejecuta GTest, imprime el registro de la prueba y el progreso en el terminal en un formato que el marco puede analizar para el estado, los resultados y los registros de la prueba.

Las ventajas de usar el modo por lotes incluyen:

Aislamiento de casos de prueba . Proporciona el mismo nivel de aislamiento de casos de prueba que el modo sin lotes si el marco reinicia el binario/dispositivo después de un bloqueo con un filtro de prueba reducido (excluyendo casos de prueba finalizados y bloqueados).
Granularidad . Proporciona la misma granularidad de casos de prueba que el modo sin lotes.

Las desventajas de usar el modo por lotes incluyen:

Costo de mantenimiento . Si el formato de registro de GTest cambia, todas las pruebas se interrumpirán.
confusión Un caso de prueba puede imprimir algo similar al formato de progreso de GTest, lo que puede confundir el formato.

Debido a estas desventajas, hemos eliminado temporalmente la opción de usar la salida de la línea de comandos. Revisaremos esta opción en el futuro para mejorar la confiabilidad de esta función.

Plantilla HostBinaryTest

La plantilla HostBinaryTest incluye ejecutables del lado del host que no existen en otros directorios o en scripts de Python. Estas pruebas incluyen:

Archivos binarios de prueba compilados ejecutables en el host
Scripts ejecutables en shell, Python u otros lenguajes

Un ejemplo es la prueba del lado del host de la política SELinux de VTS Security :

<configuration description="Config for VTS  Security SELinux policy host-side test cases">
    ...
    <test class="com.android.tradefed.testtype.VtsMultiDeviceTest">
        <option name="test-module-name" value="VtsSecuritySelinuxPolicyHost"/>
        <option name="binary-test-source" value="out/host/linux-x86/bin/VtsSecuritySelinuxPolicyHostTest" />
        <option name="binary-test-type" value="host_binary_test"/>
    </test>
</configuration>

HostBinaryTest no amplía la plantilla BinaryTest pero utiliza configuraciones de prueba similares. En el ejemplo anterior, la opción binary-test-source especifica una ruta relativa del lado del host al ejecutable de prueba, y binary-test-type es host_binary_test . Similar a la plantilla BinaryTest, el nombre de archivo binario se usa como el nombre del caso de prueba de forma predeterminada.

Ampliación de plantillas existentes

Puede usar plantillas directamente en la configuración de prueba para incluir pruebas que no sean de Python o extenderlas en una subclase para manejar requisitos de prueba específicos. Las plantillas en el repositorio de VTS tienen las siguientes extensiones:

Figura 5. Ampliación de plantillas existentes en el repositorio de VTS.

Se alienta a los desarrolladores a ampliar cualquier plantilla existente para cualquier requisito de prueba específico. Las razones comunes para extender las plantillas incluyen:

Procedimientos especiales de configuración de pruebas, como preparar un dispositivo con comandos especiales.
Generando diferentes casos de prueba y nombres de prueba.
Analizar los resultados leyendo la salida del comando o usando otras condiciones.

Para facilitar la ampliación de las plantillas existentes, las plantillas contienen métodos especializados para cada funcionalidad. Si ha mejorado los diseños de las plantillas existentes, le recomendamos que contribuya a la base de código de VTS.