Ejecutar pruebas (Atest)

Atest es una herramienta de línea de comandos que permite a los usuarios compilar, instalar y ejecutar Pruebas de Android a nivel local, lo que acelera considerablemente las repeticiones de pruebas sin necesidad Contar con conocimientos sobre el agente de prueba de la Federación de Comercio opciones de línea de comandos. En esta página, se explica cómo usar Atest para ejecutar Android y pruebas.

Para obtener información general sobre cómo escribir pruebas para Android, consulta Prueba de la plataforma de Android.

Para obtener información sobre la estructura general de Atest, consulta la Guía para desarrolladores más reciente.

Para obtener información sobre cómo ejecutar pruebas en archivos TEST_MAPPING con Atest, consulta Ejecuta pruebas en archivos TEST_MAPPING.

Para agregar una función a Atest, sigue la Flujo de trabajo de Atest Developer.

Desarrolla tu entorno

Para configurar tu entorno de Atest, sigue las instrucciones que se indican en Configura el entorno, Cómo elegir un destino y Cómo compilar el código.

Uso básico

Los comandos de Atest tienen el siguiente formato:

atest test-to-run [optional-arguments]

Argumentos opcionales

En la siguiente tabla, se enumeran los argumentos más utilizados. Hay una lista completa disponible a través de atest --help.

Opción	Opción larga	Descripción
-b	--build	Compila objetivos de prueba. (predeterminado)
-i	--install	Instala artefactos de prueba (APK) en el dispositivo. (predeterminado)
-t	--test	Ejecuta las pruebas. (predeterminado)
-s	--serial	Ejecuta las pruebas en el dispositivo especificado. Solo se puede probar un dispositivo a la vez.
-d	--disable-teardown	Inhabilita el proceso de desmontaje y limpieza de prueba.
	--dry-run	Ejecuta Atest sin compilar, instalar ni ejecutar pruebas.
-m	--rebuild-module-info	Fuerza una recompilación del archivo module-info.json.
-w	--wait-for-debugger	Espera a que finalice el depurador antes de ejecutarse.
-v	--verbose	Muestra el registro de nivel DEBUG.
	--iterations	Ejecuta pruebas en bucle hasta alcanzar la iteración máxima. (10 de forma predeterminada)
	--rerun-until-failure [COUNT=10]	Vuelve a ejecutar todas las pruebas hasta que se produce un error o se alcanza la cantidad máxima de iteraciones alcanzada. (10 de forma predeterminada)
	--retry-any-failure [COUNT=10]	Vuelve a ejecutar las pruebas fallidas hasta que se aprueban o se alcanza la iteración máxima. (10 de forma predeterminada)
	--start-avd	Crea automáticamente un AVD y ejecuta pruebas en el dispositivo virtual.
	--acloud-create	Crea un AVD con 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 por completo en el host sin un dispositivo. Nota: Ejecutar una prueba de host que requiera un dispositivo con --host fallarán.
	--history	Muestra los resultados de la prueba en orden cronológico.
	--latest-result	Imprime el resultado más reciente de la prueba.

Para obtener más información sobre -b, -i y -t, consulta la Sección Especifica los pasos: compilar, instalar o ejecutar.

Cómo especificar pruebas

Para ejecutar pruebas, especifica una o más con uno de los siguientes identificadores:

• Nombre del módulo
• Módulo:Clase
• Nombre de clase
• Prueba de integración de Tradefed
• Ruta de acceso al archivo
• Nombre de paquete

Separa las referencias a varias pruebas con espacios, como en el siguiente ejemplo:

atest test-identifier-1 test-identifier-2

Nombre del módulo

Para ejecutar un módulo de prueba completo, usa su nombre de módulo. Ingresa el nombre tal como aparece en las variables LOCAL_MODULE o LOCAL_PACKAGE_NAME en la carpeta Archivo Android.mk o Android.bp.

Ejemplos:

atest FrameworksServicesTests
atest CtsVideoTestCases

Nota: Para ejecutar pruebas que no sean de módulos integradas en TradeFed (TF), usa Prueba de integración de TF como identificador.

Módulo:Clase

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

Ejemplos:

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

Nota: Para reducir el tiempo que tarda Atest en encontrar la prueba correcta, recomendamos con la ruta de acceso de la clase completa, como se muestra en el último ejemplo.

