Stefan Schmerler - Softwaretest in der Praxis

Die Erprobungsreihenfolge orien-

tiert sich an der Nutzung.

Vorteil dieses Vorgehens ist die funktionsorientierte Sichtweise – die Sicht des späteren Kunden! Nichts ist wichtiger für einen schnellen Reifegradgewinn, als ein System so früh wie möglich aus Sicht des späteren Anwenders zu betrachten. Es ist allerdings schwierig, die Gesamtheit aller Funktionalitäten lückenlos zu erfassen. Hier droht bei seltenen oder nicht berücksichtigten Anwendungsfällen ein hohes Reifegradrisiko.

Das Wichtigste funktioniert zuerst,

Unwichtiges unter Umständen nie!

Andererseits werden mit dieser Strategie die wichtigen Funktionen bereits sehr früh einen hohen Reifegrad aufweisen – und zwar in vollständiger Implementierung. Je nach dem vorliegenden Einsatzziel der Software kann dies eine wichtige Eigenschaft sein. Trotz Weiterentwicklung könnte die Software nie die grundsätzliche Nutzungsmöglichkeit verlieren und z. B. für Kundenvalidierungen oder während der Wartung zur Verfügung stehen.

Abb. 3-11: Collaboration-Integrationsteststrategie

3.4.3.5 Ad-hoc-Integration

zufällige Integrationsreihenfolge

Die Komponenten werden in der zufälligen Reihenfolge ihrer Fertigstellung integriert. Dies hat den Vorteil, dass jede Komponente zum frühestmöglichen Zeitpunkt integriert werden kann, was den Gesamtprozess beschleunigt. Andererseits sind sowohl Treiber als auch Stubs zu entwickeln.

3.4.3.6 Backbone-Integration

Integration in einen

vorgefertigten Rahmen

Bei der Backbone-Integration wird vor der Integration eine Grobstruktur (Backbone) zur Verfügung gestellt, in die sukzessive die zu integrierenden Komponenten eingebaut werden. Die bereits angesprochene Continuous Integration kann als eine spezielle Form der Backbone-Strategie angesehen werden.

Der Vorteil dieses Vorgehens ist die beliebige Reihenfolge, in der die Komponenten in die Testumgebung eingebracht werden können. Andererseits ist die Backbone-Struktur explizit zu entwickeln, was einem gewissen Zusatzaufwand im Voraus entspricht.

3.4.4 Systemtest

Funktionstest des Gesamt-

systems aus Sicht des Kunden

Beim Systemtest wechselt die Perspektive der Absicherung: Testziel ist, die Leistung des gesamten Systems aus Sicht des späteren Kunden oder Anwenders zu prüfen. Allerdings liegt noch nicht das finale Produkt vor und der Test erfolgt auch nicht in der späteren realen Zielumgebung. Während des Tests orientiert man sich an der Anforderungsspezifikation des Systems, wir haben also einen Funktionstest vor uns.

Ziele des Systemtests

Der Systemtest erfordert eine möglichst realistische Stimulation des Systems von außen, um das SUT auch in großer Realitätsnähe erproben zu können. Als wichtigstes Ziel des Systemtests ist also die Validierung anzusehen, ob und wie gut das fertige System die funktionalen und nichtfunktionalen Anforderungen der Spezifikation erfüllt. Fehler und Mängel aufgrund falsch, unvollständig oder im System widersprüchlich umgesetzter Anforderungen sollen aufgedeckt werden. Spezifikationslücken sollen gefunden werden.

Der Systemtest ist eine gute Gelegenheit,

Defizite der Spezifikation zu beheben.

Wurde es im Rahmen der Spezifikationsphase versäumt, die entstehenden Dokumente zu konsolidieren und nach Klärung mit allen relevanten Projektbeteiligten auf Konsistenz und Vollständigkeit zu prüfen, muss dies nun beim Systemtest nachgeholt werden. Der Systemtest muss also unter Umständen nicht nur fehlende Anforderungen sammeln, sondern auch noch Klärungs- und Entscheidungsprozesse, die viele Monate unterblieben sind, zu einem eigentlich viel zu späten Zeitpunkt herbeiführen.

