Stefan Schmerler - Softwaretest in der Praxis

Tests sind immer Stichproben ohne

implizites Testendekriterium

Es bleibt festzuhalten, dass Tests einen stichprobenhaften Charakter aufweisen. Selbst bei einer hohen Anzahl fehlerfreier Tests und dem hieraus womöglich resultierenden Testende kann man nie sicher sein, dass nicht bereits der nächste Test einen kapitalen Fehler zutage gefördert hätte! Man benötigt also dringend eine Metrik, die es erlaubt, Qualitätsaussagen oder eine (noch verbleibende) Fehlerneigung numerisch auszudrücken und auf dieser Basis eine fundierte, nachvollziehbare Testende-Entscheidung zu treffen. Auch hierzu mehr im weiteren Verlauf dieses Buchs.

Testmanagement

Doch zurück zur weiteren Klärung des Testbegriffs. Zum Testprozess gehören neben der Ausführung des Testobjekts (z. B. einem eingebetteten System, Funktionsmodell oder einer Bürosoftware) mit Testdaten (Eingabedaten/Stimuli eines zu testenden Programms) auch die Planung, Durchführung sowie die Auswertung/Bewertung der Tests und die Verwaltung aller anfallenden Daten. All diese Vorgänge subsumiert man unter Testmanagement.

Testlauf, Testfall und Testszenario

Ein Testlauf (Test Run) umfasst die Ausführung mehrerer Testfälle. Unter Testfall ist eine konkrete Testdurchführung, d. h. Ausführung des Testobjekts auf einem Rechner mit spezifizierten Testdaten zu verstehen. Zu einem Testfall gehören also exakt festgelegte Randbedingungen. Testfälle können zu Testszenarien aneinandergereiht werden, wobei das Ergebnis eines Testfalls als Eingabe für den folgenden Testfall genutzt werden kann.

Testbedingung

Da eine Testbasis in der Regel eine Fülle an Anforderungen enthält, muss eine strukturierte Aufteilung auf mehrere Testfälle erfolgen. Jeder Testfall fokussiert sich dabei auf bestimmte Teilaspekte der Testbasis, woraus jeweils ein Satz von Testbedingungen (Test Conditions) abgeleitet wird. Jede dieser Testbedingungen ist durch einen oder mehrere Testfälle abzuprüfen.

Testsuite und Testzyklus

Zur weiteren Testausführungsorganisation werden Testsuites eingeführt. Unter einer Testsuite ist die geordnete Aneinanderreihung mehrere Testfälle zu verstehen, die innerhalb eines Testzyklus in einem definierten zeitlichen Muster für die Durchführung eingeplant werden.

Testskript

Im nächsten Schritt werden diese Testsuites dann automatisiert mithilfe von Testskripts ausgeführt. Testskripts sind die ersten Implementierungsinstanzen z. B. in Form ausführbarer Dateien. Hierbei werden alle Testfälle einer Testsuite mit der notwendigen Vor- und Nachbereitung, z. B. der Herstellung der für den Test erforderlichen Vorbedingungen, zur Ausführung gebracht.

Testprotokoll

Nach erfolgter Testdurchführung sind alle Ergebnisse in Testprotokollen zu erfassen, die nicht nur die direkten Testergebnisse, sondern auch alle zum Zeitpunkt der Testausführung geltenden, relevanten Randbedingungen dokumentieren.

Testkonzept

All diese Testaktivitäten und -methoden sowie Vor- und Nachbereitungen werden vor Testbeginn in einem sog. Testkonzept festgelegt. Dieses Dokument beinhaltet u. a. die Beschreibung der zum Einsatz kommenden Testverfahren und Testobjekte, die Festlegung der Testziele, die Art der Testberichterstattung sowie die gesamte Koordination der Testaktivitäten. Gerade der Dokumentation der Vorbereitungsmaßnahmen und Randbedingungen kommt beim Test eine besondere Bedeutung bei:

Ein Test ohne exakte Erfassung aller relevanten Randbedingungen, die zur Zeit des Tests vorlagen, ist nutzlos.

Alle Randbedingungen sind zu er-

fassen und zu dokumentieren!

