Ejecutar pruebas (Atest)

Atest es una herramienta de línea de comandos que permite a los usuarios crear, instalar y ejecutar pruebas de Android localmente, lo que acelera enormemente las repeticiones de pruebas sin necesidad de conocer las opciones de línea de comandos del arnés de pruebas de la Federación de Comercio . Esta página explica cómo utilizar Atest para ejecutar pruebas de Android.

Para obtener información general sobre cómo escribir pruebas para Android, consulte Pruebas de plataforma Android .

Para obtener información sobre la estructura general de Atest, consulte la Guía para desarrolladores de Atest .

Para obtener información sobre cómo ejecutar pruebas en archivos TEST_MAPPING a través de Atest, consulte Ejecución de pruebas en archivos TEST_MAPPING .

Para agregar una función a Atest, siga el flujo de trabajo del desarrollador de Atest .

Configura tu entorno

Para configurar su entorno Atest, siga las instrucciones en Configuración del entorno , Elección de un objetivo y Creación del código .

Uso básico

Los comandos de prueba toman la siguiente forma:

atest test-to-run [optional-arguments]

Argumentos opcionales

La siguiente tabla enumera los argumentos más utilizados. Una lista completa está disponible a través de atest --help .

Opción	Opción larga	Descripción
-b	--build	Construye objetivos de prueba. (por defecto)
-i	--install	Instala artefactos de prueba (APK) en el dispositivo. (por defecto)
-t	--test	Ejecuta las pruebas. (por defecto)
-s	--serial	Ejecuta las pruebas en el dispositivo especificado. Se puede probar un dispositivo a la vez.
-d	--disable-teardown	Desactiva el desmontaje y la limpieza de pruebas.
	--dry-run	Ejecute Atest en seco sin tener que construir, instalar o ejecutar pruebas.
-m	--rebuild-module-info	Fuerza una reconstrucción del archivo module-info.json .
-w	--wait-for-debugger	Espera a que finalice el depurador antes de ejecutar.
-v	--verbose	Muestra el registro de nivel DEBUG.
	--iterations	Ejecuta pruebas en bucle hasta alcanzar la iteración máxima. (10 por defecto)
	--rerun-until-failure [COUNT=10]	Vuelve a ejecutar todas las pruebas hasta que ocurre una falla o se alcanza la iteración máxima. (10 por defecto)
	--retry-any-failure [COUNT=10]	Vuelve a ejecutar las pruebas fallidas hasta que se aprueban o se alcanza la iteración máxima. (10 por defecto)
	--start-avd	Crea automáticamente un AVD y ejecuta pruebas en el dispositivo virtual.
	--acloud-create	Crea un AVD usando el comando acloud .
	--[CUSTOM_ARGS]	Especifica argumentos personalizados para los ejecutores de pruebas.
-a	--all-abi	Ejecuta las pruebas para todas las arquitecturas de dispositivos disponibles.
	--host	Ejecuta la prueba completamente en el host sin un dispositivo. Nota: La ejecución de una prueba de host que requiera un dispositivo con --host fallará.
	--history	Muestra los resultados de las pruebas en orden cronológico.
	--latest-result	Imprime el último resultado de la prueba.

Para obtener más información sobre -b , -i y -t , consulte la sección Especificar pasos: compilar, instalar o ejecutar .

Especificar pruebas

Para ejecutar pruebas, especifique una o más pruebas utilizando uno de los siguientes identificadores:

• Nombre del módulo
• Módulo:Clase
• Nombre de la clase
• Prueba de integración comercializada
• Ruta de archivo
• Nombre del paquete

Separe las referencias a múltiples pruebas con espacios, así:

atest test-identifier-1 test-identifier-2

Nombre del módulo

Para ejecutar un módulo de prueba completo, use su nombre de módulo. Ingrese el nombre tal como aparece en las variables LOCAL_MODULE o LOCAL_PACKAGE_NAME en el archivo Android.mk o Android.bp de esa prueba.

Ejemplos:

atest FrameworksServicesTests
atest CtsVideoTestCases

Módulo:Clase

Para ejecutar una sola clase dentro de un módulo, use Module:Class . El módulo es el mismo que se describe en Nombre del módulo . Clase es el nombre de la clase de prueba en el archivo .java y puede ser el nombre de clase completo o el nombre básico.

Ejemplos:

atest CtsVideoTestCases:VideoEncoderDecoderTest
atest FrameworksServicesTests:ScreenDecorWindowTests
atest FrameworksServicesTests:com.android.server.wm.ScreenDecorWindowTests

Nombre de la clase

Para ejecutar una sola clase sin indicar explícitamente el nombre del módulo, use el nombre de la clase.

