Whitepaper Team Foundation Server 2010 Lab Management

AIT GmbH & Co. KG – TeamSystemPro Team
www.aitgmbh.de/teamsystempro | info@aitgmbh.de
Whitepaper: Visual Studio Lab Management | Seite 1 of 24
Whitepaper: Visual Studio Lab
Management
Dieses Whitepaper gibt einen Einblick in die Möglichkeiten zur Verwendung des Test Lab
Managements mit Microsoft Visual Studio Team Foundation Server 2010 und Microsoft Test
Professional 2010.
Der Team Foundation Server (kurz TFS) und Visual Studio adressieren eine Menge von
Anwendungsfällen während der Softwareentwicklung und Qualitätssicherung. Beide beinhalten
bereits seit den Versionen 2005 und 2008 die Bestandteile Versionskontrolle, Arbeitsplanung (Work
Item Tracking), Reporting und Build-Management. Die große Stärke der Systeme liegt in der hohen
Integrationstiefe der unterschiedlichen Prozessbereiche, sodass eine durchgängige
Informationskette entsteht. Im Fokus der Versionen 2005 und 2008 standen zunächst primär Project
Manager und Entwickler sowie die entwicklernahe Qualitätssicherung. Mit TFS 2010 und Test
Professional 2010 werden erstmalig Testmanager und fachliche Tester adressiert.
Zielgruppe für dieses Whitepaper sind Release-Manager, Entwickler, Tester und Verantwortliche
für Qualitätssicherung in Softwareprojekten. Im Fokus stehen der Aufbau eines Test Labs,
Virtualisierung von Testumgebungen, die Sicherstellung der Skalierbarkeit für große Testlabore, die
Integration mit der Fehlerverfolgung und der Praxiseinsatz mit Microsoft Visual Studio 2010.
Stand: Juni 2013
Nico Orschel
www.aitgmbh.de/tfs
In Zusammenarbeit mit Microsoft
www.microsoft.de/visualstudio

Inhalte
Was ist Lab Management?......................................................................................................................3
Lab Management Infrastruktur...............................................................................................................4
Lizenzierung von Lab Management ........................................................................................................5
Visual Studio Lab Management Fähigkeiten...........................................................................................6
Workflow.............................................................................................................................................7
Testen und Testautomatisierung........................................................................................................7
Network Isolation................................................................................................................................9
Management von Testumgebungen.....................................................................................................10
Integration in Build- und Deployment-Prozesse...................................................................................13
Anwendung von Lab Management beim Testen..................................................................................15
Automatisches Testen.......................................................................................................................15
Manuelles Testen..............................................................................................................................18
Zusammenfassung ................................................................................................................................20
FAQ........................................................................................................................................................21
Quellen..................................................................................................................................................22
Abbildungsverzeichnis ..........................................................................................................................23
Dieses Whitepaper wurde erstellt von .................................................................................................24

Was ist Lab Management?
Der Team Foundation Server (TFS) adressiert eine Menge von Anwendungsfällen während der
Softwareentwicklung und Qualitätssicherung. Der TFS unterstützte bereits seit den ersten Versionen
2005 und 2008 die Bestandteile Versionskontrolle, Arbeitsplanung (Work Item Tracking), Reporting
und Build-Management. Die große Stärke des TFS liegt in der hohen Integrationstiefe der
unterschiedlichen Projektbereiche, sodass eine durchgängige Informationskette entsteht. Im Fokus
der TFS-Versionen 2005 und 2008 standen zunächst primär die Rollen Project Manager und
Entwickler.
Mit der Veröffentlichung des TFS 2010 wurde das Anwendungsfeld um die Prozesse des Test
Management erweitert. Der TFS unterschützt jetzt auch den Test Manager und Tester mit
Funktionalitäten rund um Testprozesse. Im Rahmen des Whitepapers liegt der Fokus auf den
Testprozessphasen „Testdurchführung“ und „Bereitstellung von Testumgebungen“.
Betrachtet man die Testdurchführung aus der Vogelperspektive, so fällt schnell auf, dass eine
schnelle Testdurchführung stark abhängig ist von einer agilen und regelmäßigen Bereitstellung von
aktuellen Testumgebungen. Testumgebungen können im einfachsten Fall aus nur einem Client-
Betriebssystem bestehen, aber es ist auch möglich, dass sehr schnell komplexe Strukturen aus
mehreren Servern und Client-Betriebssysteme entstehen.
Abbildung 1 –Typische Testumgebungen im Projektalltag
In Softwareentwicklungsprojekten finden sich sehr oft neben dem Tester noch weitere
Projektmitglieder, welche ihrerseits in aller Regel eigene Testumgebungen aufsetzen und betreiben.
Visualisiert man dieses typische Szenario, so entsteht auch hier bei einem einfachen Projekt schnell
die Szenerie aus Abbildung 1. Jede „Projektrolle“ (Qualitätssicherung (QA), Entwickler (Dev),
Benutzerakzeptanztest (UAT)) hat in diesem Szenario mindestens eine eigene Testumgebung,
bestehend aus Datenbank (DB) und Webserver (Web), installiert. Als Ergebnis sind mindestens vier
verschiedene Testumgebungen für unterschiedlichste Zwecke entstanden. Eine Folge der vielen
Testumgebungen ist es, dass aufgrund von Wartungs- und Installationsintervallen viel Zeit benötigt
wird und dadurch hohe Kosten entstehen können.