Systemtest bei agilen oder itera-

tiven Entwicklungsmodellen

Auch Projekte, die agil oder iterativ arbeiten, sehen sich damit konfrontiert, dass ihre Anforderungsbasis unvollständig oder widersprüchlich sein kann. Das Risiko, dass deshalb das Gesamtprojekt scheitert, ist aber als geringer einzuschätzen als bei sequenziellen Entwicklungsmodellen. Letztlich nutzen agile und iterative Vorgehensmodelle jede Iteration zur Validierung des Projektzwischenstands gegen die Kundenanforderungen.

Testbasis

Als Testbasis für den Systemtest dienen alle Dokumente oder Informationen, die das Testobjekt auf Systemebene beschreiben. Dies können Lastenhefte, anderweitige Spezifikationen, Benutzerhandbücher, aber auch Risikoanalysen sein.

Die Testumgebung muss der späteren Produktivumgebung der Software möglichst nahekommen. Statt Testtreibern und Stubs müssen also auf allen Ebenen die später tatsächlich eingesetzten Hardware- und Softwarekomponenten im Testsystem installiert sein. Dies beinhaltet ggf. auch Interfacesoftware, das Netzwerk oder anderweitige Fremdsoftwaresysteme.

den Systemtest nicht in der Produktiv-

umgebung durchführen!

Um die Kosten für die Bereitstellung einer separaten Testumgebung zu sparen, wird oft der Fehler begangen, den Systemtest in der Produktivumgebung durchzuführen. Dies birgt die Gefahr, dass die Produktivumgebung des Kunden beeinträchtigt wird. Teure Systemausfälle auf Kundenseite können die Folge sein. Zudem haben Tester nur geringe Kontrolle über Konfigurationen und Parameter der Produktivumgebung des Kunden. Wichtige Randbedingungen des Tests werden unter Umständen schleichend und unbemerkt verändert.

eine Aufwandsbetrachtung

Der Aufwand eines hinreichenden Systemtests kann durchaus erheblich sein und sollte nicht nur »als letzte Schleife« betrachtet werden. Analysen [20] zeigen, dass bei Beginn des Systemtests erst etwa die Hälfte der Test- und Qualitätssicherungsarbeiten geleistet sind.

Spezifika in der Automobiltechnik

In der Automobiltechnik erfolgt ein Systemtest der E/E-Komponenten im Fahrzeug oder in einem Hardware-in-the-Loop-(HiL-)Labor. Die zu testenden Steuergeräte liegen real vor, das gesamte umgebende »Restfahrzeug« wird in Echtzeit simuliert bis hin zur gesamten Aktorik und Sensorik. Auf diese Weise verhalten sich Steuergeräte exakt wie im Fahrzeug, ein Labor verfügt aber über bessere analytische Möglichkeiten als eine Testumgebung im Fahrzeug. Das Verhalten des virtuellen Fahrzeugs kann gezielt für die Durchführung spezifischer Tests eingestellt werden.

Wichtig für den Systemtest ist also die Sicht von außen und dies erfordert den Betrieb des Systems in seiner realen (Fahrzeug) oder in einer realitätsnah simulierten (HiL-Labor) Umgebung.

Abb. 3-12: Steckbrief Systemtest in der klassischen SW-Entwicklung

3.4.5 Produkttest

erster Test in der späteren Zielumgebung

Unter einem Produkttest versteht man rein funktional einen Systemtest in der realen Zielumgebung. In der Automobiltechnik ist dies z. B. eine kundennahe Fahrerprobung im realen Fahrzeug. Das zu testende Steuergerät wird hierbei im realen Fahrbetrieb durch Testingenieure des Automobilherstellers im Zielfahrzeug erprobt. Die analytischen Möglichkeiten sowie die Reproduzierbarkeit sind eingeschränkt, aber letztlich haben wir hier den finalen Fahrversuch vor uns, der trotz aller simulativen Möglichkeiten immer stattfinden muss.

Abb. 3-13: Steckbrief Produkttest in der klassischen SW-Entwicklung

3.4.6 Abnahmetest