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:
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:
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:
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.
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.
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.
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.
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:
Ist der Testlauf beendet, sprich sind alle automatisierten Tests durchgelaufen, so meldet der MTM “Completed” als Zustand zurück:
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:
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:
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.
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:
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.Die 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:
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.
Weitere Informationen zu den automatisierten Tests können natürlich mit Hilfe von Berichten und Anpassungen abgefragt bzw. hinterlegt werden.
1 Kommentar