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

Database dashboard VTS

Per supportare un dashboard di integrazione continua che sia scalabile, performante e flessibile, il back-end del dashboard VTS deve essere progettato con cura con una solida conoscenza delle funzionalità del database. Google Cloud Datastore è un database NoSQL che offre garanzie ACID transazionali e consistenza finale, nonché una forte coerenza all'interno dei gruppi di entità. Tuttavia, la struttura è molto diversa dai database SQL (e anche da Cloud Bigtable); invece di tabelle, righe e celle ci sono tipi, entità e proprietà.

Le sezioni seguenti delineano la struttura dei dati e gli schemi di interrogazione per creare un backend efficace per il servizio web VTS Dashboard.

Entità

Le entità seguenti memorizzano i riepiloghi e le risorse delle esecuzioni dei test VTS:

  • Entità di prova . Memorizza i metadati sulle esecuzioni di test di un determinato test. La sua chiave è il nome del test e le sue proprietà includono il conteggio degli errori, il conteggio dei passaggi e l'elenco delle interruzioni dei casi di test da quando i processi di avviso lo aggiornano.
  • Entità esecuzione test . Contiene i metadati delle esecuzioni di un determinato test. Deve memorizzare i timestamp di inizio e fine del test, l'ID build del test, il numero di casi di test passati e non riusciti, il tipo di esecuzione (ad es. Pre-invio, post-invio o locale), un elenco di collegamenti di registro, l'host nome della macchina e conteggi del riepilogo della copertura.
  • Entità delle informazioni sul dispositivo . Contiene dettagli sui dispositivi utilizzati durante l'esecuzione di prova. Include l'ID build del dispositivo, il nome del prodotto, la destinazione della build, il ramo e le informazioni ABI. Questo viene archiviato separatamente dall'entità di esecuzione del test per supportare le esecuzioni di test multi-dispositivo in modo uno-a-molti.
  • Entità esecuzione punto di profilatura . Riepiloga i dati raccolti per un particolare punto di profilazione all'interno di un'esecuzione di test. Descrive le etichette degli assi, il nome del punto di profilatura, i valori, il tipo e la modalità di regressione dei dati di profilatura.
  • Entità di copertura . Descrive i dati di copertura raccolti per un file. Contiene le informazioni sul progetto Git, il percorso del file e l'elenco dei conteggi di copertura per riga nel file di origine.
  • Entità di esecuzione del caso di test . Descrive il risultato di un particolare test case da un'esecuzione di test, incluso il nome del test case e il suo risultato.
  • Entità Preferiti utente . Ogni sottoscrizione utente può essere rappresentata in un'entità contenente un riferimento al test e l'ID utente generato dal servizio utente App Engine. Ciò consente un'efficiente interrogazione bidirezionale (cioè per tutti gli utenti iscritti a un test e per tutti i test preferiti da un utente).

Raggruppamento di entità

Ogni modulo di test rappresenta la radice di un gruppo di entità. Le entità di esecuzione di test sono sia figli di questo gruppo che genitori per entità dispositivo, entità di punti di profilatura ed entità di copertura rilevanti per il rispettivo antenato di test e esecuzione di test.

Figura 1 . Testare l'ascendenza dell'entità.

Punto chiave: quando si progettano relazioni di discendenza, è necessario bilanciare la necessità di fornire meccanismi di query efficaci e coerenti con le limitazioni imposte dal database.

Benefici

Il requisito di coerenza garantisce che le operazioni future non vedranno gli effetti di una transazione fino a quando non viene eseguita il commit e che le transazioni in passato siano visibili alle operazioni presenti. In Cloud Datastore, il raggruppamento di entità crea isole di forte coerenza di lettura e scrittura all'interno del gruppo, che in questo caso è costituito da tutte le esecuzioni di test e dai dati relativi a un modulo di test. Ciò offre i seguenti vantaggi:

  • Le letture e gli aggiornamenti per testare lo stato del modulo da parte di processi di avviso possono essere trattati come atomici
  • Visualizzazione coerente garantita dei risultati del test case all'interno dei moduli di test
  • Query più veloce all'interno degli alberi genealogici

Limitazioni

La scrittura in un gruppo di entità a una velocità superiore a un'entità al secondo non è consigliata poiché alcune scritture potrebbero essere rifiutate. Finché i lavori di avviso e il caricamento non avvengono a una velocità superiore a una scrittura al secondo, la struttura è solida e garantisce una forte coerenza.

In definitiva, il limite di una scrittura per modulo di test al secondo è ragionevole perché le esecuzioni dei test di solito richiedono almeno un minuto, compreso il sovraccarico del framework VTS; a meno che un test non venga costantemente eseguito simultaneamente su più di 60 host diversi, non può esserci un collo di bottiglia in scrittura. Ciò diventa ancora più improbabile dato che ogni modulo fa parte di un piano di test che spesso richiede più di un'ora. Le anomalie possono essere facilmente gestite se gli host eseguono i test contemporaneamente, causando brevi picchi di scritture sugli stessi host (ad esempio, rilevando errori di scrittura e riprovando).

