Plantillas de prueba

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

Los desarrolladores pueden usar estas plantillas para minimizar el esfuerzo que implica integrar estas pruebas. En esta sección, se explica la configuración y el uso de las herramientas plantillas (ubicadas en el VTS) casos de prueba/plantilla directorio) y proporciona ejemplos de plantillas de uso frecuente.

Plantilla de BinaryTest

Usa el Binaria plantilla para integrar pruebas que se ejecutan en el dispositivo de destino en VTS. Las pruebas de destino incluyen lo siguiente:

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

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

Integra las pruebas de destino con Plantilla de BinaryTest

La plantilla BinaryTest está diseñada para ayudar a los desarrolladores a integrar fácilmente en el destino. En la mayoría de los casos, puedes agregar unas pocas líneas simples 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, sucede lo siguiente:

• binary-test-source y binary-test-type son específica de la plantilla.
• La especificación de la ruta de acceso del host relativa de la fuente binaria de prueba habilita la plantilla para manejar la preparación, el envío de archivos, la ejecución de pruebas, el análisis de resultados y para la limpieza de datos.
• La plantilla contiene métodos relacionados con la creación de casos de prueba para que las subclases puedan anulación.
• La plantilla supone un caso de prueba por módulo binario de prueba y el objeto binario El nombre del archivo de origen 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:

Nombre de la opción	Tipo de valor	Descripción
fuente-de-prueba-binaria	cadenas	Rutas de acceso de origen de prueba binaria en relación con el directorio de casos de prueba de vts activado host. Ejemplo: DATA/nativetest/test
directorio-de-prueba-de-trabajo-binario	cadenas	Directorios de trabajo (ruta de acceso del dispositivo) Ejemplo: /data/local/tmp/testing/
prueba-binaria-envp	cadenas	Variables de entorno para objetos binarios. Ejemplo: PATH=/new:$PATH
argumentos-de-prueba-binaria	cadenas	Argumentos o marcas de prueba. Ejemplo: --gtest_filter=test1
Ruta-de-biblioteca-de-prueba-binaria-ld-biblioteca	cadenas	Variable de entorno LD_LIBRARY_PATH. Ejemplo: /data/local/tmp/lib
framework-bin-test-disable-framework	boolean	Ejecuta adb stop para desactivar el framework de Android antes de la prueba. Ejemplo: true
binaria-prueba-detención-nativo-servidores	boolean	Detén todos los servidores nativos configurados correctamente durante la prueba. Ejemplo: true
tipo de prueba-binaria	string	Tipo de plantilla. Otros tipos de plantillas se extienden desde esta plantilla, pero no tienes que especificar esta opción para esta plantilla porque especificado binary-test-source.

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, puedes agregar el prefijo strings a las opciones. y usa :: como delimitador. Las etiquetas de prueba son especialmente útil cuando se incluyen fuentes binarias con el mismo nombre, pero con diferentes directorios principales o de bits. Por ejemplo, para evitar el envío de archivos o el nombre del resultado una colisión de fuentes con el mismo nombre, pero de directorios fuente diferentes, puedes especificar distintas etiquetas para estas fuentes.

Como se muestra en el ejemplo de VtsDeviceTreeEarlyMountTest con el elemento dos fuentes dt_early_mount_test, las etiquetas de prueba son las Los prefijos _32bit:: y _64bit:: están activados binary-test-source Las etiquetas que terminan en 32bit o 64bit marca automáticamente las pruebas como disponibles para un bit de ABI. Es decir, las pruebas con la etiqueta _32bit no se ejecutan en la 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. Para Por ejemplo, binary-test-args con la etiqueta _32bit se se aplicó únicamente a binary-test-source con la misma etiqueta y se ejecutó en binary-test-working-directory con la misma etiqueta. El La opción binary-test-working-directory es opcional para las pruebas binarias. lo que te permite especificar un único directorio de trabajo para una etiqueta. Cuando La opción binary-test-working-directory no se especifica, es la configuración predeterminada directorios 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.

Integra pruebas del lado del destino sin Plantilla de BinaryTest

En VTS, el formato de prueba predeterminado son las pruebas de Python del host extendidas de BaseTest en el ejecutor de VTS. Para integrar pruebas del lado del destino, primero debes enviar el probar archivos en el dispositivo, ejecutar las pruebas con comandos shell y, luego, analizar los con secuencias de comandos de Python del lado del host.

Objetos binarios de prueba de envío

