TF-Testlebenszyklus

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

Definierte Schnittstellen

  • Build-Anbieter : Bietet einen Build zum Testen und lädt bei Bedarf die entsprechenden Dateien herunter.
  • Zielvorbereiter : Bereitet die Testumgebung vor, möglicherweise einschließlich Softwareinstallation und Gerätekonfiguration.
  • Test : Führt Tests aus und sammelt Testergebnisse. Dies kann ein beliebiger JUnit-Test sein, obwohl unsere IRemoteTest- Schnittstelle speziell für die Verwendung in der Trade Federation-Umgebung entwickelt wurde.
  • Test Invocation Listener (Ergebnisberichterstattung) : Hört auf Testergebnisse, normalerweise, um die Testergebnisse an ein Repository weiterzuleiten oder sie dem Test Runner anzuzeigen.

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

Diese Trennung des Testlebenszyklus soll eine Wiederverwendung ermöglichen. Mit diesem Design kann der Entwickler einen Test einmal erstellen, und dann kann der Integrator verschiedene Konfigurationen erstellen, um diesen Test in verschiedenen Umgebungen auszuführen. Beispielsweise könnten sie eine Konfiguration erstellen, die einen Test auf einem lokalen Computer ausführt und das Ergebnis an stdout ausgibt. 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. Möglicherweise wird eine dritte Konfiguration entworfen, die diesen Test kontinuierlich von einem Testlabor aus ausführt.

Hierbei ist zu beachten, dass eine Konfiguration zusammen mit ihren Befehlszeilenargumenten (wie vom Test Runner bereitgestellt) als Befehl bezeichnet wird . Wenn TF einen Befehl mit einem ITestDevice und ausführt, wird das nachfolgende Objekt als Aufruf bezeichnet . Kurz gesagt, ein Aufruf umfasst eine vollständige TF-Testausführung über den gesamten Lebenszyklus.

Zusätzliche Konfigurationskomponenten

Bühnenausgabe und Fehler

Jede Stufe eines Aufrufs wird nacheinander ausgeführt und hat ein bestimmtes Ziel. Dieser Abschnitt beschreibt die üblichen Ausgaben und Fehler jeder Stufe.

Anbieter erstellen

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

Der häufigste Fehler in dieser Phase ist ein Fehler beim Herunterladen oder Finden der angeforderten Dateien.

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

Zielvorbereitung

In dieser Phase werden die erforderlichen Zustände für das zu testende Ziel festgelegt. Diese Phase kann das Gerät oder das Host-Setup nach Bedarf für den angegebenen Testaufruf ändern.

Häufige Fehler in dieser Phase sind normalerweise das Versagen, das Gerät in einem bestimmten Zustand einzurichten (z. B. fehlgeschlagenes Flashen) und das Nichtfinden der für das Setup erforderlichen Dateien.

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 für das zuvor vorbereitete Ziel ausgeführt und alle Ergebnisse der Testausführung gemeldet.

Häufige Fehler in dieser Phase sind normalerweise, dass das zu testende Ziel nicht verfügbar ist oder dass ein Fehler die teilweise Ausführung der Tests verursacht. Diese Fehler sind Infrastrukturprobleme, die sich auf die Testausführung selbst auswirken, im Gegensatz zum Ausfall eines einzelnen Testfalls.

Ein Fehler in dieser Phase führt dazu, dass die Testausführung gestoppt wird, die Zielbereinigung ausgeführt wird, der Fehler gemeldet wird und Teilergebnisse abgerufen werden.

Ergebnisberichterstattung

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

Obwohl einzelne Ergebnisreporter Fehler aufweisen können, sind sie voneinander isoliert (ein Reporter sieht keine Fehler von einem anderen). Diese Fehler wirken sich nur auf die eigenen Ergebnisberichte eines einzelnen Reporters aus, und die Fehler können in den Protokollen angezeigt werden.