Dies gilt zum einen, weil der Test andernfalls nicht exakt reproduziert werden kann (z. B. um die Fehlerbeseitigung zu verifizieren), und zum anderen, weil eine spätere Fehleranalyse dann oftmals unmöglich wird. Wir erinnern uns: Die Fehlerwirkung festzustellen ist eine Sache, die genaue Fehlerursache zu ermitteln, eine andere. Hier haben wir es häufig mit Wirkungsketten zu tun, die an einer Stelle initiiert werden und sich an einem gänzlich anderen Ort als Fehlverhalten niederschlagen. Für diese Analyse ist in der Regel die Kenntnis aller Randbedingungen und Details erforderlich.

Fehlerwirkungen treten oft nicht dort in Erscheinung, wo der Fehler verursacht wurde und behoben werden muss.

Fehleranalyse

Die Tätigkeit der Fehleranalyse gleicht akribischer Detektivarbeit, die viele Daten und große technische Expertise benötigt. Häufig ist sie nicht Bestandteil des eigentlichen Testprozesses.

Wie entsteht Komplexität und was

bedeutet das für den Softwaretest?

Bei der weiteren Beschreibung der Gegebenheiten beim Testen von Software muss auf den Begriff der Komplexität eingegangen werden. Wie entsteht Komplexität und welche Konsequenzen hat sie bei Entwicklung und Test von Software?

Stellen wir uns als einfaches Beispiel einen primitiven Rechner vor, bestehend aus einer Benutzerschnittstelle und einer kleinen Recheneinheit, die laut Lastenheft die Aufgabe hat, eine Zahl durch das Produkt zweier weiterer Zahlen zu dividieren.

Die dargestellt Routine wird gestartet, sowie das Gleichheitszeichen angeklickt wird. Und das war es schon, die Benutzerschnittstelle ist getrennt von der Kernfunktionalität und wir haben einen einfachen, übersichtlichen Code vor uns.

Sonderfälle und Fehlerbe-

handlung berücksichtigen

Aber: Dies ist ein außerordentlich fehlerhafter Code! Warum? Was geschieht z. B. bei der Aufgabenstellung 7 / (2 . 0) ? Das Programm gerät in einen undefinierten Zustand, es »stürzt ab« aufgrund einer Division durch null.

Wie ist dies zu verhindern? Das Programm muss die Faktoren im Divisor abfragen und bei einer Null eine Fehlermeldung ausgeben. Dies steigert, wie man sagt, die Robustheit des Programms.

nie darauf verlassen, dass Stimuli

spezifikationskonform erfolgen

Und ist der Programmcode nun fehlerfrei? Nein! Was geschieht, wenn ein Benutzer Buchstaben statt Ziffern eingibt? Das Programm gerät wiederum in einen undefinierten Zustand, wenn eine Berechnung mit Buchstaben vom Programmcode nicht behandelt wird. Schauen wir uns den hieraus resultierenden Code an.

Die reine Funktion ist der geringste

Teil eines hochwertigen Codes aus.

Und ist das Programm denn jetzt fehlerfrei? Sie ahnen es: Nein, es enthält nach wie vor Fehler, die zum Absturz führen können. So hat jeder Rechner Größenbegrenzungen für Zahlen, z. B. wird ein Integer-Wert bei einem Prozessor mit 16 Bit und bei einem anderen mit 32 Bit bearbeitet. Je nach Größe des Zahlenwerts, den man in die GUI eingibt, werden also Speicherbereiche überschrieben – und wieder haben wir ein Problem!

Noch kritischer als falsche An-

forderungens sind vergessene!

Sukzessive ist der Code auf mögliche Fehlerzustände zu untersuchen, die durch fehlerhafte, unplausible oder auch einfach nicht spezifizierte und dann ungünstig verfügte Testdaten hervorgerufen wurden. Und glauben Sie mir: Softwarenutzer sind sehr kreativ im Aufspüren solcher problematischen Daten! Wie so oft haben auch diese Fehlerquellen ihre Wurzeln in unvollständigen Spezifikationen, die dann korrekt umgesetzt wurden. Da keine konkrete Anforderung, wie z. B. die Forderung ganzzahliger Werte, verletzt wurde – es gibt ja keine! – ist es einem funktionalen Testverfahren, wie wir später noch sehen werden, auch nicht möglich, diesen Fehler zu finden.