7 Auswertung des Systemtests (S. 144-145)

7.1 Zweck der Testauswertung

Die ewige Gretchenfrage des Testens lautet nach wie vor: Wann ist der Test zu Ende? Ab welchem Zeitpunkt kann man aufhören zu testen? Diese Fragen kann man nicht eindeutig beantworten. Im Prinzip kann man jederzeit aufhören. Eigentlich müsste man gar nicht erst damit anfangen, denn das eigentliche Ziel des Testens, alle Fehler zu entfernen und die Korrektheit nachzuweisen ist ohnehin auf diesem Wege unerreichbar, und wenn es erreichbar wäre, wäre es nicht erkennbar, d.h. es handelt sich hier um ein unerkennbares und unerreichbares Ziel. Unerkennbar ist das Ziel, weil, wie im ersten Kapitel dargestellt wurde, es sich nicht feststellen lässt, wie viele Fehler in der Software stecken. Ein Test kann nach Dijkstra nur nachweisen, dass noch Fehler existieren, jedoch nicht, dass keine mehr vorhanden sind [DIJK76].

Es auch nicht klar, was Fehler eigentlich sind. Für den einen ist ein Feature, was für einen anderen ein Fehler ist. Nehmen wir als Beispiel die Rundung arithmetischer Ergebnisse. Fast jeder Compiler rundet anders ab. Für den einen Benutzer ist das Abschneiden der letzten Kommastellen unwesentlich, ihm reichen zwei Kommastellen. Also ist dies ein Feature. Für den anderen Benutzer ist das Verschwinden der hinteren Kommastellen ein grober Fehler.

Ein anderes Beispiel ist die Benutzung von Leerzeichen in Verzeichnis- und Dateinamen. Ein Programm, das einen Verzeichnisnamen bis zum ersten Leerzeichen liest, würde diesen abschneiden und die Datei nicht finden. Der Benutzer betrachtet dies als Fehler. Es könnte aber sein, dass zu der Zeit, als dieses Programm geschrieben wurde, Verzeichnisnamen mit Leerzeichen gar nicht möglich waren. Ergo ist dies kein Fehler [GOEL85]. Die Liste solcher zweideutiger Fälle ist lang. Fehler sind letztendlich das, was der Benutzer als Fehler empfindet bzw. alles, was seinen Erwartungen nicht entspricht. Es gäbe auch eine etwas formalere, juristische Definition. Danach sind Fehler jede Abweichung von der spezifizierten Funktionalität. Dies würde aber voraussetzen, dass jede Funktion einschließ- lich der Ausnahmebehandlung und jede Fehlermeldung in der Anforderungsdokumentation spezifiziert ist. Eine derartige Genauigkeit der Anforderungsdokumentation ist in den meisten Projekten nicht zu erwarten. Was Fehler sind, bleibt also eine Frage der menschlichen Interpretation. Auch wenn es gelingen würde, Fehler genau zu definieren, wüsste man immer noch nicht, wie viele davon in der Software stecken. Wenn wir das wüssten, wüssten wir auch, wo sie sind. Fehler können überall auftauchen – in den Methoden, in den Datenvereinbarungen, in der Speicherverwaltung, in den Schnittstellen zwischen Komponenten, in der Speicherung der Daten sowie in der Erfassung und Präsentation der Daten.

Die Liste der potentiellen Fehlerquellen ist ebenso wie das Universum nicht endlos, aber doch für alle praktischen Zwecke endlos genug – und wie das Universum wächst sie mit jeder technologischen Erneuerung [FRIE02]. Es ist daher aussichtslos, die Anzahl der Fehler ermitteln zu wollen. Wir können sie nur aufgrund bisheriger Erfahrungen schätzen bzw. hochrechnen. Da es nicht möglich ist, die Zahl der Fehler zu kennen, bleibt nichts anderes übrig als den Testfortschritt mit anderen Maßen zu messen. Hierfür bieten sich die Testüberdeckungsmaße an. Es wird getestet, bis ein gewisses Maß an Testüberdeckung erreicht ist. Dies zu ermitteln, ist die Aufgabe der Testauswertung. Die Testauswertung soll dazu dienen, die Testendekriterien aus dem Testplan zu bestätigen. Sie ist somit die Rückkopplung zur Testplanung [PETS85]. Die vordergründige Aufgabe der Testauswertung bleibt jedoch die Fehlererkennung. Die Testergebnisse werden ausgewertet, um ein Fehlverhalten festzustellen. Manchmal sind Fehler offensichtlich, das System bricht ab oder liefert völlig unplausible Ergebnisse. Ein derartiges Fehlverhalten ist leicht zu erkennen. Meistens sind die Fehler aber viel subtiler. Es werden falsche Beträge errechnet oder die verkehrte Adresse gedruckt. Solche Fehler sind nicht auf den ersten Blick zu erkennen. Um sie aufzudecken, müssen die Testergebnisse einer genauen Untersuchung unterzogen werden. Wenn Fehler entdeckt werden, müssen sie genau beschrieben und gemeldet werden. Dazu ist ein Fehlermanagement mit entsprechender Fehlerverfolgung vorzusehen. Die Fehleranalyse ist eine unerlässliche Aktivität im Rahmen der Testauswertung. Schließlich kommt bei allen Aktivitäten der Testauswertung ein Thema zum Vorschein, nämlich jenes der Testmetrik. Es werden Kennzahlen benötigt, um den Korrektheitsgrad zu messen und die Fehlerhaftigkeit der Software in Zahlen auszudrücken. Diese Kennzahlen müssen erhoben, gesammelt, gespeichert und ausgewertet werden. Sie fließen letztendlich in die allgemeine betriebliche Metrikdatenbank ein. Die Testmetrik ist Vorraussetzung für eine Bewertung der Effektivität des Testbetriebs.

Zur Testauswertung gehören also

die Auswertung der Testergebnisse
die Messung der Testüberdeckung
die Fehleranalyse
die Testmetrik (siehe Abbildung 7.1)