 |
| | | | | Beschreibung | | Um Testen als validierende Tätigkeit von statischen Verifikationsmethoden, wie z. B. der Inspektion, abzugrenzen, verwendet man u.a. den Begriff des "Dynamischen Tests". "Dynamisch" bedeutet in diesem Zusammenhang, dass man die zu prüfende Software mit definierten Eingabedaten und unter kontrollierten Vorbedingungen auf einer bestimmten Hardware-Plattform ablaufen lässt, im Gegensatz zu statischen Methoden, bei denen z. B. eine manuelle Inspektion von Entwicklungsdokumenten durch gezieltes Lesen durchgeführt wird.
Um auf allen Entwicklungs- und Integrationsstufen effizient testen zu können, bedarf es einer passenden Testumgebung. So eine Testumgebung ist auch deswegen notwendig, da außer im System- oder Akzeptanztest typischerweise nur Teile bzw. einzelne Komponenten der Software getestet werden. Die folgende Grafik stellt die grundlegende Struktur einer solchen Testkonfiguration dar:
Abb.: Struktur einer Testkonfiguration.
Die Abkürzung „SUT“ steht in diesem Zusammenhang für den englischen Begriff „System Under Test“, d.h. das SUT ist das zu testende Objekt selbst, und kann eine einzelne Komponente, ein teilintegriertes System, oder auch die komplette Anwendung sein.
Je nach dem schon erreichten Integrationsgrad und der Hierarchieebene der zu testenden Komponente werden mehr oder weniger sog. Platzhalter (engl. stubs) notwendig, um fehlende Teile des Systems zu Testzwecken zu simulieren. Dies ist wichtig, da einzelne Komponenten oder Teilsysteme andere Komponenten aufrufen können, die möglicherweise noch nicht implementiert oder für den Test noch nicht verfügbar sind.
Neben der Kommunikation mit diversen Stubs wird das SUT auch mit der Laufzeitumgebung interagieren, und entsprechende Vorbereitungen (z.B. Installation von Betriebssystem-Modulen) sind vor dem Test zu treffen.
Ein sog. Testtreiber ruft während des Tests das Testobjekt mit den definierten Testfällen auf, nimmt die berechneten Ergebnisse entgegen, führt eine Testauswertung in Form eines zu ermittelnden Verdikt (entweder PASS oder FAIL) durch, und protokolliert die Testläufe.
Der Testtreiber bildet zusammen mit den Stubs und der Laufzeitumgebung den sog. Testrahmen (engl. test bed), in dem das Testobjekt eingebettet ist und dadurch ein ablauffähiges System darstellt.
Bzgl. der Ermittlung der Testfälle existieren prinzipiell zwei grundlegende Ansätze:
Beim Black-Box Verfahren hat der Tester für die Testfallermittlung keinerlei Information über das Innenleben des zu testenden Objekts. Er kann während des Tests auch nicht auf interne Operationen oder Zustände zugreifen, sondern ist an die externen Schnittstellen des Testobjekts gebunden. Diese stellen auch die einzige Möglichkeit dar, das Testobjekt mit Eingabedaten zu beaufschlagen bzw. vor der Testfallausführung in einen wohldefinierten Zustand zu bringen.
Dagegen hat der Tester beim White-Box Verfahren detaillierte Kenntnisse über das Innenleben des SUT. Der Quellcode des Testobjekts ist verfügbar und es können mittels dieser Kenntnisse Testfälle aufgestellt werden. | |
| | | | | | | | | | | | | Zu dieser Seite wurden noch keine Kommentare oder Bewertungen abgegeben. |
|
| | | | |  | Übergeordnet | | | | | | | | | | | Testtechniken | | | | |  | Untergeordnet | | | | | | | | | | | | Weitere Themen | | | | | | | | | | | | | | | | |
|
Glossar 
Forschungsprojekte 
Anbieterverzeichnis 
Datenbanksuche 
Highlights 
Eintrag kommentieren