Um die angesprochenen Punkte zu adressieren, hat Microsoft in den TFS 2010 und in Test
Professional 2010 Funktionalitäten zur Verwaltung von Testumgebungen integriert.
Zusammengefasst kann das Lab Management alle Projektbeteiligte bei folgendenden Punkten
unterstützen:
- Anlegen und Verwalten von virtuellen und physischen Testumgebungen,
- Auslieferung von Build-Ergebnissen in Testumgebungen,
- Ausführung von Tests in definierten Testumgebungen mit den Zielen
o Verifizierung der Build-Qualität
o Regressionstest
o Fehlerfindung und schnelleres Debugging unter Berücksichtigung von
umfangreichen Diagnosedaten
Alle zuvor genannten Funktionen werden unter dem Sammelbegriff
„Visual Studio Lab Management“ zusammengefasst. Das wesentliche Ziel vom Visual Studio Lab
Management ist die Steigerung der Team Produktivität beim Betrieb und Management von Test-
und Entwicklungsumgebungen, sowie die Unterstützung der Entwickler und Tester beim manuellen
und automatischen Testen mit Testumgebungen.
Lab Management Infrastruktur
Beim TFS Lab Management wird zwischen zwei Umgebungstypen unterschieden: physische und
virtuelle Testumgebungen.
Als ersten Umgebungstyp betrachten wir die virtuellen Testumgebungen. Generell wird zur
Verwaltung von virtuellen Testumgebungen der TFS 2010 und der „System Center Virtual Maschine
Manager 2008 R2 (SCVMM)“ benötigt. Der SCVMM ist für die Lab Management Nutzung bereits
über Visual Studio 2010 Ultimate und Visual Studio 2010 Test Professional lizenziert, sodass Ihnen
hier keine zusätzlichen Kosten entstehen. Die verschiedenen SCVMM-Komponenten werden
typischerweise auf verschiedene Maschinen betrieben. Damit der TFS in der Lage ist, alle Host-
Systeme „fernzusteuern“, wird auf dem TFS-Server die SCVMM Administration Console benötigt. Als
zentraler Managementschnittstelle für die komplette VM-Infrastruktur dient ein SCVMM-Server. Die
virtuellen Maschinen werden beim Lab Management über Microsoft Hyper-V virtualisiert. An einen
SCVMM-Server lassen sich bei Bedarf mehre Hyper-V Hosts anbinden. Durch die Anbindung von
mehreren Hyper-V Hosts kann die Infrastruktur im laufenden Betrieb flexibel erweitert werden. Alle
Host-Systeme können auf gemeinsame Ressourcen (Bsp.: VM-Images, Software, Testumgebungen)
über SCVMM Library Share(s) zugreifen. Eine SCVMM Library Share ist technisch gesehen eine
Windows Freigabe.
Neben dem SCVMM kommt serverseitig noch mindestens ein Test Controller und ein Build
Controller1
zum Einsatz. Der Testcontroller hat die Aufgabe Test Agents in den Testumgebungen
fernzusteuern und der Build Controller steuert entsprechend die Build Agents2
fern.
1
Siehe [1,2]
2
Siehe [3]