Recomendamos enviar archivos con 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 de acceso absoluta al archivo de origen.
3. Envía los archivos mediante el comando adb push.
4. Borra los archivos después de que se completan las pruebas.

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

Cómo ejecutar pruebas

Luego de enviar los archivos al dispositivo, ejecuta la prueba usando comandos shell en un secuencia de comandos 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 de GtestBinaryTest

El GtestBinaryTest plantilla aloja objetos binarios de prueba de GTest, cada uno de los cuales suele contener varios casos de prueba. Esta plantilla extiende la plantilla BinaryTest anulando configuración, creación de casos de prueba y métodos de análisis de resultados, por lo que todo 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	string	Tipo de plantilla. Usa el valor gtest.
modo-por lotes gtest	boolean	Ejecutar objetos binarios de Gtest en modo por lotes Ejemplo: true

En general, la configuración de gtest-batch-mode como true aumenta el rendimiento y disminuye un poco la confiabilidad. En cumplimiento con VTS muchos módulos usan el modo por lotes para mejorar el rendimiento. Por confiabilidad Sin embargo, si el modo no se especifica, la configuración predeterminada es no por lotes.

Modo que no es por lotes

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

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

• Aislamiento de caso de prueba: Una falla o bloqueo en un caso de prueba no afecta otros casos de prueba.
• Nivel de detalle. Es más fácil obtener la generación de perfiles y la cobertura por caso de prueba mediciones, Systrace, informe de errores, logcat, etc. Los resultados de las pruebas y los registros se recupera de forma inmediata después de que finaliza cada caso de prueba.

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

• Carga redundante. Cada vez que se llama al objeto binario de GTest, se cargan las bibliotecas relacionadas y se realizan las configuraciones iniciales de las clases.
• Sobrecarga de comunicación. Cuando se completa una prueba, el host y el dispositivo de destino se comunican para el análisis de resultados y los comandos siguientes (futuras optimizaciones posibles).

Modo por lotes

En el modo por lotes de GTest, se llama al objeto binario de prueba solo una vez con una prueba larga. valor de filtro que contenga todos los casos de prueba filtrados por la configuración del host (este se evita el problema de carga redundante en un modo que no es por lotes). Puedes analizar la prueba los resultados de GTest usando output.xml o usando la salida de la terminal.

Cuando uses output.xml (predeterminado), haz lo siguiente:

Al igual que en el modo que no es 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 realizan todas las pruebas, completo, si un caso de prueba falló, el objeto binario o el dispositivo, no se muestra ningún archivo en formato XML de resultados de red.

Cuando uses el resultado de la terminal, haz lo siguiente:

Mientras se ejecuta GTest, imprime el registro y el progreso de la prueba en la terminal en un formato que el framework pueda analizar para conocer el estado de la prueba, los resultados los registros del sistema operativo.

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

• Aislamiento de caso de prueba: Proporciona el mismo nivel de prueba. aislamiento de casos como modo que no es por lotes si el framework reinicia el objeto binario o el dispositivo Después de una falla con un filtro de prueba reducido (excluye las pruebas finalizadas y con fallas) ).
• Nivel de detalle. Proporciona el mismo nivel de detalle de caso de prueba que modo no por lotes.

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

• Costo de mantenimiento. Si el formato de registro de GTest cambia, todas las pruebas fallarán.
• Confusión. Un caso de prueba puede imprimir algo similar a GTest de progreso, lo que puede confundir el formato.

Debido a estas desventajas, hemos eliminado 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 la confiabilidad de esta función.

Plantilla de HostBinaryTest

La plantilla HostBinaryTest incluye ejecutables del host que no existen. en otros directorios o 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 y otros lenguajes

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

<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 una función similar. configuraciones de prueba. En el ejemplo anterior, binary-test-source especifica una ruta de acceso relativa del host al ejecutable de prueba binary-test-type es host_binary_test. Similar a BinaryTest, el nombre del archivo binario se usa como nombre del caso de prueba de forma predeterminada.

Extender las plantillas existentes

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

Se recomienda a los desarrolladores que extiendan las plantillas existentes a cualquier los requisitos de prueba. Estos son algunos de los motivos comunes para extender las plantillas:

• Procedimientos especiales de configuración para pruebas, como preparar un dispositivo con requisitos especiales con comandos de SQL sencillos.
• Generar diferentes casos y nombres de prueba
• Analizar los resultados mediante la lectura del resultado del comando o el uso de otras condiciones

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