Google se compromete a promover la equidad racial para las comunidades negras. Ver cómo.
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 comando que permite a los usuarios construir, instalar y ejecutar pruebas de Android localmente, acelerando enormemente las repeticiones de prueba sin requerir conocimiento de las opciones de línea de comandos de arnés de prueba de la Federación de Comercio . 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 del desarrollador 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 el Flujo de trabajo del desarrollador de Atest .

Configurando su entorno

Para ejecutar Atest, siga los pasos en las secciones a continuación para configurar su entorno.

Establecer variable de entorno

Establezca test_suite para Soong o LOCAL_COMPATIBILITY_SUITE para las reglas de script de compilación Make per Packaging .

1. Ejecute envsetup.sh

Desde la raíz de la comprobación de origen de Android, ejecute:

source build/envsetup.sh

2. Ejecute el almuerzo

Ejecute el comando $ lunch para abrir 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 [ optional-arguments ] test-to-run

Argumentos opcionales

Puede usar los siguientes argumentos opcionales con los comandos Atest.

Opción Opción larga Descripción
-b --build Crea 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 Inhabilita el desmontaje y la limpieza de prueba.
--info Muestra la información relevante de los objetivos y salidas especificados.
--dry-run Un sinónimo de --info.
-m --rebuild-module-info Fuerza la 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 de nivel de DEPURACIÓN.
--generate-baseline Genera métricas de línea de base, ejecuta 5 iteraciones por defecto.
--generate-new-metrics Genera nuevas métricas, ejecuta 5 iteraciones por defecto.
--detect-regression Ejecuta el 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 dispositivo 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 requiere 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 correr

Puede ejecutar una o más pruebas usando 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.

Pruebas de identificación

Puede especificar el argumento de test-to-run con el nombre del módulo de prueba, Módulo: clase, nombre de clase, prueba de integración TF, ruta de archivo o nombre de 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 . 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 el nombre de un 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 fuente completo si no se indica ningún módulo.

Ejemplos (ordenados del más rápido al más lento):

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

Prueba de integración TF

Para ejecutar pruebas que se integran 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

Puede ejecutar 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 puede ejecutar una sola clase especificando la ruta al archivo Java de la clase. Ambas rutas relativas y absolutas son compatibles.

Ejemplo: dos formas de ejecutar el módulo CtsJankDeviceTestCases través de la ruta

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

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

    atest .
    

Ejemplo: ejecutar 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: ejecutar una prueba de integración por ruta. Desde Android repo-root :

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

Nombre del paquete

Atest admite búsquedas de búsqueda 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 utilizando 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 pruebas solamente: atest -t test-to-run
  • Instale apk y ejecute pruebas: atest -it test-to-run
  • Compila y ejecuta, pero no instales: 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 . Use -d before -t para omitir el paso de limpieza de prueba y pruebe 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 construir 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 del 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 único método, testFlagChange . Estos ejemplos son preferibles a solo usar el nombre de 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 múltiples 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 se ejecutan varias pruebas. Atest construye y ejecuta clases de manera eficiente, por lo que especificar un subconjunto de clases en un módulo mejora el rendimiento sobre la ejecución de 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
    

Ejecutando pruebas nativas

Atest puede ejecutar pruebas nativas.

Ejemplos:

  • Pruebas de entrada:

    atest -a libinput_tests inputflinger_tests
    

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

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

 TEST_F(InputDispatcherTest, InjectInputEvent_ValidatesKeyEvents) 

Puede ejecutar toda la prueba usando

 atest inputflinger_tests:InputDispatcherTest 

o un método de prueba individual usando

 atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents 

Detección de regresión de métricas

Puede generar métricas previas o posteriores a la revisión 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 línea de base (parche previo) 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. Utilizando una carpeta que contiene métricas posteriores al parche generadas previamente, Atest ejecuta las pruebas n iteraciones, genera un nuevo conjunto de métricas previas al parche y las compara con las proporcionadas.

    Ejemplo:

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

    Ejemplo:

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