Ejemplos:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Prueba de integración comercializada

Para ejecutar pruebas que están integradas directamente en TradeFed (sin módulos), ingrese el nombre tal como aparece en la salida del comando tradefed.sh list configs . Por ejemplo:

Para ejecutar la prueba reboot.xml :

atest example/reboot

Para ejecutar la prueba native-benchmark.xml :

atest native-benchmark

Ruta de archivo

Atest admite la ejecución de pruebas basadas en módulos y pruebas basadas en integración ingresando la ruta a su archivo o directorio de prueba, según corresponda. También admite la ejecución de una única clase especificando la ruta al archivo Java de la clase. Se admiten rutas relativas y absolutas.

Ejecutar un módulo

Los siguientes ejemplos muestran dos formas de ejecutar el módulo CtsVideoTestCases utilizando una ruta de archivo.

Ejecutar desde repo-root de Android:

atest cts/tests/video

Ejecute desde Android repo-root/cts/tests/video :

    atest .

Ejecutar una clase de prueba

El siguiente ejemplo muestra cómo ejecutar una clase específica dentro del módulo CtsVideoTestCases usando una ruta de archivo.

Desde repo-root de Android:

    atest cts/tests/video/src/android/video/cts/VideoEncoderDecoderTest.java

Ejecute una prueba de integración

El siguiente ejemplo muestra cómo ejecutar una prueba de integración utilizando una ruta de archivo desde repo-root de Android:

    atest tools/tradefederation/contrib/res/config/example/reboot.xml

Nombre del paquete

Atest admite la búsqueda de pruebas por nombre de paquete.

Ejemplos:

    atest com.android.server.wm
    atest com.android.uibench.janktests

Especificar los pasos: compilar, instalar o ejecutar

Utilice las opciones -b , -i y -t para especificar qué pasos ejecutar. Si no especifica una opción, se ejecutarán todos los pasos.

• Solo objetivos de compilación: atest -b test-to-run
• Ejecute solo pruebas: atest -t test-to-run
• Instale apk y ejecute pruebas: atest -it test-to-run
• Compile y ejecute, pero no instale: atest -bt test-to-run

Atest puede obligar a una prueba a omitir el paso de limpieza o desmontaje. Muchas pruebas, como CTS, limpian el dispositivo después de ejecutar la prueba, por lo que intentar volver a ejecutar la prueba con -t fallará sin el parámetro --disable-teardown . Utilice -d antes de -t para omitir el paso de limpieza de la prueba y realizar la prueba de forma iterativa.

atest -d test-to-run
atest -t test-to-run

Ejecutar métodos específicos

Atest admite la ejecución de métodos específicos dentro de una clase de prueba. Aunque es necesario construir todo el módulo, esto reduce el tiempo necesario para ejecutar las pruebas. Para ejecutar métodos específicos, identifique la clase usando cualquiera de las formas admitidas para identificar una clase (Módulo:Clase, ruta de archivo, etc.) y agregue el nombre del método:

atest reference-to-class#method1

Al especificar varios métodos, sepárelos con comas:

atest reference-to-class#method1,method2,method3

Ejemplos:

atest com.android.server.wm.ScreenDecorWindowTests#testMultipleDecors
atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval

Los dos ejemplos siguientes muestran las formas preferidas de ejecutar un único método, testFlagChange . Se prefieren estos ejemplos a usar solo el nombre de la clase porque especificar el módulo o la ubicación del archivo Java permite a Atest encontrar la prueba mucho más rápidamente.

Usando el módulo: Clase:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Desde repo-root de Android:

atest frameworks/base/services/tests/wmtests/src/com/android/server/wm/ScreenDecorWindowTests.java#testFlagChange

Se pueden ejecutar varios métodos desde diferentes clases y módulos:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Ejecutar múltiples clases

Para ejecutar varias clases, sepárelas con espacios de la misma manera que para ejecutar varias pruebas. Atest crea y ejecuta clases de manera eficiente, por lo que especificar un subconjunto de clases en un módulo mejora el rendimiento al ejecutar todo el módulo.

Para ejecutar dos clases en el mismo módulo:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

Para ejecutar dos clases en módulos diferentes:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

Ejecutar binarios de GTest

Atest puede ejecutar archivos binarios de GTest. Utilice -a para ejecutar estas pruebas para todas las arquitecturas de dispositivos disponibles, que en este ejemplo son armeabi-v7a (ARM de 32 bits) y arm64-v8a (ARM de 64 bits).

Ejemplo de prueba de entrada:

atest -a libinput_tests inputflinger_tests