Auch innerhalb der virtuellen Testmaschinen wird ein Minimum an Software benötigt. Im Fall von
virtuellen Testumgebungen wird in den virtuellen Maschinen ein Build Agent, ein Test Agent und ein
Lab Agent installiert. Die einzelnen Funktionsbereiche der Agents werden in einem Folgekapitel
genauer besprochen. Einen Überblick über die gesamte Infrastruktur zeigt Abbildung 2.
Abbildung 2 - Architektur - Lab + Build + Test
Als zweiten Umgebungstyp betrachten wir jetzt die physische Testumgebung. Bei physischen
Testumgebungen kommen im Unterschied zu virtuellen Testumgebungen zur Verwaltung nur die
Test-Controller, Build Controller, Build Agent und Test Agent zum Einsatz. Der Einsatz von SCVMM
und Lab Agent entfällt in diesem Szenario. Die Details zu den Hintergründen finden Sie im Kapitel Lab
Management Fähigkeiten.
Lizenzierung von Lab Management
Die Visual Studio Lab Management Funktionalität können lizensierte Benutzer von Visual Studio
2010 Test Professional oder Visual Studio 2010 Ultimate Lizenzen nutzen. Der im Kapitel Lab
Management Infrastruktur angesprochende für virtuelle Testumgeungen notwendige SCVMM ist für
den Einsatzzweck Lab Management bereits über die zuvor angesprochenden Visual Studio Editionen
lizenziert.
Das Produkt Visual Studio 2010 Test Professional setzt sich aus den Bestandteilen Microsoft Test
Manager 2010 (MTM) und Agents, (genauer Test Agent und Lab Agent), zusammen. Test- und Lab
Agents werden auf einer Benutzerbasis im Rahmen des Test Professional Pakets lizenziert, d. h., Sie
können beliebig viele Testumgebungen pro lizenzierten Benutzer nutzen.
Alle Nutzer von Visual Studio 2010 Ultimate benötigen keine extra Test Professional Lizenz, da
Microsoft Test Professional Paket bereits Bestandteil der Visual Studio Ultimate Edition ist.
Details zu den verschiedenen Lizenzierungsszenarien von der Visual Studio 2010 Familie finden Sie
im Lizenz-Whitepaper3
.
3
Siehe [4]

Visual Studio Lab Management Fähigkeiten
Das Visual Studio Lab Management System unterstützt aktuell drei Funktionen innerhalb von
Testumgebungen:
1. Run Workflows
2. Run Tests
3. Execute Network Isolation.
Die genannten Funktionen werden über den Microsoft Test Manager 2010 (MTM) in der Lab Center
Perspektive für jede Testumgebungen konfiguriert. Ein Beispiel für die Konfiguration einzelner
Parameter zu Testumgebungen zeigt Abbildung 3.
Abbildung 3 – Konfiguration von Lab Management Eigenschaften
Die Funktionen können in Abhängigkeit vom Typ der Testumgebung variieren. Alle Funktionen
werden bei virtuellen Testumgebungen unterstützt. Network Isolation wird bei physischen
Testumgebungen nicht unterstützt. Einen detaillierten Überblick über die Beziehung von Agents und
Lab Fähigkeit zeigt die nachfolgende Tabelle 1.
Tabelle 1 - Agents und Lab Fähigkeiten4
Umgebungsfähigkeit Lab Agent
notwendig?
Test Agent
notwendig?
Build Agent
notwendig?
Testing √ √ X
Deployment
Workflow
√ X √
Network Isolation √ X X
Damit kann man unterschiedlichste Umgebungen je nach Bedarf erstellen und über die Lab
Management Komponente verwalten.
4
Quelle siehe [1]

Workflow
Die Workflow-Fähigkeit wird beim TFS Lab Management über das Zusammenwirken von Build Agent
und Lab Agent realisiert. Beide Agenten sorgen dafür, dass jede virtuelle Maschine innerhalb einer
Testumgebung mit der korrekten Software bespielt wird. In Abhängigkeit vom Anwendungstyp und
Bestandteilen können die ausgerollten Produkte, z.B. Webseiten, Datenbankskripte oder MSI Setup
Pakete sein. Das Ausrollen der unterschiedlichen Build-Ergebnisse kann über Power Shell oder Batch-
Dateien gesteuert werden.
Ein Beispiel für ein einfaches Deployment-Skript zeigt das folgende Code-Schnipsel von [5]:
set RemotePath=%1
set LocalPath=%SystemDrive%Calculator
if not exist %RemotePath% (
echo remote path %RemotePath% doesn't exist
goto Error
)
if exist %LocalPath% (
rmdir /s /q %LocalPath%
)
REM Copy files to the local machine
mkdir %LocalPath%
copy /y %RemotePath%* %LocalPath%.
xcopy /cseirhdzv %RemotePath%_PublishedWebsitesCalc %LocalPath%
@echo Copied the build locally
:Success
echo Deploy succeeded
exit /b 0
:Error
echo Deploy failed
exit /b 1
Testen und Testautomatisierung
Die Test-Funktion ist für zwei Bereiche verantwortlich, die Ausführung von Tests und die Erfassung
von Diagnosedaten. Zur Durchführung von Tests ist ein Test-Agent notwendig. In Abhängigkeit vom
auszuführenden Testtyp kann der Agent als interaktiver Dienst oder Hintergrunddienst laufen.
Benötigt ein Test die Interaktion mit der Benutzeroberfläche, wie dies z.B. bei automatisierten
Oberflächentests (Coded UI Tests) notwendig ist, wird der Test Agent als interaktiver Dienst
konfiguriert. Im Gegensatz dazu, wenn keine Interaktion mit der Oberfläche notwendig ist, wie z.B.
bei Unit- und Lasttests, dann wird der Test Agent als Hintergrunddienst konfiguriert.
Neben der Testausführung sorgt der Test Agent durch die Erfassung von Diagnosedaten für die
Grundlage sogenannter „Rich Information Bugs“. Rich Information Bugs sind Fehlermeldungen mit
erweiterten Informationen. Beispiele für erweiterte Informationen sind z. B. ein Video der
Testausführung, Systeminformationen, Server Log Dateien, IntelliTrace Daten („historical
debugging“). Einen Überblick über die zusätzlichen Informationen zeigt nachfolgende Abbildung 4.

