Automatisierbarkeit von Softwaretests 2

3.2. Grenzen von automatischen Tests
Die Ergebnisse von automatischen Tests sind kritisch zu bewerten, da diese eben nur so aussagekräftig sind, wie sie geschrieben wurden. Durch wird der Entwickler unter Umständen verleitet, sich auf das Testergebnis zu verlassen, statt selbst noch einen manuellen Test durchzuführen, durch den er vielleicht weitere Fehler gefunden hätte. Es ist weiterhin nicht immer sinnvoll, die Tests zu automatisieren, bzw. nur bedingt möglich. So kann z.B. eine grafische Benutzeroberfläche, beispielsweise bei einem Spiel, in dem grafische Elemente zufällig umher fliegen, nicht zuverlässig automatisch getestet werden. Es kann möglicherweise festgestellt werden ob und wie viele Elemente sich bewegen, jedoch kaum ob das so gewollt ist. Hierbei ist es sinnvoller sich auf manuelle Tests zu stützen.
Modulare Software kann besser durch Unit-Tests getestet werden. Je Strukturierter eine Software aufgebaut ist, desto einfacher ist das Erstellen automatischer Tests.

3.3. Sinnvolle Tests
Der automatische Test von Formularen, wie z.B. für die Registrierung oder ein Kontakt formular, kann über Selenium einfach und sinnvoll gestaltet werden. Die Validierung kann durch falsche Eingaben getestet werden. Durch eine zusätzliche Abfrage im System kann auch sichergestellt werden, ob die Validierung doppelte Benutzernamen, bzw. E-Mail-Adressen korrekt erkennt. Es kann außerdem geprüft werden, ob die Seite nach dem erfolgreichen Absenden des Formulars entsprechend angezeigt wird. Hier kann zusätzlich getestet werden, ob die richtige Seite angezeigt wird, falls es mehrere gibt. Dieser Test kann bei jeder Änderung im System ohne großen Aufwand vollautomatisch durchgeführt werden. Wie im Abschnitt 10 beschrieben, könnte dieser Test auch anhand des Änderungslogs aus dem Versionskontrollsystem automatisch ausgeführt werden, wenn sich eine Datei wie z.B. register.php oder contact.php ändert.Ein solcher Test kann vielleicht sogar entsprechen Generisch erstellt werden und für diverse Projekte wiederverwendet werden. Dadurch würde bei anderen Projekten der Zeitaufwand für die Erstellung des Tests entfallen.

3.4. Wie viel testen
Ein weiterer wichtiger Punkt ist zu entscheiden, wie lange getestet werden soll. Weniger zu testen spart zwar momentan Zeit, jedoch ist das beheben von Fehlern, die nach der Auslieferung der Software gefunden werden, deutlich aufwendiger und teurer. Der Anwender ist auch nicht erfreut, wenn er als unbezahlter Tester eingesetzt wird. Zudem ist die Fehlerkorrektur am Livesystem gegebenenfalls mit Ausfallzeiten verbunden. Zu viel Testen macht die Software vielleicht unnötig Teuer und eventuell sogar veraltet, bevor sie zum Einsatz kommt. Daher muss ein Mittelmaß gefunden werden, wie lange die Software getestet werden soll. Hierbei kommt es darauf an, das Restrisiko für Fehler zu minimieren. Auch die Entscheidung, wie viele Tests für eine Software geschrieben werden sollen muss bedacht getroffen werden. 100%-ige Abdeckung des Quellcodes durch Tests ist unnötig, sehr  aufwändig und kaum realisierbar. Daher sollte die gewünschte Testabdeckung einer Software im Vorfeld festgelegt werden.

4. Vorteile automatisierter Tests
Automatisierte Tests haben diverse Vorteile gegenüber manuellen Tests. So kann deren Ausführung nach jeder Änderung im Programm erneut gestartet werden und die gesamte Software auf neue Fehler untersucht werden. Bei großen Projekten kann es nötig sein, die Tests selektiv auszuführen, da der gesamte Test zu aufwändig wäre, wie im 7. Abschnitt genauer beschrieben.

nächster Teil

Dieser Beitrag wurde unter Sonstiges, Webserver abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.