> ## Documentation Index > Fetch the complete documentation index at: https://docs.baenninger.me/llms.txt > Use this file to discover all available pages before exploring further. # Grundlagen Der dynamische Test beschreibt die Prüfung des Testobjekts durch dessen Ausführung auf einem Rechner. Damit ein dynamischer Test durchgeführt werden kann, muss ein ablauffähiges Programm vorliegen. In den unteren Teststufen (Komponenten- und Integrationstest) ist das Testobjekt oft noch nicht als eigenständiges Programm lauffähig. Es muss daher in einen Testrahmen (*Test Bed*) eingebettet werden, um die Ausführung zu ermöglichen. Abbildung Treiber und Platzhalter bilden zusammen den Testrahmen, der mit dem Testobjekt zusammen das ablauffähige Programm ergibt. ## Unterschied zum statischen Testen Der wesentliche Unterschied zwischen statischen und dynamischen Tests liegt in der Ausführung des Testobjekts. Während beim statischen Test Dokumente und Programmtext ohne eine Ausführung auf einem Rechner geprüft werden, setzt der dynamische Test ein ablauffähiges Programm voraus, das mit Testdaten versorgt und tatsächlich ausgeführt wird. Statische Tests können auf alle Arten von Arbeitsergebnissen (Anforderungen, Entwürfe, Quellcode, Verträge, Benutzerhandbücher) angewendet werden. Dynamische Tests konzentrieren sich ausschliesslich auf den ausführbaren Programmcode. Statische Tests entdecken Fehlerzustände (Defekte) direkt im Dokument. Dynamische Tests weisen dagegen Fehlerwirkungen (Ausfälle) nach, also die sichtbaren Konsequenzen von im Code verborgenen Fehlerzuständen. Statische Verfahren können sehr früh (z.B. direkt nach der Erstellung einer Spezifikation) eingesetzt werden. Dynamische Tests können erst durchgeführt werden, wenn ein ausführbares Programmfragment vorliegt. Statische Tests bewerten vor allem die innere Qualität und Wartbarkeit (Struktur, Einhaltung von Standards). Dynamische Tests messen Eigenschaften, die erst zur Laufzeit sichtbar werden, wie Performanz, Antwortzeiten oder das Ressourcenverhalten. ## Vor- und Nachteile * Realitätsprüfung * Sichtbarkeit von Fehlwirkungen * Messbarkeit *** * Späterer Start * Aufwendige Diagnose * Infrastrukturbedarf ## Elemente des Testrahmens Das Testobjekt ist die Komponente oder das (Teil-)System, das getestet wird. Es wird mit Eingabedaten versehen und zur Ausführung gebracht. Ein Testtreiber ist ein Testwerkzeug oder ein speziell entwickeltes Programm, das das Testobjekt aufruft und/oder steuert. Der Treiber muss das Testobjekt mit den Eingabedaten versorgen. Das Testobjekt ruft meist weitere Programmteile über definierte Schnittstellen auf. Wenn diese Teile noch nicht implementiert oder nur simuliert werden sollen, werden sie durch Platzhalter (Stubs) realisiert. Platzhalter simulieren das Ein-/Ausgabeverhalten des eigentlich aufzurufenden Programmteils. Die gesamte Umgebung, in der der Test abläuft, umfasst die benötigte Hardware, Simulatoren, Softwarewerkzeuge und weitere unterstützende Hilfsmittel. Das Testobjekt erzeugt Ausgaben. Die Ergebnisse des Testlaufs sind zu protokollieren. Das tatsächliche Ergebnis wird mit dem erwarteten Ergebnis verglichen, um Abweichungen und Fehlerwirkungen festzustellen. ## Blackbox- und Whitebox-Testverfahren Zur systematischen Erstellung von Testfällen beim dynamischen Testen werden Testverfahren in zwei Hauptkategorien eingeteilt. Blackbox Whitebox ### Blackbox-Testverfahren Blackbox-Verfahren werden auch spezifikationsbasierte oder verhaltensgesteuerte Verfahren genannt. Die Testfälle werden aus der Spezifikation oder Anforderungsbeschreibung abgeleitet. Das Testobjekt wird als »schwarzer Kasten« angesehen; Informationen über den Programmtext und den inneren Aufbau sind nicht erforderlich. Der Point of Control (PoC) (Steuerung) und der Point of Observation (PoO) (Beobachtung) liegen ausserhalb des Testobjekts. Diese Verfahren konzentrieren sich auf die Eingaben und Ausgaben des Testobjekts. ### Whitebox-Testverfahren Whitebox-Verfahren werden auch strukturelle oder strukturbasierte Verfahren genannt. Die Testfälle werden aufgrund der Programmstruktur (Programmcode oder detaillierte Spezifikation) gewonnen. Diese Verfahren fokussieren auf die Struktur und die Abläufe innerhalb des Testobjekts. Der PoO (Beobachtung) liegt innerhalb des Testobjekts, da der innere Ablauf analysiert wird. In Ausnahmefällen kann der PoC (Eingriff in den Ablauf) auch innerhalb des Testobjekts liegen. Ein nachzuweisender Überdeckungsgrad (z. B. 80 % aller Anweisungen des Testobjekts sollen überdeckt werden) wird angestrebt. Das primäre Anwendungsgebiet liegt im Komponententest bzw. dem Test der API der zu testenden Komponenten.