Abbildung 4 – Informationen in Rich Bugs
Ein praktisches Beispiel für einen Rich Bug mit angefügten Zusatzinformationen zeigt Abbildung 5.
Der erzeugte Bug war das Ergebnis aus einem Lab Management Testdurchlauf. Im Rahmen des
Testlaufes wurden aus den verschiedenen virtuellen Maschinen, sowohl die Systeminformationen,
die Eventlog-Einträge und ein Video der Testausführung angefügt.
Abbildung 5 - Rich Bug aus automatischer Testausführung
Fehler
Log Files
System
Info
Code
Coverage
Bild +
Screen
Videos
System
Events
Debug-
Info
Intelli-
Trace
VM Snap-
shot
…

Network Isolation
Die Network Isolation - Funktion vom Visual Studio Lab Management ermöglicht den Parallelbetrieb
von Kopien der Testumgebung (Klone). Unter normalen Umständen ist ein Parallelbetrieb von
duplizierten Testumgebungen nicht möglich, weil es in Netzwerken zu Konflikten bei den
Netzwerkeinstellungen kommt (z. B. doppelte Rechnernamen, doppelte IP Adressen) 5
. Eine
Lösungsmöglichkeit um Konflikte bei den Netzwerkeinstellungen zu verhindern, zeigt beispielhaft
Abbildung 6. In Abbildung 6 kann jeweils nur eine Kopie der Testumgebung mit dem Netzwerk
verbunden sein.
Abbildung 6 - Konflikte ohne Network Isolation
Das Visual Studio Lab Management kann nun mit Hilfe des Lab Agents diesen Prozess drastisch
verbessern, indem die einzelnen Kopien isoliert werden. Die Isolation wird erreicht, indem für jede
virtuelle Maschine je zwei Netzwerkkarten angelegt werden. Je eine der beiden Netzwerkkarten pro
virtuellen Testrechner ist dabei jeweils mit dem öffentlichen Netzwerk oder dem internen
Testnetzwerk verbunden. Die Einstellungen der internen Netzwerkkarten bleiben auch beim
Duplizieren konstant, d. h. Rechnername und IP Adresse bleiben immer erhalten (siehe Abbildung 7).
Um dies zu ermöglichen, ändert der Lab Agent bei den öffentlichen Netzwerkkarten die IP-Adressen
und den DNS-Namen, um eine Eindeutigkeit im öffentlichen Netzwerk sicherzustellen und einen
Zugriff auf die Testrechner von außen zu ermöglichen.
5
Siehe [6]

Abbildung 7 - Network Isolation
Management von Testumgebungen
Das Management von Testumgebungen, wie z.B. erstellen, löschen und verbinden, findet beim Lab
Management auch über den Microsoft Testmanager (MTM) statt. Um auf Testumgebungen
zuzugreifen, ist ein Wechsel in den das Lab Center („grüne Oberfläche“), notwendig.
Wie einfach es ist eine Testumgebung zu erstellen, wird im Folgenden exemplarisch vorgestellt. Als
ersten Schritt zur Erstellung einer Testumgebung wird der Umgebungstyp „virtuelle Testumgebung“
ausgewählt. In Abbildung 8 wurde dazu „New virtual environment“ geklickt.
Abbildung 8 - Auswahl der zu erstellenden Testumgebung
Nachdem der Umgebungstyp festgelegt wurde, kann auf Basis der verfügbaren Vorlagen an
virtuellen Maschinen, ein oder mehrere Testrechner für die Testumgebung erzeugt werden (siehe
Abbildung 9).

