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 partner che eseguono l'immagine di sistema generica (GSI) AOSP. In precedenza, l'esecuzione di questi test era un'operazione altamente manuale. La nuova infrastruttura di test VTS è progettata per supportare test automatici più volte al giorno su più dispositivi.

Architettura

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

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

1. Recupera gli artefatti di build e le risorse di test da diverse posizioni:
   • Partner Android Build (PAB). Per la GSI, il 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. Trasferisce gli artefatti di build (dal dispositivo) e la GSI (da AOSP) sui dispositivi connessi.
3. Esegue test VTS utilizzando TradeFed locale o TradeFed nel cloud.
4. Riporta i risultati del test alla dashboard VTS

Il processo è coordinato dal controller host (HC) di VTS, una macchina nel lab che dirige il comportamento di tutti i dispositivi connessi in fase di test. L'HC è responsabile del recupero delle build più recenti, del loro flashing sui dispositivi e dell'invocazione dei test (localmente o tramite il commander). 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 informazioni dettagliate 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 dall'origine, è più facile crearli regolarmente dalla punta dell'albero e poi pubblicare gli artefatti per il download.

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

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

Per l'utilizzo successivo nel flashing dei dispositivi, le risorse includono fornitori di build per entrambe le opzioni, a partire da un singolo build_provider.py che memorizza le 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 ultime immagini di sistema 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 alle RPC richieste. Utilizzando l'approccio standard per generare le credenziali OAuth2, il partner deve configurare una coppia ID client/secret con Google. Quando PartnerAndroidBuildClient punta a questo secret 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 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 quella risorsa, tra cui:

• ID build, target build
• nome risorsa
• branch
• 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 utilizzabile per accedere alla risorsa.

• Per le risorse APK di Clockwork Companion, l'URL è un URL leggibile ospitato su PAB (protetto da 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 attacchi di cross-site request forgery, la RPC buildsvc richiede l'invio di un token XSRF 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. Il 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ò bypassare i problemi XSRF/cookie perché non ha bisogno della RPC buildsvc.

File system locale

Dato un elenco (o un file zip) di artefatti, il fornitore 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 immagini devono essere caricate 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:

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

Esegui test

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

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 comando lease nella console del controller host, che cerca 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 del report

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