Plantillas de prueba

AOSP incluye plantillas de prueba para módulos de prueba que no son subclases de Python del host de BaseTest del ejecutor de VTS.

Los desarrolladores pueden usar estas plantillas para minimizar el esfuerzo que implica integrar esas pruebas. En esta sección, se describe la configuración y el uso de las plantillas de prueba (que se encuentran en el directorio testcases/template de VTS) y se proporcionan ejemplos de plantillas de uso general.

Plantilla de BinaryTest

Usa la plantilla BinaryTest para integrar pruebas que se ejecuten en el dispositivo de destino en VTS. Entre las pruebas del destino, se incluyen las siguientes:

• Pruebas basadas en C++ compiladas y enviadas al dispositivo
• Pruebas de Python del destino compiladas como objetos binarios
• Secuencias de comandos de shell ejecutables en dispositivos

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

Integra pruebas del destino con la plantilla BinaryTest

La plantilla BinaryTest está diseñada para ayudar a los desarrolladores a integrar pruebas del destino con facilidad. En la mayoría de los casos, puedes agregar algunas líneas de configuración simples 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, ocurre lo siguiente:

• binary-test-source y binary-test-type son específicos de la plantilla.
• Especificar la ruta de acceso del host relativa de la fuente binaria de prueba permite que la plantilla controle 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 para que las subclases los anulen.
• La plantilla supone un caso de prueba por módulo binario de prueba, y el nombre del archivo fuente binario se usa como nombre del caso de prueba de forma predeterminada.

Opciones de configuración

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

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

Etiquetas de prueba

Para agregar etiquetas de prueba, agrégales un prefijo a las opciones con valores strings y usa :: como delimitador. Las etiquetas de prueba son útiles cuando se incluyen fuentes binarias con el mismo nombre, pero con diferentes tamaños de bits o directorios superiores. Por ejemplo, para evitar la colisión de nombres de archivos o resultados para fuentes con el mismo nombre, pero de diferentes directorios de origen, puedes 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 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 tamaño de bits de 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 se 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 te permite especificar un solo directorio de trabajo para una etiqueta. Cuando no se especifica la opción binary-test-working-directory, se usan 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.

Cómo integrar pruebas del destino sin la plantilla de BinaryTest

En VTS, el formato de prueba predeterminado son las pruebas de Python del host que se extienden desde BaseTest en el ejecutor de VTS. Para integrar pruebas del destino, primero debes enviar los archivos de prueba al dispositivo, ejecutar las pruebas con comandos de shell y, luego, analizar los resultados con secuencias de comandos de Python del host.

Cómo enviar objetos binarios de prueba

Recomendamos enviar archivos con el preparador de destinos 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 realiza las siguientes acciones:

1. Verifica la conectividad del dispositivo.
2. Determina la ruta de acceso absoluta del archivo fuente.
3. Envía los archivos con el comando adb push.
4. Borra los archivos después de que se completen las pruebas.

Como alternativa, puedes enviar archivos de forma manual con una secuencia de comandos de prueba de Python del host que siga un procedimiento similar.

Cómo ejecutar pruebas

Después de enviar archivos al dispositivo, ejecuta la prueba con comandos de shell en una secuencia de comandos de prueba de Python 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 de GtestBinaryTest

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

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 los VTS, muchos módulos usan el modo por lotes para mejorar el rendimiento. Sin embargo, por motivos de confiabilidad, si no se especifica el modo, el valor predeterminado es no por lotes.

Modo no por lotes

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

Estas son algunas de las ventajas de usar el modo no por lotes:

• Aislamiento de casos de prueba. Una falla o un bloqueo en un caso de prueba no afecta a otros casos de prueba.
• Nivel de detalle: Es más fácil obtener la medición de perfiles o cobertura por caso de prueba, systrace, informe de errores, logcat, etcétera. Los resultados y registros de las pruebas se recuperan inmediatamente después de que finaliza cada caso de prueba.

Estas son algunas de las desventajas de usar el modo no por lotes:

• Carga redundante: Cada vez que se llama al binario de GTest, carga las bibliotecas relacionadas y realiza la configuración inicial de la clase.
• Sobrecarga de comunicación: Una vez que se completa una prueba, el host y el dispositivo de destino se comunican para el análisis de resultados y los próximos comandos (es posible realizar optimizaciones futuras).

Modo por lotes

En el modo por lotes de GTest, se llama al binario de prueba solo una vez con un valor de filtro de prueba largo que contiene todos los casos de prueba filtrados por la configuración del host (esto evita el problema de carga redundante en el modo no por lotes). Puedes analizar los resultados de las pruebas de GTest con output.xml o con el resultado de la terminal.

Cuando se usa output.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, como el XML de salida se genera después de que se completan todas las pruebas, si un caso de prueba falla en el binario o el dispositivo, no se genera ningún archivo en formato XML de resultados.

Cuando uses el resultado de la terminal, ten en cuenta lo siguiente:

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

Estas son algunas de las ventajas de usar el modo por lotes:

• Aislamiento de casos de prueba. Proporciona el mismo nivel de aislamiento de casos de prueba que el modo no por lotes si el framework reinicia el binario o el dispositivo después de una falla con un filtro de prueba reducido (sin incluir casos de prueba terminados y con fallas).
• Nivel de detalle: Proporciona el mismo nivel de detalle de casos de prueba que el modo no por lotes.

Estas son algunas de las desventajas de usar el modo por lotes:

• Costo de mantenimiento. Si cambia el formato de registro de GTest, se interrumpirán todas las pruebas.
• 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, quitamos temporalmente la opción de usar el resultado de la línea de comandos. Volveremos a revisar esta opción en el futuro para mejorar la confiabilidad de esta función.

Plantilla de HostBinaryTest

La plantilla HostBinaryTest incluye ejecutables del host que no existen en otros directorios ni en secuencias de comandos de Python. Estas pruebas incluyen lo siguiente:

• Objetos binarios de prueba compilados ejecutables en el host
• Secuencias de comandos ejecutables en shell, Python o cualquier otro lenguaje

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

<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 extiende la plantilla de BinaryTest, pero usa configuraciones de prueba similares. En el ejemplo anterior, la opción binary-test-source especifica una ruta de acceso relativa del host al ejecutable de prueba, y binary-test-type es host_binary_test. Al igual que en la plantilla de BinaryTest, el nombre del archivo binario se usa como nombre del caso de prueba de forma predeterminada.

Cómo extender plantillas existentes

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

Se recomienda a los desarrolladores que extiendan cualquier plantilla existente para cualquier requisito de prueba específico. Estos son algunos de los motivos comunes para extender plantillas:

• Procedimientos especiales de configuración de pruebas, como preparar un dispositivo con comandos especiales
• Generar diferentes casos de prueba y nombres de prueba
• Analizar los resultados leyendo el resultado del comando o usando otras condiciones

Para facilitar la extensión de las plantillas existentes, estas contienen métodos especializados para cada funcionalidad. Si mejoraste los diseños de las plantillas existentes, te recomendamos que contribuyas a la base de código de VTS.