Infraestructura de pruebas automatizadas

Android 9 incluye un Conjunto de pruebas de proveedores (VTS) infraestructura para pruebas automatizadas de VTS, CTS u otras pruebas en el socio que ejecutan la imagen genérica del sistema (GSI) del AOSP. Anteriormente, ejecutar estas las pruebas era una operación altamente manual; la nueva infraestructura de prueba de VTS diseñada para admitir pruebas automatizadas varias veces al día en varias dispositivos.

Arquitectura

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

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

1. Recupera artefactos de compilación y recursos de prueba desde diferentes ubicaciones:
   • Compilaciones de Android para socios (PAB). Para la GSI, VTS el framework y algunas otras compilaciones.
   • Sistema de archivos local, Google Cloud Storage y otros archivos sistema de compilación. Para los socios que no almacenan compilaciones en en la nube.
2. Enciende los artefactos de compilación (del dispositivo) y la GSI (de AOSP) en los dispositivos conectados.
3. Ejecuta pruebas de VTS con TradeFed o TradeFed local en la nube.
4. Informa los resultados de las pruebas en el panel de VTS

El controlador de host (HC) de VTS, una máquina del lab que dirige el comportamiento de todos los dispositivos conectados en prueba, coordina el proceso. El HC es responsable de recuperar las compilaciones más recientes, escribirlas en los dispositivos y invocar pruebas (ya sea de forma local o a través del comandante). También comunica con un programador en la nube y dirige el tráfico entre este Instancia de TradeFed (o algún otro agente) que se ejecuta en el HC Para obtener detalles sobre el controlador de host, consulta Arquitectura del controlador de host.

Proveedores de recursos

Las pruebas automatizadas requieren recursos como compilaciones de sistemas, archivos de prueba y artefactos de VTS. Si bien es posible compilarlos a partir del código fuente, construirlos a partir de la punta del árbol con regularidad y luego publicar los artefactos para descargarlos.

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

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

Para usar luego en la escritura en la memoria flash de los dispositivos, 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 del socio

En Android 8.1 y versiones anteriores, los socios de Android debían visitar el Sitio web del socio de compilación de Android (https://partner.android.com/build), navegar a su cuenta y recuperar las últimas imágenes del sistema a través del interfaz de usuario. Para ayudar a los socios a evitar este proceso lento y laborioso, Android 9 incluye compatibilidad para descargar automáticamente estos recursos de PAB cuando se proporcionan las credenciales adecuadas.

Establece el acceso

El acceso programático usa OAuth2 en las APIs de Google para acceder a las RPC requeridas. Con el enfoque estándar para generar credenciales de OAuth2, el socio debe configurar un par de ID de cliente/secreto con Google. Cuando se apunta a PartnerAndroidBuildClient a ese secreto por primera vez, se abre una ventana del navegador para que el usuario acceda a su cuenta de Google, lo que genera las credenciales de OAuth2 necesarias para continuar. Las credenciales (token de acceso y token de actualización) se almacenan de forma local, lo que significa que los socios solo deben acceder una vez.

Solicitud POST para la URL

Si haces clic en un vínculo de recurso en la PAB, se enviará una solicitud POST que incluirá los datos necesarios para ese recurso, incluidos los siguientes:

• ID de compilación, destino de compilación
• nombre del recurso
• rama
• el nombre de la versión candidata y si es una compilación interna o no

El método downloadBuildArtifact de la RPC buildsvc recibe la solicitud POST, que muestra una URL que se puede usar para acceder al recurso.

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

Obtén la URL

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

Para evitar este problema, Android 9 rediseñó el esquema de nombres de URL para todos los archivos (no solo los APK) para usar nombres de URL predecibles para acceder a las listas de artefactos y las URLs de artefactos. El PAB ahora usa un formato de URL conveniente que permite a los socios descargar recursos. Las secuencias de comandos de HC pueden descargar esos APK fácilmente, ya que se conoce el formato de la URL, y HC puede omitir los problemas de XSRF o cookies porque no necesita la RPC de buildsvc.

Sistema de archivos local

Si tienes un directorio con una lista (o un archivo ZIP) de artefactos, el proveedor de compilación Configura las imágenes relevantes según el contenido del directorio. Puedes usar la herramienta gsutil para copiar archivos de Google Cloud Storage a un directorio local.

Compilaciones de Flash

Una vez descargadas en el host las imágenes más recientes del dispositivo, esas imágenes debe instalarse en los dispositivos. Esto se hace con los comandos adb y fastboot estándar y los subprocesos de Python, según las rutas de acceso de archivos temporales que almacenan los proveedores de compilación.

Acciones admitidas:

• Cómo instalar solo la GSI
• Instala imágenes individuales desde el sistema principal (p.ej., fastboot flash boot boot.img)
• Se borran todas las imágenes del sistema principal. Ejemplo:
  • fastboot flashall (con la utilidad flashall integrada)
  • fastboot flash (uno a la vez)

Cómo ejecutar pruebas

En Android 9, la infraestructura de pruebas automatizadas de VTS solo admite el agente de prueba de TradeFed, pero se podría extender para admitir otros agentes en el futuro.

Una vez que los dispositivos estén preparados, puedes invocar pruebas mediante una de las las siguientes opciones:

• Cuando uses TradeFed localmente, usa el comando test en el host. que toma el nombre de un plan de prueba de VTS (p.ej., vts-selftest) y ejecuta la prueba.
• Cuando uses un clúster de TradeFed (conectado opcionalmente a MTT), usa el lease en la consola del controlador de host, que busca sin completar.

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

Cómo informar resultados

VtsMultiDeviceTest informa automáticamente los resultados de las pruebas a algunos proyectos del panel de VTS.