Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

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 tablero de VTS admite funciones (como la cobertura de código nativo) proporcionada por la infraestructura de VTS y ofrece un monitoreo continuo 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:

Visualización de cobertura de la prueba se basa en una API REST a un servidor de código fuente (por ejemplo, Gerrit), lo que permite que el servicio web para descargar fuentes 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 ascendencia de Datastore y los resultados de la prueba se indexan con la marca de tiempo de 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 los lugares y las descripciones de estos componentes (todos 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 los archivos Java para Protobuf, incluyendo VtsReportMessage.java , que es una implementación de Java de tipo Protobuf utilizado para describir los resultados de pruebas STM.
  • 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 de utilidad y las clases que utilizan los servlets.
  • src/test/java/com/android/vts/
    Contiene pruebas de IU para los servlets y utilidades.
  • 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 servlet 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. Especificar las variables de entorno en el tablero de instrumentos 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 un terminal, ejecute mvn clean appengine:update .

Consideraciones de Seguridad

La información de cobertura sólida requiere acceso al código fuente original. Sin embargo, algunos códigos pueden ser confidenciales 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 mapeado a líneas en un archivo fuente). Junto con el vector de cobertura, el Tablero recibe un nombre de proyecto Git y una ruta 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).