Stefan Schmerler - Softwaretest in der Praxis

13.3.2 Beschreibung

13.3.3 Tipps

13.4 Kombinatorik und Abhängigkeiten

13.4.1 Steckbrief

13.4.2 Beschreibung

13.4.3 Tipps

13.5 Zustandsbasierter Test

13.5.1 Steckbrief

13.5.2 Beschreibung

13.5.3 Tipps

13.6 Schnittstellentest

13.6.1 Steckbrief

13.6.2 Beschreibung

13.6.3 Tipps

13.7 Kontrollflussorientierter Test

13.7.1 Steckbrief

13.7.2 Beschreibung

13.7.3 Tipps

13.8 Anforderungsbasierter Test

13.8.1 Steckbrief

13.8.2 Beschreibung

13.8.3 Tipps

Abkürzungsverzeichnis

Glossar

Literaturverzeichnis

1 Grundlagen des Testens

Bei der Herstellung aller industriellen Güter gibt es konkrete Anforderungen an die Qualität. Das grundsätzliche Vorgehen bei der Sicherstellung dieser Qualität ist oft die Entnahme von Stichproben, an denen dann geprüft wird, ob alle gestellten Anforderungen erfüllt werden oder ob Abweichungen existieren. Versteht man Software als solches industrielles Gut, so entspricht die Sicherstellung dieser Qualitätsmerkmale hier einem Softwaretest.

Software ist immateriell.

Im Gegensatz zu materiellen Gütern ist Software allerdings immateriell, sie kann nicht angefasst und einer materiellen Prüfung unterzogen werden. Lediglich eine Art optische Prüfung ist in eingeschränktem Umfang durch intensives Gegenlesen der Entwicklungsdokumente möglich.

die Folgen fehlerhafter Software

Dabei können die Folgen fehlerhafter Software durchaus erheblich sein, von einer verspäteten Markteinführung bis zu existenzbedrohenden finanziellen Verlusten und Gefahren für Leib und Leben. Auch ein Imageschaden kann eine negative Konsequenz sein. Beispiele hierfür können der Tagespresse entnommen werden wie z. B. eine fehlerhafte teilautonome Fahrfunktion (»Autopilot«).

stichprobenhafter Charakter

Der Test von Software ist in der Regel eine stichprobenhafte Prüfung durch Ausführung der Software anhand von Testfällen. Die Durchführung eines Testfalls bedeutet hierbei die Ausführung des Testobjekts (der zu testenden Software) anhand spezifischer, durch den Testfall definierter Testdaten (Stimuli).

dynamischer und statischer Test

Je nach Ausprägung des Tests unterscheidet man zwischen dynamischem und statischem Test. Während beim dynamischen Test das Testobjekt ausgeführt wird, erfolgt ein statischer Test durch Prüfung der relevanten Dokumente wie der Anforderungsspezifikation (Lastenheft) der Software oder des Quellcodes.

Validierung und Verifikation

Bei der Frage, ob Anforderungen erfüllt werden, ist relevant, von welcher Seite diese erhoben werden. Handelt es sich um die Prüfung der Anforderungen im Lastenheft, spricht man von einer Verifikation. Die Prüfung, ob sich das System in der späteren Zielumgebung entsprechend den Vorstellungen der Nutzer verhält, wird hingegen als Validierung bezeichnet.

Software ist (fast)

immer fehlerhaft.

Viele Jahre praktischer Erfahrung in der Softwareentwicklung führen leider zu der Erkenntnis, dass fast jede nichttriviale Software fehlerhaft ist. Die Gründe hierfür sind vielfältig. Häufig werden während der Entwicklung und beim Testen bestimmte Ausnahmesituationen nicht bedacht oder überprüft. Seien es etwa eine eigentlich nicht vorgesehene Eingabe des Anwenders oder sehr seltene Systemzustände, die dann aber doch im Laufe der Softwarenutzung eingenommen werden. Fehler kommen auch zustande bei großem Zeitdruck oder hoher Komplexität der zu lösenden Entwicklungsaufgabe oder eingesetzten Technologien. Auch Missverständnisse zwischen den Projektbeteiligten z. B. in Bezug auf Schnittstellen sind häufige Fehlerursachen.

