Mapeo de prueba

Esta es una breve introducción al mapeo de pruebas y una explicación de cómo comenzar a configurar pruebas fácilmente en el Proyecto de código abierto de Android (AOSP).

Acerca del mapeo de prueba

El mapeo de pruebas es un enfoque basado en Gerrit que permite a los desarrolladores crear reglas de prueba previas y posteriores al envío directamente en el árbol fuente de Android y dejar las decisiones de las ramas y dispositivos que se probarán en la propia infraestructura de prueba. Las definiciones de mapeo de prueba son archivos JSON denominados TEST_MAPPING que se pueden colocar en cualquier directorio de origen.

Atest puede usar los archivos TEST_MAPPING para ejecutar pruebas de envío previo en los directorios asociados. Con el mapeo de pruebas, puede agregar el mismo conjunto de pruebas para enviar comprobaciones previamente con un simple cambio dentro del árbol de fuentes de Android.

Vea estos ejemplos:

Agregue pruebas de envío previo a TEST_MAPPING para servicios.core

Agregue pruebas de envío previo a TEST_MAPPING para herramientas/dexter usando importaciones

El mapeo de pruebas se basa en el arnés de pruebas de la Federación de Comercio (TF) para la ejecución de pruebas y la presentación de informes de resultados.

Definir grupos de prueba

El mapeo de pruebas agrupa las pruebas a través de un grupo de pruebas . El nombre de un grupo de prueba puede ser cualquier cadena. Por ejemplo, el envío previo puede ser para que se ejecute un grupo de pruebas al validar cambios. Y las pruebas posteriores al envío se pueden utilizar para validar las compilaciones después de que se fusionen los cambios.

Reglas de secuencia de comandos de creación de paquetes

Para que Trade Federation Test Harness ejecute los módulos de prueba del mapeo de prueba para una compilación determinada, estos módulos deben tener test_suite configurado para Soong o LOCAL_COMPATIBILITY_SUITE configurado para Make en uno de estos dos conjuntos:

• pruebas generales : pruebas que no dependen de la funcionalidad específica del dispositivo (como el hardware específico del proveedor que la mayoría de los dispositivos no tienen). La mayoría de las pruebas deben estar en el conjunto de pruebas generales, incluso si son específicas de una ABI o bitness o características de hardware como HWASan (hay un objetivo test_suites separado para cada ABI), e incluso si tienen que ejecutarse en un dispositivo.
• pruebas de dispositivo : pruebas que dependen de la funcionalidad específica del dispositivo. Normalmente, estas pruebas se encontrarán en vendor/ . Debido a que "específico del dispositivo" no se refiere a la funcionalidad ABI o SoC que otros dispositivos podrían o no tener, sino solo a la funcionalidad que es exclusiva de un dispositivo, esto se aplica tanto a las pruebas JUnit como a las pruebas nativas GTest (que generalmente ser general-tests incluso si son específicas de ABI).

Ejemplos:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

Configurar pruebas para ejecutarlas en un conjunto de pruebas

Para que una prueba se ejecute dentro de un conjunto de pruebas, la prueba:

• no debe tener ningún proveedor de compilación.
• debe limpiarse una vez finalizado, por ejemplo, eliminando cualquier archivo temporal generado durante la prueba.
• cambie la configuración del sistema al valor predeterminado u original.
• No debe asumir un dispositivo en un estado determinado, por ejemplo, listo para root. La mayoría de las pruebas no requieren privilegios de root para ejecutarse. Si una prueba debe requerir root, debe especificarlo con un RootTargetPreparer en su AndroidTest.xml , como en el siguiente ejemplo:

<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

Crear archivos de mapeo de prueba

Para el directorio que requiere cobertura de prueba, simplemente agregue un archivo JSON TEST_MAPPING similar al ejemplo siguiente. Estas reglas garantizarán que las pruebas se ejecuten en comprobaciones previas al envío cuando se toque cualquier archivo en ese directorio o cualquiera de sus subdirectorios.

Sigue un ejemplo

Aquí hay un archivo TEST_MAPPING de muestra (está en formato JSON pero admite comentarios):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Establecer atributos

En el ejemplo anterior, presubmit y postsubmit son los nombres de cada grupo de prueba . Consulte Definición de grupos de prueba para obtener más información sobre los grupos de prueba.

El nombre del módulo de prueba o el nombre de la prueba de integración de la Federación de Comercio (ruta del recurso al archivo XML de prueba, por ejemplo, uiautomator/uiautomator-demo ) se puede establecer en el valor del atributo name . Tenga en cuenta que el campo de nombre no puede utilizar name de la clase ni name del método de prueba. Para limitar las pruebas a ejecutar, puede utilizar opciones como include-filter aquí. Consulte ( uso de muestra de filtro de inclusión ).

