Stefan Schmerler - Softwaretest in der Praxis

Das Modell sieht vor, dass in jeder Entwicklungsphase ein Testschritt unternommen wird. Man bewegt sich von links oben durch das V-Diagramm bis zur Ankunft rechts oben. Beim Systemtest prüft man z. B. gegen die horizontal auf gleicher Höhe im V-Diagramm gelisteten Softwareanforderungen, beim Abnahmetest gegen die Systemanforderungen.

Abb. 3-2: Das V-Modell in der SW-Entwicklung

Validierung: Doing the right thing?

Diese horizontalen Testschritte bezeichnet man als Validierung, gemeint ist damit die Überprüfung, ob die Entwicklungsergebnisse auf der jeweiligen Stufe noch den Kundenanforderungen entsprechen. Falls nein, kann man korrigieren, ohne lange in die falsche Richtung weiterzuarbeiten. Die Fragestellung ist hier also »Am I doing the right thing?«

Verifikation: Doing the thing right?

Unter Verifikation versteht man hingegen die Überprüfung der Korrektheit und Vollständigkeit eines Phasenergebnisses relativ zu seinen direkten Spezifikations-/Phaseneingangsdokumenten. Es ist die Überprüfung, ob der letzte Schritt fehlerfrei absolviert wurde. Die Fragestellung lautet hier »Am I doing the thing right?

3.3 Iterative und inkrementelle Entwicklungsmodelle

iterative Annäherung an die Kunden-

anforderungen in vielen Zyklen

Das Grundprinzip einer iterativen Entwicklung ist das stetige Einbringen von Kundenrückmeldungen und anderen Erkenntnissen aus dem Einsatz des aktuellen Entwicklungsstands eines Softwareprodukts in den Entwicklungsprozess. Durch diese fortgesetzte Validierung wird das Produkt schrittweise immer weiter verbessert und kann die Kundenerwartungen immer genauer und besser erfüllen. Die Software wird nicht »an einem Stück« erstellt, sondern in Form einer Abfolge von Versionsständen mit jeweils anwachsender Funktionalität – daher der Name »inkrementelles Entwicklungsmodell«.

ein schneller erster Stand, der

sukzessive erweitert wird

Das Ziel ist, mit einer Vorstufe (Basis-Features) des Produkts möglichst schnell auf den Markt zu kommen und es dann schrittweise weiter auszubauen. Man spricht auch von iterativ-inkrementeller Entwicklung. Beispiele hierfür sind der Rational Unified Process [15] und das Evolutionary Development [16]. Auch alle Formen der agilen Softwareentwicklung sind dieser Gattung von Entwicklungsprozessen zuzuordnen. Die bekanntesten sind Extreme Programming [17] und das Modell von Kanban und Scrum [18]. Letzteres Prozessmodell ist in den letzten Jahren zu großer Bekanntheit gelangt.

Automatisierung und Wiederverwen-

dung von Tests sind obligatorisch.

Aber wie sind Testaktivitäten in diesem Entwicklungsprozess zu verankern? Fest steht, dass sich der Test an die iterativ-inkrementellen Abläufen anpassen muss. Für jede Komponente müssen wiederverwendbare Tests vorhanden sein, die an jedem Inkrement wiederholt werden können. Zu beachten ist hierbei, dass für jedes Inkrement entsprechend dem jeweiligen Funktionszuwachs zusätzliche Testfälle implementiert werden müssen.

Agile Vorgehensweisen zielen auf möglichst kurze Iterationszyklen ab, z. B. wöchentlich (Weekly Builds). Eine besondere Bedeutung kommt daher der Testautomatisierung zu, die entsprechend effizient gestaltet sein muss.

Continuous Integration

Kommen mit anwachsender Softwarefunktionalität immer weitere Testfälle hinzu, muss der Testprozess mit dem Entwicklungsprozess schritthalten können. Aufgedeckte Fehlerwirkungen werden hierbei kurzfristig korrigiert. Das Projekt besitzt daher in seiner Testumgebung zu jedem Zeitpunkt ein integriertes, getestetes System. Dieses Vorgehen wird als Continuous Integration bezeichnet.

