VSTS im Einsatz: Test & Qualitätssicherung

… Das verkürzte Beispiel in Listing 1 zeigt
einen minimalen Unit-Test, der genau eine
öffentliche Methode Calculate der Klasse
ClassToTest testet:

/// 
///This is a test class for DemoApp.ClassToTest and is
///intended to contain all DemoApp.ClassToTest Unit Tests
///
[TestClass()]
public class ClassToTestTest
{
/// 
///A test for Calculate ()
///
[TestMethod()]
public void CalculateTest()
{
ClassToTest target = new ClassToTest();
int expected = 0;
int actual;
actual = target.Calculate();
Assert.AreEqual(expected, actual, "DemoApp
.ClassToTest.Calculate did not return the expected
value.");
Assert.Inconclusive(
"Verify the correctness of this test method.");
}

Die Klasse, die die
Testfälle enthält, muss mit dem TestClass-Attribut dekoriert sein. Die Testfälle selbst
müssen mit dem TestMethod-Attribut
versehen sein. Bis auf die Attributnamen
entspricht das Vorgehen dem, das bei der
Verwendung des alternativen NUnit-Testframeworks
angewandt wird [4].

Die Unit-Tests lassen sich entweder
über das Test-Menü oder die Test-Tools-
Symbolleiste starten. Der Fortschritt der
Testausführung lässt sich im Test-Result-
Fenster (Abbildung 4), das automatisch
eingeblendet wird, verfolgen. Generierte
Test-Methoden, die noch nicht final ausformuliert
sind, führen zum Testergebnis
„Inconclusive“, während fertig gestellte
Tests zu den Testergebnissen „Passed“ oder
„Failed“ führen sollten. In der Symbolleiste
dieses Fensters lassen sich die Ergebnisse filtern,
gruppieren und manuell in die Datenbank
des TFS publizieren. Die Voraussetzung
für das Publizieren ist eine bestehende
Verbindung zum Team Foundation Server
und mindestens ein konfigurierter Team-
Build, dem die Testergebnisse zugeordnet
werden können.

Abb. 4: Das Fenster mit den Test-Resultaten

Bei der Definition eines Team-Build-
Types ist es möglich, vordefinierte Testlisten
auszuwählen, die automatisch nach
jedem Build ausgeführt werden sollen. Die
Ergebnisse der während eines Team-Builds
ausgeführten Tests werden – im Gegensatz
zu den Ergebnissen manuell gestarteter
Tests – automatisch in die Datenbank
publiziert. Die so im TFS kontinuierlich
gesammelten Testergebnisse ermöglichen
dem Team die Beobachtung von Testmetriken
über einen längeren Zeitraum und
die Erzeugung verschiedener Reports zur
Analyse.

Umfangreiche Möglichkeiten zum
Verwalten von Tests bietet Microsoft in
der Tester-Edition von VSTS. Damit lassen
sich unterschiedliche Testlisten erzeugen,
ineinander verschachteln und hierarchisch
darstellen. Darüber hinaus stehen in der
Tester-Edition weitere Test-Varianten zur
Verfügung. Dazu zählen Load-Tests, Web-
Tests, manuelle Tests und generische Tests.
Generische Tests sind Container, aus denen
externe Programme oder Batch-Skripte als
Tests aufgerufen werden können. Das Testergebnis
wird dabei durch den Exit-Code
des externen Programmes bestimmt.

Wer auf die zusätzlichen Test-Varianten
verzichten kann, findet in dem kommerziell
erhältlichen Test Manager Add-
In
von Ekobit für die Developer Edition
des VSTS einen nahezu gleichwertigen
Ersatz für die Verwaltungsmöglichkeiten
der VSTS Tester Edition [7]. Genau so wie
das Microsoft-Vorbild arbeitet das Addin
von Ekobit auf den bereits erwähnten
Testlisten, so dass diese problemlos beim
automatischen Build-Prozess verwendet
werden können.

Testfälle alleine genügen nicht

Testfälle, die beim Lauf alle erfolgreich
„grün“ werden, sind für sich genommen
aber noch kein Maß für die erreichte Qualität.
Dazu muss die Aussagekraft der Tests
selbst überprüft werden. Ein Tool, das
VSTS dafür zur Verfügung stellt, ist die
„Code Coverage“. Diese liefert eine Aussage
über den Anteil des Sourcecodes, der
von den Tests abgedeckt wird. Zu diesem
Zweck können in der Testlauf-Konfiguration
die Code Coverage aktiviert und die
Assemblies selektiert werden, die überprüft
werden sollen. Anschließend muss
die Testsuite zur Messung ohne Debugging
gestartet werden. Danach stehen im Fenster
Code Coverage Results die statistischen
Merkmale zur Verfügung, die hierarchisch
nach Assembly, Klasse und Methode geordnet
dargestellt werden (Abb. 5). Außerdem
kann im Code nachvollzogen werden,
welche Teile einer Methode nicht ausgeführt
wurden. Dazu wird der Code mit drei
Farben hinterlegt: In der Standardeinstellung
steht hellblau für ausgeführten Code,
rot für nicht ausgeführten Code und hellrot
für teilweise ausgeführten Code.

Abb. 5: Die Ergebnisse einer Code Coverage

In der Praxis hat sich gezeigt, dass das
Ziel „100 Prozent Codeabdeckung durch
die Testfälle“ nur durch einen unverhältnismäßig
hohen Aufwand zu erreichen ist, da
manche Codeteile nur unter Bedingungen
ausgeführt werden, die im Test schwer zu
simulieren sind. Dies betrifft insbesondere
Codeblöcke zur Ausnahmebehandlung
oder Pfade in stark voneinander abhängigen
Klassen. Einer der Hauptvorteile der
Code Coverage besteht in der Identifikation
relevanter Bestandteile, die nicht durch
bestehende Tests abgedeckt sind.

Zum Schluss – die Performance Analyse

Neben den funktionalen Anforderungen
an die Software, die sich meist sehr gut
über die beschriebenen Unit-Tests überprüfen
lassen, gibt es noch nicht-funktionale
Anforderungen, wie beispielsweise
die Ausführungsgeschwindigkeit oder den
detaillierten Speicherverbrauch. Um diese
Anforderungen zu überprüfen, bedarf es
zusätzlicher Tool-Unterstützung, da die
benötigten Infos nicht ohne Weiteres von
der Laufzeitumgebung zur Verfügung
gestellt werden. Microsoft bietet hierzu
den im VSTS für Entwickler integrierten
„Performance Explorer“, der sich über
die Auswahl des gleichnamigen Fensters
aus dem View-Menü heraus öffnen lässt.
Das Starten des „Performance Wizard“
ermöglicht es, in zwei simplen Schritten
eine „Performance Session“ einzurichten,
die auf Knopfdruck sofort Messergebnisse
liefern kann. Im ersten Schritt lässt sich das
zu untersuchende …

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.