Nombre de clase

Para ejecutar una sola clase sin indicar explícitamente un nombre de módulo, usa la clase de la fuente de datos.

Ejemplos:

atest ScreenDecorWindowTests
atest VideoEncoderDecoderTest

Nota: Para reducir el tiempo que tarda Atest en encontrar la prueba correcta, te recomendamos que uses Module:Class en lugar de solo el nombre de la clase siempre que sea posible.

Prueba de integración de Tradefed

Para ejecutar pruebas que estén integradas directamente en TradeFed (que no sean módulos), ingresa nombre como aparece en el resultado del comando tradefed.sh list configs. Por ejemplo:

Para ejecutar Prueba reboot.xml:

atest example/reboot

Para ejecutar Prueba native-benchmark.xml:

atest native-benchmark

Ruta de acceso al archivo

Atest admite la ejecución de pruebas basadas en módulos y pruebas basadas en la integración. Para ello, debes ingresar la ruta de acceso al archivo o directorio de prueba según corresponda. También admite la ejecución de una sola clase especificando la ruta de acceso al archivo Java de la clase. Se admiten rutas de acceso relativas y absolutas.

Cómo ejecutar un módulo

En los siguientes ejemplos, se muestran dos formas de ejecutar el módulo CtsVideoTestCases con una ruta de acceso de archivo.

Ejecutar desde Android repo-root:

atest cts/tests/video

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

    atest .

Cómo ejecutar una clase de prueba

En el siguiente ejemplo, se muestra cómo ejecutar una clase específica dentro del módulo CtsVideoTestCases con una ruta de acceso de archivo.

Desde Android repo-root:

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

Ejecuta una prueba de integración

En el siguiente ejemplo, se muestra cómo ejecutar una prueba de integración con una ruta de acceso a archivos De Android repo-root:

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

Nombre de paquete

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

Ejemplos:

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

Especifica los pasos: Compilación, instalación o ejecución

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

Nota: -b y -t se pueden ejecutar de forma individual, pero -i no se puede ejecutar sin -t.

• Solo objetivos de compilación: atest -b test-to-run
• Ejecutar solo pruebas: atest -t test-to-run
• Instala el APK y ejecuta las pruebas: atest -it test-to-run
• Compila y ejecuta, pero no lo instales: atest -bt test-to-run

Atest puede forzar una prueba para que omita el paso de limpieza o desmontaje. Muchas pruebas, como CTS, limpia el dispositivo después de ejecutar la prueba, por lo que debes intentar volver a ejecutar la prueba con -t fallará sin el parámetro --disable-teardown. Usa -d antes del -t para omitir el paso de limpieza de pruebas y realizar la prueba iterativamente.

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

Nota: Debido a que -t inhabilita la configuración/instalación y la desinstalación/limpieza del dispositivo, puedes volver a ejecutar la prueba con atest -t test-to-run tantas veces como desees.

Ejecuta métodos específicos

Atest admite la ejecución de métodos específicos dentro de una clase de prueba. Aunque se debe compilar todo el módulo, esto reduce el tiempo necesario para ejecutar las pruebas. Para ejecutar métodos específicos, identifica la clase con cualquiera de las formas compatibles para identificar una clase (Module:Class, ruta de acceso al archivo, etcétera) y agrega el nombre del método:

atest reference-to-class#method1

Cuando especifiques varios métodos, sepáralos con comas:

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

Ejemplos:

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

En los dos ejemplos siguientes, se muestran las formas preferidas de ejecutar un solo método: testFlagChange Se prefieren estos ejemplos en lugar de solo usar el nombre de clase porque especificar el módulo o la ubicación del archivo Java permite que Atest encuentre probar mucho más rápido.

Uso de Module:Class:

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 a partir de diferentes clases y módulos:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange,testRemoval ScreenDecorWindowTests#testMultipleDecors

Ejecuta varias clases

Para ejecutar varias clases, sepáralas con espacios de la misma manera que lo harías para ejecutar varias pruebas. Atest compila y ejecuta las clases de manera eficiente, por lo que especificar un subconjunto de clases en un módulo mejora el rendimiento en comparación con la ejecución completa módulo.