Continuous Deployment

Werden die Tests fehlerfrei durchlaufen, so kann das getestete System automatisiert in die Produktivumgebung kopiert und dort Anwendern zur Verfügung gestellt werden. Man spricht von Continuous Deployment.

Continuous Testing

Grundvoraussetzung für diese hochfrequenten, automatisierten Abläufe ist natürlich ein automatisiertes, kontinuierlich stattfindendes Testing, das man als Continuous Testing bezeichnet im Gegensatz zu einem phasenorientiert erfolgenden Testvorgang.

3.4 Teststufen in der Softwareabsicherung

Softwarearchitektur und Teststufen

Ein Softwaresystem weist in der Regel eine Struktur aus einer Reihe von Teilsystemen auf, die wiederum aus einer Vielzahl elementarer Komponenten bestehen. Die gesamte Struktur wird als Softwarearchitektur bezeichnet. Beim Testen muss das zu testende System auf diesen verschiedenen Architekturebenen geprüft werden. Der Begriff der Teststufen hat sich etabliert, jede Teststufe ist eine Instanz des Testprozesses.

phasenorientierter Test

Im Folgenden werden die einzelnen Absicherungsschritte von phasenorientierten Testprozessen näher erläutert, insbesondere im Hinblick auf das in der jeweiligen Stufe verfolgte Testziel.

Ausgangspunkt ist das Entwicklungsstufendiagramm, wie in Abb. 3-3 dargestellt. Der Entwicklungsverlauf beginnt links oben bei der Anforderungsspezifikation.

Abb. 3-3: Übersicht Teststufen im V-Diagramm

3.4.1 Unit-Test

Der Unit-Test ist der erste Testschritt im rechten Schenkel des V-Diagramms. Er setzt ein direkt mit Beginn der Implementierung der Quelltexte und überprüft den Reifegrad der Entwicklungsphase Modulentwurf, d. h. die Implementierung einzelner Softwarefunktionen und Methoden.

Testtreiber stimulieren für die Ausführung

das SUT und erfassen die Ausgaben.

Unter Testtreiber ist hierbei ein Programm zu verstehen, das es ermöglicht, ein Testobjekt aufzurufen, mit Testdaten (Stimuli) zu versorgen, die Ausgaben des Testobjekts zu erfassen, das Testergebnis zu ermitteln und das gesamte Vorgehen zu dokumentieren.

Boolean main () /* Testtreiber */

{ Boolean result;

int in_1, in_2;

/* Testdaten bzw. Stimuli aus Tabelle laden */

Lies_Eingangsdaten (&in_1, &in_2);

/* Die Testobjekte sind mit den Stimuli aufzurufen */

result = Mein_TestObjekt_1 (in_1, in_2);

/* Wir vergleichen Ist- und Sollwert */

if (TestOrakel (in_1, in_2) != result) return 0; /* Fail */

else return 1; /* Pass */

/* Testergebnis wird dokumentiert */

Testprotokoll_Testobjekt_1 (result);

/* Das zweite Testobjekt wird aufgerufen */

result = Mein_TestObjekt_2 (in_1);

...

}

Komponententest-Frameworks

Der Einsatz von Komponententest-Frameworks reduziert den Aufwand für die Erstellung der Testtreiber-Programmierung. In [19] werden Installation und Einsatz des Google C++ Testing Framework beschrieben. Vorteil einer solchen Umgebung sind einheitliche Testtreiber, die entsprechend wiederverwendet und ausgetauscht werden können. Solche Testtreiber können z. B. über eine Kommandoschnittstelle bedient werden und bieten komfortable Mechanismen zur Handhabung der Testdaten sowie zur Protokollierung und Auswertung.

Stubs sind Platzhalter noch

nicht implementierter Module.

Unter Stub (Platzhalter) ist letztlich eine leere Hülle ohne Funktion, aber mit geeigneter Schnittstelle zu verstehen, da bei Fehlen dieses Moduls keine Kompilierung erfolgen könnte. Die Erstellung von Stubs erfordert keinen Aufwand, die Möglichkeit einer Wiederverwendung ist daher nicht von Bedeutung.