Google is committed to advancing racial equity for Black communities. See how.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Plantillas de prueba

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

Figura 1. Arquitectura de la plantilla de prueba.

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 testcases / template de VTS) y proporciona ejemplos de plantillas de uso común.

Plantilla BinaryTest

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

  • Pruebas basadas en C ++ compiladas y enviadas al dispositivo
  • Pruebas de Python del lado de destino compiladas como binarios
  • Scripts de shell 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 del objetivo. En la mayoría de los casos, puede 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.
  • 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 anulen.
  • La plantilla asume un caso de prueba por módulo binario de prueba y el nombre del archivo de origen 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:

Nombre de la opción Tipo de valor Descripción
fuente de prueba binaria instrumentos de cuerda Rutas de origen de prueba binarias relativas al directorio de casos de prueba de 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/
binary-test-envp instrumentos de cuerda Variables de entorno para binarios.
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-deshabilitación-de-prueba-binaria booleano Ejecute adb stop para apagar Android Framework antes de la prueba. Ejemplo: true
binary-test-stop-native-servers booleano Detenga todos los servidores nativos configurados correctamente durante la prueba. Ejemplo: true
tipo-prueba-binaria cuerda Tipo de plantilla. Otros tipos de plantillas se extienden desde esta plantilla, pero no es necesario que especifique esta opción para esta plantilla porque ya especificó binary-test-source .

Para las opciones con strings 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 de VtsDeviceTreeEarlyMountTest ).

Etiquetas de prueba

Puede agregar etiquetas de prueba prefijándolas a 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 el envío 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 64bit o 64bit marcan automáticamente las pruebas como disponibles para un bit 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 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 ú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 etiqueta _32bit aparece como testcase1_32bit en el informe de resultados.

Integración de pruebas del lado del destino 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 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.

Empujar binarios de prueba

Recomendamos VtsFilePusher 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>

El VtsFilePusher hace lo siguiente:

  1. Comprueba la conectividad del dispositivo.
  2. Determina la ruta absoluta del archivo de origen.
  3. Inserta los archivos mediante el comando adb push .
  4. Elimina los archivos después de completar las pruebas.

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

Ejecutando pruebas

Después de enviar archivos al dispositivo, ejecute la prueba utilizando 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 binarios de prueba GTest, cada uno de los cuales generalmente contiene 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-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 al tiempo que 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, para mayor confiabilidad, si el modo no está especificado, el valor predeterminado es no por lotes.

Modo sin lotes

El modo no por lotes hace 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 GTest único.

Figura 2. Modo no por lotes.

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 / medición de cobertura por caso de prueba, rastreo del sistema, 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 usar el modo no por lotes incluyen:

  • Carga redundante . Cada vez que se llama al binario GTest, carga las bibliotecas relacionadas y realiza las configuraciones iniciales de la clase.
  • Gastos generales de comunicación . Después de que se completa una prueba, el host y el dispositivo de destino se comunican para el análisis de resultados y los siguientes comandos (posibles optimizaciones futuras).

Por lotes

En el modo de lote 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 la prueba para GTest usando output.xml o usando la salida del terminal.

Al usar output.xml (predeterminado):

Figura 3. Modo por lotes, output.xml.

Como en el modo no por lotes, el resultado de la prueba se analiza a través del archivo xml de salida 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 un archivo xml de resultado.

Al usar la salida de terminal:

Figura 4. Modo por lotes, salida de terminal.

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

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 no por lotes si el marco reinicia el dispositivo binario después de un bloqueo con un filtro de prueba reducido (excluyendo los casos de prueba terminados 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 cambia el formato de registro de GTest, todas las pruebas se interrumpirán.
  • Confusión Un caso de prueba puede imprimir algo similar al formato de progreso 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 o en scripts de Python. Estas pruebas incluyen:

  • Binarios de prueba compilados ejecutables en el host
  • Secuencias de comandos ejecutables en shell, Python u otros lenguajes

Un ejemplo es la prueba del lado del host de la política SELinux de seguridad 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 BinaryTest pero usa 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 anima 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 prueba, 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 del código VTS.