"Irren ist menschlich". Das beginnt schon bei der Systemanalyse. Testverfahren setzen aber in aller Regel erst auf dem Algorithmus oder sogar erst auf dem Maschinenprogramm auf. Es wird häufig nur noch geprüft, ob der Algorithmus richtig funktioniert, nicht aber, ob die Anforderungen richtig und widerspruchsfrei definiert wurden, und inwieweit diese Anforderungen korrekt auf die Algorithmen übertragen wurden.

Ziel des Testens ist der Nachweis der funktionalen Korrektheit, was eine korrekte und vollständige Spezifikation voraussetzt, deren Korrektheit wiederum auch nicht vom Himmel fällt.

Erfahrungen in der Praxis haben gezeigt, dass die Kosten für die Beseitigung von Fehlern exponentiell ansteigen, je später sie im Lebenszyklus eines Softwaresystems erkannt werden. Es ist daher wirtschaftlich erforderlich, Fehler möglichst früh zu erkennen und zu beheben.

Grundsätzlich steht man beim Testen von Softwaresystemen leider immer noch vor dem Problem, dass man durch Testen nur die Abwesenheit bestimmter Fehler, nicht aber die völlige Fehlerfreiheit eines Produktes nachweisen kann.

In der Literatur wird zunächst zwischen Systemverifikation (korrekt im Sinne der Spezifikation) und Systemvalidation (praktischer Test in einer definierten Testumgebung) unterschieden. Die Erfahrung hat gezeigt, dass trotz erfolgreicher Verifikation auf die Validierung eines Systems nicht verzichtet werden kann.

Nach der Art des Testverfahrens unterscheidet man konventionelle Testmethoden und formale Testmethoden (z.B. Programmverifikation über Schleifeninvarianten oder symbolisches Testen). Bei den sog. "formalen Testmethoden" wird versucht die Korrektheit eines Softwaresystems mit Hilfe mathematische Kalküle zu beweisen, was in der Praxis schon bei einfacheren Systemen am notwendigen Formalisierungsaufwand scheitert, so dass solche Methoden wenig praktische Bedeutung erlangt haben. Bei der Anwendungsentwicklung stehen nach wie vor konventionelle Testmethoden im Vordergrund, mit denen wir uns im Folgenden beschäftigen wollen.

Konventionelle Testmethoden

In der Praxis werden Programme i.d.R. einer Kombination aus funktionalen und strukturellen Testverfahren unterzogen. Zur Auswahl geeigneter Testdaten für funktionale Tests, können die nachfolgenden Methoden herangezogen werden

1. Anweisungsüberdeckung
   Jede Anweisung wird mindestens einmal ausgeführt.
   Dabei gilt eine Auswahl oder Fallunterscheidung insgesamt als eine Anweisung.
2. Zweigüberdeckung (beinhaltet i.d.R. die Anweisungsüberdeckung)
   Jeder Programmzweig muss mindestens einmal durchlaufen werden.
   (Also jede Schleife wenigstens 1x durchlaufen werden und jede Auswahl wenigstens 1x im True- oder False-Teil durchlaufen werden.)
3. Bedingungsüberdeckung
   Jede Möglichkeit, die in einer Bedingung auftreten kann, muss mindestens
   einmal getestet werden. (Also alle einer Teile einer Auswahl, True- und False-Teil.)
4. Pfadüberdeckung
   Ein Pfad beschreibt einen möglichen Weg durch das Programm vom Anfang bis zu Ende. Jeder mögliche (denkbare !!) Pfad muss einmal durchlaufen werden, also auch jede denkbare Ereignisreihenfolge. (Und das immer vom Anfang bis zum Ende und nicht nur teilweise.)
   Schon bei mittleren Programmgrößen ist dies mit vertretbarem Aufwand nicht mehr erreichbar wohl aber beim Testen von Objekten und hier insbesondere beim Testen der einzelnen Objektmethoden.)

1. Bildung von Äquivalenzklassen (Diese Klassen haben nichts mit Klassen im Sinne der OOP zu tun.)
   Prämisse: Das Programm reagiert bei allen Werten aus einer definierten Äquivalenzklasse gleich. Funktioniert das Programm mit einem Wert aus der Äquivalenzklasse fehlerfrei, so funktioniert es mit allen anderen Werten aus dieser Klasse ebenfalls korrekt. Durch dieses Verfahren lässt sich die Anzahl der erforderlichen Testfälle deutlich einschränken. (So können z.B. bei Notenpunkten die Äquivalenzklassen "zu klein" für alle Werte < 0, "korrek" für alle Werte im Bereich 0..15 und "zu groß" gebildet werden. Die jeweilige Programmfunktion kann nun mit 3 repräsentativen Werten wie ( –2 ,5 und 20) hinreichend getestet werden.)
2. Grenzwertanalyse
   Dieses Verfahren setzt voraus, dass die Werte innerhalb einer Äquivalenzklasse sinnvoll geordnet werden können, z.B. aufsteigend, absteigend, nach dem Wert oder der Zeit. Dies geht bei Mengen, Preisen etc., aber z.B. nicht bei Daten wie "Eigenschaften", "Kennbuchstaben".
   Bei der Grenzwertanalyse wird nicht irgend ein beliebiger Wert aus einer Äquivalenzklasse, sondern es werden gezielt Randwerte getestet. Erfahrungsgemäß tauchen hier am häufigsten Fehler auf. Im Gegensatz zur Äquivalenzklassenbildung kann man bei der Grenzwertanalyse auch aus der Betrachtung der Ausgabewerte Testdaten ableiten. Beim praktischen Test wird man sowohl aus dem gültigen wie auch aus dem ungültigen Wertebereich einen möglichst dicht an der jeweiligen Grenze liegenden Wert testen. Als Grenzwerte eignen sich Randwerte von Gültigkeitsintervallen, Maxima, Minima, Ausnahme– und Fehlerfälle, wie falsche Eingabezeichen oder Wert außerhalb des Wertebereiches.
3. intuitive Testfallermittlung
   (Besonders Kritische Fälle aus der Erfahrung.)

• extrem große oder kleine Werte
• wirre Eingabefolgen, mit der Hand beliebig über die Tastatur gleiten
• absichtliche Fehlbedienungen, Stecker ziehen
• Eingabekombinationen die bisher häufig zu Fehlern führten

Und nun noch das weniger Angenehme!

Alle Tests sind zu planen und ihre Durchführung ist zu dokumentieren!

Dazu ist ein Plan (am besten als Tabelle) aufzustellen, in dem die einzelnen Testfälle mit

- Testfall (Eingabedaten)
- Was soll mit diesem Testfall getestet werden (Testzweck) – erwartetes (korrektes) Ergebnis
- eventuell abweichendem tatsächlichen Testergebnis

dokumentiert werden müssen. Dabei ist es guter Stil – soweit sinnvoll – die jeweiligen E/A-Masken auszudrucken und als Anlage dem Testprotokoll beizufügen.

Diese Dokumentation ist insbesondere für die nach Programmänderungen erneut erforderlichen Tests unverzichtbar.

[Home | Gymn. Oberstufe | Informatik | Unterrichtsmaterialien]]
[Textanfang]