Google is committed to advancing racial equity for Black communities. See how.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Configurazione dashboard VTS

Il dashboard VTS fornisce un backend utente e un'interfaccia utente (UI) per visualizzare i risultati dei test dal sistema di integrazione continua VTS. Supporta lo sviluppo basato sui test con strumenti come le notifiche sullo stato dei test per aiutare gli sviluppatori a individuare e prevenire le aree di regressione durante il ciclo di sviluppo (include il monitoraggio dei test e il supporto per la valutazione).

L'interfaccia utente del dashboard VTS supporta funzionalità (come la copertura del codice nativo) fornite dall'infrastruttura VTS e offre un monitoraggio continuo delle prestazioni per consentire lo sviluppo di strumenti per le prestazioni ottimizzati e ben caratterizzati.

Requisiti

I seguenti servizi sono necessari per utilizzare il dashboard VTS:

La visualizzazione della copertura del test si basa su un'API REST per un server del codice sorgente (ad esempio Gerrit), che consente al servizio Web di recuperare il codice sorgente originale in base agli elenchi di controllo di accesso esistenti.

Architettura

Il dashboard VTS utilizza la seguente architettura:

Figura 1 . Architettura del dashboard VTS.

I risultati dello stato dei test vengono caricati continuamente nel database Cloud Datastore tramite un'interfaccia REST. Il runner VTS elabora automaticamente i risultati e li serializza utilizzando il formato Protobuf.

I servlet Web costituiscono il punto di accesso principale per gli utenti, fornendo ed elaborando i dati dal database Datastore. I servlet includono: un servlet principale per fornire tutti i test, un servlet delle preferenze per la gestione dei preferiti dell'utente, un servlet dei risultati per popolare una tabella di test, un servlet del grafico per preparare i dati di profilazione e un servlet di copertura per preparare i dati di copertura per il client .

Ogni modulo di test ha il proprio albero genealogico Datastore ei risultati dei test sono indicizzati con il timestamp Unix dell'ora di inizio del test. I dati di copertura nel database vengono memorizzati con i risultati del test come vettore di conteggi (cioè per ogni riga nel file sorgente originale) e informazioni di identificazione per recuperare il codice sorgente da un server del codice sorgente.

Il servizio di notifica viene eseguito utilizzando le code delle attività, identificando le modifiche allo stato del test case e inviando una notifica ai sottoscrittori. Le informazioni stateful vengono archiviate in una tabella di stato per tenere traccia dell'aggiornamento dei dati e degli errori esistenti. Ciò consente al servizio di notifica di fornire informazioni dettagliate sui singoli errori e soluzioni dei casi di test.

Struttura del codice

I componenti essenziali di VTS Dashboard includono i servlet implementati in Java, i JSP front-end, i fogli di stile CSS ei file di configurazione. Il seguente elenco descrive in dettaglio le posizioni e le descrizioni di questi componenti (tutti i percorsi relativi a test/vts/web/dashboard ):

  • pom.xml
    File delle impostazioni in cui vengono definite le variabili di ambiente e le dipendenze.
  • src/main/java/com/android/vts/api/
    Contiene endpoint per l'interazione con i dati tramite REST.
  • src/main/java/com/android/vts/entity/
    Contiene i modelli Java delle entità Datastore.
  • src/main/java/com/android/vts/proto/
    Contiene file Java per Protobuf, incluso VtsReportMessage.java , un'implementazione Java di tipo Protobuf utilizzata per descrivere i risultati del test VTS.
  • src/main/java/com/android/vts/servlet/
    Contiene file Java per servlet.
  • src/main/java/com/android/vts/util/
    Contiene i file Java per le funzioni di utilità e le classi utilizzate dai servlet.
  • src/test/java/com/android/vts/
    Contiene i test dell'interfaccia utente per i servlet e le utilità.
  • src/main/webapp/
    Contiene file relativi all'interfaccia utente (JSP, CSS, XML):
    • js/ . Contiene i file Javascript utilizzati dalle pagine web.
    • WEB-INF/ . Contiene i file di configurazione e dell'interfaccia utente.
    • jsp/ . Contiene i file JSP per ogni pagina web.
  • appengine-web.xml
    File delle impostazioni in cui le variabili di ambiente vengono caricate nelle variabili.
  • web.xml
    File delle impostazioni in cui vengono definiti i mapping servlet e i vincoli di sicurezza.
  • cron.xml
    File di impostazioni che definisce le attività pianificate (ad esempio il servizio di notifiche).

Configurazione della dashboard

Per configurare il dashboard VTS:

  1. Crea un progetto Google Cloud App Engine e configura l'host di distribuzione installando:
    • Java 8
    • SDK di Google App Engine
    • Esperto di
  2. Genera un ID client OAuth 2.0 in Google Cloud API Manager.
  3. Crea un account di servizio e crea un file di chiavi.
  4. Aggiungi un indirizzo email all'elenco dei mittenti autorizzati dell'API email di App Engine.
  5. Crea un account Google Analytics.
  6. Specificare le variabili d'ambiente nel dashboard pom.xml :
    • Imposta l'ID client con l'ID OAuth 2.0 (dal passaggio 2).
    • Impostare l'ID del client del servizio con l'identificatore incluso nel file di chiavi (dal passaggio 3).
    • Specificare l'indirizzo e-mail del mittente per gli avvisi (dal passaggio 4).
    • Specifica un dominio di posta elettronica a cui verranno inviate tutte le email.
    • Specificare l'indirizzo del server REST di Gerrit.
    • Specificare l'ambito OAuth 2.0 da utilizzare per il server REST Gerrit.
    • Specifica l'ID di Google Analytics (dal passaggio 5).
    • Compilare e distribuire il progetto.
  7. In un terminale, esegui mvn clean appengine:update

Per ulteriori informazioni sull'impostazione e la configurazione del dashboard, fare riferimento a Android VTS Code Lab .

Considerazioni sulla sicurezza

Informazioni di copertura affidabili richiedono l'accesso al codice sorgente originale. Tuttavia, alcuni codici potrebbero essere sensibili e un gateway aggiuntivo potrebbe consentire lo sfruttamento degli elenchi di controllo di accesso esistenti.

Per evitare questa minaccia, invece di fornire il codice sorgente con le informazioni sulla copertura, il dashboard gestisce direttamente un vettore di copertura (cioè, un vettore di esecuzione conta la mappatura alle linee in un file sorgente). Insieme al vettore di copertura, il dashboard riceve un nome e un percorso del progetto Git in modo che il client possa recuperare il codice da un'API del codice sorgente esterno. Il browser client riceve queste informazioni e utilizza CORS (cross-origin resource sharing) in Javascript per interrogare il server del codice sorgente per il codice sorgente originale; il codice risultante viene combinato con il vettore di copertura per produrre una visualizzazione.

Questo approccio diretto non amplia la superficie di attacco perché il Dashboard utilizza i cookie dell'utente per autenticarsi con un servizio esterno (ovvero un utente che non può accedere direttamente al codice sorgente non può sfruttare il Dashboard per visualizzare informazioni sensibili).