Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Panoramica della Federazione commerciale

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 gira su un computer host e comunica con uno o più dispositivi Android usando ddmlib (la libreria dietro DDMS) su adb.

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

Caratteristiche

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

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

Casi d'uso

La modularità della Trade Federation rende semplice l'inserimento in ambienti con infrastrutture di compilazione, test e reporting esistenti. Elenchiamo di seguito alcuni esempi dimostrativi in ​​cui gli scambi potrebbero consentire pratiche di test efficienti e scalabili.

In primo luogo, è utile considerare il panorama di 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 scarso 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 disporrà di opzioni diverse nel caso di una serie di errori di test. Nonostante queste differenze, la Trade Federation può contribuire a rendere ciascuno dei loro processi di test efficienti, flessibili e scalabili.

Dispositivo OEM

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

L'OEM potrebbe implementare un modulo di lampeggiamento del dispositivo che verrà eseguito durante la fase di impostazione del target 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 per collegarsi a un sistema di generazione 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 Java.

Una volta avviato completamente il dispositivo, l'OEM sarà in grado di sfruttare i test basati su JUnit esistenti o di scriverne di nuovi per verificare la funzionalità di interesse. Infine, potrebbero scrivere uno o più moduli di report dei risultati per collegarli ai repository dei risultati dei test esistenti o per segnalare direttamente i risultati (ad esempio via 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 utilizza i moduli di installazione del 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 compilazione . È importante notare che quest'ultima versione continuerà a funzionare correttamente con arbitrariamente molte istanze TF in esecuzione sullo stesso computer 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 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 di energia dell'app. Ciò differisce dai due precedenti casi d'uso 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 un pezzo di hardware esterno con il case test che viene eseguito sul dispositivo. Il driver stesso può generare thread, inviare richieste ad altri server o fare qualsiasi altra cosa di cui possa aver bisogno. Inoltre, la semplicità e la versatilità dell'interfaccia di report dei risultati, ITestInvocationListener , significa che è altrettanto semplice rappresentare risultati di test arbitrari (inclusi, ad esempio, metriche di potenza numerica) nella pipeline di report dei risultati standard.