Google is committed to advancing racial equity for Black communities. See how.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Infraestructura de prueba automatizada

Android 9 incluye una infraestructura Vendor Test Suite (VTS) para pruebas automatizadas 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 muy manual; la nueva infraestructura de prueba VTS está diseñada para admitir pruebas automatizadas varias veces al día en varios dispositivos.

Arquitectura

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

Automated test architecture

Figura 1. Arquitectura de la infraestructura de pruebas automatizadas de VTS

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

  1. Obtiene artefactos de construcció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 construyen artefactos (desde el dispositivo) y el GSI (desde AOSP) en los dispositivos conectados.
  3. Ejecuta pruebas de VTS utilizando TradeFed local o TradeFed en la nube.
  4. Reporta los resultados de las pruebas al tablero 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 versiones, actualizarlas en los dispositivos e invocar las pruebas (ya sea localmente o mediante el 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 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 compilarlos desde la fuente, es más fácil compilarlos regularmente desde la punta del árbol y luego publicar los artefactos para su descarga.

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 usarlos 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.

Compilación de Android para socios

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 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 soporte para descargar automáticamente estos recursos de PAB cuando se proporcionan las credenciales adecuadas.

Establecer acceso

El acceso programático utiliza OAuth2 en las API de Google para acceder a las RPC necesarias. Con el método estándar para generar credenciales OAuth2, el socio debe configurar un par secreto / ID de cliente con Google. Cuando PartnerAndroidBuildClient se apunta a 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 seguir adelante. Las credenciales (token de acceso y token de actualización) se almacenan localmente, lo que significa que los socios deben iniciar sesión solo una vez.

Solicitud POST de URL

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

  • ID de compilación, objetivo de compilación
  • nombre del recurso
  • rama
  • Publicar el nombre del candidato y si el candidato es una compilación interna.

La solicitud POST es recibida por el método downloadBuildArtifact del buildsvc RPC, que devuelve una URL que se puede usar 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 de OAuth2 apropiadas).
  • Para otros recursos, la URL es una URL larga y no protegida de la API de compilación interna de Android (que caduca después de cinco minutos).

Obtener 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 dificulta mucho el acceso mediante programación, ya que el token (que solo está disponible en el JavaScript de la página PAB) ahora también es necesario para acceder.

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. La PAB ahora usa 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 omitir 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 según lo que hay en el directorio. Puedes usar la herramienta gsutil para copiar archivos de Google Cloud Storage a un directorio local.

Construcciones intermitentes

Una vez que se descargan las imágenes más recientes del dispositivo en el host, esas imágenes deben actualizarse en los dispositivos. Esto se hace usando los comandos estándar adb y fastboot y los subprocesos de Python, basados ​​en las rutas de archivo 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 )
  • Destellando todas las imágenes del sistema principal. Ejemplo:
    • fastboot flashall (usando la utilidad flashall )
    • fastboot flash (uno a la vez)

Ejecutando 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 mediante una de las siguientes opciones:

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

Si usa TradeFedCluster, TradeFed se ejecuta localmente como 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 paneles de VtsMultiDeviceTest .