Infraestructura de pruebas automatizadas

Android 9 incluye una infraestructura de VTS para las pruebas automatizadas de VTS, CTS u otras pruebas en dispositivos de socios que ejecutan la imagen genérica del sistema (GSI) de AOSP. Antes, la ejecución de estas pruebas era una operación altamente manual. La nueva infraestructura de prueba de VTS está diseñada para admitir pruebas automatizadas varias veces al día en varios 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, el framework de VTS y algunas otras compilaciones.
   • Sistema de archivos local, Google Cloud Storage o cualquier otro sistema de compilación específico del proveedor Para socios que no almacenan compilaciones en la nube de Google.
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 local o TradeFed 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 se comunica con un programador de nube y dirige el tráfico entre el programador y la instancia de TradeFed (o algún otro arnés) 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 del sistema, archivos de prueba y artefactos de VTS. Si bien es posible compilarlos desde la fuente, es más fácil compilarlos desde la punta del árbol con regularidad y, luego, publicar los artefactos para su descarga.

Los socios pueden acceder a los recursos de automatización mediante 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 la actualización de firmware de los dispositivos más adelante, los recursos incluyen proveedores de compilación para ambas opciones, que se extienden desde un solo build_provider.py que almacena las compilaciones en directorios temporales locales.

Compilación de Android para socios

En Android 8.1 y versiones anteriores, los socios de Android debían visitar el sitio web de compilación de Android para socios (https://partner.android.com/build), navegar a su cuenta y recuperar las imágenes del sistema más recientes a través de la interfaz de usuario. Para ayudar a los socios a evitar este proceso lento y laborioso, Android 9 incluye compatibilidad con la descarga automática de 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 PartnerAndroidBuildClient apunta 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 avanzar. 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, objetivo 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.

• En el caso de los recursos del APK de Clockwork Companion, la URL es una URL legible alojada en PAB (que está protegida por autenticación y a la que se puede acceder con las credenciales de OAuth2 adecuadas).
• Para otros recursos, la URL es larga y no está protegida de la API de compilación de Android interna (que vence después de cinco minutos).

Obtén la URL

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

Para evitar este problema, Android 9 rediseña el esquema de nombres de URL para todos los archivos (no solo los APK) a fin de usar nombres de URL predecibles para acceder a listas de artefactos y URL de artefactos. Ahora, el PAB usa un formato de URL conveniente que permite a los socios descargar recursos. Las secuencias de comandos del Centro de ayuda pueden descargar esos APK con facilidad, ya que el formato de URL es conocido, y el Centro de ayuda puede omitir los problemas de RPC de XSRF/cookies porque no necesita el buildsvc.

Sistema de archivos local

Dado un directorio con una lista (o un archivo ZIP) de artefactos, el proveedor de compilación configura las imágenes relevantes según lo que se encuentra en el directorio. Puedes usar la herramienta gsutil para copiar archivos de Google Cloud Storage a un directorio local.

Compilaciones de Flash

Después de que las imágenes de dispositivos más recientes se descarguen en el host, esas imágenes deben escribirse en la memoria flash de 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
• Escritura de 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 por 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.

Después de preparar los dispositivos, puedes invocar pruebas con una de las siguientes opciones:

• Cuando uses TradeFed de forma local, usa el comando test en el controlador de 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 de forma opcional a MTT), usa el comando lease en la consola del controlador de host, que busca ejecuciones de prueba no completadas.

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

Cómo informar resultados

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