Considerazioni sulla scalabilità

Un'esecuzione di test non deve necessariamente avere il test come genitore (ad esempio, potrebbe richiedere un'altra chiave e avere il nome del test, l'ora di inizio del test come proprietà); tuttavia, questo scambierà una forte coerenza con un'eventuale coerenza. Ad esempio, il processo di avviso potrebbe non visualizzare un'istantanea reciprocamente coerente delle esecuzioni di test più recenti all'interno di un modulo di test, il che significa che lo stato globale potrebbe non rappresentare una rappresentazione completamente accurata della sequenza di esecuzioni di test. Ciò può anche influire sulla visualizzazione delle esecuzioni di test all'interno di un singolo modulo di test, che potrebbe non essere necessariamente un'istantanea coerente della sequenza di esecuzioni. Alla fine lo snapshot sarà coerente, ma non ci sono garanzie che i dati più aggiornati saranno.

Casi test

Un altro potenziale collo di bottiglia sono i test di grandi dimensioni con molti casi di test. I due vincoli operativi sono il throughput massimo di scrittura all'interno di un gruppo di entità di uno al secondo, insieme a una dimensione massima della transazione di 500 entità.

Un approccio potrebbe essere quello di specificare un test case che ha un test eseguito come antenato (simile a come vengono memorizzati i dati di copertura, i dati di profilazione e le informazioni sul dispositivo):

Figura 2 . I casi di test discendono dalle esecuzioni di test (NON RACCOMANDATO).

Sebbene questo approccio offra atomicità e coerenza, impone forti limitazioni ai test: se una transazione è limitata a 500 entità, un test non può avere più di 498 casi di test (presumendo che non ci siano dati di copertura o di profilazione). Se un test dovesse superare questo limite, una singola transazione non potrebbe scrivere tutti i risultati del test case contemporaneamente e la divisione dei test case in transazioni separate potrebbe superare il throughput massimo di scrittura del gruppo di entità di un'iterazione al secondo. Poiché questa soluzione non scalerà bene senza sacrificare le prestazioni, non è consigliata.

Tuttavia, invece di memorizzare i risultati dello scenario di test come figli dell'esecuzione di test, gli scenari di test possono essere archiviati in modo indipendente e le relative chiavi fornite all'esecuzione di test (un'esecuzione di test contiene un elenco di identificatori per le entità degli scenari di test):

Figura 3 . Casi di test memorizzati in modo indipendente (CONSIGLIATO).

A prima vista, questo può sembrare rompere la forte garanzia di coerenza. Tuttavia, se il client ha un'entità di esecuzione di test e un elenco di identificatori di casi di test, non è necessario creare una query; può invece ottenere direttamente i casi di test dai loro identificatori, che è sempre garantito per essere coerente. Questo approccio allevia notevolmente il vincolo sul numero di casi di test che un'esecuzione di test può avere, acquisendo una forte coerenza senza minacciare una scrittura eccessiva all'interno di un gruppo di entità.

Modelli di accesso ai dati

Il dashboard VTS utilizza i seguenti modelli di accesso ai dati:

  • Preferiti dell'utente . Può essere interrogato utilizzando un filtro di uguaglianza sulle entità dei preferiti dell'utente che hanno come proprietà il particolare oggetto Utente di App Engine.
  • Elenco di prova . Semplice query di entità di test. Per ridurre la larghezza di banda per il rendering della home page, è possibile utilizzare una proiezione sui conteggi passati e non riusciti in modo da omettere l'elenco potenzialmente lungo degli ID dei casi di test non riusciti e altri metadati utilizzati dai lavori di avviso.
  • Test eseguiti . La query per le entità di esecuzione di test richiede un ordinamento sulla chiave (timestamp) e un possibile filtraggio sulle proprietà dell'esecuzione di test come ID build, conteggio passaggi, ecc. Eseguendo una query antenata con una chiave dell'entità di test, la lettura è fortemente coerente. A questo punto, tutti i risultati dello scenario di test possono essere recuperati utilizzando l'elenco di ID memorizzati in una proprietà di esecuzione di test; questo è anche garantito per essere un risultato fortemente coerente dalla natura delle operazioni di recupero del datastore.
  • Dati di profilazione e copertura . È possibile eseguire query sui dati di profilazione o di copertura associati a un test senza recuperare anche altri dati di esecuzione di test (come altri dati di profilazione / copertura, dati di casi di test, ecc.). Una query antenata che utilizza le chiavi di entità del test e dell'esecuzione di test recupererà tutti i punti di creazione profili registrati durante l'esecuzione del test; filtrando anche in base al nome del punto di profilatura o al nome del file, è possibile recuperare una singola entità di profilazione o copertura. Per la natura delle query degli antenati, questa operazione è fortemente coerente.

Per i dettagli sull'interfaccia utente e gli screenshot di questi modelli di dati in azione, vedi Interfaccia utente del dashboard VTS .