Infrastruttura di test automatica

Android 9 include un'infrastruttura Vendor Test Suite (VTS) per i test automatici di VTS, CTS o altri test sui dispositivi dei 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 i test automatici più volte al giorno su più dispositivi.

Architettura

L'infrastruttura di test automatici VTS utilizza la seguente architettura:

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

1. Recupera gli artefatti della build e le risorse di test da diverse località:
   • Partner Android Build (PAB). Per GSI, il framework VTS e alcune altre build.
   • File system locale, Google Cloud Storage o altro sistema di compilazione specifico del fornitore. Per i partner che non archiviano le build nel cloud di Google.
2. Esegue il flashing degli artefatti della build (dal dispositivo) e di GSI (da AOSP) sui dispositivi connessi.
3. Esegue i test VTS utilizzando TradeFed locale o TradeFed nel cloud.
4. Segnala i risultati dei test alla dashboard VTS

Il processo è coordinato dal controller host (HC) VTS, una macchina nel laboratorio che dirige il comportamento di tutti i dispositivi connessi in fase di test. L'HC è responsabile del recupero delle build più recenti, del flashing sui dispositivi e dell'invocazione dei test (localmente o tramite il comando). Comunica anche con uno scheduler cloud e indirizza il traffico tra lo scheduler e l'istanza TradeFed (o un altro harness) in esecuzione sull'HC. Per maggiori dettagli sul controller host, consulta Architettura del controller host.

Fornitori di risorse

I test automatici richiedono risorse come build di sistema, file di test e artefatti VTS. Sebbene sia possibile crearli dal codice sorgente, è più facile crearli regolarmente dal tip-of-tree e poi pubblicare gli artefatti per il download.

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

• Partner Android Build. Accesso programmatico concesso per ogni account.
• File system locale (o simile). Per i partner che non utilizzano Partner Android Build.

Per l'utilizzo nel flashing dei dispositivi in un secondo momento, le risorse includono fornitori di build per entrambe le opzioni, che si estendono da un singolo build_provider.py che archivia le build nelle directory temporanee locali.

Partner Android Build

Nelle release di Android 8.1 e 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 laborioso, 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 agli RPC richiesti. Utilizzando l' approccio standard per la generazione delle credenziali OAuth2, il partner deve configurare una coppia ID client/secret con Google. Quando il PartnerAndroidBuildClient viene indirizzato a questo secret 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 procedere. Le credenziali (token di accesso e token di aggiornamento) vengono archiviate localmente, il che significa che i partner devono accedere una sola volta.

Richiesta POST per l'URL

Se fai clic su un link a una risorsa in PAB, viene inviata una richiesta POST che include i dati necessari per la risorsa, tra cui:

• ID build, target build
• nome risorsa
• salto
• nome del candidato per la release e se il candidato è 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 (protetto dall'autenticazione e accessibile con le credenziali OAuth2 appropriate).
• Per altre risorse, l'URL è un URL lungo e non protetto dell'API Android Build interna (che scade dopo cinque minuti).

Recuperare l'URL

Per evitare attacchi di richiesta cross-site forgery, l'buildsvc RPC richiede che un token XSRF venga inviato tramite POST con gli altri parametri. Sebbene questo token renda il processo più sicuro, rende anche l'accesso programmatico molto più difficile, poiché ora è necessario anche il token (disponibile solo in JavaScript della pagina PAB) per l'accesso.

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

File system locale

Dato un elenco (o un file ZIP) di artefatti in una directory, il fornitore di build imposta le immagini pertinenti in base al contenuto della directory. Puoi utilizzare lo strumento gsutil per copiare i file da Google Cloud Storage a una directory locale.

Eseguire il flashing delle build

Dopo aver scaricato le immagini del dispositivo più recenti sull'host, queste immagini devono essere eseguite sui dispositivi. Questa operazione viene eseguita utilizzando i comandi standard adb e fastboot e i sottoprocessi Python, in base ai percorsi dei file temporanei archiviati dai fornitori di build.

Azioni supportate:

• Eseguire il flashing solo di GSI
• Eseguire il flashing di singole immagini dal sistema principale (ad es. fastboot flash boot boot.img)
• Eseguire il flashing di tutte le immagini dal sistema principale. Esempio:
  • fastboot flashall (utilizzando l'utilità flashall integrata)
  • fastboot flash (una alla volta)

Eseguire test

In Android 9, l'infrastruttura di test automatici VTS supporta solo l'harness di test TradeFed, ma in futuro potrebbe essere estesa per supportare altri harness.

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

• Quando utilizzi TradeFed localmente, utilizza il comando test nel controller host, che accetta il nome di un piano di test VTS (ad es. vts-selftest) ed esegue il test.
• Quando utilizzi un cluster TradeFed (facoltativamente connesso a MTT), utilizza il lease comando nella console del controller host, che cerca le esecuzioni di test non completate.

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

Risultati report

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