Para ejecutar dos clases en el mismo módulo, haz lo siguiente:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

Para ejecutar dos clases en módulos diferentes, haz lo siguiente:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

Ejecuta objetos binarios de GTest

Atest puede ejecutar objetos binarios de GTest. Usa -a para ejecutar estas pruebas en todas las pruebas disponibles de dispositivos de Windows, 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

Nota: Si solo necesitas ejecutar pruebas para una arquitectura de dispositivo específica, usa atest -- --abi arm64-v8a o atest -- --abi armeabi-v7a

Si quieres seleccionar un objeto binario de GTest específico para ejecutar, usa dos puntos (:) para indicar la prueba y un hashtag (#) para especificar un método individual.

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

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Ejecuta el siguiente comando para especificar la prueba completa:

atest inputflinger_tests:InputDispatcherTest

También puedes ejecutar una prueba individual con lo siguiente:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Ejecutar pruebas en TEST_MAPPING

Atest puede ejecutar pruebas en archivos TEST_MAPPING.

Ejecuta pruebas previas al envío de forma implícita

Ejecuta pruebas de envío previo en archivos TEST_MAPPING, en los directorios actuales y superiores:

atest

Ejecuta pruebas previas al envío en archivos TEST_MAPPING en /path/to/project y sus directorios superiores:

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

Ejecuta un grupo de prueba especificado

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

Ejecuta pruebas posteriores al envío en los archivos TEST_MAPPING de los directorios principales y actuales:

atest :postsubmit

Ejecuta pruebas de todos los grupos en los archivos TEST_MAPPING:

atest :all

Ejecuta pruebas posteriores al envío en los archivos TEST_MAPPING en /path/to/project y sus directorios superiores:

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

Ejecuta pruebas de línea principal en los archivos TEST_MAPPING en /path/to/project y sus directorios superiores:

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

Cómo ejecutar pruebas en subdirectorios

De forma predeterminada, Atest solo busca pruebas en archivos TEST_MAPPING en orden ascendente (desde el directorio actual o determinado en sus directorios superiores). Si también quieres Para ejecutar pruebas en los archivos TEST_MAPPING de los subdirectorios, usa --include-subdirs para forzar a Atest a que también incluya esas pruebas:

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

Ejecutar pruebas de iteración

Para ejecutar pruebas en iteración, pasa el argumento --iterations. Si se aprueba o falla, Atest repetirá la prueba hasta que se alcance la iteración máxima.

Ejemplos:

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

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

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

Enfoque 1: Ejecuta todas las pruebas hasta que se produzca una falla o se alcance la iteración máxima.

• Deténgase cuando se produzca 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 se produzca una falla o la iteración llegue a la ronda 100.

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

Enfoque 2: Ejecutar solo las pruebas con errores hasta que se aprueben o se alcance la iteración máxima

• Supón que test-to-run tiene varios casos de prueba y uno de las pruebas fallan. Ejecutar solo la prueba con errores 10 veces (de forma predeterminada) o hasta que pruebas aprobadas.

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

• Detén la ejecución de la prueba con errores cuando se completa o alcanza la ronda 100.

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

Cómo ejecutar pruebas en AVD

Atest puede ejecutar pruebas en un AVD recién creado. Ejecuta acloud create para crear un AVD y artefactos de compilación, luego usa los siguientes ejemplos para ejecutar tus pruebas.

Inicia un AVD y ejecuta pruebas en él:

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

Inicia 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, ejecuta acloud create --help.

Nota: --acloud-create debe ser el ÚLTIMO argumento opcional. Cualquier argumento que lo siga se considerará un argumento posicional para el AVD.

Nota: --acloud-create y --start-avd no borran los AVD creados recientemente. Los usuarios deben borrarlas de forma manual.

Pasar opciones al módulo

Atest puede aprobar opciones para probar módulos. Agrega la línea de comandos de TradeFed opciones para la ejecución de tu prueba, usa la siguiente estructura y asegúrate de que tus los argumentos siguen el formato de opción de línea de comandos de Tradefed.

atest test-to-run -- [CUSTOM_ARGS]

Pasar las opciones del módulo de prueba para preparar el destino o los 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

Pasa opciones a un tipo o clase de ejecutor:

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 solo de prueba, consulta Pasar opciones a los módulos