Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Sven Hubert

Sven Hubert

Traceability zwischen Unit Tests und Test Cases

Samstag, 28. Mai 2011

In Visual Studio Team Foundation Server 2010 lassen sich Testfälle mit automatisierten Tests in Form von Coded-UI- oder Unit-Tests verknüpfen. Zu dieser Funktionalität erreichen uns immer wieder Fragen, die wir hier gerne beantworten:

  • Wie funktioniert diese Verlinkung und welche Möglichkeiten bietet sie?
  • Kann man automatisierte Tests planen und über das Microsoft Test Manager (kurz: MTM) anstoßen?
  • Welche Zustandsinformation des automatisierten Tests ist in den Work Items sichtbar?

Wie erzeugt man eine Verknüpfung zwischen Testfall und automatisiertem Test?

Im Test Case Work Item ist ein spezieller Bereich für die Verknüpfung mit automatisierten Testsdefiniert. Dieser besteht aus dem Automation Status und demAssociated Automation Tab:

SNAGHTMLff0800

Im Visual Studio muss eine Solution geöffnet werden, die z.B. Unit-Tests enthält. Ist dies der Fall, kann man den Test Case über Klick auf “…” im Associated Automation Tab mit einem Unit-Test der Solution verknüpfen. Es erscheint eine Auswahlbox, welche alle verfügbaren Tests der Solution auflistet:

SNAGHTMLfcdb27

Wählt man einen Test aus und klickt Ok, so wird der Automation Status des Work Items auf Automated (1) und im Tab Associated Automation (2) entsprechend der Name des Tests, die Asssembly, die den Test enthält sowie dessen Typ gesetzt (3). Die Assoziation mit dem Test lässt sich mit dem Button “Remove association” wieder aufheben:

SNAGHTMLf8d369

Was wird nun aber im Testfall hinterlegt? Tatsächlich wird keine DLL angehängt. Die Testdaten im Testfall-Work Item dienen im Build-Prozess dem Auffinden der richtigen Tests. Die angegebene DLL muss also im Test-Deployment-Verzeichnis auf dem Build bzw. Test Agent vorhanden sein, damit sich der Testfall automatisiert ausführen lässt.

Man kann auch auf Basis eines bestehenden Unit-Tests einen Testfall aus Visual Studio 2010 oder gar der Kommandozeile heraus anlegen. Dies zeigt der Artikel Verknüpfen von automatisierten Tests mit Testfällen im Detail.

Wie startet man den automatisierten Test auf Basis des Testfalls?

Mit dem Microsoft Test Manager

Doch wie verwendet man nun den Testfall zur tatsächlichen Ausführung? Zum einen lässt sich der Testfall direkt aus dem Microsoft Test Manager heraus starten. Dazu ist zunächst einmal eine Testumgebung (physikalisch oder virtuell) nötig. Auf einer solchen Umgebung muss zumindest der Test Agent installiert und an einer Team Project Collection angemeldet werden.

SNAGHTML10faca8

Als weitere Voraussetzung muss die Umgebung in den Test Run Settings des Testplans (im MTM –> Plan –> Properties) selektiert werden. Über Manage lassen sich hier weitere Filter und Einstellungen setzen.

SNAGHTML7dd1d1

In der Test-Ansicht des Test Managers können dann ein oder mehrere Testfälle ausgewählt werden. Ist der Automation Status auf “Automated”, so sind nach Aufruf von “Run with options” die Einstellungen für den automatischen Testlauf auswählbar. Im unteren Beispiel sogar direkt vorausgewählt.

SNAGHTML110a3b3

image

Nach dem Starten des Testlaufs wird dieser im MTM mit aktuellen Zustandsinformationen dargestellt. Der Zustand im Titel der “Summary” ist hierbei zunächst “Waiting for Test Controller”. Die auszuführenden Tests sind unter “Tests” mit jeweiligem Ausführungszustand aufgeführt.

image

Der Test läuft nun auf dem Test Agent. Ist dieser als interaktiver Prozess (im Gegensatz zur Option “Run as Windows Service”) gestartet, kann man auf der Testmaschine die Ausführung der Tests mitverfolgen:

image

Ist der Testlauf beendet, sprich sind alle automatisierten Tests durchgelaufen, so meldet der MTM “Completed” als Zustand zurück:

image

Die verwendeten Assemblies sowie die aufgezeichneten Informationen (Videos, Logs, Systeminfo) werden als Attachment zum Testlauf in der Datenbank des TFS abgelegt.

Hinweis: Die Datenbank des TFS füllt sich demenstprechend schnell. Wie dem begegnet werden kann, findet sich in TFS-Blog: Löschen von Test-(Diagnose-)Daten aus dem TFS 2010.

