OSZ Handel I
Informatik

Software Engineering
Testverfahren

Hartmut Härtl

[Home | Wirtschaftsgymnasium | Informatik | Unterrichtsmaterialien]]
[Textende]


Verfahren zur Qualitätssicherung von Software

"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

Je nachdem, was Gegenstand der Untersuchung ist, unterscheidet man …

statisches Testen
(Inspektion des Quelltextes)

dynamisches Testen
(ablaufbezogenes Testen)

Solche Verfahren erscheinen in der Literatur häufig unter den Stichworten Inspektion, Review, Walkthrough.

Bei diesen Verfahren wird das Programm nicht ausgeführt, sondern der Quellcode inspiziert. (Einhaltung der Programmierrichtlinien, Vollständigkeit, klare Dokumentation, Variablen initialisiert, sauber gekapselte Attribute, Vererbungsbeziehungen, Typkompatibilität, Schnittstellen, terminieren alle Schleifen, werden alle deklarierten Datenobjekte auch benutzt etc.)

Zur Unterstützung des Testers stehen zum Teil DV-Werkzeuge wie "Lint" (für C-Programme) zur Verfügung, mit deren Hilfe die Untersuchung des Quelltextes unterstützt werden kann.

Der Programmlauf wird untersucht, das heißt, das Programm wird gestartet und durch geeignete Eingaben systematisch auf Fehler untersucht. Je nachdem ob der Tester hier seine Kenntnis des Quellprogrammes zu Grunde legen kann unterscheidet man hier sog.

  • Black-Box-Tests

  • White-Box-Tests

 

Black-Box-Test
Quellprogramm nicht bekannt

White-Box-Test
(Glass-Box-Test)
Quellprogramm bekannt

Datenbezogene Tests unter der Annahme "Welche Aufgaben erledigt das Programm (Funktion) und welche Daten müsste es dabei richtig verarbeiten können?" (Siehe "funktionales Testen")

Auf der Grundlage der Kenntnis aller Implementierungsdetails können gezielte ablauf- und datenbezogene Tests durchgeführt werden. (Siehe "Strukturtests").

 

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

 

Strukturtests (Quellprogramm muss bekannt sein)

Bei solchen Tests werden die Testdaten so gewählt, dass …

White-Box-Tests

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

 

Funktionales Testen

Bei diesen Testverfahren werden die Testdaten ausschließlich auf Basis
des Pflichtenheftes oder der Programmbeschreibung ermittelt.

Black-Box-Tests

  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]

© 05. April 2006    Hartmut Härtl