Plantillas de prueba

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

Los desarrolladores pueden utilizar estas plantillas para minimizar el esfuerzo que implica 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 VTS testcases/template ) 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 objetivo compiladas como binarios
• Scripts de Shell ejecutables en dispositivos

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

Integre pruebas del lado objetivo con la plantilla BinaryTest

La plantilla BinaryTest está diseñada para ayudar a los desarrolladores a integrar fácilmente pruebas del lado objetivo. En la mayoría de los casos, puedes agregar algunas líneas simples de configuración en AndroidTest.xml . Configuración de ejemplo 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.
• Especificar 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 pruebas, el análisis de resultados y la limpieza.
• La plantilla contiene métodos relacionados con la creación de casos de prueba que las subclases pueden anular.
• La plantilla supone un caso de prueba por módulo binario de prueba y el nombre del archivo fuente binario se utiliza como nombre del caso de prueba de forma predeterminada.

Opciones de configuración

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

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

Etiquetas de prueba

Puede agregar etiquetas de prueba prefijándolas a opciones con valores strings y usando :: como delimitador. Las etiquetas de prueba son especialmente útiles cuando se incluyen fuentes binarias con el mismo nombre pero con diferentes bits 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 origen, puede especificar diferentes etiquetas para estas fuentes.

Como se muestra en el ejemplo VtsDeviceTreeEarlyMountTest con las dos fuentes dt_early_mount_test , las etiquetas de prueba son los prefijos _32bit:: y _64bit:: en binary-test-source . Las etiquetas que terminan en 32bit o 64bit marcan automáticamente las pruebas como disponibles para un bitness ABI; es decir, las pruebas con la etiqueta _32bit no se ejecutan en ABI de 64 bits. No especificar una etiqueta equivale 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 aplican 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 único 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.

Integre pruebas del lado objetivo sin la plantilla BinaryTest

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

Empujar binarios de prueba

Recomendamos enviar archivos utilizando 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>

VtsFilePusher hace lo siguiente:

1. Comprueba la conectividad del dispositivo.
2. Determina la ruta absoluta del archivo fuente.
3. Empuja los archivos usando el comando adb push .
4. Elimina los archivos una vez completadas las pruebas.

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

Ejecutar pruebas

Después de enviar 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 los archivos binarios de prueba de GTest, cada uno de los cuales suele contener varios casos de prueba. Esta plantilla amplía la plantilla de BinaryTest al anular los métodos de configuración, creación de casos de prueba y análisis de resultados, de modo que todas las configuraciones de BinaryTest se heredan.

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

En general, configurar gtest-batch-mode en true aumenta el rendimiento y disminuye ligeramente la confiabilidad. En las pruebas de cumplimiento de VTS, muchos módulos utilizan el modo por lotes para mejorar el rendimiento. Sin embargo, por motivos de confiabilidad, si el modo no se especifica, el valor predeterminado es no por 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 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.

Las ventajas de utilizar 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 . Es más fácil obtener perfiles/mediciones de cobertura por caso de prueba, systrace, informe de errores, 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 utilizar el modo no por lotes incluyen:

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

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 no por lotes). Puede analizar los resultados de las pruebas para GTest usando output.xml o usando la salida del terminal.

Cuando se utiliza salida.xml (predeterminado):

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 completar todas las pruebas, si un caso de prueba falla el binario o el dispositivo, no se genera ningún archivo xml de resultados.

Cuando se utiliza la salida del 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 conocer el estado, los resultados y los registros de la prueba.

Las ventajas de utilizar el modo por lotes incluyen:

• Aislamiento de casos de prueba . Proporciona el mismo nivel de aislamiento de casos de prueba que el modo no por lotes si el marco reinicia el binario/dispositivo después de una falla 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 no por lotes.

Las desventajas de utilizar 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 utilizar 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 ni en scripts de Python. Estas pruebas incluyen:

• 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 . De forma similar a la plantilla BinaryTest, el nombre del archivo binario se utiliza como nombre del caso de prueba de forma predeterminada.

Ampliar plantillas existentes

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

Se anima a los desarrolladores a ampliar cualquier plantilla existente para cualquier requisito de prueba específico. Los motivos habituales para ampliar 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 pruebas.
• 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 tiene diseños mejorados para las plantillas existentes, le recomendamos que contribuya a la base del código VTS.