La configuración del host de una prueba indica si la prueba es una prueba sin dispositivo que se ejecuta en el host o no. El valor predeterminado es false , lo que significa que la prueba requiere un dispositivo para ejecutarse. Los tipos de prueba admitidos son HostGTest para binarios GTest y HostTest para pruebas JUnit.

El atributo file_patterns le permite establecer una lista de cadenas de expresiones regulares para que coincidan con la ruta relativa de cualquier archivo de código fuente (en relación con el directorio que contiene el archivo TEST_MAPPING). En el ejemplo anterior, la prueba CtsWindowManagerDeviceTestCases se ejecutará en el envío previo solo cuando se cambie cualquier archivo Java que comience con Ventana o Actividad, que existe en el mismo directorio del archivo TEST_MAPPING o cualquiera de sus subdirectorios. Las barras invertidas \ deben tener carácter de escape, ya que están en un archivo JSON.

El atributo de importaciones le permite incluir pruebas en otros archivos TEST_MAPPING sin copiar el contenido. Tenga en cuenta que también se incluirán los archivos TEST_MAPPING en los directorios principales de la ruta importada. El mapeo de prueba permite importaciones anidadas; esto significa que dos archivos TEST_MAPPING pueden importarse entre sí y el mapeo de pruebas puede fusionar correctamente las pruebas incluidas.

El atributo de opciones contiene opciones adicionales de línea de comando de TradeFed.

Para obtener una lista completa de las opciones disponibles para una prueba determinada, ejecute:

tradefed.sh run commandAndExit [test_module] --help

Consulte Manejo de opciones de TradeFed para obtener más detalles sobre cómo funcionan las opciones.

Ejecutar pruebas con Atest

Para ejecutar las reglas de prueba de envío previo localmente:

1. Vaya al directorio que contiene el archivo TEST_MAPPING.
2. Ejecute el comando:

atest

Se ejecutan todas las pruebas de envío previo configuradas en los archivos TEST_MAPPING del directorio actual y sus directorios principales. Atest localizará y ejecutará dos pruebas para el envío previo (A y B).

Esta es la forma más sencilla de ejecutar pruebas de envío previo en archivos TEST_MAPPING en el directorio de trabajo actual (CWD) y los directorios principales. Atest localizará y utilizará el archivo TEST_MAPPING en CWD y todos sus directorios principales.

Código fuente de estructura

El siguiente ejemplo muestra cómo se pueden configurar los archivos TEST_MAPPING en el árbol de origen.

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

Contenido de src/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

Contenido de src/project_1/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

Contenido de src/project_2/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

Especificar directorios de destino

Puede especificar un directorio de destino para ejecutar pruebas en archivos TEST_MAPPING en ese directorio. El siguiente comando ejecutará dos pruebas (A, B).

atest --test-mapping src/project_1

Ejecutar reglas de prueba posteriores al envío

También puede usar este comando para ejecutar las reglas de prueba posteriores al envío definidas en TEST_MAPPING en src_path (predeterminado en CWD) y sus directorios principales:

atest [--test-mapping] [src_path]:postsubmit

Ejecute solo pruebas que no requieran ningún dispositivo

Puede usar la opción --host para que Atest solo ejecute pruebas configuradas en el host que no requieran ningún dispositivo. Sin esta opción, Atest ejecutará ambas pruebas, las que requieren un dispositivo y las que se ejecutan en el host y no requieren ningún dispositivo. Las pruebas se realizarán en dos suites separadas.

atest [--test-mapping] --host

Identificar grupos de prueba

Puede especificar grupos de prueba en el comando Atest. El siguiente comando ejecutará todas las pruebas posteriores al envío relacionadas con archivos en el directorio src/project_1, que contiene solo una prueba (C).

O puedes usar :all para ejecutar todas las pruebas independientemente del grupo. El siguiente comando ejecuta cuatro pruebas (A, B, C, X):

atest --test-mapping src/project_1:all

Incluir subdirectorios

De forma predeterminada, la ejecución de pruebas en TEST_MAPPING con Atest ejecutará solo las pruebas de envío previo configuradas en el archivo TEST_MAPPING en CWD (o directorio determinado) y sus directorios principales. Si desea ejecutar pruebas en todos los archivos TEST_MAPPING en los subdirectorios, use la opción --include-subdir para forzar a Atest a incluir esas pruebas también.

atest --include-subdir

Sin la opción --include-subdir , Atest ejecutará solo la prueba A. Con la opción --include-subdir , Atest ejecutará dos pruebas (A, B).

Se admiten comentarios a nivel de línea

Puede agregar un comentario de formato // a nivel de línea para desarrollar el archivo TEST_MAPPING con una descripción de la configuración que sigue. ATest y Trade Federation preprocesarán TEST_MAPPING a un formato JSON válido sin comentarios. Para mantener el archivo JSON limpio y fácil de leer, solo se admiten comentarios en formato // de nivel de línea.

Ejemplo:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}