TF-Testlebenszyklus

Der Lebenszyklus eines mit Trade Federation ausgeführten Tests besteht aus vier separaten Phasen, die auf formal definierten Schnittstellen basieren.

Definierte Schnittstellen

  • Build-Anbieter: Stellt einen Build zum Testen bereit und lädt bei Bedarf die entsprechenden Dateien herunter.
  • Target Preparer: Bereitet die Testumgebung vor, einschließlich Softwareinstallation und Gerätekonfiguration.
  • Test: Hier werden Tests ausgeführt und Testergebnisse erfasst. Dies kann jeder JUnit-Test sein, obwohl unsere IRemoteTest-Schnittstelle speziell für die Trade Federation-Umgebung entwickelt wurde.
  • Test Invocation Listener (Ergebnisberichte): Hört auf Testergebnisse, in der Regel um sie an ein Repository weiterzuleiten oder im Test Runner anzuzeigen.

Die grundlegende Testentität in TF ist eine Konfiguration (config). Eine Konfiguration ist eine XML-Datei, in der die Lebenszykluskomponenten eines Tests deklariert werden.

Diese Trennung des Testlebenszyklus soll eine Wiederverwendung ermöglichen. Mit diesem Design kann der Entwickler einen Test einmal erstellen und der Integrator dann verschiedene Konfigurationen erstellen, um diesen Test in verschiedenen Umgebungen auszuführen. So kann beispielsweise eine Konfiguration erstellt werden, mit der ein Test auf einem lokalen Computer ausgeführt und das Ergebnis in stdout ausgegeben wird. Sie könnten dann eine zweite Konfiguration erstellen, die denselben Test ausführt, aber einen anderen Testaufruf-Listener verwendet, um die Testergebnisse in einer Datenbank zu speichern. Eine dritte Konfiguration könnte so konzipiert sein, dass der Test kontinuierlich von einem Testlabor aus ausgeführt wird.

Eine Konfiguration zusammen mit den Befehlszeilenargumenten (wie vom Test Runner bereitgestellt) wird als Befehl bezeichnet. Wenn TF einen Befehl mit einem ITestDevice verknüpft und ausführt, wird das nachfolgende Objekt als Aufruf bezeichnet. Kurz gesagt umfasst eine Aufrufung die vollständige Ausführung eines TF-Tests über den gesamten Lebenszyklus hinweg.

Zusätzliche Konfigurationskomponenten

Ausgabe und Fehler der Phase

Jede Phase eines Aufrufs wird nacheinander ausgeführt und hat ein bestimmtes Ziel. In diesem Abschnitt werden die üblichen Ausgaben und Fehler der einzelnen Phasen beschrieben.

Anbieter erstellen

In dieser Phase wird ein IBuildInfo -Objekt erstellt und ausgegeben, das alle erforderlichen Dateiverweise zum Einrichten und Ausführen der Tests enthält.

Der häufigste Fehler in dieser Phase ist, dass die angeforderten Dateien nicht heruntergeladen oder gefunden werden können.

Ein Fehler in dieser Phase führt dazu, dass der Fehler direkt gemeldet und keine Tests ausgeführt werden.

Zielvorbereitung

In dieser Phase werden die erforderlichen Status für das Testziel eingerichtet. In dieser Phase kann die Geräte- oder Hostkonfiguration nach Bedarf für die jeweilige Testausführung geändert werden.

Häufige Fehler in dieser Phase sind in der Regel das Versagen der Einrichtung des Geräts in einem bestimmten Zustand (z. B. fehlgeschlagenes Flashen) und das Nichtfinden der erforderlichen Dateien für die Einrichtung.

Ein Fehler in dieser Phase führt dazu, dass die Zielbereinigung ausgeführt wird, der Fehler gemeldet wird und keine Tests ausgeführt werden.

Tests

In dieser Phase werden die angeforderten Tests auf dem zuvor vorbereiteten Ziel ausgeführt und alle Ergebnisse der Testausführung werden erfasst.

Häufige Fehler in dieser Phase sind in der Regel auf die Unverfügbarkeit des Testobjekts oder einen Fehler zurückzuführen, der zu einer teilweisen Ausführung der Tests führt. Diese Fehler sind Infrastrukturprobleme, die sich auf die Testausführung selbst auswirken, im Gegensatz zu einem Fehler bei einem einzelnen Testfall.

Ein Fehler in dieser Phase führt dazu, dass die Testausführung beendet wird, die Bereinigung des Ziels ausgeführt wird, der Fehler gemeldet wird und nur teilweise Ergebnisse zurückgegeben werden.

Ergebnisberichte

In dieser Phase werden die Ergebnisse und Fehler an die konfigurierten Dienste (z. B. Server und lokale Dateien) gemeldet.

Auch wenn einzelne Ergebnisberichte Fehler enthalten können, sind sie voneinander getrennt. Das bedeutet, dass ein Bericht Fehler eines anderen nicht enthält. Diese Fehler wirken sich nur auf die eigenen Ergebnisberichte eines einzelnen Nutzers aus und können in den Protokollen eingesehen werden.