Infraestructura de pruebas automatizadas

Android 9 incluye una infraestructura del paquete de pruebas del proveedor (VTS) para las pruebas automatizadas de VTS, CTS o cualquier otra prueba en dispositivos de socios que ejecutan la imagen genérica del sistema (GSI) de AOSP. Anteriormente, la ejecución de estas pruebas era una operación muy manual. La nueva infraestructura de pruebas de 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 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 de diferentes ubicaciones:
   • Compilación de Android para socios (PAB). Para la GSI, el framework de VTS y algunas otras compilaciones.
   • Sistema de archivos local, Google Cloud Storage o algún otro sistema de compilación específico del proveedor. Para los socios que no almacenan compilaciones en la nube de Google
2. Escribe los artefactos de compilación (desde el dispositivo) y la GSI (desde el 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 al panel de VTS

El proceso está coordinado por el controlador de host (HC) de VTS, una máquina en el lab que dirige el comportamiento de todos los dispositivos conectados en prueba. El HC es responsable de recuperar las compilaciones más recientes, grabarlas en los dispositivos y ejecutar pruebas (ya sea de forma local o a través del comandante). También se comunica con un programador de Cloud 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 host, consulta Arquitectura del controlador host.

Proveedores de recursos

Las pruebas automatizadas requieren recursos como compilaciones del sistema, archivos de prueba y artefactos de VTS. Si bien es posible compilar estos elementos desde el código fuente, es más fácil hacerlo desde la versión más reciente del árbol de código con regularidad y, luego, publicar los artefactos para su descarga.

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

• Compilación de Android para socios. El acceso programático se otorga por cuenta.
• Sistema de archivos local (o similar) Para los socios que no usan la compilación de Android para socios

Para usarse en la instalación 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 Partner Android Build (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 para descargar automáticamente estos recursos desde 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 RPCs requeridas. Con el enfoque estándar para generar credenciales de OAuth2, el socio debe configurar un par de ID y secreto del cliente con Google. Cuando el 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 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

Cuando haces clic en un vínculo de recurso en la PAB, se envía una solicitud POST que incluye los datos necesarios para ese recurso, incluidos los siguientes:

• ID de compilación, objetivo de compilación
• Nombre del recurso
• rama
• Nombre de la versión candidata para lanzamiento y si es una compilación interna

El método downloadBuildArtifact de la RPC buildsvc recibe la solicitud POST, que devuelve 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 es accesible con las credenciales de OAuth2 adecuadas).
• En el caso de otros recursos, la URL es una URL larga y no 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, el RPC buildsvc requiere que se envíe un token de XSRF con los demás parámetros a través de POST. Si bien este token hace que el proceso sea más seguro, también dificulta mucho el acceso programático, ya que ahora también se requiere el token (que solo está disponible en JavaScript de la página del PAB) para acceder.

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

Sistema de archivos local

Dado un directorio con una lista (o un archivo ZIP) de artefactos, el proveedor de compilación establece las imágenes pertinentes 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

Después de descargar las imágenes de dispositivo más recientes en el host, se deben instalar en los dispositivos. Esto se realiza con los comandos estándar adb y fastboot y subprocesos de Python, según las rutas de archivos temporales que almacenan los proveedores de compilación.

Acciones admitidas:

• Cómo instalar solo la GSI
• Cómo escribir imágenes individuales en la memoria flash del sistema principal (p.ej., fastboot flash boot boot.img)
• Escribir todas las imágenes del sistema principal en la memoria flash 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 pruebas de TradeFed, pero podría extenderse 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 del host, que toma el nombre de un plan de pruebas de VTS (p.ej., vts-selftest) y ejecuta la prueba.
• Cuando uses un clúster de TradeFed (opcionalmente conectado a MTT), usa el comando lease en la consola del controlador del host, que busca ejecuciones de prueba no completadas.

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

Resultados del informe

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