Google is committed to advancing racial equity for Black communities. See how.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Panoramica della Federazione dei Mercanti

Trade Federation (Tradefed o TF in breve) è un framework di test continuo progettato per l'esecuzione di test su dispositivi Android. Ad esempio, Tradefed viene utilizzato per eseguire Compatibility Test Suite (CTS) e Vendor Test Suite (VTS) .

Trade Federation è un'applicazione Java che viene eseguita su un computer host e comunica con uno o più dispositivi Android utilizzando ddmlib (la libreria dietro DDMS) su adb.

Abbiamo elencato alcune delle caratteristiche principali di TF di seguito, insieme a un paio di casi d'uso di esempio. Detto questo, se vuoi saltare subito e iniziare, puoi andare direttamente alla pagina Inizia qui .

Caratteristiche

  • design modulare, flessibile e scalabile
  • ha il supporto integrato per l'esecuzione di molti diversi tipi di test Android: strumentazione , uiautomator , native / gtest, JUnit basato su host, ecc.
  • fornisce affidabilità e meccanismi di ripristino in cima adb
  • supporta la pianificazione e l'esecuzione di test su più dispositivi in ​​parallelo

Vedere Testing Through TF per le informazioni più aggiornate su come eseguire i test esistenti, come la strumentazione .

Casi d'uso

La modularità di Trade Federation semplifica l'inserimento in ambienti con infrastrutture di build, test e reporting esistenti. Di seguito elenchiamo alcuni casi d'uso dimostrativi in ​​cui tradefed potrebbe consentire pratiche di test efficienti e scalabili.

In primo luogo, è utile considerare il panorama dei potenziali casi d'uso in termini di domanda "quali parti sono modificabili e quali sono statiche?" Ad esempio, un OEM di dispositivi può modificare il framework, il sistema e l'hardware, ma ha poca o nessuna influenza sulle applicazioni esistenti. Uno sviluppatore di applicazioni, d'altra parte, può modificare l'app, ma ha scarso controllo sulla maggior parte degli aspetti del sistema o del framework.

Di conseguenza, un'entità in ogni caso d'uso avrà obiettivi di test diversi e avrà opzioni diverse nel caso di una serie di errori di test. Nonostante queste differenze, Trade Federation può contribuire a rendere efficiente, flessibile e scalabile ciascuno dei loro processi di test.

OEM del dispositivo

Un OEM di dispositivi costruisce hardware e spesso modifica il sistema Android e i framework per funzionare bene su quell'hardware. L'OEM potrebbe sforzarsi di raggiungere questi obiettivi mantenendo stabilità e prestazioni a livello di hardware e sistema e assicurandosi che le modifiche al framework non interrompano la compatibilità con le applicazioni esistenti.

L'OEM potrebbe implementare un modulo di flashing del dispositivo che verrà eseguito durante la fase di configurazione della destinazione del ciclo di vita . Quel modulo avrebbe il controllo completo sul dispositivo durante il suo periodo di esecuzione, il che gli consentirebbe di forzare potenzialmente il dispositivo nel bootloader, eseguire il flash e quindi forzare il riavvio del dispositivo in modalità spazio utente. Combinato con un modulo da collegare a un sistema di build continuo, ciò consentirebbe all'OEM di eseguire test sul proprio dispositivo mentre apporta modifiche al firmware a livello di sistema e ai framework a livello di Java.

Una volta che il dispositivo è stato completamente avviato, l'OEM potrebbe sfruttare i test esistenti basati su JUnit o scriverne di nuovi per verificare la funzionalità di interesse. Infine, potrebbero scrivere uno o più moduli di reporting dei risultati da collegare a repository di risultati di test esistenti o per riportare i risultati direttamente (ad esempio, tramite e-mail ).

Sviluppatore di app

Uno sviluppatore di applicazioni crea un'app che deve funzionare bene su una varietà di versioni della piattaforma e una varietà di dispositivi. Se si verifica un problema su una particolare versione della piattaforma e / o dispositivo, l'unico rimedio è aggiungere una soluzione alternativa e andare avanti. Per sviluppatori più grandi, il processo di test potrebbe essere incorporato in una sequenza di build continua. Per gli sviluppatori più piccoli, potrebbe essere avviato periodicamente o manualmente.

La maggior parte degli sviluppatori di app utilizzerebbe i moduli di installazione di test apk già esistenti in TF. C'è una versione che si installa dal filesystem locale , così come una versione che può installare apk scaricati da un servizio di build . È importante notare che quest'ultima versione continuerà a funzionare correttamente con arbitrariamente molte istanze TF in esecuzione sulla stessa macchina host.

A causa della competenza di TF nel trattare con più dispositivi, sarebbe semplice classificare ogni risultato del test in base al tipo di dispositivo utilizzato per quel test. Pertanto, TF potrebbe potenzialmente generare una matrice di compatibilità bidimensionale (o multidimensionale) per ogni build dell'applicazione.

Servizio di collaudo

Un servizio di test potrebbe, ad esempio, consentire agli sviluppatori di app di inviare app ed eseguire test su dispositivi dotati di strumenti di misurazione della potenza per determinare l'utilizzo di energia per l'app. Ciò differisce dai due casi d'uso precedenti in quanto il generatore di servizi non controlla i dispositivi o le applicazioni in esecuzione.

Poiché Trade Federation può eseguire qualsiasi classe Java che implementa la semplice interfaccia IRemoteTest , è banale scrivere driver in grado di coordinare alcuni componenti hardware esterni con il test case in esecuzione sul dispositivo. Il driver stesso può generare thread, inviare richieste ad altri server o fare qualsiasi altra cosa di cui potrebbe aver bisogno. Inoltre, la semplicità e la versatilità dell'interfaccia di reporting dei risultati, ITestInvocationListener , significa che è altrettanto semplice rappresentare risultati di test arbitrari (inclusi, ad esempio, metriche di potenza numerica) nella pipeline di reporting dei risultati standard.