Trade Federation (Tradefed oder kurz TF) ist ein Framework für kontinuierliche Tests, das für die Ausführung von Tests auf Android-Geräten entwickelt wurde. Tradefed wird beispielsweise zum Ausführen der Compatibility Test Suite (CTS) und der Vendor Test Suite (VTS) verwendet.
Trade Federation ist eine Java-Anwendung, die auf einem Hostcomputer ausgeführt wird und über adb mit einem oder mehreren Android-Geräten über ddmlib (die Bibliothek hinter DDMS) kommuniziert.
Unten finden Sie einige der wichtigsten Funktionen von TF sowie einige Beispielanwendungen. Wenn Sie jedoch gleich loslegen möchten, können Sie direkt zur Seite Jetzt starten gehen.
Funktionen
- modulares, flexibles, skalierbares Design
- bietet eine integrierte Unterstützung für viele verschiedene Arten von Android-Tests: Instrumentierung, UI Automator, native/gtest, hostbasierte JUnit usw.
- bietet Zuverlässigkeits- und Wiederherstellungsmechanismen zusätzlich zu adb
- unterstützt die Planung und Ausführung von Tests auf mehreren Geräten parallel
Unter Testing Through TF finden Sie aktuelle Informationen zum Ausführen vorhandener Tests, z. B. Instrumentierung.
Anwendungsfälle
Die Modularität von Trade Federation ermöglicht eine einfache Einbindung in Umgebungen mit vorhandenen Build-, Test- und Berichtsinfrastrukturen. Unten finden Sie einige Anwendungsfälle, in denen Tradefed effiziente, skalierbare Testmethoden ermöglichen könnte.
Zuerst ist es hilfreich, die Landschaft der potenziellen Anwendungsfälle im Hinblick auf die Frage zu betrachten: „Welche Teile sind anpassbar und welche Teile sind statisch?“ Ein Gerätehersteller kann beispielsweise das Framework, das System und die Hardware ändern, hat aber wenig oder keinen Einfluss auf vorhandene Anwendungen. Ein App-Entwickler kann die App hingegen ändern, hat aber nur wenig Kontrolle über die meisten Aspekte des Systems oder des Frameworks.
Daher hat eine Entität in jedem Anwendungsfall unterschiedliche Testziele und unterschiedliche Optionen im Falle mehrerer Testfehler. Trotz dieser Unterschiede kann Trade Federation dabei helfen, jeden Testprozess effizient, flexibel und skalierbar zu gestalten.
OEM des Geräts
Ein Geräte-OEM stellt Hardware her und passt das Android-System und die Frameworks häufig so an, dass sie auf dieser Hardware gut funktionieren. Der OEM möchte diese Ziele erreichen und gleichzeitig Stabilität und Leistung auf Hardware- und Systemebene beibehalten sowie dafür sorgen, dass die Framework-Änderungen die Kompatibilität mit vorhandenen Anwendungen nicht beeinträchtigen.
Der OEM kann ein Modul zum Flashen von Geräten implementieren, das während der Phase der Zieleinrichtung des Lebenszyklus ausgeführt wird. Dieses Modul hätte während der Ausführungsdauer die vollständige Kontrolle über das Gerät. So könnte es das Gerät möglicherweise zum Bootloader zwingen, das Flash-Laufwerk auslesen und dann den Neustart des Geräts in den Userspace-Modus erzwingen. In Kombination mit einem Modul, das in ein kontinuierliches Build-System eingebunden ist, können OEMs Tests auf ihrem Gerät ausführen, während sie Änderungen an der Firmware auf Systemebene und an den Frameworks auf Java-Ebene vornehmen.
Sobald das Gerät vollständig gestartet ist, kann der OEM vorhandene JUnit-basierte Tests nutzen oder neue schreiben, um die gewünschte Funktion zu überprüfen. Schließlich können sie ein oder mehrere Ergebnisberichtsmodule schreiben, die in vorhandene Testergebnis-Repositories eingebunden werden oder Ergebnisse direkt melden (z. B. per E-Mail).
App-Entwickler
Ein App-Entwickler erstellt eine App, die auf einer Vielzahl von Plattformversionen und auf einer Vielzahl von Geräten einwandfrei funktionieren muss. Wenn ein Problem bei einer bestimmten Plattformversion und/oder einem bestimmten Gerät auftritt, bleibt nur die Möglichkeit, eine Problemumgehung hinzuzufügen und weiterzumachen. Bei größeren Entwicklerteams kann der Testprozess in eine kontinuierliche Build-Sequenz eingebunden werden. Bei kleineren Entwicklern wird die Prüfung möglicherweise regelmäßig oder manuell gestartet.
Die meisten App-Entwickler verwenden die in TF bereits vorhandenen APK-Testinstallationsmodule. Es gibt eine Version, die über das lokale Dateisystem installiert wird, sowie eine Version, mit der über einen Build-Dienst heruntergeladene APKs installiert werden können. Die letzte Version funktioniert auch dann ordnungsgemäß, wenn beliebig viele TF-Instanzen auf demselben Hostcomputer ausgeführt werden.
Da TF mit mehreren Geräten umgehen kann, wäre es einfach, jedes Testergebnis nach dem Typ des Geräts zu klassifizieren, das für diesen Test verwendet wurde. So kann TF potenziell eine zweidimensionale (oder mehrdimensionale) Kompatibilitätsmatrix für jeden Build der Anwendung generieren.
Testdienst
Mit einem Testdienst können App-Entwickler beispielsweise Apps einreichen und Tests auf Geräten ausführen, die mit Energiemesstools ausgestattet sind, um den Energieverbrauch der App zu ermitteln. Dieser Anwendungsfall unterscheidet sich von den beiden vorherigen Anwendungsfällen dadurch, dass der Dienstanbieter weder die Geräte noch die ausgeführten Anwendungen steuert.
Da Trade Federation jede Java-Klasse ausführen kann, die die einfache IRemoteTest-Schnittstelle implementiert, ist es ganz einfach, Treiber zu schreiben, die eine externe Hardware mit dem Testfall koordinieren können, der auf dem Gerät ausgeführt wird. Der Treiber selbst kann Threads erstellen, Anfragen an andere Server senden oder andere Aktionen ausführen. Außerdem ist es dank der einfachen und vielseitigen Benutzeroberfläche für die Ergebnisberichte (ITestInvocationListener) ganz einfach, beliebige Testergebnisse (z. B. numerische Leistungsmesswerte) in der Standardpipeline für Ergebnisberichte darzustellen.