Abbildung 9 - Zusammenstellung der Testumgebung
Als nächster Schritt wird das Hardware Profil (z.B. Arbeitsspeicher, CPU, Festplattenspeicher) und
Betriebssystemprofil (z.B. Domänen-Mitgliedschaft, Administratorpasswort) konfiguriert (siehe
Abbildung 10).
Abbildung 10 - Konfiguration der Rechnerparameter
Die Erstellung einer Testumgebung wird durch das Zuweisen der Lab Management Fähigkeiten
abgeschlossen. Im Rahmen dieser Phase wird zum einen die Fähigkeit als auch der zuständige
Controller direkt ausgewählt. Wird im Rahmen der Erstellung einer Testumgebung ein Active
Directory eingerichtet, dann wird der entsprechende Server explizit benannt, damit er Server durch
die Network Isolation isoliert werden kann.

Abbildung 11 - Auswahl der Umgebungsfähigkeiten

Integration in Build- und Deployment-Prozesse
Die Verbindung von Release-Prozessen und Testausführung im Kontext Lab Management findet über
Build-Prozesse statt. Beim TFS 2010 wurde das Build-System komplett überarbeitet und dabei wurde
die globale Build-Prozess-Steuerung von MSBuild auf die Windows Workflow Foundation umgestellt.
Bei der Nutzung der Lab Management Fähigkeiten kommt ein neues Workflow Template zum
Einsatz (labdefaulttemplate.xaml).
Dieses Lab Management Template bildet intern einen abstrahierten Workflow aus Abbildung 12 ab.
Abbildung 12 - Lab Management Prozess
Die einzelnen Schritte vom Übersetzen des Codes, über das Ausrollen in die Testumgebung und die
Ausführung von Tests wird in vier Phasen über einen Workflow Wizard konfiguriert. Dieses
Verfahren wird als „Build, Deploy and Test“-Workflow bezeichnet. In der Literatur können Sie den
Prozess auch unter dem Namen „Continuous Delivery“ wiederfinden. „Continuous Delivery“ ist -
bildlich gesprochen - die nächste Stufe nach „Continuous Integration“, um agiler und günstiger
qualitativ hochwertige Software ausliefern zu können.
Der zuvor angesprochene Workflow Wizard ermöglicht das Einrichten eines Lab Management
Prozesses in vier Phasen:
1. Environment
Im Environment Schritt wird die zu nutzende Testumgebung konfiguriert. Testumgebungen
müssen vor der Konfiguration bereits über den MTM erstellt worden sein.
Compile
Code
Restore
Environ-
ment
Deploy
Appl.
Take
Check-
point
Run
Tests
Bug
Snapshot

2. Build
In diesem Schritt werden die für die Testumgebung zu verwendenden Build-Ergebnisse
konfiguriert. Es gibt zwei mögliche Orte, aus denen sich das Lab Management für das
Ausrollen von neuen Versionen bedienen kann, der TFS Build-Service oder eine Windows
Dateifreigabe. Wird die Option TFS Build-Service gewählt, so hat man die Möglichkeit
entweder einen neuen Build auszulösen oder die Ergebnisse eines existierenden Build zu
verwenden.
3. Deploy
Bei diesem Schritt werden die Skripte zum Ausrollen (Deployment) von Software oder
notwendigen Elementen mit den virtuellen Maschinen der Testumgebung verknüpft.

4. Test
Im Test-Schritt werden die auszuführenden Tests bzw. Testsuiten konfiguriert. Die
auszuführenden Tests werden durch Zuweisung eines Testplans, die Auswahl von ein oder
mehreren Testsuiten und Festlegung der zu testenden Konfiguration angegeben.
Anwendung von Lab Management beim Testen
Automatisches Testen
Beim automatischen Testen unter Verwendung des Lab Managements wird der im Kapitel
„Integration in Build-Prozesse“ beschriebene Workflow „Build, Deploy and Test“ eingesetzt. Das Ziel
des Verfahrens ist die regelmäßige Prüfung von neuen Softwareversionen durch automatisierte
Tests. Damit die Tests in den Testumgebungen automatisiert ablaufen können, müssen diese zuvor
durch einen Tester mit Entwicklungshintergrund (z.B. Testengineer) automatisiert werden. In Visual
Studio hat der Testengineer die folgenden Testtypen zur Verfügung:
1) Unit Test: Test von Logik auf Modul- und Komponentenebene
2) Datenbank-Unit Tests: Test von Datenbanklogik (Functions, Stored Procedures, etc.)
3) Coded UI Tests: Test von Oberflächen (Web, WPF, Silverlight, .net Forms etc.) über die
Standards und Technologien6
MSAA7
, UIA8
, MSHTML, JavaScript, Firefox DOM, Code
Injection oder Reflection
4) Lasttests: Testet das Anwendungsverhalten unter simulierter Last
Von den genannten Testtypen werden typischerweise die ersten drei genannten in Lab Management
Testumgebungen ausgeführt.
Die Ausführung eines Oberflächentests ist beispielhaft in Abbildung 13 dargestellt.
6
UI Tracking Technologien, siehe [7]
7
Microsoft Active Accessibility , siehe [8]
8
Microsoft UI Automation, siehe [9]

