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:

Architettura di test automatico

Figura 1. Architettura dell'infrastruttura di test automatico VTS

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 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 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 per singolo account.
  • File system locale (o simile). Per i partner che non utilizzano la build Android per i partner.

Per essere utilizzate in seguito per il flashing dei dispositivi, le risorse includono provider di build per entrambe le opzioni, che si estendono da un singolo build_provider.py che archivia 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.

Stabilisci accesso

L'accesso programmatico utilizza OAuth2 sulle API di Google per accedere alle RPC richieste. Utilizzando l'approccio standard per generare le 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) sono 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 nella PAB, viene inviata una richiesta POST che include i dati necessari per la risorsa, tra cui:

  • ID build, target build
  • 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).

Recupera l'URL

Per evitare la falsificazione delle richieste tra siti, l'RPC buildsvc richiede il POST di un token XSRF con gli altri parametri. Sebbene questo token renda il processo più sicuro, rende anche molto più difficile l'accesso programmatico poiché ora è necessario anche il token (che è disponibile solo nel 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 l'accesso agli elenchi di elementi e agli URL degli elementi. Il PAB ora utilizza un formato di URL pratico che consente ai partner di scaricare le risorse. Gli script del Centro assistenza possono scaricare facilmente questi APK, poiché il formato dell'URL è noto, e il Centro assistenza può bypassare i problemi XSRF/cookie perché non richiede l'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 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 cablaggio di test TradeFed, ma in futuro potrebbe essere estesa per supportare altri cablaggi.

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.