Trade Federation (in breve Tradefed o TF) è un framework di test continuo progettato per eseguire 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.
Di seguito abbiamo elencato alcune delle caratteristiche principali di TF, insieme a un paio di casi d'uso di esempio. Detto questo, se vuoi entrare subito e iniziare, puoi andare direttamente alla pagina Inizia qui .
Caratteristiche
- design modulare, flessibile, scalabile
- ha il supporto integrato per l'esecuzione di diversi tipi di test Android: strumentazione , uiautomator , native/gtest, JUnit basato su host, ecc.
- fornisce affidabilità e meccanismi di ripristino su adb
- supporta la pianificazione e l'esecuzione di test su più dispositivi in parallelo
Consulta Testing Through TF per le informazioni più aggiornate su come eseguire i test esistenti, ad esempio Strumentazione .
Casi d'uso
La modularità di Trade Federation semplifica l'inserimento in ambienti con infrastrutture di creazione, test e reporting esistenti. Elenchiamo di seguito 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 parti sono statiche?" Ad esempio, un Device OEM 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 poco 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 ciascuno dei propri processi di test efficiente, flessibile e scalabile.
Dispositivo OEM
Un OEM di dispositivi costruisce hardware e spesso modificherà il sistema e i framework Android per funzionare bene su quell'hardware. L'OEM potrebbe sforzarsi di raggiungere tali obiettivi mantenendo la stabilità e le 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 del target del ciclo di vita. Quel modulo avrebbe il controllo completo sul dispositivo durante il suo periodo di esecuzione, il che gli consentirebbe potenzialmente di forzare il dispositivo nel bootloader, eseguire il flashing 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 apportano modifiche al firmware a livello di sistema e ai framework a livello di Java.
Una volta che il dispositivo è completamente avviato, l'OEM potrebbe sfruttare i test basati su JUnit esistenti, o scriverne di nuovi, per verificare la funzionalità di interesse. Infine, potrebbero scrivere uno o più moduli di reporting dei risultati da collegare ai repository dei risultati dei test esistenti o per segnalare 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 gli 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 utilizzerà i moduli di installazione di prova 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 un numero arbitrario di istanze TF in esecuzione sulla stessa macchina host.
Data la competenza di TF nell'affrontare 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 test
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 il consumo energetico dell'app. Ciò differisce dai due casi d'uso precedenti in quanto il service builder 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.