Abbildung 13 - Ausführung Coded UI Test in Testumgebung
Auch während der Ausführung der zuvor genannten Tests werden innerhalb der Testumgebung
fortlaufend Diagnosedaten durch den Testagent eingesammelt und im TFS gespeichert (siehe
Abbildung 14).
Abbildung 14 - Analyse von Testläufen aus der Testumgebung

Abbildung 15 - Diagnose Adapter
Die Erfassung von Diagnosedaten kann in Abhängigkeit von der Rolle der virtuellen Maschine
individuell konfiguriert werden. Die einfache Konfiguration dieser Einstellungen und ein
Beispielszenario zeigen die Abbildungen 15 und 16.
Testumgebung bestehend aus 2 Clients und 2 Servern
Windows 7
Client + IE 8
Datenbank-
Server
Web-
Server
Windows XP
Client + Firefox
Testausführung Testausführung
Erfassung von
Diagnosedaten
Erfassung von
Diagnosedaten
Erfassung von
Systeminformationen
Erfassung von
Diagnosedaten
Erfassung von
Systeminformationen
Network
Emulation
Abbildung 16 - Testumgebung für automatisches Testen9
9
Quelle siehe [10]

Manuelles Testen
Das manuelle Testen bindet einen großen Anteil der Ressourcen von Testabteilungen. Auch bei
dieser Form des Testens kann das Lab Management Unterstützung leisten. Beim manuellen Testen
arbeitet der Tester mit einer Kombination aus dem „MTM Test Runner“ als Client und dem Lab
Management für die Testobjekt-Server-Infrastruktur. Ein typisches Anwendungsszenario ist das
Testen einer Webanwendung, dabei wird die Anwendung durch einen Build-Prozess auf das
Testsystem, bestehend aus Web Server und Datenbank Server, ausgerollt. In diesem Szenario wird
ein lokaler MTM benutzt und die Webseite aus der virtuellen Testumgebung über den Browser
geöffnet (siehe Abbildung 17).
Abbildung 17 - Testen von Web Applikationen mit dem MTM und Lab Management
Findet der Tester während der Testausführung einen Fehler, so hat er jetzt die Möglichkeit simultan
und ohne manuelle Tätigkeiten alle Diagnosedaten von allen an der Testausführung beteiligten
Computer zu holen (siehe Abbildung 18).

Manuelles Testen von Mehrschichtigen Anwendungen
Testumgebung
Lokaler Client
Datenbank-
Server
Web-
Server
Testausführung
Erfassung von
IntelliTrace Daten
Erfassung von
Systeminformationen
Erfassung von
Systeminformationen
Erfassung von Event-
Log Informationen
Erfassung von
IntelliTrace DatenVideo-
aufzeichnung
Abbildung 18 - Testumgebung für manuelles Testen10
Unabhängig von den Diagnosedaten aus den Testumgebungen lassen sich im Fehlerfall die
komplette Test-Infrastruktur (hier: Web Server, Datenbank) in einem konsistenten Zustand
einfrieren (ein Test Environment Snapshot)(siehe Abbildung 19).
Abbildung 19 - Einfrieren von Testumgebungen im Fehlerfehl
Durch das Verlinken der Snapshots zu den Fehlern (Bug Work Items) können Tests und Fehlerfälle
leichter reproduziert und bei Bedarf die Korrekturen in der ursprünglichen Testumgebung
nachgetestet werden. Vor der Verfügbarkeit von Lab Management mussten Entwickler sehr oft
aufwendig eigene Testumgebungen aufsetzen, um Fehler reproduzieren zu können. Mit dem Lab
Management haben Sie jetzt die Möglichkeit, die Umgebungen der Tester zu verwenden bzw. sich
exakte Kopien von diesen zu erzeugen und diese mit Hilfe von Network Isolation sogar parallel zu
betreiben. Damit können die Tester schon das nächste Release testen, während die Entwickler im
letzten Release die gefundenen Fehler nachstellen und beheben.
10
Quelle siehe [10]

