Infrastruttura di test automatizzata

Android 9 include un'infrastruttura VTS (Vendor Test Suite) per i test automatici 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 molto 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 automatico VTS utilizza la seguente architettura:

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

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

Il processo è coordinato dal controller host (HC) del VTS, un computer del laboratorio che dirige il comportamento di tutti i dispositivi connessi in test. L'HC è responsabile del recupero delle build più recenti, del loro aggiornamento sui dispositivi e dell'attivazione dei test (localmente o tramite il commander). Inoltre, comunica con un programmatore cloud e indirizza il traffico tra il programmatore e l'istanza TradeFed (o un altro harness) in esecuzione sull'HC. Per maggiori dettagli sul controller dell'host, consulta Architettura del controller dell'host.

Fornitori di risorse

I test automatici richiedono risorse come build di sistema, file di test e artefatti VTS. Sebbene sia possibile compilarli dal codice sorgente, è più facile compilarli regolarmente dalla punta dell'albero e poi pubblicare gli elementi per il download.

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

• Build Android partner. Accesso programmatico concesso su base per account.
• File system locale (o simile). Per i partner che non utilizzano la build Android per i partner.

Per l'utilizzo durante il flashing dei dispositivi in un secondo momento, le risorse includono i provider di build per entrambe le opzioni, che si estendono da un singolo build_provider.py che memorizza le build in directory temporanee locali.

Partner Android Build

Nelle release di 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 questa procedura lenta e laboriosa, Android 9 include il supporto per il download automatico di queste risorse dal 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 configurare una coppia ID client/secret con Google. Quando il PartnerAndroidBuildClient viene indirizzato al segreto per la prima volta, si 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 memorizzate 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 nella PAB, viene inviata una richiesta POST che include i dati necessari per la risorsa, tra cui:

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

Recuperare l'URL

Per evitare la contraffazione delle richieste cross-site, l'RPC buildsvc richiede che un token XSRF venga inviato tramite POST con gli altri parametri. Sebbene questo token renda la procedura più sicura, rende anche molto più difficile l'accesso programmatico, poiché ora il token (disponibile solo nel codice JavaScript della pagina PAB) è obbligatorio anche 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 elementi e agli URL degli elementi. Ora la PAB utilizza un pratico formato URL che consente ai partner di scaricare le risorse; gli script HC possono scaricare facilmente questi APK, poiché il formato dell'URL è noto e HC può aggirare i problemi XSRF/cookie perché non ha bisogno dell'RPC buildsvc.

File system locale

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

Build di Flash

Dopo aver scaricato le immagini del dispositivo più recenti sull'host, queste devono essere trasferite sui dispositivi. Questo viene eseguito utilizzando i comandi adb e fastboot standard e i sottoprocessi Python, in base ai percorsi dei file temporanei memorizzati dai provider di build.

Azioni supportate:

• Eseguire il flashing solo del GSI
• Lampeggiamento 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 (uno alla volta)

Esegui test

In Android 9, l'infrastruttura di test automatico VTS supporta solo il test harness 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 prende il nome di un piano di test VTS (ad es. vts-selftest) ed esegue il test.
• Quando utilizzi un cluster TradeFed (opzionalmente collegato a MTT), utilizza il comando lease 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 registrati automaticamente in alcuni progetti della dashboard VTS da VtsMultiDeviceTest.