Ejecución de pruebas (Atest),Ejecución de pruebas (Atest)

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

Para agregar una característica a Atest, siga el flujo de trabajo del desarrollador de Atest .

Configuración de su entorno

Siga los pasos de las siguientes secciones para configurar su entorno Atest.

Establecer variable de entorno

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

Ejecute envsetup.sh

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

source build/envsetup.sh

ejecutar el lunch

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 Atest toman la siguiente forma:

atest test-to-run [optional-arguments]

Argumentos opcionales

En la tabla siguiente se enumeran los argumentos más utilizados. Una lista completa está disponible a través atest --help .

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

Especificar pruebas

Para ejecutar pruebas, especifique una o más pruebas utilizando uno de los siguientes identificadores:

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

Separe las referencias a varias pruebas con espacios, así:

atest test-identifier-1 test-identifier-2

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 LOCAL_MODULE o LOCAL_PACKAGE_NAME en el archivo Android.mk o Android.bp 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 completo de la clase o el nombre básico.

Ejemplos:

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

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

Prueba de integración de Tradefed

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 de reboot.xml :

atest example/reboot

Para ejecutar la prueba native-benchmark.xml :

atest native-benchmark

Ruta de archivo

Atest admite la ejecución de 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 admite la ejecución de una sola clase especificando la ruta al archivo Java de la clase. Se admiten rutas relativas y absolutas.

Ejecutar un módulo

Los siguientes ejemplos muestran dos formas de ejecutar el módulo CtsVideoTestCases usando una ruta de archivo.

Ejecutar desde repo-root de Android:

atest cts/tests/video

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

    atest .

Ejecutar una clase de prueba

El siguiente ejemplo muestra cómo ejecutar una clase específica dentro del módulo CtsVideoTestCases usando una ruta de archivo.

Desde repo-root Android:

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

Ejecutar una prueba de integración

El siguiente ejemplo muestra cómo ejecutar una prueba de integración utilizando una ruta de archivo desde repo-root de Android:

    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 com.android.uibench.janktests

Especifique los pasos: compilar, instalar o ejecutar

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

• Solo objetivos de compilación: atest -b test-to-run
• Ejecutar pruebas únicamente: atest -t test-to-run
• Instalar apk y ejecutar pruebas: atest -it test-to-run
• Compile y ejecute, pero no instale: atest -bt test-to-run

Atest puede obligar a una prueba a omitir el paso de limpieza o 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 antes de -t para omitir el paso de limpieza de la prueba y probar iterativamente.

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

Ejecutar métodos específicos

Atest admite la ejecución de 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

Al especificar varios métodos, sepárelos 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 . Estos ejemplos son preferibles a usar solo el nombre de la clase porque especificar el módulo o la ubicación del archivo Java le permite a Atest encontrar la prueba mucho más rápido.

Usando Módulo: Clase:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Desde repo-root Android:

atest frameworks/base/services/tests/wmtests/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

Ejecución de varias clases

Para ejecutar varias clases, sepárelas con espacios de la misma manera que para ejecutar 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 con respecto a la ejecución de todo el módulo.

Para ejecutar dos clases en el mismo módulo:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

Para ejecutar dos clases en diferentes módulos:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

Ejecutar binarios de GTest

Atest puede ejecutar binarios de GTest. Utilice -a para ejecutar estas 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).

Ejemplo de prueba de entrada:

atest -a libinput_tests inputflinger_tests

Para seleccionar un binario GTest específico para ejecutar, use dos puntos (:) para especificar el nombre de la prueba y un 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)

Ejecute lo siguiente para especificar la prueba completa:

atest inputflinger_tests:InputDispatcherTest

O ejecute una prueba individual usando lo siguiente:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Ejecutar pruebas en TEST_MAPPING

Atest puede ejecutar pruebas en archivos TEST_MAPPING .

Ejecutar pruebas de preenvío implícitamente

Ejecute pruebas de envío previo en archivos TEST_MAPPING en los directorios actual y principal:

atest

Ejecute pruebas de envío previo en archivos TEST_MAPPING en /path/to/project y sus directorios principales:

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

Ejecutar un grupo de prueba específico

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

Ejecute pruebas posteriores al envío en archivos TEST_MAPPING en los directorios actual y principal:

<pre>
<code class="devsite-terminal">atest :postsubmit</code>
</pre>

Ejecute pruebas de todos los grupos en archivos TEST_MAPPING:

<pre>
<code class="devsite-terminal">atest :all</code>
</pre>

Ejecute pruebas posteriores al envío en archivos TEST_MAPPING en /path/to/project y sus directorios principales:

