Benutzer:Bernd Wolfram/Softwaretests
Um die Qualität in Softwareprojekten zu ermitteln stehen einige Testmethoden zu Verfügung. Im Rahmen der IEEE Initiative SWEBOK (Software Engineering Body of Knowledge) werden die Testmethoden in Klassen eingeteilt:
- Nach der Art wie Tests generiert werden (zum Beispiel nach Erfahrung des Testers, Spezifikationen, Code Struktur...)
- Nach der Transparenz der Software
Im folgenden wird auf die zweite Gruppe eingegangen. Diese beinhaltet, ob Tests von Informationen über Design und Code abhängen (Whitebox), von Ein- und Ausgabeverhalten ohne Wissen über innere Abläufe (Blackbox) oder Kombinationen eingesetzt werden.
Allgemeines[Bearbeiten | Quelltext bearbeiten]
Eine Teststrategie ist ein Algorithmus oder eine Heuristik um aus einer Repräsentation, einer Implementation oder einem Testmodell Testfälle zu erzeugen. Dieser Vorgang wird Testdesign genannt. Ein Testmodell zeigt die Beziehungen zwischen den Elementen der Repräsentation oder Implementation. Typischerweise basiert dieses Modell auf einem Fehlermodell. Testdesign beinhaltet typischerweise drei Schwerpunkte:
- Identifikation geeigneter Funktionspunkte
- Platzieren der Punkte in einer Testsequenz und
- Definierung des zu erwartenden Ergebnisses für jeden Punkt der Sequenz.
Die Effektivität eines Testes entspricht der relativen Fähigkeit der Teststrategie Fehler zu finden. Testeffizienz beschreibt die relativen Kosten um einen Fehler zu finden (Absatz übersetzt aus Robert V. Binder ([1])).
Whitebox - Test[Bearbeiten | Quelltext bearbeiten]
Beim Whitebox - Test (auch Glassbox - Test) ist der Programmcode sichtbar; das Programm ist wie eine Maschine im gläsernen Gehäuse, deren Arbeit man von außen nicht direkt beeinflussen, aber beobachten kann. In jedem Whitebox Test geht es darum, beim Testen bestimmte, auf den Code bezogene Überdeckungen zu erreichen. Beispielsweise kann das Ziel sein, eine Anweisungsüberdeckung von 80% zu erzielen. Dann wird getestet, bis 80% der ausführbaren Befehle im Programm mindestens einmal ausgeführt wurden. Um festzustellen, ob dieses Ziel erreicht ist, braucht man unbedingt ein Werkzeug, das den Prüfling instrumentiert, d.h. mit zusätzlichen Anweisungen ausrüstet, die die notwendigen Zählungen realisieren. Die Zählerstände werden über beliebig viele Programmabläufe akkumuliert und auf Wunsch in einer anschaulichen Form angezeigt; beispielsweise können alle Teile des Programms, die noch nie ausgeführt wurden, mit einer speziellen Farbe markiert sein. Dann kann man untersuchen, wie die Testfälle beschaffen sein müssten, um diese „weißen Flecken auf der Landkarte“ zu beseitigen (laut Jochen Ludewig, Horst Lichter ([2])).
Überdeckungskriterien für den Whitebox Test
Die Anweisungsüberdeckung ist erreicht, wenn alle Anweisungen des Programms ausgeführt werden. Die Zweigüberdeckung ist erreicht, wenn bei allen Verzweigungen des Programms alle möglichen Wege (Zweige) durchlaufen wurden. Die Terminüberdeckung(Bedingungsüberdeckung) ist erreicht, wenn jeder logische Term, der den Ablauf in einer Verzweigung steuert, mit beiden möglichen Werten (true und false) wirksam geworden ist. Die Pfadüberdeckung ist die Anzahl der ausgeführten Pfade an der Gesamtzahl der Pfade. Sie spielt in der Praxis eher keine Rolle. Wenn das zu messende Programm eine WHILE Schleife einschließt, ist die Zahl der Pfade im Allgemeinen nicht definiert. Somit kann die Gesamtzahl der Pfade nur in Spezialfällen ermittelt werden.
Blackbox - Test[Bearbeiten | Quelltext bearbeiten]
Der Blackbox - Test verbirgt Programmcode und innere Struktur vor dem Softwaretester. Die Softwarekomponente wird anhand der Eingabe und Ausgabewerte analysiert. Die dazwischenliegenden Verarbeitungsschritte werden außer Acht gelassen. Diese Art der Analyse ist gröber als der Whitebox Test, ist aber bei Objektorientierten- oder Komponentenumsetzungen hilfreich, da in diesen Fällen der Code nicht zugänglich ist.
Die Ziele des Blackbox Tests
Laut Jochen Ludewig, Horst Lichter ([2]) sollte ein umfassender Blackbox Test folgendes erreichen:
- alle Funktionen des Programms aktivieren (Funktionsüberdeckung),
- alle möglichen Eingaben bearbeiten (Eingabeüberdeckung),
- alle möglichen Ausgabeformen erzeugen (Ausgabeüberdeckung),
- die Leistungsgrenzen ausloten,
- die spezifizierten Mengengrenzen ausschöpfen,
- alle definierten Fehlersituationen herbeiführen.
Die Funktionsüberdeckung geht von der Menge der Funktionen aus, die ein Programm anbietet. Die Eingabeüberdeckung ist auf die Menge möglicher Eingaben, die Ausgabeüberdeckung auf die Menge möglicher Ausgaben.
Greybox - Test[Bearbeiten | Quelltext bearbeiten]
Mittels Greybox - Test wird versucht, die Vorteile des Whitebox- und Blackbox - Tests zu nutzen. Spezifikationsansätze, welche den Zustand vor der Operationsausführung mit dem Zustand nach der Operationsausführung vergleichen (Blackbox), können nicht mit „callbacks“ umgehen. Ein “callback” ist ein Mechanismus, welcher Ergebnisse erst nach Eintritt bestimmter Ereignisse an das Programm liefert. Die Sequenz dieser externen Aufrufe und die entsprechenden Zustände können nicht erfasst werden. Die Verwendung von Whitebox – Tests erlaubt zwar besseren Umgang mit „callbacks“ aufgrund der vorhandenen Implementationsdetails, die große Anzahl dieser führt jedoch zu erhöhter Komplexität und Testeinschränkungen. Als Abhilfe kann eine strikt getrennte Mischung der Whitebox und Blackbox Konzepte angewendet werden, aber auch eine stufenlose (Greybox). Hierbei werden externe „callbacks“ durch Schnittstellen Spezifikationen der einzelnen Komponenten erkannt und abstrakte Programme mit ähnlichen Eigenschaften anstatt Blackboxes getestet (Reverse Engineering). Dies kann durch die Definition von Greybox – Spezifikationsregeln für vorhandene Entwicklungssprachen weiter unterstützt werden. Weitere Vorteile von Greybox Tests sind kürzerer Quellcode und somit verbesserte Lesbarkeit sowie gute Skalierung.
Quellen[Bearbeiten | Quelltext bearbeiten]
Weblinks[Bearbeiten | Quelltext bearbeiten]
- The Greybox Approach: When Blackbox Specifications Hide Too Much
- Software Engineering Body of Knowledge
Literatur[Bearbeiten | Quelltext bearbeiten]
- ↑ Robert V. Binder: Testing Object - Oriented Systems: Models, Patterns, and Tools , Addison Wesley Longman, 1999. ISBN 0-201-80938-9
- ↑ a b Jochen Ludewig, Horst Lichter: Software Engineering: Grundlagen, Menschen, Prozesse, Techniken , dpunkt.verlag, Heidelberg 2007. ISBN 3-89864-268-2