Stefan Schmerler - Softwaretest in der Praxis

All dies ist festzulegen, bevor der erste Test ausgeführt wird. Nur so kann man der Gefahr entgehen, in der Endphase eines Projekts vor der vollendeten Tatsache eines Ressourcenmangels zu stehen und als einzig jetzt noch verbleibende Option den Test vorzeitig abbrechen zu müssen. Ohne vorherige Planung ist man gegen derartige Überraschungen nicht gefeit und bei Feststellung des Sachverhalts ist kein Gegensteuern mehr möglich – dies hätte früher erfolgen müssen.

Abb. 3-17: Steckbrief Testplanung

3.5.2 Testspezifikation

Die Testspezifikationsphase beginnt, sobald die Spezifikation des SUT (Lastenheft) und der Testplan zur Verfügung stehen. In dieser Phase geht es darum, abstrakte Testfälle, sog. Testspezifikationen, zu ermitteln. Diese Testspezifikationen beinhalten in aller Regel eine überwiegend nichtformale, verbale Beschreibung, wie der Test abläuft, welche Randbedingungen zu Beginn herzustellen sind und welches Sollverhalten abzuprüfen ist. Die Festlegung auf eine konkrete Testausführungsplattform erfolgt noch nicht.

Beispiel: Kaffeeautomat

Beim Test eines Kaffeeautomaten könnte man sich z. B. folgende Testspezifikation vorstellen: »Der Automat ist voll bestückt und funktionsbereit. Der Kunde wirft mindestens eine Münze ein und drückt eine Kaffeewahltaste. Der Zahlbetrag ist allerdings nicht ausreichend. Eine Kaffeeausgabe darf nicht erfolgen, der Automat wartet auf eine weitere Münzeingabe oder Betätigung der Rückgabetaste.« Dies wäre ein Test für die Anforderung im Lastenheft »Unter keinen Umständen darf eine Produktausgabe bei Unterzahlung erfolgen«. Anforderung und Testspezifikation sind einander zugehörig, die Testumgebung muss die Möglichkeit einer Referenzierung bzw. Verlinkung in geeigneter Weise unterstützen.

Tracing

Den Vorgang dieser Referenzierung assoziierter Testartefakte bezeichnet man auch als Tracing. Tracing wird z. B. eingesetzt, um Tests mit den resultierenden Testergebnissen in Verbindung zu setzen.

Testspezifikationen sind abstrakt

und implementierungsunabhängig

Testspezifikationen sind als abstrakte Testfälle zu verstehen, d. h. sie sind noch eine Vorstufe der Testimplementierung. Der Testplaner hat sich noch nicht festgelegt, wie und auf welchen Testplattformen der Test ausgeführt werden soll. Im obigen Beispiel könnte man sich vorstellen, dass bei Ausführung ein Testkunde vor dem Automaten steht und diesen bedient (eine Implementierung) oder der Mikrocontroller, auf dem die Steuerung implementiert ist, im Labor durch eine Testumgebung stimuliert wird (eine andere Implementierung). Merken wir uns, dass eine Testspezifikation mehrere Implementierungen aufweisen kann, die miteinander in Beziehung stehen.

Abb. 3-18: Steckbrief Testspezifikation

Black-Box- und White- Box-Test

In der Praxis gibt es mehrere Methoden für die Testspezifikation, zwei wichtige Vertreter sind als Black Box und White Box bekannt. Kennt oder beschreibt man bei der Testspezifikation nur das von außen beobachtbare Verhalten des SUT, also nur die Ein-/Ausgabe auf oberster Ebene, spricht man von einem Black-Box-Test. Sind auch die inneren Strukturen des SUT (z. B. der Quellcode oder ein Kontrollflussgraph) bekannt und nehmen Tests Bezug darauf, liegt ein White-Box-Test vor.

kein Test ohne Testspezifikation!