Mit Testen kann man keine

fehlerfreie Software erzielen.

Eine weitere bittere Erkenntnis, die offensichtlich aus dem stichprobenhaften Charakter des Softwaretests folgt: Auch wenn alle durchgeführten Tests keine Fehler mehr aufdecken, kann nicht ausgeschlossen werden, dass andere Tests bislang unerkannte Fehler entdecken würden. Durch Testen kann keine Fehlerfreiheit nachgewiesen werden!

Test und Entwicklung

Der Test von Software und eingebetteten Systemen kann, über den Lebenszyklus betrachtet, als der teuerste, aber auch der am meisten unterschätzte Entwicklungsschritt betrachtet werden. Für die ersten 50 % der Entwicklungsarbeit wie Analyse, Spezifikation oder Implementierung steht ein hervorragender Methoden-, Werkzeug- und Technologiebaukasten zur Verfügung. Wir haben z. B. werkzeugunterstützte Anforderungserfassung und modellbasierte Funktionsentwicklung bis hin zum Fehlermanagement mit vollständiger Durchgängigkeit sogar in großen Konzernen.

Fokus auf den linken Ast

im V-Diagramm

Von der anderen Hälfte der Entwicklungsarbeit – dem Testen – kann man das leider nicht behaupten. Die testmethodische Begleitung wird oftmals stiefmütterlich behandelt – Ausnahmen bestätigen natürlich die Regel. Oftmals wird es der persönlichen Intuition des Entwicklers anheim gestellt, welche Tests durchgeführt werden und welcher Testaufwand und Testabdeckungsgrad vorgesehen werden. Anstelle von klaren Testende-Kriterien tritt ein »gutes Bauchgefühl« und auch die Wahl der Testtechnologie scheint in der Praxis oft willkürlich oder zufällig. Diese Aussagen beziehen sich nicht auf spezifische Industriedomänen oder Anwendungen. Sie beziehen sich auch nicht auf die Entwicklung sicherheitskritischer Systeme, für die besondere Regelungen und Absicherungskonzepte sogar gesetzlich vorgeschrieben sind, deren Einhaltung in Form von Audits auch überprüft wird. Dennoch sind die beschriebenen Phänomene immer noch viel zu oft in der Praxis anzutreffen.

Das Schöne am Testen ist: Man

kann jederzeit damit aufhören –

die Rechnung kommt später.

Eine Ursache hierfür könnte sein, dass mit dem Testen keine unmittelbar ersichtliche Wertschöpfung verbunden ist. Man kann letztlich jederzeit einen Testprozess abbrechen, die Funktion scheint vordergründig ja gegeben. Häufig wird dieser Umstand auch genutzt, um die am Ende fehlende Projektlaufzeit an einen schleppenden Gesamtprojektverlauf »anzupassen«. Oder positiv formuliert: Das Schöne am Testen ist, dass man jederzeit damit aufhören kann. Die Rechnung kommt später …

eine Metrik zur Erfassung

des Reifegrads von Software

Um diesem Problem begegnen zu können, müssen Aussagen über den Reifegrad einer Software getroffen werden – idealerweise durch Nutzung einer Metrik, die reproduzierbare Ergebnisse liefert. Nur auf diese Art und Weise kann ein Testende-Kriterium sinnvoll festgelegt werden.

eine Chronik historischer Softwarefehler

Ferner brauchen Entwickler und Testingenieure einfach anwendbare Methoden und Werkzeuge, die aufgrund der dann hoffentlich hohen Akzeptanz auch tatsächlich zur Anwendung kommen. Hochkomplexe Expertenwerkzeuge oder Testtechnologien laufen Gefahr, im Entwickleralltag nicht oder nur formal eingesetzt zu werden, um gewisse Anforderungen im Entwicklungsprozess zu erfüllen. Die Erfahrung zeigt: Für viele Testprobleme genügt bereits eine einfache, methodisch untermauerte Vorgehensweise, um mit vergleichsweise niedrigem Testaufwand einen signifikanten Reifegradgewinn zu erzielen.