Trade Federation (kurz Tradefed oder TF) ist ein Framework für kontinuierliche Tests, das für die Ausführung von Tests auf Android-Geräten entwickelt wurde. Beispielsweise wird Tradefed verwendet, um die Compatibility Test Suite (CTS) und die Vendor Test Suite (VTS) auszuführen.
Trade Federation ist eine Java-Anwendung, die auf einem Host-Computer läuft und mit einem oder mehreren Android-Geräten kommuniziert, indem sie ddmlib (die Bibliothek hinter DDMS) über adb verwendet.
Wir haben unten einige der Hauptfunktionen von TF zusammen mit einigen Beispielanwendungsfällen aufgelistet. Wenn Sie jedoch direkt loslegen und loslegen möchten, können Sie direkt zur Seite Start Here gehen.
Merkmale
- modulares, flexibles, skalierbares Design
- hat eine integrierte Unterstützung für die Ausführung vieler verschiedener Arten von Android-Tests: Instrumentation , uiautomator , native/gtest, hostbasiertes JUnit usw
- bietet zusätzlich zu adb Zuverlässigkeits- und Wiederherstellungsmechanismen
- unterstützt das Planen und Ausführen von Tests auf mehreren Geräten parallel
Unter Testen durch TF finden Sie die aktuellsten Informationen zum Ausführen Ihrer vorhandenen Tests, z. B. Instrumentation .
Anwendungsfälle
Die Modularität von Trade Federation macht es einfach, sich in Umgebungen mit bestehenden Build-, Test- und Reporting-Infrastrukturen einzufügen. 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 „Welche Teile sind modifizierbar und welche Teile statisch?“ zu betrachten. Beispielsweise kann ein Geräte-OEM das Framework, das System und die Hardware modifizieren, hat aber wenig oder keinen Einfluss auf bestehende Anwendungen. Ein Anwendungsentwickler hingegen kann die App modifizieren, hat aber wenig Kontrolle über die meisten Aspekte des Systems oder des Frameworks.
Infolgedessen hat eine Entität in jedem Anwendungsfall unterschiedliche Testziele und unterschiedliche Optionen im Falle einer Reihe von Testfehlern. Trotz dieser Unterschiede kann Trade Federation dazu beitragen, 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 laufen. Der OEM könnte bestrebt sein, diese Ziele zu erreichen, während er Stabilität und Leistung auf Hardware- und Systemebene beibehält und sicherstellt, dass die Framework-Änderungen die Kompatibilität mit bestehenden 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 seiner Ausführungszeit 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 in den Userspace-Modus zu booten. 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-Repositories einzubinden oder um Ergebnisse direkt (z. B. per E-Mail ) zu melden.
App-Entwickler
Ein Anwendungsentwickler erstellt eine App, die auf einer Vielzahl von Plattformversionen und einer Vielzahl von Geräten gut ausgeführt werden muss. Wenn ein Problem auf einer bestimmten Plattformversion und/oder einem bestimmten Gerät auftritt, besteht die einzige Abhilfe darin, eine Problemumgehung hinzuzufügen und fortzufahren. Bei größeren Entwicklern kann der Testprozess in eine kontinuierliche Build-Sequenz integriert werden. Bei kleineren Entwicklern kann es regelmäßig oder manuell 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 APKs installieren kann, die von einem Build-Service heruntergeladen wurden . 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.
Testservice
Ein Testdienst könnte es beispielsweise App-Entwicklern ermöglichen, Apps einzureichen und Tests auf Geräten durchzuführen, die mit Leistungsmess-Tools ausgestattet sind, um den Stromverbrauch für die App zu bestimmen. Dies unterscheidet sich von den beiden vorherigen Anwendungsfällen darin, dass der Service Builder nicht die Geräte oder die ausgeführten Anwendungen steuert.
Da Trade Federation jede Java-Klasse ausführen kann, die die einfache IRemoteTest -Schnittstelle implementiert, ist es trivial, Treiber zu schreiben, die eine externe Hardware mit dem auf dem Gerät ausgeführten Testfall koordinieren können. Der Treiber selbst kann Threads erstellen, Anforderungen 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.