<pre>
<code class="devsite-terminal">atest --test-mapping <var>/path/to/project</var>:postsubmit</code>
</pre>

Ejecute pruebas principales en archivos TEST_MAPPING en /path/to/project y sus directorios principales:

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

Ejecutar pruebas en subdirectorios

De forma predeterminada, Atest solo busca pruebas en archivos TEST_MAPPING hacia arriba (desde el directorio actual o dado hasta sus directorios principales). Si también desea ejecutar pruebas en archivos TEST_MAPPING en los subdirectorios, use --include-subdirs para obligar a Atest a incluir esas pruebas también:

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

Ejecutar pruebas en iteración

Ejecute pruebas en iteración pasando el argumento --iterations . Ya sea que pase o falle, Atest repetirá la prueba hasta que se alcance la iteración máxima.

Ejemplos:

Por defecto, Atest itera 10 veces. El número de iteraciones debe ser un número entero positivo.

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

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

Enfoque 1: Ejecute todas las pruebas hasta que ocurra 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 ocurra una falla o la iteración llegue a la ronda 100.

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

Enfoque 2: Ejecute solo las pruebas fallidas hasta que se superen o se alcance la iteración máxima.

• Suponga que test-to-run tiene varios casos de prueba y una de las pruebas falla. Ejecute solo la prueba fallida 10 veces (de forma predeterminada) 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
  

Ejecutar pruebas en AVD

Atest puede ejecutar pruebas en un AVD recién creado. Ejecute acloud create para crear un AVD y crear artefactos, luego use los siguientes ejemplos para ejecutar sus pruebas.

Inicie un AVD y ejecute pruebas en él:

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

Inicie 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, ejecute acloud create --help .

Pasar opciones al módulo

Atest es capaz de pasar opciones a módulos de prueba. Para agregar opciones de línea de comando de TradeFed a su ejecución de prueba, use la siguiente estructura y asegúrese de que sus argumentos personalizados sigan el formato de opción de línea de comando de Tradefed.

atest test-to-run -- [CUSTOM_ARGS]

Pase las opciones del módulo de prueba a los preparadores de destino o ejecutores de prueba 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

Pasar opciones a un tipo o clase de corredor:

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

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

Para agregar una característica a Atest, siga el flujo de trabajo del desarrollador de Atest .

Configuración de su entorno

Siga los pasos de las siguientes secciones para configurar su entorno Atest.

Establecer variable de entorno

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

Ejecute envsetup.sh

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

source build/envsetup.sh

ejecutar el lunch

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 Atest toman la siguiente forma:

atest test-to-run [optional-arguments]

Argumentos opcionales

En la tabla siguiente se enumeran los argumentos más utilizados. Una lista completa está disponible a través atest --help .

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

Especificar pruebas

Para ejecutar pruebas, especifique una o más pruebas utilizando uno de los siguientes identificadores:

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

Separe las referencias a varias pruebas con espacios, así:

atest test-identifier-1 test-identifier-2

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 LOCAL_MODULE o LOCAL_PACKAGE_NAME en el archivo Android.mk o Android.bp 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 completo de la clase o el nombre básico.

Ejemplos:

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

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

Prueba de integración de Tradefed

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 de reboot.xml :

atest example/reboot

Para ejecutar la prueba native-benchmark.xml :

atest native-benchmark

Ruta de archivo

Atest admite la ejecución de 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 admite la ejecución de una sola clase especificando la ruta al archivo Java de la clase. Se admiten rutas relativas y absolutas.

Ejecutar un módulo

Los siguientes ejemplos muestran dos formas de ejecutar el módulo CtsVideoTestCases usando una ruta de archivo.

Ejecutar desde repo-root de Android:

atest cts/tests/video

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

    atest .

Ejecutar una clase de prueba

El siguiente ejemplo muestra cómo ejecutar una clase específica dentro del módulo CtsVideoTestCases usando una ruta de archivo.

Desde repo-root Android:

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

Ejecutar una prueba de integración

El siguiente ejemplo muestra cómo ejecutar una prueba de integración utilizando una ruta de archivo desde repo-root de Android:

    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 com.android.uibench.janktests

Especifique los pasos: compilar, instalar o ejecutar

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

• Solo objetivos de compilación: atest -b test-to-run
• Ejecutar pruebas únicamente: atest -t test-to-run
• Instalar apk y ejecutar pruebas: atest -it test-to-run
• Compile y ejecute, pero no instale: atest -bt test-to-run

Atest puede obligar a una prueba a omitir el paso de limpieza o 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 antes de -t para omitir el paso de limpieza de la prueba y probar iterativamente.

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

Ejecutar métodos específicos

Atest admite la ejecución de 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

