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

Configuración del panel de VTS

El panel de VTS proporciona un backend de usuario y una interfaz de usuario (UI) para ver los resultados de las pruebas del sistema de integración continua VTS. Es compatible con el desarrollo impulsado por pruebas con herramientas como notificaciones de estado de prueba para ayudar a los desarrolladores a localizar y prevenir áreas de regresión durante el ciclo de desarrollo (incluye supervisión de pruebas y soporte de clasificación).

La interfaz de usuario del panel de VTS admite funciones (como la cobertura de código nativo) proporcionada por la infraestructura de VTS y ofrece una supervisión continua del rendimiento para permitir el desarrollo de herramientas de rendimiento optimizadas y bien caracterizadas.

Requisitos

Se requieren los siguientes servicios para utilizar el panel de VTS:

La visualización de la cobertura de la prueba se basa en una API REST para un servidor de código fuente (por ejemplo, Gerrit), que permite al servicio web obtener el código fuente original de acuerdo con las listas de control de acceso existentes.

Arquitectura

El panel de VTS utiliza la siguiente arquitectura:

Figura 1 . Arquitectura del tablero de VTS.

Los resultados del estado de la prueba se cargan continuamente a la base de datos de Cloud Datastore a través de una interfaz REST. El corredor VTS procesa automáticamente los resultados y los serializa usando el formato Protobuf.

Los servlets web forman el punto de acceso principal para los usuarios, entregando y procesando datos de la base de datos de Datastore. Los servlets incluyen: un servlet principal para entregar todas las pruebas, un servlet de preferencias para administrar los favoritos del usuario, un servlet de resultados para completar una tabla de prueba, un servlet de gráficos para preparar datos de perfiles y un servlet de cobertura para preparar datos de cobertura para el cliente .

Cada módulo de prueba tiene su propio árbol de ancestros de Datastore y los resultados de la prueba se indexan con la marca de tiempo Unix de la hora de inicio de la prueba. Los datos de cobertura en la base de datos se almacenan con los resultados de la prueba como un vector de conteos (es decir, para cada línea en el archivo fuente original) e información de identificación para obtener el código fuente de un servidor de código fuente.

El servicio de notificación se ejecuta mediante colas de tareas, identificando cambios de estado de casos de prueba y notificando a los suscriptores. La información con estado se almacena en una tabla de estado para realizar un seguimiento de la actualización de los datos y las fallas existentes. Esto permite que el servicio de notificación proporcione información detallada sobre fallos y correcciones de casos de prueba individuales.

Estructura de código

Los componentes esenciales de VTS Dashboard incluyen los servlets implementados en Java, las JSP de front-end, las hojas de estilo CSS y los archivos de configuración. La siguiente lista detalla las ubicaciones y descripciones de estos componentes (todas las rutas relativas a test/vts/web/dashboard ):

  • pom.xml
    Archivo de configuración donde se definen las variables de entorno y las dependencias.
  • src/main/java/com/android/vts/api/
    Contiene puntos finales para interactuar con los datos a través de REST.
  • src/main/java/com/android/vts/entity/
    Contiene modelos Java de las entidades de Datastore.
  • src/main/java/com/android/vts/proto/
    Contiene archivos Java para Protobuf, incluido VtsReportMessage.java , que es una implementación Java del tipo Protobuf que se utiliza para describir los resultados de las pruebas VTS.
  • src/main/java/com/android/vts/servlet/
    Contiene archivos Java para servlets.
  • src/main/java/com/android/vts/util/
    Contiene archivos Java para las funciones y clases de utilidad que utilizan los servlets.
  • src/test/java/com/android/vts/
    Contiene pruebas de IU para los servlets y utils.
  • src/main/webapp/
    Contiene archivos relacionados con la interfaz de usuario (JSP, CSS, XML):
    • js/ . Contiene archivos Javascript utilizados por las páginas web.
    • WEB-INF/ . Contiene archivos de configuración y de interfaz de usuario.
    • jsp/ . Contiene los archivos JSP de cada página web.
  • appengine-web.xml
    Archivo de configuración donde las variables de entorno se cargan en variables.
  • web.xml
    Archivo de configuración donde se definen las asignaciones de servlets y las restricciones de seguridad.
  • cron.xml
    Archivo de configuración que define las tareas programadas (es decir, el servicio de notificaciones).

Configurar el tablero

Para configurar el panel de VTS:

  1. Cree un proyecto de Google Cloud App Engine y configure el host de implementación instalando:
    • Java 8
    • SDK de Google App Engine
    • Maven
  2. Genere un ID de cliente de OAuth 2.0 en Google Cloud API Manager.
  3. Cree una cuenta de servicio y cree un archivo de claves.
  4. Agrega una dirección de correo electrónico a la lista de remitentes autorizados de la API de correo electrónico de App Engine.
  5. Configure una cuenta de Google Analytics.
  6. Especifique las variables de entorno en Dashboard pom.xml :
    • Configure el ID de cliente con el ID de OAuth 2.0 (del paso 2).
    • Configure el ID del cliente de servicio con el identificador incluido en el archivo de claves (del paso 3).
    • Especifique la dirección de correo electrónico del remitente para las alertas (del paso 4).
    • Especifique un dominio de correo electrónico al que se enviarán todos los correos electrónicos.
    • Especifique la dirección del servidor REST de Gerrit.
    • Especifique el alcance de OAuth 2.0 que se utilizará para el servidor REST de Gerrit.
    • Especifique el ID de Google Analytics (del paso 5).
    • Construya e implemente el proyecto.
  7. En una terminal, ejecute mvn clean appengine:update

Para obtener más información sobre la instalación y configuración del panel, consulte el Laboratorio de código de Android VTS .

Consideraciones de Seguridad

La información de cobertura sólida requiere acceso al código fuente original. Sin embargo, algunos códigos pueden ser sensibles y una puerta de enlace adicional puede permitir la explotación de listas de control de acceso existentes.

Para evitar esta amenaza, en lugar de entregar el código fuente con la información de cobertura, el Tablero maneja directamente un vector de cobertura (es decir, un vector de recuentos de ejecución mapeados a líneas en un archivo fuente). Junto con el vector de cobertura, el Tablero recibe un nombre y una ruta de proyecto de Git para que el cliente pueda obtener el código de una API de código fuente externa. El navegador del cliente recibe esta información y utiliza el intercambio de recursos de origen cruzado (CORS) en Javascript para consultar el servidor de código fuente para el código fuente original; el código resultante se combina con el vector de cobertura para producir una visualización.

Este enfoque directo no amplía la superficie de ataque porque el Tablero utiliza las cookies del usuario para autenticarse con un servicio externo (lo que significa que un usuario que no puede acceder al código fuente directamente no puede explotar el Tablero para ver información confidencial).