Google se compromete a promover la equidad racial para las comunidades negras. Ver cómo.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Infraestructura de prueba automatizada

Android 9 incluye una infraestructura de Vendor Test Suite (VTS) para pruebas automáticas de VTS, CTS u otras pruebas en dispositivos asociados que ejecutan la imagen de sistema genérico (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:

Automated test architecture

Figura 1. Arquitectura de infraestructura de prueba automatizada VTS

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

  1. Obtiene artefactos de construcción y recursos de prueba desde diferentes ubicaciones:
    • Partner Android Build (PAB) . Para el marco GSI, 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. Parpadea los artefactos de construcción (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 la prueba al panel de VTS

El proceso es coordinado por el controlador de host VTS (HC), 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 compilaciones, mostrarlas en los dispositivos e invocar pruebas (ya sea localmente o a través del comandante). También se comunica con un planificador en la nube y dirige el tráfico entre el planificador 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, 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 construirlos desde la fuente, es más fácil construirlos desde la punta del árbol regularmente y luego publicar los artefactos para descargar.

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

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

Para su uso en la actualización posterior 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.

Partner Android Build

En Android 8.1 y versiones anteriores, los socios de Android debían visitar el sitio web Partner Android Build ( https://partner.android.com/build ), navegar a su cuenta y obtener las últimas imágenes 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 de PAB cuando se proporcionan las credenciales apropiadas.

Establecer acceso

El acceso programático utiliza OAuth2 en las API de Google para acceder a los RPC requeridos. Usando el enfoque estándar para generar credenciales OAuth2, el socio debe configurar un par de identificación / secreto de cliente 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 de OAuth2 necesarias para avanzar. Las credenciales (token de acceso y token de actualización) se almacenan localmente, lo que significa que los socios solo deben iniciar sesión una vez.

Solicitud POST para 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 id, 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 se recibe mediante el método downloadBuildArtifact del buildsvc RPC, 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 accesible con las credenciales OAuth2 apropiadas).
  • Para otros recursos, la URL es una URL larga y no protegida de la API interna de compilación de Android (que caduca después de cinco minutos).

Obteniendo la URL

Para evitar la falsificación de solicitudes entre sitios, el RPC buildsvc requiere que se envíe 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 programático sea mucho más difícil ya que el token (que está disponible solo en el JavaScript de la página PAB) ahora también se requiere para el acceso.

Para evitar este problema, Android 9 rediseña el esquema de nombres de URL para todos los archivos (no solo APK) para usar nombres de URL predecibles para acceder a listas de artefactos y URL de artefactos. El PAB ahora usa un conveniente formato de URL 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 omitir los problemas de XSRF / cookie porque no necesita el buildsvc RPC.

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 usar la herramienta gsutil para copiar archivos de Google Cloud Storage a un directorio local.

Construcciones intermitentes

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

Acciones apoyadas:

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

Ejecutando pruebas

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

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

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

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

Informe de resultados

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