Al especificar varios métodos, sepárelos 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 . Estos ejemplos son preferibles a usar solo el nombre de la clase porque especificar el módulo o la ubicación del archivo Java le permite a Atest encontrar la prueba mucho más rápido.

Usando Módulo: Clase:

atest FrameworksServicesTests:ScreenDecorWindowTests#testFlagChange

Desde repo-root Android:

atest frameworks/base/services/tests/wmtests/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

Ejecución de varias clases

Para ejecutar varias clases, sepárelas con espacios de la misma manera que para ejecutar 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 con respecto a la ejecución de todo el módulo.

Para ejecutar dos clases en el mismo módulo:

atest FrameworksServicesTests:ScreenDecorWindowTests FrameworksServicesTests:DimmerTests

Para ejecutar dos clases en diferentes módulos:

atest FrameworksServicesTests:ScreenDecorWindowTests CtsVideoTestCases:VideoEncoderDecoderTest

Ejecutar binarios de GTest

Atest puede ejecutar binarios de GTest. Utilice -a para ejecutar estas 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).

Ejemplo de prueba de entrada:

atest -a libinput_tests inputflinger_tests

Para seleccionar un binario GTest específico para ejecutar, use dos puntos (:) para especificar el nombre de la prueba y un 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)

Ejecute lo siguiente para especificar la prueba completa:

atest inputflinger_tests:InputDispatcherTest

O ejecute una prueba individual usando lo siguiente:

atest inputflinger_tests:InputDispatcherTest#InjectInputEvent_ValidatesKeyEvents

Ejecutar pruebas en TEST_MAPPING

Atest puede ejecutar pruebas en archivos TEST_MAPPING .

Ejecutar pruebas de preenvío implícitamente

Ejecute pruebas de envío previo en archivos TEST_MAPPING en los directorios actual y principal:

atest

Ejecute pruebas de envío previo en archivos TEST_MAPPING en /path/to/project y sus directorios principales:

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

Ejecutar un grupo de prueba específico

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

Ejecute pruebas posteriores al envío en archivos TEST_MAPPING en los directorios actual y principal:

<pre>
<code class="devsite-terminal">atest :postsubmit</code>
</pre>

Ejecute pruebas de todos los grupos en archivos TEST_MAPPING:

<pre>
<code class="devsite-terminal">atest :all</code>
</pre>

Ejecute pruebas posteriores al envío en archivos TEST_MAPPING en /path/to/project y sus directorios principales:

<pre>
<code class="devsite-terminal">atest --test-mapping <var>/path/to/project</var>:postsubmit</code>
</pre>

Ejecute pruebas principales en archivos TEST_MAPPING en /path/to/project y sus directorios principales:

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

Ejecutar pruebas en subdirectorios

De forma predeterminada, Atest solo busca pruebas en archivos TEST_MAPPING hacia arriba (desde el directorio actual o dado hasta sus directorios principales). Si también desea ejecutar pruebas en archivos TEST_MAPPING en los subdirectorios, use --include-subdirs para obligar a Atest a incluir esas pruebas también:

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

Ejecutar pruebas en iteración

Ejecute pruebas en iteración pasando el argumento --iterations . Ya sea que pase o falle, Atest repetirá la prueba hasta que se alcance la iteración máxima.

Ejemplos:

Por defecto, Atest itera 10 veces. El número de iteraciones debe ser un número entero positivo.

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

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

Enfoque 1: Ejecute todas las pruebas hasta que ocurra 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 ocurra una falla o la iteración llegue a la ronda 100.

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

Enfoque 2: Ejecute solo las pruebas fallidas hasta que se superen o se alcance la iteración máxima.

• Suponga que test-to-run tiene varios casos de prueba y una de las pruebas falla. Ejecute solo la prueba fallida 10 veces (de forma predeterminada) 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
  

Ejecutar pruebas en AVD

Atest puede ejecutar pruebas en un AVD recién creado. Ejecute acloud create para crear un AVD y crear artefactos, luego use los siguientes ejemplos para ejecutar sus pruebas.

Inicie un AVD y ejecute pruebas en él:

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

Inicie 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, ejecute acloud create --help .

Pasar opciones al módulo

Atest es capaz de pasar opciones a módulos de prueba. Para agregar opciones de línea de comando de TradeFed a su ejecución de prueba, use la siguiente estructura y asegúrese de que sus argumentos personalizados sigan el formato de opción de línea de comando de Tradefed.

atest test-to-run -- [CUSTOM_ARGS]

Pase las opciones del módulo de prueba a los preparadores de destino o ejecutores de prueba 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

Pasar opciones a un tipo o clase de corredor:

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