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

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 .

1. Ejecute envsetup.sh

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

source build/envsetup.sh

2. 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 tienen la siguiente forma:

atest [optional-arguments] test-to-run

Argumentos opcionales

Puede utilizar los siguientes argumentos opcionales con los comandos Atest.

Opción Opción larga Descripción
-b --build Construye objetivos de prueba.
-i --install Instala artefactos de prueba (APK) en el dispositivo.
-t --test Ejecuta las pruebas.
-s --serial Ejecuta las pruebas en el dispositivo especificado. Se puede probar un dispositivo a la vez.
-d --disable-teardown Deshabilita la prueba de desmontaje y limpieza.
--info Muestra la información relevante de los objetivos y salidas especificados.
--dry-run Un sinónimo de --info.
-m --rebuild-module-info Fuerza una reconstrucción del archivo module-info.json.
-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.
--generate-baseline Genera métricas de referencia, ejecuta 5 iteraciones de forma predeterminada.
--generate-new-metrics Genera nuevas métricas, ejecuta 5 iteraciones por defecto.
--detect-regression Ejecuta un algoritmo de detección de regresión.
--[CUSTOM_ARGS] Especifica argumentos personalizados para los corredores de prueba.
-a --all-abi Ejecuta las pruebas para todas las arquitecturas de dispositivos disponibles.
-h --help Muestra mensaje de ayuda y salidas.
--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á).

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 CtsJankDeviceTestCases
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 clase, prueba de integración TF, ruta de 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 CtsJankDeviceTestCases

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 CtsJankDeviceTestCases:CtsDeviceJankUi

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 CtsDeviceJankUi

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 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 CtsJankDeviceTestCases través de la ruta

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

    atest cts/tests/jank
    
  2. Desde android repo-root / cts / tests / jank:

    atest .
    

Ejemplo: Ejecute una clase específica dentro del módulo CtsJankDeviceTestCases través de la ruta. Desde android repo-root :

atest cts/tests/jank/src/android/jank/cts/ui/CtsDeviceJankUi.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.

  • Construir solo objetivos: 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 dos ejemplos siguientes muestran las formas preferidas de ejecutar un único método, testFlagChange . Estos ejemplos son preferibles 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/servicestests/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 CtsJankDeviceTestCases:CtsDeviceJankUi
    

Ejecución de pruebas nativas

Atest puede ejecutar pruebas nativas.

Ejemplos:

  • Pruebas de entrada:

    atest -a libinput_tests inputflinger_tests
    

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

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

Detectar regresión de métricas

Puede generar métricas anteriores o posteriores al parche sin ejecutar la detección de regresión. Puede especificar el número de iteraciones, pero el valor predeterminado es cinco.

Ejemplos:

atest test-to-run --generate-baseline [optional-iteration]
atest test-to-run --generate-new-metrics [optional-iteration]

La detección de regresión local se puede ejecutar en tres opciones:

  1. Genere métricas de referencia (previas al parche) y colóquelas en una carpeta. Atest ejecuta las pruebas a través de las iteraciones especificadas, genera métricas posteriores al parche y las compara con las métricas existentes.

    Ejemplo:

    atest test-to-run --detect-regression /path/to/baseline --generate-new-metrics [optional-iteration]
    
  2. Uso de una carpeta que contiene las métricas de post-parche generados previamente, Atest ejecuta las pruebas n iteraciones, genera un nuevo conjunto de métricas pre-parche, y compara aquellos contra los previstos.

    Ejemplo:

    atest test-to-run --detect-regression /path/to/new --generate-baseline [optional-iteration]
    
  3. Utilizando dos carpetas que contienen métricas previas y posteriores al parche, Atest ejecuta el algoritmo de detección de regresión sin ninguna prueba.

    Ejemplo:

    atest --detect-regression /path/to/baseline /path/to/new