Configuración del panel VTS

El panel de VTS proporciona un backend de usuario y una interfaz de usuario (UI) para ver los resultados de las pruebas desde el sistema de integración continua de VTS. Admite el desarrollo basado en pruebas con herramientas como notificaciones de estado de pruebas para ayudar a los desarrolladores a localizar y prevenir áreas de regresión durante el ciclo de desarrollo (incluye soporte de clasificación y monitoreo de pruebas).

La interfaz de usuario del panel VTS admite funciones (como la cobertura de código nativo) proporcionadas por la infraestructura VTS y ofrece 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 VTS:

• Apache Maven , para construcción e implementación
• Google Cloud App Engine , para alojamiento de servicios web
• Google Cloud Datastore , para almacenamiento
• Google Stackdriver , para seguimiento

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

Arquitectura

El panel VTS utiliza la siguiente arquitectura:

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

Los servlets web forman el punto de acceso principal para los usuarios, entregando y procesando datos de la base de datos del almacén de datos. 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 pruebas, 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 del almacén de datos 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 las pruebas como un vector de recuentos (es decir, para cada línea en el archivo fuente original) e información de identificación para recuperar el código fuente de un servidor de código fuente.

El servicio de notificación se ejecuta utilizando 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 valiosa sobre fallas y correcciones de casos de prueba individuales.

Estructura del código

Los componentes esenciales de VTS Dashboard incluyen los servlets implementados en Java, los 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 del almacén de datos.
• src/main/java/com/android/vts/proto/
  Contiene archivos Java para Protobuf, incluido VtsReportMessage.java , que es una implementación Java del tipo Protobuf utilizada 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 funciones de utilidad y clases utilizadas por los servlets.
• src/test/java/com/android/vts/
  Contiene pruebas de UI 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 UI.
  • jsp/ . Contiene los archivos JSP para 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 panel

Para configurar el panel 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
   • experto
2. Genere un ID de cliente OAuth 2.0 en Google Cloud API Manager.
3. Cree una cuenta de servicio y cree un archivo de claves.
4. Agregue 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 variables de entorno en el panel pom.xml :
   • Configure el ID del cliente con el ID de OAuth 2.0 (del paso 2).
   • Configure el ID del cliente del 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 (desde el 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 .

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 Panel maneja directamente un vector de cobertura (es decir, un vector de recuentos de ejecución asignados a líneas en un archivo fuente). Junto con el vector de cobertura, el Panel recibe un nombre de proyecto Git y una ruta para que el cliente pueda recuperar el código de una API de código fuente externo. El navegador del cliente recibe esta información y utiliza el intercambio de recursos entre orígenes (CORS) en Javascript para consultar el código fuente original en el servidor de código fuente; 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 Panel utiliza las cookies del usuario para autenticarse con un servicio externo (lo que significa que un usuario que no puede acceder directamente al código fuente no puede explotar el Panel para ver información confidencial).