Zusammenfassung
Testausführung und die Bereitstellung von Testumgebungen binden einen großen Anteil an
Ressourcen (Zeit, Personal, Hardware). Aufgrund des großen Anteils am Testprozess ergibt sich hier
eine hohes Optimierungs- und Einsparpotential durch das Visual Studio Lab Management.
Das Lab Management schafft erstmals für viele Anwender eine kostenneutrale, in den Test- und
Entwicklungsprozess integrierte Lösung, zur Verwaltung und Bereitstellung von Testumgebungen,
sowie die Möglichkeit der automatischen Ausführung von Tests und bei Bedarf die Erfassung von
umfangreichen Diagnosedaten.
Die Stärke des Systems liegt in der hohen Integrationstiefe zwischen Release- und Testprozess.
Manueller Aufwand für den Testadministrator kann hier, z.B. durch ein automatisches Ausrollen von
aktuellen Softwareversionen eingespart werden. Weiterer Aufwand für alle Testbeteiligte lässt sich
hier zum einen beim Einrichten von „sauberen“ Testumgebungen und zum anderen beim
regelmäßigen installieren von neuen internen Testversionen einsparen.
Weitere Vorteile können sich durch Verwendung von virtuellen Testumgebungen ergeben, indem
z.B. im Fehlerfall und beim Bugfixing Entwickler auf die Testumgebungen der Tester zugreifen bzw.
sich Kopien der Testumgebungen mit „einem Mausklick“ ohne administrativen Overhead erzeugen
lassen können. Damit stehen die Testumgebungen für alle Rollen zur Verfügung, wenn diese
benötigt werden und nicht, wenn die Umgebungen gerade zufällig frei sind.
Neben der Unterstützung des manuellen Testens, lässt sich ein automatischer Testprozess nach der
Methodik „Continuous Delivery“, bestehend aus den Phasen Kompilieren, Ausrollen und Testen sehr
einfach realisieren. Continuous Delivery wird in der Literatur als „Continous Integration Plus“
gesehen. Das Testen von Software mit Lab Management ist nicht nur auf virtuelle Testumgebungen
begrenzt, denn es kann auch die Kombination aus Hardware und Software in physischen
Umgebungen getestet werden.
Unabhängig davon, ob mit Hilfe von Visual Studio Lab Management Umgebungen manuelles oder
automatisches Testen unterstützt wird: In beiden Anwendungsfällen haben Sie die Möglichkeit,
umfangreiche Diagnosedaten von allen beteiligten Testrechnern ohne manuelle Tätigkeiten zu
extrahieren und dem Entwickler über den TFS zur Verfügung zu stellen.

FAQ
1) Werden auch andere Virtualisierungstechnologien als Microsoft Hyper-V unterstützt?
Sie haben die Möglichkeit virtuellen Maschinen, (z. B. VMware ESX, XEN, VirtualBox) als
physische Testumgebungen in ihren Testprozess einzubinden.
2) Welche Unterschiede existieren zwischen virtuellen und physischen Testumgebungen?
Eine Übersicht über die Unterschiede zeigt nachfolgende Tabelle11
:
Die wesentlichen Unterschiede zeigen sich bei virtualisierungsspezifischen Funktionen, wie
z. B. Snapshots, Erstellung von Umgebungen auf Basis von Vorlagen und Network Isolation.
3) Ist die Installation des Visual Studio 2010 und TFS 2010 Service Pack 1 empfehlenswert?
Die Service Packs von Visual Studio 2010 und TFS 2010 enthalten wichtige Fehlerkorrekten
für die unterschiedlichen Bereiche von Visual Studio 2010 und TFS 2010 und das zuvor
separate veröffentlichte Lab Management Update. Eine Installation auf allen beteiligten
Clients und Servern ist sehr zu empfehlen. Mehr Informationen zu der Installation der
Service Packs finden Sie unter [12].
4) Ist die Installation des Windows Server 2008 R2 Service Pack 1 empfehlenswert?
Das Service Pack 1 für den Windows Server 2008 R2 enthält wichtige Fehlerkorrekturen und
neue Funktionen für die Serverrolle Hyper-V, welche die Basis für virtuelle Testumgebungen
ist. Nach der Installation des Service Pack 1 für Windows Server 2008 R2 ist die Installation
des Service Pack 1 für den SCVMM 2008 R2 ebenfalls erforderlich. Bitte beachten Sie, dass
die neue Hyper-V Funktion „Dynamic Memory“ bereits mit dem Lab Management nutzbar
ist, aber noch nicht direkt über den MTM konfiguriert werden kann.
11
Quelle siehe [11]

