Trade Federation (Tradefed o TF in breve) è 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 principali funzionalità 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 e scalabile
- ha il supporto integrato per l'esecuzione di diversi tipi di test Android: strumentazione , uiautomator , nativo/gtest, JUnit basato su host, ecc.
- fornisce meccanismi di affidabilità e ripristino su adb
- supporta la pianificazione e l'esecuzione di test su più dispositivi in parallelo
Consulta Testing tramite 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 abilitare pratiche di test efficienti e scalabili.
Innanzitutto, è 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 OEM di dispositivi può modificare la struttura, il sistema e l'hardware, ma ha poca o nessuna influenza sulle applicazioni esistenti. Uno sviluppatore di applicazioni, d'altro canto, può modificare l'app, ma ha poco controllo sulla maggior parte degli aspetti del sistema o del framework.
Di conseguenza, un'entità in ciascun caso d'uso avrà obiettivi di test diversi e avrà opzioni diverse nel caso di una serie di test falliti. Nonostante queste differenze, Trade Federation può contribuire a rendere ciascuno dei propri processi di test efficiente, flessibile e scalabile.
OEM del dispositivo
Un OEM di dispositivi crea hardware e spesso modifica il sistema e i framework Android 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 impostazione 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 flashing e quindi forzare il riavvio del dispositivo in modalità spazio utente. Combinato con un modulo da collegare a un sistema di creazione continua, ciò consentirebbe all'OEM di eseguire test sul proprio dispositivo mentre apportano modifiche al firmware a livello di sistema e ai framework a livello Java.
Una volta avviato completamente il dispositivo, l'OEM sarà in grado di sfruttare i test esistenti basati su JUnit o di scriverne di nuovi per verificare la funzionalità di interesse. Infine, potrebbero scrivere uno o più moduli di reporting dei risultati da collegare agli archivi esistenti dei risultati dei test o per riportare i risultati direttamente (ad esempio, tramite e-mail ).
Sviluppatore dell'app
Uno sviluppatore di applicazioni crea un'app che deve funzionare bene su una varietà di versioni della piattaforma e su 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 creazione 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. Esiste una versione che si installa dal filesystem locale , nonché 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 nel gestire più dispositivi, sarebbe semplice classificare ciascun 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 energetica per determinare il consumo energetico dell'app. Ciò differisce dai due casi d'uso precedenti in quanto il costruttore del servizio non controlla i dispositivi o le applicazioni in esecuzione.
Poiché Trade Federation può eseguire qualsiasi classe Java che implementi la semplice interfaccia IRemoteTest , è banale scrivere driver in grado di coordinare alcuni componenti hardware esterni con il test case eseguito 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, parametri di potenza numerica) nella pipeline di reporting dei risultati standard.