Die Architektur der Testtreiber bestimmt ihren Wert

Grob gesehen gibt es drei Klassen von Testtreibern:

• Treiber der Klasse 1 sind solche, die bei jedem Aufruf die Anwendung in exakt gleicher Weise triggern mit jeweils denselben Daten.
• Treiber der Klasse 2 sind solche, die bei ihrem Aufruf einer CSV-Datei entnehmen, wie und mit welchen Daten sie die Anwendung zu triggern haben.
• Treiber der Klasse 3 schließlich errechnen diese CSV-Datei zudem noch selbst und zwar ihrem Inhalt nach in Abhängigkeit einer Zeitangabe (und vielleicht weiterer Parameter).
  
  

Ganz offensichtlich gilt:

• Jeder Treiber der Klasse 1 ist ein Programm, welches entweder von Hand programmiert oder über geeignetes Werkzeug von Hand im Dialog definiert werden muss. Dies zu tun verursacht i.A. weit mehr Aufwand als lediglich eine weitere CSV-Datei zu schreiben, die ein schon existierender Treiber der Klasse 2 akzeptiert.
• Anwendungsfehler — die zu finden eine Testsuite da ja ist — sind ähnlich verteilt wie Hundehaufen in einer großen Parkanlage: weit verstreut, aber doch so häufig anzutreffen, dass sie Ärger verur­sachen. Da Klasse 1 Treiber an stets derselben Stelle nach Fehler suchen, ist ihr Wert begrenzt.
• Treiber der Klasse 2 sind da schon besser: Je nachdem, welche CSV-Datei man ihnen beim Aufruf mitgibt, suchen sie an entsprechend anderer Stelle.
• Um Welten wirkungsvoller aber sind Testtreiber der Klasse 3: Bei ihnen bestimmt ein Zeit­parameter die Stellen, an denen man "Hundehaufen" sucht (sprich: Fehler der Anwendung). Auch die Arbeit, zu jedem Treiber zahlreiche CSV-Dateien zu erstellen, zu verwalten und ständig neuen Versionen der Anwendung anzupassen, entfällt: Zu pflegen ist nur der sie produzie­rende Generator.
  
  

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:

• Der Aufwand, eine Testsuite der Klasse 1 zu bauen, ist proportional zu ihrem Umfang, steigt also linear.
• Gleiches gilt für Testsuiten der Klasse 2, doch wird hier vergleichbarer Nutzen mit weniger Aufwand erreicht (80 bis 90 Prozent aller Treiber sind ersetzt durch einfache CSV-Dateien).
• Übergang zu Klasse 3 Treibern reduziert das Kosten/Nutzen-Verhältnis noch weit dramatischer: Fast aufwandsneutral wird die Testsuite deutlich effektiver.
  
  

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).



stw5077KTT — Klasse . Treiber . Testtreiber — News?

Mehr + B G E + S H A + More