Suchen

Qualitätssicherung in der Software-Entwicklung

Softwaretests mit Augenmaß

Seite: 2/3

Firma zum Thema

Grundlage der automatischen oder programmgesteuerten Testdurchführung ist also eine Funktionalität, die Augen (künftig sicher auch Ohren und Tastsinn) und Finger (Mund) des Menschen ersetzt wie zum Beispiel „Ranorex“ oder Microsofts „Visual Studio 2010“, um zwei Hilfsmittel mit unterschiedlichen Ansätzen zu nennen.

Beide haben einen Recorder zum Mitschneiden von Bedienabläufen, Methoden zum Identifizieren der Objekte und einen Player zum „Abspielen“ der Tests und zur Erstellung eines detaillierten Ablaufprotokolls. „Visual Studio 2010“ kann darüber hinaus Testpläne erstellen und Testdaten und Testergebnisse verwalten. Das Testgeschehen selbst wird vollständig in virtuelle Maschinen ausgelagert. Das Testprogramm und die Entwicklungsumgebung beeinflussen die Testdurchführung also nur geringfügig, und der Systemzustand im Fehlerfall kann zur Diagnose „eingefroren“ und dokumentiert werden.

Nicht alles lässt sich automatisieren

Zahlreiche andere Hersteller bieten eine Fülle von Testsystemen („Testbench“, „Testsuite“ und so weiter) mit unterschiedlichem Funktionsumfang. Kein Tool entbindet den Tester jedoch davon, sinnvolle und qualitätssichernde Tests zu erstellen. In der Praxis wird oft sehr schnell die Forderung laut, alle möglichen Ablaufpfade mögen doch bitte automatisch getestet werden. Den Sinn oder vielmehr Unsinn dieser Anforderung möchte ich an einem einfachen Beispiel erläutern.

Ein Programm kann bei Windows üblicherweise auf drei Arten beendet werden: erstens mit der Schaltfläche „X“ im Fenster oben rechts; zweitens mit dem Menüpunkt „Datei/Beenden“; drittens mit der Tastenkombination „Alt-F4“. Hinzu kommt die Frage „Speichern: Ja, Nein, Abbrechen?“, wenn nichtgespeicherte Änderungen existieren. Das sind insgesamt zwölf mögliche Ablaufvarianten, die sich aus sieben Einzelaktionen kombinieren lassen. Dabei sind effektiv nur zwei Funktionsgruppen zu testen (Aktion an der Oberfläche und auszuführende Operation „Beenden“).

Sicher, wenn die Tests einmal programmiert sind, dann kostet die Durchführung „nichts“. Doch bei einem Fehler bekomme ich dann drei Fehlermeldungen mit derselben Ursache. Und alles muß dokumentiert werden, ohne einen zusätzlichen Informationsgewinn. In der Praxis erscheint es sinnvoll, mit Hilfe von Oberflächentests lediglich die Funktionen der Bedienoberfläche zu testen. Diese Tests prüfen nur, ob die Aktionen an der Oberfläche mit den eingegebenen Werten die richtigen Funktionen anstoßen. Das ähnelt dem Testablauf der Unit-Tests. Eine der Bedienungsanleitung gemäße Programmarchitektur mit Präsentations- und Logikschicht sollte diese Trennung der Tests unterstützen.

weiter mit: automatische Black-Box-Tests

(ID:2051069)