Testen auf Knopfdruck

Anbieter zum Thema

MicroConsult Academy GmbH

Heitec AG

ISH Ingenieursozietät GmbH

Method Park Software AG

Nach der Einarbeitungs- und Implementierungsphase konnten erste Erfolge erzielt werden: Viele Systemtests waren automatisiert. Besonders hilfreich waren Smoke-Tests, die nach jeder Installation einer neuen Software-Version die Basisfunktionen überprüfen, und Longrunner, die die Dauerbelastung des Systems testen. Um allerdings nicht nur den vielzitierten „teuersten Bildschirmschoner der Welt“ zu entwickeln, bei der sich der Mauszeiger wie von Geisterhand bewegt, sondern wirklich gute und hilfreiche Test-Software, waren einige Hürden zu überwinden.

Zunächst darf man nicht auf schnelle Ergebnisse schielen. Es sollte nicht versucht werden, zur Beruhigung der Projektleitung „Masse statt Klasse“ zu erzeugen. Die Anzahl der automatisierten Testfälle ist gerade in der Anfangsphase als Fortschrittsmetrik ungeeignet. Früh entstandene Testskripte müssen oft in stupiden Wartungsarbeiten nachgebessert werden. Das kostet Zeit und dämpft die Begeisterung für die Testautomatisierung.

Will man ein ständiges Überarbeiten der Testskripte vermeiden, muss man darauf achten, dass das weiterentwickelte ramework abwärtskompatibel bleibt und gut dokumentiert wird. Außerdem sollten logische Namen verwendet und veränderliche Namen nur an einer Stelle stehen und dort gepflegt werden.

Ebenso darf man das Kosten-Nutzen-Verhältnis nicht außer acht lassen. Es ist unsinnig, alles automatisieren zu wollen. Für neue oder sich häufig ändernde Funktionen ist das manuelle Testen besser geeignet, da der menschliche Tester flexibler reagiert und sehr viel implizit mittestet. Bei den Testprogrammen muss erst ein aufwändiger Synchronisationsmechanismus eingebaut werden, damit nicht mitten im Ladevorgang versucht wird, die Bilder zu bearbeiten. Auch könnten noch störende Dialoge vom vorherigen Testfall offen sein.

Acht Regeln für die Testautomatisierung

Während ein Bild vom Auge schnell erfasst wird, ist beim automatisierten Test ein Referenzbild nötig. Beim Bildvergleich sollten veränderliche Bildteile maskiert werden oder die Zahl der erlaubten, differierenden Pixel einstellbar sein, um kleinere Abweichungen zu tolerieren.

Bei einem nichtbestandenen Testfall kann die Fehlerquelle auch im Code des Test-Frameworks liegen, im Testskript oder veralteten Referenzbildern. Diese Fehlersuche ist mitunter sehr Zeit raubend und unterstreicht die Notwendigkeit von aussagekräftigen Fehlermeldungen im Code und der Qualitätssicherung der Testprogramme. Genauso wichtig sind robuste Testskripte, die auftretende Fehler abfangen und stabil weiterlaufen.

(ID:322144)