Es sei an dieser Stelle nochmals an die besondere Bedeutung der Testspezifikation hingewiesen. Da sie implementierungsunabhängig ist, besteht hier die Möglichkeit der Wiederverwendung und dadurch der Kostensenkung. Eine Testspezifikation kann jeder verstehen, ein Testprogramm nicht unbedingt, d. h. Testspezifikation und Testimplementierung können von unterschiedlichen Personengruppen durchgeführt werden. Dies gilt es bei komplexen Testaufgaben auszunutzen. Niemals sollte man den Testprozess direkt mit einer Testimplementierung beginnen, so groß die Versuchung auch sein mag.

3.5.3 Testimplementierung

Wie im Abschnitt Testspezifikation bereits ausgeführt, basieren Testimplementierungen auf Testspezifikationen, sie bilden konkrete Instanzen der allgemeineren Spezifikationen und ermöglichen damit erst die Ausführung eines Tests. Grundsätzlich können aus einer Testspezifikation mehrere Testimplementierungen hervorgehen.

eine Testspezifikation, mehrere

Testimplementierungen

Zu einer Testimplementierung gehören auch die Auswahl geeigneter Testdaten sowie die Darstellung einer konkreten, ausführbaren Testvorschrift – also der detaillierte Ablauf des Tests. Dieser kann entweder manuell, Schritt für Schritt, erfolgen oder automatisiert, indem Testskripts mit den einzelnen Testschritten ausgeführt werden. Die Testimplementierung selbst ist stark abhängig vom geplanten Testsystem und lässt sich in der Regel nicht von einer Testplattform auf eine andere übertragen.

Abb. 3-19: Steckbrief Testimplementierung

Die Implementierungsplattformen reichen hierbei von einer Abfolge manueller Fahrinstruktionen bis hin zum vollautomatisierten Testskript eines HiL-Simulators.

Neben der Festlegung der einzelnen auszuführenden Testschritte (Testvorschriften) sind auch die zur Anwendung kommenden konkreten Testdaten sowie die zu erwartenden Testergebnisse (Sollwerte) zu spezifizieren.

Ein Test ohne Kenntnis aller rele-

vanten Randbedingungen ist nutzlos.

Wichtig bei einer Testimplementierung ist die exakte technische Einstellung der Randbedingungen, die zu Testbeginn laut Testspezifikation vorliegen müssen. Ein Test ohne Kenntnis aller relevanten Randbedingungen ist nicht reproduzierbar, erlaubt keine Fehleranalyse und ist daher nutzlos!

3.5.4 Testausführung

Endlich ist es soweit: Der Test wird ausgeführt!

Schön wäre Automatisierung, unerlässlich die

Dokumentation aller Randbedingungen.

Die Phase der Testausführung beginnt mit der Verfügbarkeit des Testobjekts bzw. der Testimplementierung. Oft ist diese Phase aufgrund einer hohen Anzahl von auszuführenden Tests automatisiert. Die Testumgebung stellt die erforderlichen, spezifizierten Randbedingungen her, stimuliert das Testobjekt mit Eingangsdaten entsprechend der Testspezifikation und erfasst die Ergebnisse. Ergebnisse, Stimuli und Randbedingungen müssen lückenlos dokumentiert werden. Auf diese Weise wird die Wiederholbarkeit und Reproduzierbarkeit der Tests ermöglicht. Dies sicherzustellen, ist von besonderer Bedeutung auch im Hinblick auf die zu wartenden Regressionstests zur Absicherung von nachträglichen Codeänderungen bei Fehlerbeseitigung, Wartung oder Weiterentwicklung der Software. Diese sollte auf jeden Fall automatisiert erfolgen. Ferner wird dokumentiert, wann und durch wen der Test ausgeführt wurde.

Abb. 3-20: Steckbrief Testausführung

3.5.5 Testevaluierung

Testurteile Pass oder Fail

Bei der Testevaluierung findet der Vergleich zwischen Testergebnis und Sollwert statt. Entsprechend wird das Urteil Pass oder Fail gefällt. Defects werden im Defect-Management-System des Unternehmens eingetragen, die aus Fehlern resultierenden Fehlerkorrekturen im sog. Change-Management-System.