Trade Federation (abbreviato in Tradefed o TF) è un framework di test continuo progettato per eseguire test su dispositivi Android. Ad esempio, Tradefed viene utilizzato per eseguire la Compatibility Test Suite (CTS) e la 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 alla base di DDMS) tramite adb.
Di seguito abbiamo elencato alcune delle funzionalità principali di TF, insieme a un paio di casi d'uso di esempio. Detto questo, se vuoi iniziare subito, puoi andare direttamente alla pagina Inizia.
Funzionalità
- Design modulare, flessibile e scalabile
- supporta l'esecuzione di molti tipi diversi di test Android: strumentazione, uiautomator, native/gtest, JUnit basato sull'host e così via
- fornisce meccanismi di affidabilità e recupero su adb
- supporta la pianificazione ed esecuzione di test su più dispositivi in parallelo
Consulta Test tramite TF per informazioni aggiornate su come eseguire i test esistenti, ad esempio la strumentazione.
Casi d'uso
La modularità di Trade Federation consente di integrarlo facilmente in ambienti con infrastrutture di compilazione, test e generazione di report esistenti. Di seguito sono riportati alcuni use case dimostrativi in cui la funzionalità tradefed potrebbe consentire pratiche di test efficienti e scalabili.
Innanzitutto, è utile considerare il panorama dei potenziali casi d'uso in termini della domanda "Quali parti sono modificabili e quali sono statiche?" Ad esempio, un OEM del dispositivo può modificare il framework, il sistema e l'hardware, ma ha poca o nessuna influenza sulle applicazioni esistenti. Uno sviluppatore di applicazioni, invece, 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 opzioni diverse nel caso di una serie di errori di test. Nonostante queste differenze, Trade Federation può contribuire a rendere ogni processo di test efficiente, flessibile e scalabile.
OEM del dispositivo
Un OEM di dispositivi produce hardware e spesso modifica il sistema e i framework Android in modo che funzionino bene su quell'hardware. L'OEM potrebbe impegnarsi a raggiungere questi 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 aggiornamento del firmware del dispositivo che verrà eseguito durante la fase di configurazione del target del ciclo di vita. Questo modulo avrebbe il controllo completo sul dispositivo durante il periodo di esecuzione, il che gli consentirebbe di forzare il bootloader, eseguire il flashing e riavviare il dispositivo in modalità spazio utente. Se combinato con un modulo da collegare a un sistema di compilazione continua, questo consente all'OEM di eseguire test sul proprio dispositivo durante l'applicazione di modifiche al firmware a livello di sistema e ai framework a livello di Java.
Una volta avviato completamente il dispositivo, l'OEM potrà utilizzare i test basati su JUnit esistenti o scriverne di nuovi per verificare la funzionalità di interesse. Infine, potrebbe scrivere uno o più moduli di generazione di report sui risultati da collegare a repository di risultati dei test esistenti o per generare report direttamente sui risultati (ad esempio, via email).
Sviluppatore di app
Uno sviluppatore di applicazioni crea un'app che deve funzionare correttamente su varie versioni della piattaforma e su diversi dispositivi. Se si verifica un problema su una determinata versione della piattaforma e/o su un determinato 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 utilizza i moduli di installazione di test APK già esistenti in TF. Esiste una versione che si installa dal file system locale e una che può installare gli apk scaricati da un servizio di compilazione. È importante notare che la seconda versione continuerebbe a funzionare correttamente con un numero arbitrario di istanze TF in esecuzione sulla stessa macchina host.
Grazie alla competenza di TF nel gestire più dispositivi, sarebbe facile classificare ogni risultato del test in base al tipo di dispositivo utilizzato per il test. Pertanto, TF potrebbe potenzialmente generare una matrice di compatibilità 2D (o multi-dimensionale) per ogni compilazione 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 instrumentati con strumenti di misurazione della potenza per determinare il consumo di energia dell'app. Questo caso d'uso è diverso dai due precedenti in quanto il Service Builder non controlla i dispositivi o le applicazioni in esecuzione.
Poiché Trade Federation può eseguire qualsiasi classe Java che implementi l'interfaccia semplice
IRemoteTest, è
banale scrivere driver in grado di coordinare un componente hardware esterno con il test case
in esecuzione sul dispositivo. Il driver stesso può generare thread, inviare richieste ad altri
server o fare qualsiasi altra cosa possa essere necessaria. Inoltre, la semplicità e la versatilità dell'interfaccia di generazione di report sui risultati,
ITestInvocationListener, consentono di rappresentare facilmente risultati di test arbitrari (ad esempio le metriche di potenza numerica) nella
pipeline standard di generazione di report sui risultati.