Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Impostazione Dashboard VTS

Il Dashboard VTS fornisce un backend utente e un'interfaccia utente (UI) per la visualizzazione dei risultati dei test dal sistema di integrazione continua VTS. Supporta lo sviluppo guidato dai 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 del triaging).

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 di prestazioni ottimizzati e ben caratterizzati.

Requisiti

Per utilizzare il Dashboard VTS sono richiesti i seguenti servizi:

La visualizzazione della copertura del test si basa su un'API REST su un server di 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 Dashboard VTS.

I risultati dello stato del test vengono continuamente caricati 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 la consegna di tutti i test, un servlet delle preferenze per la gestione dei preferiti degli utenti, un servlet dei risultati per il popolamento di una tabella di test, un servlet grafico per la preparazione dei dati di profiling e un servlet di copertura per la preparazione dei dati di copertura per il client .

Ogni modulo di test ha il proprio albero di origini Datastore e i risultati dei test sono indicizzati con il timestamp Unix dell'ora di inizio del test. I dati di copertura nel database vengono archiviati con i risultati del test come vettore di conteggi (ovvero per ogni riga nel file di origine originale) e identificando le informazioni per recuperare il codice sorgente da un server di codice sorgente.

Il servizio di notifica viene eseguito utilizzando le code delle attività, identificando le modifiche allo stato del test case e notificando agli abbonati. Le informazioni stateful sono 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 sugli errori e le correzioni dei singoli 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 e i file di configurazione. L'elenco seguente 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 sono 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 modelli Java delle entità Datastore.
  • src/main/java/com/android/vts/proto/
    Contiene file Java per Protobuf, incluso VtsReportMessage.java , che è un'implementazione Java di tipo Protobuf utilizzata per descrivere i risultati dei 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 test dell'interfaccia utente per servlet e programmi di 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 in variabili.
  • web.xml
    File delle impostazioni in cui sono definiti mapping servlet e vincoli di sicurezza.
  • cron.xml
    File delle impostazioni che definisce le attività pianificate (ad es. Il servizio di notifica).

Impostazione della dashboard

Per configurare il dashboard VTS:

  1. Crea un progetto di 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 nel gestore API di Google Cloud.
  3. Creare un account di servizio e creare un file di chiavi.
  4. Aggiungi un indirizzo e-mail all'Elenco mittenti autorizzati dell'API e-mail di App Engine.
  5. Imposta un account Google Analytics.
  6. Specificare le variabili di ambiente nel Dashboard pom.xml :
    • Impostare l'ID client con l'ID OAuth 2.0 (dal passaggio 2).
    • Impostare l'ID 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).
    • Specificare un dominio e-mail a cui verranno inviate tutte le e-mail.
    • Specificare l'indirizzo per il server REST 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, eseguire mvn clean appengine:update

Per ulteriori informazioni sull'impostazione e la configurazione del Dashboard, consultare Android VTS Code Lab .

Considerazioni sulla sicurezza

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

Per evitare questa minaccia, invece di fornire il codice sorgente con le informazioni sulla copertura, il Dashboard gestisce direttamente un vettore di copertura (ovvero, un vettore di esecuzione conta il mapping alle linee in un file di origine). Insieme al vettore di copertura, Dashboard riceve un nome e un percorso del progetto Git in modo che il client possa recuperare il codice da un'API di codice sorgente esterna. Il browser client riceve queste informazioni e utilizza la condivisione di risorse tra origini (CORS) in Javascript per eseguire una query sul server del codice sorgente per il codice sorgente originale; il codice risultante viene combinato con il vettore di copertura per produrre un display.

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