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
.
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 | Deshabilita la prueba de desmontaje y limpieza. |
--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 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. |
--iterations | Pruebas en bucle hasta que se alcanza la iteración máxima. (10 por defecto) | |
--rerun-until-failure | 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 | Vuelve a ejecutar las pruebas fallidas hasta que se superan 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 AVD usando 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 requiera 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 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
Ejecute el módulo desde repo-root Android:
atest cts/tests/video
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:
Usando 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 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
atest test-to-run --start-avd
Inicie los AVD especificando
acloud create
argumentos en laacloud 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
.