Infrastruttura di test automatizzata

Android 9 include un'infrastruttura Vendor Test Suite (VTS) per test automatizzati di VTS, CTS o altri test sui dispositivi partner che eseguono l'immagine di sistema generica AOSP (GSI). In precedenza, l'esecuzione di questi test era un'operazione altamente manuale; la nuova infrastruttura di test VTS è progettata per supportare test automatizzati più volte al giorno su più dispositivi.

Architettura

L'infrastruttura di testing automatizzato VTS utilizza la seguente architettura:

Automated test architecture

Figura 1. Architettura dell'infrastruttura di test automatizzata VTS

Quando viene attivato un test, l'infrastruttura di test automatizzato VTS esegue le seguenti attività:

  1. I recuperi creano artefatti e testano risorse da diverse posizioni:
    • Partner Android Build (PAB) . Per GSI, framework VTS e alcune altre build.
    • File system locale, Google Cloud Storage o altro sistema di build specifico del fornitore . Per i partner che non archiviano le build nel cloud di Google.
  2. I flash creano artefatti (dal dispositivo) e GSI (da AOSP) sui dispositivi collegati.
  3. Esegue test VTS utilizzando TradeFed locale o TradeFed nel cloud.
  4. Riporta i risultati dei test al dashboard VTS

Il processo è coordinato dal controller host VTS (HC), una macchina in laboratorio che dirige il comportamento di tutti i dispositivi collegati sotto test. L'HC è responsabile del recupero delle build più recenti, del loro flashing sui dispositivi e dell'esecuzione di test (localmente o tramite il comandante). Comunica inoltre con uno scheduler cloud e dirige il traffico tra lo scheduler e l'istanza TradeFed (o qualche altro cablaggio) in esecuzione sull'HC. Per dettagli sul controller host, vedere Architettura del controller host .

Fornitori di risorse

I test automatizzati richiedono risorse come build di sistema, file di test e artefatti VTS. Sebbene sia possibile crearli dal sorgente, è più semplice crearli regolarmente dalla punta dell'albero e quindi pubblicare gli artefatti per il download.

I partner possono accedere alle risorse di automazione utilizzando le seguenti posizioni:

  • Creazione Android partner . Accesso programmatico concesso in base al singolo account.
  • Filesystem locale (o simile). Per i partner che non utilizzano Partner Android Build.

Da utilizzare successivamente per eseguire il flashing dei dispositivi, le risorse includono provider di build per entrambe le opzioni, estendendosi da un singolo build_provider.py che memorizza le build in directory temporanee locali.

Creazione Android partner

In Android 8.1 e versioni precedenti, i partner Android dovevano visitare il sito Web Partner Android Build ( https://partner.android.com/build ), accedere al proprio account e recuperare le immagini di sistema più recenti tramite l'interfaccia utente. Per aiutare i partner a evitare questo processo lento e dispendioso in termini di manodopera, Android 9 include il supporto per il download automatico di queste risorse da PAB quando vengono fornite le credenziali appropriate.

Stabilire l'accesso

L'accesso programmatico utilizza OAuth2 sulle API di Google per accedere alle RPC richieste. Utilizzando l' approccio standard per la generazione delle credenziali OAuth2, il partner deve impostare una coppia ID client/segreto con Google. Quando PartnerAndroidBuildClient viene indirizzato a quel segreto per la prima volta, apre una finestra del browser in cui l'utente può accedere al proprio account Google, che genera le credenziali OAuth2 necessarie per andare avanti. Le credenziali (token di accesso e token di aggiornamento) vengono archiviate localmente, il che significa che i partner dovrebbero accedere solo una volta.

Richiesta POST per URL

Facendo clic su un collegamento a una risorsa in PAB viene inviata una richiesta POST che include i dati necessari per tale risorsa, tra cui:

  • ID build, destinazione build
  • nome della risorsa
  • ramo
  • nome del candidato al rilascio e se il candidato è o meno una build interna

La richiesta POST viene ricevuta dal metodo downloadBuildArtifact dell'RPC buildsvc , che restituisce un URL che può essere utilizzato per accedere alla risorsa.

  • Per le risorse APK di Clockwork Companion, l'URL è un URL leggibile ospitato su PAB (che è protetto da autenticazione e accessibile con le credenziali OAuth2 appropriate).
  • Per le altre risorse, l'URL è un URL lungo e non protetto dall'API Android Build interna (che scade dopo cinque minuti).

Ottieni l'URL

Per evitare la falsificazione delle richieste tra siti, l'RPC buildsvc richiede che un token XSRF venga inviato in POST con gli altri parametri. Sebbene questo token renda il processo più sicuro, rende anche molto più difficile l'accesso a livello di codice poiché il token (disponibile solo nel JavaScript della pagina PAB) è ora richiesto anche per l'accesso.

Per evitare questo problema, Android 9 ridisegna lo schema di denominazione degli URL per tutti i file (non solo gli APK) per utilizzare nomi URL prevedibili per accedere agli elenchi di artefatti e agli URL degli artefatti. Il PAB ora utilizza un formato URL conveniente che consente ai partner di scaricare risorse; Gli script HC possono scaricare facilmente questi APK, poiché il formato URL è noto e HC può ignorare i problemi XSRF/cookie perché non necessita dell'RPC buildsvc .

File system locale

Data una directory con un elenco (o un file zip) di elementi, il provider di build imposta le immagini pertinenti in base al contenuto della directory. Puoi utilizzare lo strumento gsutil per copiare file da Google Cloud Storage a una directory locale.

Build Flash

Dopo che le immagini del dispositivo più recenti sono state scaricate sull'host, tali immagini devono essere flashate sui dispositivi. Questo viene fatto utilizzando i comandi adb e fastboot standard e i sottoprocessi Python, in base ai percorsi dei file temporanei memorizzati dai fornitori di build.

Azioni supportate:

  • Lampeggia solo il GSI
  • Lampeggio di singole immagini dal sistema principale (ad esempio, fastboot flash boot boot.img )
  • Lampeggio di tutte le immagini dal sistema principale. Esempio:
    • fastboot flashall (utilizzando l'utilità flashall integrata)
    • fastboot flash (uno alla volta)

Esegui dei test

In Android 9, l'infrastruttura di test automatizzata VTS supporta solo il test cablaggio TradeFed ma potrebbe essere estesa per supportare altri cablaggi in futuro.

Dopo aver preparato i dispositivi, è possibile richiamare i test utilizzando una delle seguenti opzioni:

  • Quando si utilizza TradeFed localmente, utilizzare il comando test nel controller host, che prende il nome di un piano di test VTS (ad esempio vts-selftest ) ed esegue il test.
  • Quando si utilizza un TradeFed Cluster (opzionalmente connesso a MTT), utilizzare il comando lease nella console del controller host, che cerca le esecuzioni di test non completate.

Se si utilizza TradeFedCluster, TradeFed viene eseguito localmente come gestore remoto . In caso contrario, i test vengono invocati utilizzando i sottoprocessi Python.

Riporta i risultati

I risultati dei test vengono automaticamente segnalati ad alcuni progetti dashboard VTS da VtsMultiDeviceTest .