Akzeptanzttest, Komponententest, Systemtest - Was ist was?

Übersicht

Immer wieder taucht die Frage auf, welche Arten von Tests XP vorsieht. Dann schwirren Begriffe wie Systemtest, Akzeptanztest, Regressionstest, Unittest, Komponententest und weitere durch den Raum. Dieser Beitrag soll diesen Nebel etwas lichten, indem er die in der Literatur verwendeten Begriffe und deren Definitionen nebeneinander und gegenüber stellt.

Abgrenzung

Vom Testen abgrenzen muß man die Fehlersuche sowie die Quellcodedurchsicht oder -inspektion. Im Unterschied zur Fehlersuche starten Tests mit bekannten Startbedingungen; es werden genau definierte Funktionen ausgeführt und es gibt eine vorher bekannte Ergebnismenge, nämlich der Test ist erfolgreich oder ist nicht erfolgreich.

Bei der Fehlersuche hingegen ist nur bekannt, daß es zu einem Fehlverhalten kommt. Die erforderlichen Startbedingungen sind noch nicht bekannt (sonst hätte man ja gleich einen Test schreiben können, der das Fehlverhalten gleich von vornherein aufgezeigt hätte).

Testen im Rahmen von XP

Es gibt im Grundsatz genau zwei Arten von Tests, die XP vorsieht:

• Akzeptanztests
• Komponententests

Akzeptanztests testen das System aus der Sicht des Kunden. Die Programmierer setzen Komponententests in ihrer täglichen Entwicklungsarbeit ein.

Daneben können Tests auch noch eingeteilt werden anhand der Rollen, die sie spielen. Ist beispielsweise eine Aufgabe fertig implementiert und in das System integriert, werden alle bis dahin exisitierenden Komponenten zu Regressionstests (siehe unten). Das gleiche gilt für Akzeptanztests, sofern die zugrunde liegende Benutzergeschichte fertig implementiert ist.

Testen ist, im Unterschied zum Beispiel zum V-Modell 97, keine Aufgabe einer separaten Qualitätssicherungsabteilung (QS-Abteilung), sondern ein wichtiger Bestandteil der Programmiertätigkeit und vollständig in den Prozess integriert. Auf diese Weise kann keine Lücke entstehen zwischen dem XP-Team und der QS-Abteilung. Das wirkt sich auch auf die Produktivität aus, indem beispielsweise redundante Tests vermieden werden können.

Im Rational Unified Process werden Tests durch einen Test-Designer identifiziert und implementiert (Kruchten 2000, Seite 243). Das kann, und wird häufig, parallel zur Implementierung erfolgen, hat jedoch nicht die gleiche Wirkung wie eine direkte Integration. Warum zum Beispiel wird im produzierenden Gewerbe ebenfalls die QS-Funktion direkt in die Fertigungslinien integriert?

Regressionstest

Ein Regressionstest werden typischerweise eingesetzt, um nach einer Veränderung des Quellcodes eines Systems festzustellen, ob sich unerwünschte Seiteneffekte ergeben haben. Unerheblich ist dabei, ob die Codeänderung aus einem Hinzufügen von neuen Features oder aus dem Beheben eines Defektes herrühren.

Sowohl Komponententests als auch Akzeptanztests werden mit der Zeit zu Regressionstests. Während der Integration neuer Funktionalitäten werden alle Komponenten- und Akzeptanztests ausgeführt. Komponententests müssen zu jeder Zeit zu hundert Prozent erfolgreich ausgeführt werden. Bei Akzeptanztests hängt die Richtigkeit des Ergebnisses davon ab, ob alle zu einem Akzeptanztest gehörenden Aufgaben abgeschlossen wurden. Erst am Ende des Releasezyklus müssen dann auch alle Akzeptanztests zu hundert Prozent erfolgreich sein.

Systemtest

Der Begriff Systemtest wird häufig verwendet, um die Tests zu beschreiben, die ein System als Ganzes, als Einheit überprüfen. Aus dieser Perspektive betrachtet, können auch die Akzeptanztests zu den Systemtests gezählt werden.

Häufig ist es jedoch so, daß der Begriff Systemtest im Zusammenhang mit schwergewichtigen Entwicklungsprozessen verwendet wird. Diese Tests sind dann zum Teil ohne Einbeziehung des Kunden entstanden. Sie prüfen dann zwar eine Korrektheit des Systems, jedoch ist nicht garantiert, dass diese Korrektheit den Kundenanforderungen entspricht.

Integrationstest

Wenn zu einem System eine neue Funktionalität hinzugefügt wird, prüft ein Integrationstest, ob die Funktionalität korrekt arbeitet, und keinen negativen Seiteneffekt auf bereits vorhandene Funktionalität hat.

In manchen Unternehmen wird nur selten, z.B. alle drei Wochen, integriert, d.h. das komplette System mit allen Subsystemen, mit allen Veränderung gebaut. Das führt häufig zu erhöhtem Aufwand alle Integrationstest wieder zum Laufen zu bringen.

Funktionstest

Im Rational Unified Process (RUP) dient ein Funktionstest der Überprüfung, ob ein Use Case korrekt implementiert ist.

Stresstest

Beim Stresstest werden die Arbeitsbedingungen für den Testkandidaten erschwert, z.B. Verringerung der Resourcen wie Speicher. Danach muß sich der Testkandidat im Rahmen der Spezifikationen verhalten, z.B. definierte Antwortzeiten einhalten.

Im Falle von XP kann auch dafür ein Komponententest geschrieben werden, z.B. indem zusätzlich am Ende eines Tests geprüft wird, ob er nicht länger als eine definierte Zeit benötigt hat. Dieser Ansatz hat sich auch in der Praxis bewährt.

Lasttest

Bei dieser Art von Test werden die Randbedingungen, wie z.B. reduzierte Resourcen, für den Testkandidaten (System, Subsystem, Klasse) verändert. Statt dessen wird die Anzahl der Aufrufe vergrößert.

Für eine Web-Applikation kann z.B. die Last erhöht werden, indem ein Komponententest mehrfach parallel ausgeführt wird. Alternativ können mehrere unterschiedliche Komponententests gleichzeit ausgeführt werden. Am besten werden dann diese Tests entweder auf mehreren Rechnern und/oder in mehreren Prozessen oder Threads ausgeführt. In jedem Fall muß man sich darüber im Klaren sein, daß sich dei Tests in diesem Fall hinsichtlich des zeitlichen Ablaufs nicht deterministisch verhalten.