Praktisches & Grundsätzliches zur Informatik

Testsuite Architecture, Testtreiber Architektur, Testabdeckung, Testeffektivität

Die Architektur der Testtreiber bestimmt ihren Wert

Grob gesehen gibt es drei Klassen von Testtreibern:

Ganz offensichtlich gilt:

Nebenbei: Wie die großen Wiesen in einem Park hat auch jede Anwendung — was Fehlersuche betrifft — zwei Dimensionen (Sourcecode ist die eine, Daten sind die andere). Vergleicht man jeden Aufruf eines Test­treibers mit dem Absuchen einiger weniger Quadratmeter im 10000-fach größeren Park, so wird klar, wie wichtig es ist, dass nicht jeder Aufruf eines Testtreibers an der gleichen Stelle nach Fehlern sucht.

Konsequenz daraus:

Eine Testsuite der Klasse 3 zu haben ist besonders nützlich, wenn eine dedizierte Testumgebung zur Verfügung steht: Man kann und sollte die Testsuite dann — da sie sich ja ständig selbst modifiziert — wenigstens nachts ununterbrochen aktiv haben. Entsprechend hoch wird die erreichte Testabdeckung sein.

Da auf dem Markt verfügbare Testwerkzeuge nur Treiber der Klassen 1 und 2 unterstützen, muss man sie stets kombinieren mit selbst erstelltem Hilfswerkzeug. Das aber ist nur möglich, wo solche Produkte dem Tester erlauben, den die Testtreiber darstellenden Code einzusehen und zu editieren. Tricentis TOSCA etwa erlaubt das nicht und ist daher eher nur Spielzeug. Hinreichend offen ist HP QuickTest (QTP).

Wo es nur um den Test rein web-basierter Anwendungen geht, könnte man auch Sahi verwenden. So reichhaltig wie das durch QTP unterstützte VBScript ist Sahis Skriptsprache allerdings nicht (man muss im Zweifelsfall in Java implementierte Funktionalität aufrufen, was möglich aber doch eher umständlich ist).
Wissenswertes zu "Testeffektivität, Testabdeckung, Testtreiber Architektur, Testsuite Architecture" zusammengestellt durch Gebhard Greiter.
tags: Klasse1gegreit Treiber1gegreit Testtreiber1gegreit