Infraestructura de prueba automatizada

Android 9 incluye una infraestructura de Vendor Test Suite (VTS) para pruebas automatizadas de VTS, CTS u otras pruebas en dispositivos asociados que ejecutan la imagen genérica del sistema (GSI) de AOSP. Anteriormente, ejecutar estas pruebas era una operación altamente manual; La nueva infraestructura de prueba VTS está diseñada para admitir pruebas automatizadas varias veces al día en múltiples dispositivos.

Arquitectura

La infraestructura de pruebas automatizadas de VTS utiliza la siguiente arquitectura:

Cuando se activa una prueba, la infraestructura de pruebas automatizadas de VTS realiza las siguientes tareas:

1. Obtiene artefactos de compilación y recursos de prueba desde diferentes ubicaciones:
   • Compilación de Android para socios (PAB) . Para GSI, marco VTS y algunas otras compilaciones.
   • Sistema de archivos local, Google Cloud Storage u otro sistema de compilación específico del proveedor . Para socios que no almacenan compilaciones en la nube de Google.
2. Los flashes crean artefactos (desde el dispositivo) y el GSI (desde AOSP) en los dispositivos conectados.
3. Ejecuta pruebas VTS utilizando TradeFed local o TradeFed en la nube.
4. Informa los resultados de las pruebas al panel de VTS

El proceso lo coordina el controlador de host (HC) VTS, una máquina en el laboratorio que dirige el comportamiento de todos los dispositivos conectados bajo prueba. El HC es responsable de obtener las últimas versiones, actualizarlas en los dispositivos e invocar pruebas (ya sea localmente o a través del comandante). También se comunica con un programador en la nube y dirige el tráfico entre el programador y la instancia de TradeFed (o algún otro arnés) que se ejecuta en HC. Para obtener detalles sobre el controlador de host, consulte Arquitectura del controlador de host .

Proveedores de recursos

Las pruebas automatizadas requieren recursos como compilaciones del sistema, archivos de prueba y artefactos VTS. Si bien es posible compilarlos desde el código fuente, es más fácil compilarlos regularmente desde la punta del árbol y luego publicar los artefactos para descargarlos.

Los socios pueden acceder a los recursos de automatización utilizando las siguientes ubicaciones:

• Compilación de Android para socios . Acceso programático otorgado por cuenta.
• Sistema de archivos local (o similar). Para socios que no utilizan Partner Android Build.

Para usar en la actualización de los dispositivos más adelante, los recursos incluyen proveedores de compilación para ambas opciones, que se extienden desde un único build_provider.py que almacena las compilaciones en directorios temporales locales.

Compilación de Android para socios

En Android 8.1 y versiones inferiores, los socios de Android debían visitar el sitio web Partner Android Build ( https://partner.android.com/build ), navegar hasta su cuenta y obtener las imágenes más recientes del sistema a través de la interfaz de usuario. Para ayudar a los socios a evitar este proceso lento y laborioso, Android 9 incluye soporte para descargar automáticamente estos recursos desde PAB cuando se proporcionan las credenciales adecuadas.

Establecer acceso

El acceso programático utiliza OAuth2 en las API de Google para acceder a los RPC necesarios. Utilizando el enfoque estándar para generar credenciales OAuth2, el socio debe configurar un par de ID de cliente/secreto con Google. Cuando PartnerAndroidBuildClient señala ese secreto por primera vez, abre una ventana del navegador para que el usuario inicie sesión en su cuenta de Google, lo que genera las credenciales OAuth2 necesarias para seguir adelante. Las credenciales (token de acceso y token de actualización) se almacenan localmente, lo que significa que los socios deberían iniciar sesión solo una vez.

Solicitud POST de URL

Al hacer clic en un enlace de recurso en PAB, se envía una solicitud POST que incluye los datos necesarios para ese recurso, que incluyen:

• construir identificación, construir objetivo
• nombre del recurso
• rama
• liberar el nombre del candidato y si el candidato es o no una compilación interna

La solicitud POST es recibida por el método downloadBuildArtifact del RPC buildsvc , que devuelve una URL que se puede utilizar para acceder al recurso.

• Para los recursos APK de Clockwork Companion, la URL es una URL legible alojada en PAB (que está protegida por autenticación y es accesible con las credenciales OAuth2 apropiadas).
• Para otros recursos, la URL es una URL larga y no protegida de la API interna de Android Build (que caduca después de cinco minutos).

Obtener la URL

Para evitar la falsificación de solicitudes entre sitios, buildsvc RPC requiere que se publique un token XSRF con los otros parámetros. Si bien este token hace que el proceso sea más seguro, también hace que el acceso mediante programación sea mucho más difícil, ya que el token (que está disponible solo en JavaScript de la página PAB) ahora también es necesario para el acceso.

Para evitar este problema, Android 9 rediseña el esquema de nomenclatura de URL para todos los archivos (no solo los APK) para utilizar nombres de URL predecibles para acceder a listas de artefactos y URL de artefactos. La PAB ahora utiliza un formato de URL conveniente que permite a los socios descargar recursos; Los scripts de HC pueden descargar esos APK fácilmente, ya que se conoce el formato de URL, y HC puede evitar los problemas de XSRF/cookies porque no necesita el RPC buildsvc .

Sistema de archivos local

Dado un directorio con una lista (o archivo zip) de artefactos, el proveedor de compilación establece las imágenes relevantes en función de lo que hay en el directorio. Puede utilizar la herramienta gsutil para copiar archivos de Google Cloud Storage a un directorio local.

compilaciones flash

Después de descargar las imágenes más recientes del dispositivo al host, esas imágenes deben actualizarse en los dispositivos. Esto se hace utilizando los comandos estándar adb y fastboot y los subprocesos de Python, según las rutas de archivos temporales almacenadas por los proveedores de compilación.

Acciones apoyadas:

• Parpadeando solo el GSI
• Intermitente de imágenes individuales del sistema principal (por ejemplo, fastboot flash boot boot.img )
• Flashear todas las imágenes del sistema principal. Ejemplo:
  • fastboot flashall (usando la utilidad flashall incorporada)
  • fastboot flash (uno a la vez)

Ejecutar pruebas

En Android 9, la infraestructura de pruebas automatizadas de VTS solo admite el arnés de prueba TradeFed, pero podría ampliarse para admitir otros arneses en el futuro.

Una vez preparados los dispositivos, puede invocar pruebas utilizando una de las siguientes opciones:

• Cuando utilice TradeFed localmente, utilice el comando test en el controlador host, que toma el nombre de un plan de prueba VTS (por ejemplo, vts-selftest ) y ejecuta la prueba.
• Cuando utilice un clúster TradeFed (opcionalmente conectado a MTT), utilice el comando lease en la consola del controlador del host, que busca ejecuciones de pruebas no completadas.

Si utiliza TradeFedCluster, TradeFed se ejecuta localmente como un administrador remoto . De lo contrario, las pruebas se invocan mediante subprocesos de Python.

Informar resultados

Los resultados de las pruebas se informan automáticamente a algunos proyectos del panel VTS mediante VtsMultiDeviceTest .