Se usó la API de Cloud Translation para traducir esta página.

Una prueba

Atest es una herramienta de línea de comandos que permite a los usuarios construir, instalar y ejecutar las pruebas de Android a nivel local, lo que acelera enormemente la prueba re-corre sin necesidad de conocimientos de instrumento de prueba Federación de Comercio opciones de línea de comandos. Esta página explica cómo usar Atest para ejecutar pruebas de Android.

Para obtener información general sobre cómo escribir pruebas para Android, consulte Android Plataforma de la prueba .

Para obtener información sobre la estructura general de Atest, ver Atest Guía del Desarrollador .

Para obtener información sobre la ejecución de pruebas en archivos a través TEST_MAPPING Atest, consulte Ejecución de pruebas en los archivos TEST_MAPPING .

Y para agregar una función para Atest, siga Atest desarrollador de flujo de trabajo .

Configurando su entorno

Para ejecutar Atest, siga los pasos de las secciones siguientes para configurar su entorno.

Establecer variable de entorno

Test_suite conjunto de Soong o LOCAL_COMPATIBILITY_SUITE Para haga por Packaging reglas de escritura de la estructura .

Ejecute envsetup.sh

Desde la raíz de la verificación de la fuente de Android, ejecute:

source build/envsetup.sh

Ejecutar el almuerzo

Ejecutar el lunch comando para que aparezca un menú de dispositivos compatibles. Encuentra el dispositivo y ejecuta ese comando.

Por ejemplo, si tiene un dispositivo ARM conectado, ejecute el siguiente comando:

lunch aosp_arm64-eng

Esto establece diversas variables de entorno necesarias para el funcionamiento de Atest y añade el comando Atest a tu $PATH .

Uso básico

Los comandos Atest tienen la siguiente forma:

atest test-to-run [optional-arguments]

Argumentos opcionales

A continuación se muestran los argumentos más utilizados. Una lista completa está disponible a través atest --help .

