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 del triage).
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 la dashboard VTS sono necessari i seguenti servizi:
- Apache Maven , per la creazione e la distribuzione
- Google Cloud App Engine , per l'hosting di servizi Web
- Google Cloud Datastore , per l'archiviazione
- Google Stackdriver , per il monitoraggio
La visualizzazione della copertura dei test si basa su un'API REST su 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 degli accessi esistenti.
Architettura
Il Dashboard VTS utilizza la seguente architettura:
I risultati dello stato del 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 primario per gli utenti, fornendo ed elaborando i dati dal database Datastore. Le servlet includono: una servlet principale per fornire tutti i test, una servlet delle preferenze per gestire i preferiti dell'utente, una servlet dei risultati per popolare una tabella di test, una servlet del grafico per preparare i dati di profilazione e una servlet di copertura per preparare i dati di copertura per il client .
Ogni modulo di test ha il proprio albero genealogico 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 (ad esempio 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 di attività, identificando le modifiche allo stato dei test case e inviando notifiche ai sottoscrittori. Le informazioni sullo stato 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 sugli errori e sulle 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 di 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, inclusoVtsReportMessage.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 file Java per funzioni di utilità e classi utilizzate dai servlet. -
src/test/java/com/android/vts/
Contiene test dell'interfaccia utente per servlet e 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 file di configurazione e dell'interfaccia utente. -
jsp/. Contiene i file JSP per ogni pagina Web.
-
-
appengine-web.xml
File di impostazioni in cui le variabili di ambiente vengono caricate in variabili. -
web.xml
File di impostazioni in cui vengono definiti i mapping dei servlet e i vincoli di sicurezza. -
cron.xml
File di impostazioni che definisce le attività pianificate (ad esempio il servizio di notifiche).
Configura la dashboard
Per impostare la dashboard VTS:
- Crea un progetto Google Cloud App Engine e configura l'host di distribuzione installando:
- Giava8
- SDK di Google App Engine
- Esperto di
- Genera un ID client OAuth 2.0 nel Gestore API Google Cloud.
- Crea un account di servizio e crea un file di chiavi.
- Aggiungi un indirizzo email all'elenco dei mittenti autorizzati dell'API Email di App Engine.
- Configura un account Google Analytics.
- Specificare le variabili di ambiente nel Dashboard
pom.xml:- Imposta l'ID client con l'ID OAuth 2.0 (dal passaggio 2).
- Imposta 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 del server REST Gerrit.
- Specificare l'ambito OAuth 2.0 da utilizzare per il server Gerrit REST.
- Specifica l'ID di Google Analytics (dal passaggio 5).
- Costruisci e distribuisci il progetto.
- In un terminale, esegui
mvn clean appengine:update.
Considerazioni sulla sicurezza
Informazioni di copertura affidabili richiedono l'accesso al codice sorgente originale. Tuttavia, parte del codice potrebbe essere sensibile e un gateway aggiuntivo potrebbe consentire lo sfruttamento degli elenchi di controllo degli accessi esistenti.
Per evitare questa minaccia, invece di fornire al codice sorgente le informazioni sulla copertura, la Dashboard gestisce direttamente un vettore di copertura (ovvero, un vettore di conteggi di esecuzione mappato sulle righe in un file sorgente). Insieme al vettore di copertura, la Dashboard riceve un nome e un percorso di progetto Git in modo che il client possa recuperare il codice da un'API del codice sorgente esterna. Il browser client riceve queste informazioni e utilizza la condivisione di risorse multiorigine (CORS) 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é la 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 la Dashboard per visualizzare informazioni sensibili).