Para seleccionar un binario GTest específico para ejecutar, use dos puntos (:) para especificar el nombre de la prueba y un hashtag (#) para especificar más un método individual.

Por ejemplo, para la siguiente definición de prueba:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Ejecute lo siguiente para especificar la prueba completa:

atest inputflinger_tests:InputDispatcherTest

O ejecute una prueba individual usando lo siguiente:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Ejecutar pruebas en TEST_MAPPING

Atest puede ejecutar pruebas en archivos TEST_MAPPING .

Ejecutar pruebas previas al envío implícitamente

Ejecute pruebas de envío previo en archivos TEST_MAPPING en los directorios actual y principal:

atest

Ejecute pruebas de envío previo en archivos TEST_MAPPING en /path/to/project y sus directorios principales:

atest --test-mapping /path/to/project

Ejecutar un grupo de prueba específico

Los grupos de prueba disponibles son: presubmit (predeterminado), postsubmit , mainline-presubmit y all .

Ejecute pruebas posteriores al envío en archivos TEST_MAPPING en los directorios actual y principal:

atest :postsubmit

Ejecute pruebas de todos los grupos en archivos TEST_MAPPING:

atest :all

Ejecute pruebas posteriores al envío en archivos TEST_MAPPING en /path/to/project y sus directorios principales:

atest --test-mapping /path/to/project:postsubmit

Ejecute pruebas de línea principal en archivos TEST_MAPPING en /path/to/project y sus directorios principales:

atest --test-mapping /path/to/project:mainline-presubmit

Ejecutar pruebas en subdirectorios

De forma predeterminada, Atest solo busca pruebas en archivos TEST_MAPPING hacia arriba (desde el directorio actual o dado hasta sus directorios principales). Si también desea ejecutar pruebas en archivos TEST_MAPPING en los subdirectorios, use --include-subdirs para forzar a Atest a incluir esas pruebas también:

atest --include-subdirs /path/to/project

Ejecutar pruebas en iteración.

Ejecute pruebas en iteración pasando el argumento --iterations . Ya sea que pase o falle, Atest repetirá la prueba hasta alcanzar la iteración máxima.

Ejemplos:

De forma predeterminada, Atest itera 10 veces. El número de iteraciones debe ser un número entero positivo.

atest test-to-run --iterations
atest test-to-run --iterations 5

Los siguientes enfoques facilitan la detección de pruebas inestables:

Método 1: ejecutar todas las pruebas hasta que se produzca una falla o se alcance la iteración máxima.

• Deténgase cuando ocurra una falla o la iteración llegue a la décima ronda (de forma predeterminada).

  atest test-to-run --rerun-until-failure
  

• Deténgase cuando ocurra una falla o la iteración llegue a la ronda número 100.

  atest test-to-run --rerun-until-failure 100
  

Enfoque 2: ejecutar solo las pruebas fallidas hasta que se aprueben o se alcance la iteración máxima.

• Supongamos que test-to-run tiene varios casos de prueba y una de las pruebas falla. Ejecute solo la prueba fallida 10 veces (de forma predeterminada) o hasta que pase la prueba.

  atest test-to-run --retry-any-failure
  

• Deje de ejecutar la prueba fallida cuando pase o llegue a la ronda 100.

  atest test-to-run --retry-any-failure 100
  

Ejecute pruebas en AVD

Atest puede ejecutar pruebas en un AVD recién creado. Ejecute acloud create para crear un AVD y compilar artefactos, luego use los siguientes ejemplos para ejecutar sus pruebas.

Inicie un AVD y ejecute pruebas en él:

acloud create --local-instance --local-image && atest test-to-run

Inicie un AVD como parte de una ejecución de prueba:

atest test-to-run --acloud-create "--local-instance --local-image"

Para obtener más información, ejecute acloud create --help .

Pasar opciones al módulo

Atest puede pasar opciones para probar módulos. Para agregar opciones de línea de comando de TradeFed a su ejecución de prueba, use la siguiente estructura y asegúrese de que sus argumentos personalizados sigan el formato de opción de línea de comando de Tradefed.

atest test-to-run -- [CUSTOM_ARGS]

Pase las opciones del módulo de prueba a los preparadores de destino o ejecutores de pruebas definidos en el archivo de configuración de prueba:

atest test-to-run -- --module-arg module-name:option-name:option-value
atest GtsPermissionTestCases -- --module-arg GtsPermissionTestCases:ignore-business-logic-failure:true

Opciones de pase a un tipo o clase de corredor:

atest test-to-run -- --test-arg test-class:option-name:option-value
atest CtsVideoTestCases -- --test-arg com.android.tradefed.testtype.JarHosttest:collect-tests-only:true

Para obtener más información sobre las opciones de solo prueba, consulte Pasar opciones a los módulos .