Im Build-Prozess

Die zweite Möglichkeit, automatisierte Tests auszuführen ist es, diese in den Team Foundation Build zu integrieren. Das geht natürlich wie gewohnt direkt über die in der Visual Studio Solution enthaltenen Unit-Tests. Aber auch die Testfälle mit Automation Status “Automated” können im Build verwendet werden. Das ist dann sinnvoll, wenn die Zusammenstellung und Auswertung der auszuführenden Tests zentral über den Testplan erfolgen soll und ein Mix aus automatisierten und manuellen Tests existiert – wie das z.B. bei Systemtests der Fall ist. Für die Integration der automatisierten Testfälle muss ein virtuelles Test-Lab aufgesetzt werden. Im Anschluss kann dann über ein spezielles Build Process Template – das LabDefaultTemplate.xaml – die Ausführung auf Basis ausgewählter Test-Suiten eingerichtet werden:

SNAGHTMLa33d22

Wie im obigen Bild erkennbar, ist dies nur der letzte Schritt im Assistenten zur Einrichtung des Lab-Builds. Vorher werden noch Einstellungen zur Auswahl der Testumgebung, dem eigentlichen Build-Prozess, der die zu testenden Assemblies zur Verfügung stellt, dem Wiederherstellen von Snapshots und zum Deployment der Testumgebung getroffen.

Ergebnis dieser Testdurchführung im Build ist dann wiederum ein Testlauf, der im Microsoft Test Manager ausgewertet werden kann:

SNAGHTMLab34a9

Welche Zustandsinformation des automatisierten Tests ist in den Work Items sichtbar?

Der Testfall wird zunächst einmal wie ein ganz normales Work Item behandelt. Somit hat dieser eine Zustandsmaschine, die den Workflow zum Testfall begleitet und beschreibt, in welchem Zustand oder welcher “Phase” sich der Testfall befindet. Die Standardzustandsmaschine des Testfalls besitzt die Zustände “Design” – Testfall wird inhaltlich definiert und sollte noch nicht zum Testen verwendet werden, “Ready” – Testfall kann zum Testen verwendet werden und “Closed” – Testfall ist abgeschlossen und wird nicht mehr zum Testen herangezogen. Ein Review-Zustand fehlt und muss nachträglich eingebaut werden. Die folgende Abbildung zeigt den Standard-Workflow und den angepassten Zustandsautomaten mit eingebautem Review-Zustand.

image

image

Standard-Workflow des Test Case Work Items

Angepasster Review-Workflow

Doch diese Zustände beziehen sich nur auf den Testfall, dieser hat aber noch nicht direkt mit dem Testergebnis zu tun. Um die Zusammenhänge zu verstehen, muss man sich die Beziehungen zwischen den Testartefakten vor Augen halten. Die folgende Darstellung zeigt ein vereinfachtes Modell dieser Zusammenhänge:

image

Der Testfall bzw. das Test Case Work Item bildet zusammen mit der Testkonfiguration (beschreibt grob die Testumgebung z.B. IE6, Win7, English oder Firefox4, WinXP, German) und der Test Suite in der der Testfall verwendet wird den sogenannten Testpunkt (engl. Test Point). Erst dieser kennt das Testergebnis. Ein Testfall kennt indirekt (nur über die Test-Results-View) allerdings auch die  gesamte Testergebnishistorie, die alle Ergebnisse in allen Testpunkten des Testfalls enthält.SNAGHTML8044c55Die Ergebnisse enthalten zudem Anhänge, wie zum Beispiel die Daten der Diagnoseadapter (Video, Test Impact, IntelliTrace usw.). Unter den Anhängen ist bei den automatisierten Tests auch eine .trx-Datei zu finden:

SNAGHTML81315db

Diese Datei kann via Doppelklick im Visual Studio geöffnet werden. Hier lässt sich nachvollziehen, welche Unit-Tests gelaufen sind. Ein Zugriff auf den Code des Unit Tests ist aber nur über den Build und das Build-Label eindeutig möglich und zugegebenermaßen nicht einfach zu navigieren – aber auffindbar.

SNAGHTML8115431

Weitere Informationen zu den automatisierten Tests können natürlich mit Hilfe von Berichten und Anpassungen abgefragt bzw. hinterlegt werden.

Verwandte Artikel:

Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

Tags: , ,

Eine Antwort zu “Traceability zwischen Unit Tests und Test Cases”

  1. QuickLinks for May 2011 | (Agile) Testing sagt:

    […] Traceability zwischen Unit Tests und Test Cases […]

Hinterlasse eine Antwort