Trade Federation (kurz Tradefed oder TF) ist ein kontinuierliches Test-Framework, das für die Durchführung von Tests auf Android-Geräten entwickelt wurde. Beispielsweise wird Tradefed zum Ausführen der Compatibility Test Suite (CTS) und der Vendor Test Suite (VTS) verwendet.
Trade Federation ist eine Java-Anwendung, die auf einem Host-Computer ausgeführt wird und mithilfe von ddmlib (der Bibliothek hinter DDMS) über adb mit einem oder mehreren Android-Geräten kommuniziert.
Nachfolgend haben wir einige der Hauptfunktionen von TF zusammen mit einigen Beispielanwendungsfällen aufgelistet. Wenn Sie jedoch sofort einsteigen und loslegen möchten, können Sie direkt zur Seite „Hier starten“ gehen.
Merkmale
- modulares, flexibles, skalierbares Design
- verfügt über integrierte Unterstützung für die Ausführung vieler verschiedener Arten von Android-Tests: Instrumentierung , uiautomator , native/gtest, hostbasiertes JUnit usw
- Bietet Zuverlässigkeits- und Wiederherstellungsmechanismen zusätzlich zu ADB
- unterstützt das Planen und Ausführen von Tests auf mehreren Geräten parallel
Aktuelle Informationen zum Ausführen Ihrer vorhandenen Tests, z. B. Instrumentierung , finden Sie unter Testen über TF .
Anwendungsfälle
Die Modularität von Trade Federation erleichtert die Integration in Umgebungen mit vorhandenen Build-, Test- und Berichtsinfrastrukturen. Nachfolgend listen wir einige demonstrative Anwendungsfälle auf, in denen Tradefed effiziente, skalierbare Testpraktiken ermöglichen könnte.
Zunächst ist es sinnvoll, die Landschaft potenzieller Anwendungsfälle im Hinblick auf die Frage zu betrachten: „Welche Teile sind modifizierbar und welche statisch?“ Beispielsweise kann ein Geräte-OEM das Framework, das System und die Hardware ändern, hat aber kaum oder keinen Einfluss auf bestehende Anwendungen. Ein Anwendungsentwickler hingegen kann die App ändern, hat aber kaum Kontrolle über die meisten Aspekte des Systems oder des Frameworks.
Infolgedessen hat eine Entität in jedem Anwendungsfall unterschiedliche Testziele und verfügt im Falle einer Reihe von Testfehlern über unterschiedliche Optionen. Trotz dieser Unterschiede kann Trade Federation dabei helfen, jeden ihrer Testprozesse effizient, flexibel und skalierbar zu gestalten.
Geräte-OEM
Ein Geräte-OEM baut Hardware und optimiert häufig das Android-System und die Frameworks, damit sie auf dieser Hardware gut funktionieren. Der OEM könnte bestrebt sein, diese Ziele zu erreichen und gleichzeitig die Stabilität und Leistung auf Hardware- und Systemebene beizubehalten und sicherzustellen, dass die Framework-Änderungen die Kompatibilität mit vorhandenen Anwendungen nicht beeinträchtigen.
Der OEM könnte ein Geräte-Flashing-Modul implementieren, das während der Target-Setup-Phase des Lebenszyklus ausgeführt wird. Dieses Modul hätte während seines Ausführungszeitraums die vollständige Kontrolle über das Gerät, was es ihm ermöglichen würde, das Gerät möglicherweise in den Bootloader zu zwingen, zu flashen und dann das Gerät zu zwingen, wieder im Userspace-Modus neu zu starten. In Kombination mit einem Modul zur Einbindung in ein kontinuierliches Build-System würde dies es dem OEM ermöglichen, Tests auf seinem Gerät durchzuführen, während er Änderungen an der Firmware auf Systemebene und den Frameworks auf Java-Ebene vornimmt.
Sobald das Gerät vollständig hochgefahren ist, könnte der OEM vorhandene JUnit-basierte Tests nutzen oder neue schreiben, um die gewünschte Funktionalität zu überprüfen. Schließlich könnten sie ein oder mehrere Ergebnisberichtsmodule schreiben, um sie in bestehende Testergebnis-Repositorys einzubinden oder um Ergebnisse direkt zu melden (z. B. per E-Mail ).
App-Entwickler
Ein Anwendungsentwickler erstellt eine App, die auf verschiedenen Plattformversionen und auf verschiedenen Geräten gut laufen muss. Wenn auf einer bestimmten Plattformversion und/oder einem bestimmten Gerät ein Problem auftritt, besteht die einzige Lösung darin, einen Workaround hinzuzufügen und fortzufahren. Für größere Entwickler könnte der Testprozess in eine kontinuierliche Build-Sequenz integriert werden. Für kleinere Entwickler kann es in regelmäßigen Abständen oder von Hand gestartet werden.
Die meisten App-Entwickler würden die APK-Testinstallationsmodule verwenden, die bereits in TF vorhanden sind. Es gibt eine Version, die vom lokalen Dateisystem installiert wird , sowie eine Version, die von einem Build-Dienst heruntergeladene APKs installieren kann. Es ist wichtig zu beachten, dass die letztere Version weiterhin ordnungsgemäß funktioniert, wenn beliebig viele TF-Instanzen auf demselben Hostcomputer ausgeführt werden.
Aufgrund der Kompetenz von TF im Umgang mit mehreren Geräten wäre es einfach, jedes Testergebnis nach dem Gerätetyp zu klassifizieren, der für diesen Test verwendet wurde. Somit könnte TF möglicherweise eine zweidimensionale (oder mehrdimensionale) Kompatibilitätsmatrix für jeden Build der Anwendung generieren.
Prüfservice
Ein Testdienst könnte es App-Entwicklern beispielsweise ermöglichen, Apps einzureichen und Tests auf Geräten durchzuführen, die mit Leistungsmesstools ausgestattet sind, um den Stromverbrauch der App zu ermitteln. Dies unterscheidet sich von den beiden vorherigen Anwendungsfällen darin, dass der Service Builder nicht die Geräte oder Anwendungen steuert, die ausgeführt werden.
Da Trade Federation jede Java-Klasse ausführen kann, die die einfache IRemoteTest Schnittstelle implementiert, ist es einfach, Treiber zu schreiben, die externe Hardware mit dem Testfall koordinieren können, der auf dem Gerät ausgeführt wird. Der Treiber selbst kann Threads erzeugen, Anfragen an andere Server senden oder alles andere tun, was er möglicherweise benötigt. Darüber hinaus bedeutet die Einfachheit und Vielseitigkeit der Ergebnisberichtsschnittstelle ITestInvocationListener , dass es ebenfalls einfach ist, beliebige Testergebnisse (einschließlich beispielsweise numerischer Leistungsmetriken) in der Standard-Ergebnisberichtspipeline darzustellen.