Quellen
[1] Setting up agents/controllers for lab:
http://blogs.msdn.com/b/lab_management/archive/2010/04/21/setting-up-agents-controllers-for-
lab.aspx
[2] Planning and Setting Up Your Virtual Lab:
http://msdn.microsoft.com/en-us/library/dd380688.aspx
[3] Lab Build agents – How it works:
http://blogs.msdn.com/b/lab_management/archive/2010/05/02/lab-build-agents-how-it-
works.aspx
[4] Visual Studio 2010 and MSDN Licensing White Paper:
http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=2b1504e6-0bf1-
46da-be0e-85cc792c6b9d
[5] Getting started with Lab Management – VS2010 RC (Part: 4):
http://blogs.msdn.com/b/lab_management/archive/2010/02/16/getting-started-with-lab-
management-vs2010-rc-part-4.aspx
[6] How does Network Isolation in VS Lab Management work?:
http://sstjean.blogspot.com/2010/07/how-does-network-isolation-in-vs-lab.html
[7] Visual Studio UI Test Extensibility–Scenarios & Guiding:
Principleshttp://blogs.msdn.com/b/mathew_aniyan/archive/2011/03/28/visual-studio-ui-test-
extensibility-scenarios-amp-guiding-principles.aspx
[8] Microsoft Active Accessibility:
https://secure.wikimedia.org/wikipedia/en/wiki/Microsoft_Active_Accessibility
[9] Microsoft UI Automation:
https://secure.wikimedia.org/wikipedia/en/wiki/Microsoft_UI_Automation
[10] Setting Up Machines and Collecting Diagnostic Information Using Test Settings:
http://msdn.microsoft.com/en-us/library/dd286743.aspx
[11] Does Lab Management support non-Hyper-V platforms?:
http://blogs.msdn.com/b/lab_management/archive/2010/10/27/does-lab-management-work-on-
non-hyper-v-platforms.aspx
[12] FAQ: Team Foundation Server (TFS) und Visual Studio (VS) 2010 SP1 Installation:
http://www.tfsblog.de/2011/03/21/faq-team-foundation-server-tfs-und-visual-studio-vs-2010-sp1-
installation/

Abbildungsverzeichnis
Abbildung 1 –Typische Testumgebungen im Projektalltag.....................................................................3
Abbildung 2 - Architektur - Lab + Build + Test ........................................................................................5
Abbildung 3 – Konfiguration von Lab Management Eigenschaften .......................................................6
Abbildung 4 – Informationen in Rich Bugs..............................................................................................8
Abbildung 5 - Rich Bug aus automatischer Testausführung ...................................................................8
Abbildung 6 - Konflikte ohne Network Isolation.....................................................................................9
Abbildung 7 - Network Isolation ...........................................................................................................10
Abbildung 8 - Auswahl der zu erstellenden Testumgebung.................................................................10
Abbildung 9 - Zusammenstellung der Testumgebung..........................................................................11
Abbildung 10 - Konfiguration der Rechnerparameter..........................................................................11
Abbildung 11 - Auswahl der Umgebungsfähigkeiten............................................................................12
Abbildung 12 - Lab Management Prozess ............................................................................................13
Abbildung 13 - Ausführung Coded UI Test in Testumgebung...............................................................16
Abbildung 14 - Analyse von Testläufen aus der Testumgebung...........................................................16
Abbildung 15 - Diagnose Adapter.........................................................................................................17
Abbildung 16 - Testumgebung für automatisches Testen....................................................................17
Abbildung 17 - Testen von Web Applikationen mit dem MTM und Lab Management........................18
Abbildung 18 - Testumgebung für manuelles Testen...........................................................................19
Abbildung 19 - Einfrieren von Testumgebungen im Fehlerfehl............................................................19

Dieses Whitepaper wurde erstellt von
Autor: Nico Orschel (AIT GmbH & Co. KG)
Reviewer: Artur Niesporek (Microsoft Deutschland GmbH)
Steffen Ritter (Microsoft Deutschland GmbH)
Mathias Zieger (Microsoft Deutschland GmH)
AIT Applied Information Technologies GmbH & Co. KG
AIT TeamSystemPro Team
Postanschrift:
Leitzstr. 45
70469 Stuttgart
Amtsgericht Stuttgart
HRA 725452
Komplementär:
AIT Verwaltungs GmbH
Amtsgericht Stuttgart
HRB 734136
Geschäftsführer: Lars Roith
IBAN: DE80 61191310 0664310001
SWIFT: GENODES1VBP
Telefon 0711/ 49066-430
E-Mail info@aitgmbh.de
Internet http://www.aitgmbh.de/teamsystempro

Whitepaper Team Foundation Server 2010 Lab Management

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a Whitepaper Team Foundation Server 2010 Lab Management

Similar a Whitepaper Team Foundation Server 2010 Lab Management (20)

Más de Nico Orschel

Más de Nico Orschel (15)

Whitepaper Team Foundation Server 2010 Lab Management