Opción	Opción larga	Descripción
`-b`	`--build`	Construye objetivos de prueba. (defecto)
`-i`	`--install`	Instala artefactos de prueba (APK) en el dispositivo. (defecto)
`-t`	`--test`	Ejecuta las pruebas. (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 prueba.
	`--info`	Muestra la información relevante de los objetivos y salidas especificados.
	`--dry-run`	Pruebas en seco sin construir, instalar y ejecutar pruebas en la actualidad
`-m`	`--rebuild-module-info`	Fuerza la reconstrucción del `module-info.json` archivo.
`-w`	`--wait-for-debugger`	Espera al depurador antes de la ejecución. Solo para pruebas de instrumentación.
`-v`	`--verbose`	Muestra el registro del nivel DEBUG.
	`--iterations`	Pruebas en bucle hasta que se alcanza la iteración máxima. (10 por defecto)
	`--rerun-until-failure [COUNT=10]`	Vuelve a ejecutar todas las pruebas hasta que se produce 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 pasan 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 AVDs utilizando el `acloud command.`
	`--[CUSTOM_ARGS]`	Especifica argumentos personalizados para los corredores de prueba.
`-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 requiere un dispositivo con `--host` fallará.)
	`--flakes-info`	Muestra el resultado de la prueba con información de escamas.
	`--history`	Muestra el resultado de la prueba 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 los pasos Especificación: construir, instalar, o correr.

Pruebas para ejecutar

Puede ejecutar una o más pruebas utilizando test-to-run . Para ejecutar varias pruebas, separe las referencias de prueba con espacios. Por ejemplo:

atest test-to-run-1 test-to-run-2

Aquí hay unos ejemplos:

atest FrameworksServicesTests
atest example/reboot
atest FrameworksServicesTests CtsVideoTestCases
atest FrameworksServicesTests:ScreenDecorWindowTests

Para obtener más información acerca de cómo hacer referencia a una prueba, consulte Identificación de pruebas.

Identificación de pruebas

Se puede especificar la test-to-run argumento con el nombre de la prueba de módulo, Módulo: Clase, nombre de la clase, prueba de integración del TF, la ruta del archivo o el nombre del paquete.

Nombre del módulo

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

Ejemplos:

atest FrameworksServicesTests
atest CtsVideoTestCases

Módulo: Clase

Para ejecutar una única clase dentro de un módulo, utilice Módulo: Clase. Módulo es el mismo que se describe en el nombre de módulo . Clase es el nombre de la clase de prueba en el .java archivo y puede ser el nombre completo de la clase o el nombre básico.

Ejemplos:

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

Nombre de la clase

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

Ejemplos:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Uso del módulo: Clase de referencia se recomienda siempre que sea posible, ya que Atest requiere más tiempo para buscar el árbol de código fuente completo para partidos potenciales si no se indica módulo.

Ejemplos (ordenados de más rápido a más lento):

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

Prueba de integración TF

Para ejecutar las pruebas que se integran directamente en TradeFed (no módulos de entrada), el nombre que aparece en la salida de la tradefed.sh list configs de comandos. Por ejemplo:

Para ejecutar el reboot.xml prueba :

atest example/reboot

Para ejecutar el native-benchmark.xml de prueba :

atest native-benchmark

Ruta de archivo

Puede ejecutar pruebas basadas en módulos y pruebas basadas en integración ingresando la ruta a su archivo de prueba o directorio según corresponda. También puede ejecutar una sola clase especificando la ruta al archivo Java de la clase. Se admiten rutas relativas y absolutas.

Ejemplo: dos formas de ejecutar la CtsVideoTestCases módulo a través de camino

Módulo de ejecutar desde Android repo-root :
```
atest cts/tests/video
```
Desde Android repo-root / cts / pruebas / vídeo:
```
atest .
```

Ejemplo: Ejecutar una clase específica dentro CtsVideoTestCases módulo a través de camino. Desde Android repo-root :

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

Ejemplo: Ejecute una prueba de integración a través de la ruta. Desde Android repo-root :

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 pasos: compilar, instalar o ejecutar

Puede especificar los pasos a ejecutar mediante el uso de la -b , -i , y -t opciones. Si no especifica una opción, se ejecutan todos los pasos.

Tipos de generación única: atest -b test-to-run
Ejecutar pruebas de forma única: atest -t test-to-run
Instalar apk y ejecutar pruebas: atest -it test-to-run
Generar y ejecutar, pero no se instalan: atest -bt test-to-run

Atest puede forzar una prueba para omitir el paso de limpieza / desmontaje. Muchas pruebas, como CTS, A Limpiar el dispositivo después de que se ejecute la prueba, por lo que intentar volver a ejecutar la prueba con -t fallará sin la --disable-teardown parámetro. Use -d antes de -t para omitir la prueba de paso limpio y prueba de forma iterativa.

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

Ejecutando métodos específicos

Puede ejecutar métodos específicos dentro de una clase de prueba. Aunque es necesario compilar todo el módulo, esto reduce el tiempo necesario para ejecutar las pruebas. Para ejecutar métodos específicos, identifique la clase utilizando 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

Puede especificar varios métodos 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 para ejecutar un método único, 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 que Atest encuentre la prueba mucho más rápido:

Usando el módulo: clase

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Desde Android repo-root

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

Ejecutando múltiples clases

Para ejecutar varias clases, sepárelas con espacios de la misma manera que ejecuta varias pruebas. Atest compila 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.

Ejemplos:

Dos clases en el mismo módulo:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

Dos clases en diferentes módulos:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

Ejecución de pruebas nativas

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

Ejemplos:

Pruebas de entrada:

atest -a libinput_tests inputflinger_tests

Para seleccionar una prueba nativa específica para ejecutar, use dos puntos (:) para especificar el nombre de la prueba y el hashtag (#) para especificar más un método individual. Por ejemplo, para la definición de la prueba siguiente:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Puede ejecutar toda la prueba usando

atest inputflinger_tests:InputDispatcherTest

o un método de ensayo individual usando

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Ejecutando pruebas en TEST_MAPPING

Atest puede ejecutar pruebas en archivos TEST_MAPPING.

Ejecute pruebas de preenvío implícitamente en archivos TEST_MAPPING en directorios actuales, principales o específicos.
Pruebas de presentar previamente ejecute en archivos TEST_MAPPING en directorios actuales y de los padres:
```
atest
```
Pruebas de presentar previamente ejecute en archivos TEST_MAPPING en /path/to/project y sus directorios padre:
```
atest --test-mapping /path/to/project
```
Ejecutar un grupo de prueba especificado en TEST_MAPPING archivos; grupos de prueba disponibles son: presubmit (por defecto), postsubmit , mainline-presubmit y all .
- Pruebas postsubmit ejecute en archivos TEST_MAPPING en directorios actuales y de los padres:
```
atest :postsubmit
```
- Ejecutar pruebas de todos los grupos de archivos TEST_MAPPING:
```
atest :all
```
- Pruebas postsubmit ejecute en archivos TEST_MAPPING en /path/to/project y sus directorios padre
```
atest --test-mapping /path/to/project:postsubmit
```
- Ejecutar las pruebas de la línea principal en los archivos TEST_MAPPING en /path/to/project y sus directorios padre
```
atest --test-mapping /path/to/project:mainline-presubmit
```
Ejecute pruebas en archivos TEST_MAPPING, incluidos subdirectorios.

De forma predeterminada, atest solo busca pruebas en archivos TEST_MAPPING hacia arriba (desde el actual o el dado hasta sus directorios principales). Si también desea ejecutar pruebas en archivos TEST_MAPPING en los subdirectorios, puede utilizar la opción --include-subdirs para forzar atest para incluir esas pruebas también.

Pruebas de presentar previamente ejecute en archivos TEST_MAPPING en la corriente, los padres y subdirectorios:

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

Ejecución de pruebas en iteración

Para ejecutar las pruebas en iteración, simplemente pasar el --iterations argumento. Ya sea que pase o falle, una prueba no dejará de probar hasta que se alcance la iteración máxima.

Ejemplos:

Por defecto, atest itera 10 veces, dando un número entero para cambiar la ronda de iteración.

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

Dos enfoques que ayudan a los usuarios a detectar pruebas inestables:

Método 1: Ejecute 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 (por defecto).
```
atest test-to-run --rerun-until-failure
```
Deténgase cuando se produzca una falla o la iteración llegue a la ronda número 100.
```
atest test-to-run --rerun-until-failure 100
```

Método 2: Ejecute solo las pruebas fallidas hasta que se aprueben o se alcance la iteración máxima.

Asumir test-to-run tiene cinco casos de prueba y una de las pruebas falla. Ejecute solo la prueba fallida 10 veces 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 número 100.
```
atest test-to-run --retry-any-failure 100
```

Ejecución de pruebas en AVD

Atest puede ejecutar pruebas con el AVD recién creado. Atest puede construir artefactos junto con el corredor acloud create y ejecutar pruebas después de la AVD se ha creado correctamente.

Ejemplos:

Iniciar una AVD antes de ejecutar las pruebas en ese dispositivo recién creado:
```
acloud create && atest test-to-run
```
Ahora se pueden simplificarse:
```
atest test-to-run --start-avd
```

AVDs comenzar especificando el acloud create argumentos y las pruebas realizadas en ese dispositivo recién creado.

atest test-to-run --acloud-create "--build-id 6509363 --build-target aosp_cf_x86_phone-userdebug --branch aosp_master"

Para obtener detalles sobre el uso del argumento, ejecute acloud create --help .

Pasar opciones al módulo

Atest puede pasar opciones a los módulos. El formato breve de línea de comandos Atest añadir la opción de línea de comandos es TradeFed

atest test-to-run -- [CUSTOM_ARGS]

Los CUSTOM_ARGS [] deben seguir los formatos de línea de comando opción Tradefed.

Ejemplos de pasar las opciones del módulo de prueba a los preparadores de destino o los corredores de prueba 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

Ejemplos de opciones de pase al 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 pruebas únicas opciones, consulte Opciones Pass a los módulos