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

Infrastruttura di test automatizzata

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

Architettura

L'infrastruttura di test automatizzati 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 automatizzata VTS esegue le seguenti attività:

  1. Recupera crea artefatti e verifica risorse da diverse posizioni:
    • Partner Android Build (PAB) . Per il GSI, il framework VTS e alcune altre build.
    • File system locale, Google Cloud Storage o altri sistemi di build specifici del fornitore . Per i partner che non archiviano build nel cloud di Google.
  2. I flash generano 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 alla 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 degli ultimi build, del flashing sui dispositivi e del richiamo dei test (localmente o tramite il comandante). Comunica anche con uno scheduler cloud e dirige il traffico tra lo scheduler e l'istanza TradeFed (o qualche altro cablaggio) in esecuzione sull'HC. Per i dettagli sul controller host, consultare Architettura controller host .

Fornitori di risorse

Il test automatizzato richiede risorse come build di sistema, file di test e artefatti VTS. Sebbene sia possibile costruirli dal sorgente, è più facile costruirli regolarmente dalla punta dell'albero, quindi pubblicare gli artefatti per il download.

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

  • Partner Android Build . Accesso programmatico concesso in base all'account.
  • File system locale (o simile). Per i partner che non utilizzano Partner Android Build.

Per l'uso nel flashing dei dispositivi in ​​un secondo momento, le risorse includono provider di build per entrambe le opzioni, che si estendono da un unico build_provider.py che archivia i build in directory temporanee locali.

Partner Android Build

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 ad alta intensità di lavoro, Android 9 include il supporto per il download automatico di queste risorse dalla rubrica personale quando vengono fornite le credenziali appropriate.

Stabilire l'accesso

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

Richiesta POST per URL

Facendo clic su un collegamento di risorse in PAB si invia una richiesta POST che include i dati necessari per quella risorsa, tra cui:

  • costruire id, costruire target
  • nome della risorsa
  • ramo
  • rilasciare il nome del candidato e se il candidato è o meno una build interna

La richiesta POST viene ricevuta dal metodo downloadBuildArtifact di 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 dall'autorizzazione e accessibile con le credenziali OAuth2 appropriate).
  • Per altre risorse, l'URL è un URL lungo e non protetto dall'API Android Build interna (che scade dopo cinque minuti).

Ottenere l'URL

Per evitare la falsificazione di richieste tra siti, l'RPC buildsvc richiede che un token XSRF sia POSTATO con gli altri parametri. Sebbene questo token renda il processo più sicuro, rende anche l'accesso programmatico molto più difficile poiché il token (che è disponibile solo nella JavaScript della pagina della rubrica personale) è ora richiesto anche per l'accesso.

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

File system locale

Data una directory con un elenco (o file zip) di artefatti, il provider di build imposta le immagini rilevanti in base a ciò che si trova nella directory. Puoi utilizzare lo strumento gsutil per copiare i file da Google Cloud Storage in una directory locale.

Build lampeggianti

Dopo che le immagini del dispositivo più recenti sono state scaricate sull'host, è necessario eseguire il flashing di tali immagini sui dispositivi. Questo viene fatto usando i comandi standard adb e fastboot e i sottoprocessi di Python, in base ai percorsi di file temporanei memorizzati dai provider di build.

Azioni supportate:

  • Lampeggiante solo GSI
  • Immagini singole lampeggianti dal sistema principale (ad es. fastboot flash boot boot.img )
  • Lampeggiamento di tutte le immagini dal sistema principale. Esempio:
    • fastboot flashall (usando l'utility flashall )
    • fastboot flash (uno alla volta)

Esecuzione di test

In Android 9, l'infrastruttura di test automatizzati VTS supporta solo il cablaggio di test TradeFed ma potrebbe essere esteso 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 es. vts-selftest ) ed esegue il test.
  • Quando si utilizza un cluster TradeFed (facoltativamente collegato a MTT), utilizzare il comando lease nella console del controller host, che cerca esecuzioni di test non completate.

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

Risultati dei rapporti

VtsMultiDeviceTest riporta automaticamente i risultati dei test ad alcuni progetti di dashboard VTS.