Una prueba

Atest es una herramienta de línea de comandos que permite a los usuarios crear, instalar y ejecutar pruebas de Android de forma local, lo que acelera enormemente las repeticiones de pruebas sin necesidad de conocer las opciones de la línea de comandos del arnés de pruebas de Trade Federation . 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 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 .

Y para agregar una función a Atest, siga Atest Developer Workflow .

Configurando su entorno

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

Establecer variable de entorno

Configure test_suite para Soong o LOCAL_COMPATIBILITY_SUITE para las reglas de secuencia de comandos de compilación Make per Packaging .

Ejecute envsetup.sh

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

source build/envsetup.sh

Ejecutar el almuerzo

Ejecute el comando lunch 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 varias variables de entorno necesarias para ejecutar Atest y agrega el comando Atest a su $PATH .

Uso básico

Los comandos de prueba toman 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 de una atest --help .

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

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 sobre cómo hacer referencia a una prueba, consulte Identificación de pruebas.

Identificación de pruebas

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

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 Android.mk o Android.bp archivo LOCAL_MODULE o LOCAL_PACKAGE_NAME 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 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: se recomienda la referencia de clase siempre que sea posible, ya que Atest requiere más tiempo para buscar posibles coincidencias en el árbol de fuentes completo si no se indica ningún 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 pruebas que están integradas directamente en TradeFed (no 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

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 el módulo CtsVideoTestCases través de la ruta

1. Ejecute el módulo desde repo-root Android:

   atest cts/tests/video
   

2. Desde Android repo-root / cts / tests / video:

   atest .
   

Ejemplo: Ejecute una clase específica dentro del módulo CtsVideoTestCases través de la ruta. 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 android.jank.cts

Especificación de pasos: compilar, instalar o ejecutar

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

• Solo objetivos de compilación: atest -b test-to-run
• Ejecutar 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 forzar una prueba para omitir el paso de limpieza / 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 probar 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 siguientes dos ejemplos muestran las formas preferidas de ejecutar un solo 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 que Atest encuentre la prueba mucho más rápido:

1. Usando Módulo: Clase

   atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange
   

2. 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 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.

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 de 32 bits) y arm64-v8a (ARM de 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 siguiente definición de prueba:

TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents)

Puede ejecutar la prueba completa usando

atest inputflinger_tests:InputDispatcherTest

o un método de prueba individual usando

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Ejecución de pruebas en iteración

Para ejecutar pruebas en iteración, simplemente pase el argumento --iterations . 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 100.

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

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

• Suponga que la 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 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 ejecutar acloud create y ejecutar pruebas después de que el AVD se haya creado con éxito.

Ejemplos:

• Inicie un AVD antes de ejecutar pruebas en ese dispositivo recién creado:

  acloud create && atest test-to-run
  

  Ahora se puede simplificar con:

  atest test-to-run --start-avd
  

• Inicie los AVD especificando acloud create argumentos en la acloud create y ejecute pruebas 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 de uso sobre el argumento, ejecute acloud create --help .