Fehlerarten, Teststrategien und Hilfsmittel

Fehlerarten, Teststrategien

und Hilfsmittel

Fehlerarten

Abweichungen gegenüber der Spezifikation

Syntaktische Fehler

werden beim Übersetzen vom Compiler erkannt, der Compiler gibt eine entsprechende Fehlermeldung aus. Diese Fehlerart ist am schnellsten von allen zu beheben.

Typische Fehler: falsch geschriebene Befehle, vergessene Klammern, kein Strichpunkt

Logische Fehler

Die Syntax ist korrekt, das Programm läuft jedoch nicht wie geplant.

Folgen:

falsche Ergebnisse

Endlosschleifen

nie erreichter Code

Ursachen:

falsche Bedingungen in Schleifen oder Verzweigungen

falsche Operatoren

Laufzeitfehler

treten während der Laufzeit des Programmes auf und führen meist zum Programmabsturz.

Beispiele:

Division durch 0

Überschreiben von verwendetem Speicher

Pointer zeigt nicht an die richtige Stelle

Stack oder Heap Overflow

Testen und Debugging

Begriffe

Testen: ist die Untersuchung eines Programmes auf alle Arten von Fehlern

Debugging: Analysieren und Beheben von Fehlern.

Teststrategien

codeorientiert (White-Box, intern, WIE funktioniert das Programm?)

Jeder Befehl des Codes (alle Zweige von Entscheidungen, alle Schleifen) werden in allen Kombinationen mindestens 1 mal durchlaufen. Basis ist der Programmentwurf.

Vorteil: sehr gründlich

Nachteil: sehr aufwendig (nur für kleine Module)

funktionsorientiert (Black-Box, extern, WAS leistet das Programm?)

Die fertigen Funktionen werden mit Hilfe des Pflichtenheftes und dem Kriterienkatalog (aus Benutzersicht) getestet, wesentlich ist das Verhalten der Schnittstelle.

Auswahl der Testfälle bei funktionsorientiertem Test

repräsentatives Testen

Die Funktionen werden entsprechend der Häufigkeit, mit der sie verwendet werden, getestet.

schwachstellenorientiertes Testen

Jene Funktionen, bei denen die Wahrscheinlichkeit, daß ein Fehler auftritt, relativ hoch ist, werden intensiver getestet (z.B. komplexe Algorithmen, komplizierte Datenstrukturen).

schadensausmaßorientiertes Testen

Es werden jene Funktionen, bei denen Fehler gravierend sind oder sehr teuer wären, besonders intensiv getestet.

nicht gravierend: Fehler beim Schreiben einer Überschrift

gravierend: Zerstörung der Datei

Arten von Testdaten

Normalwerte

Werte, die im Betrieb häufig vorkommen

Extremwerte

Minimum, Maximum, NULL, Leerstring, leere Datei

falsche Werte

"Robustheit" - können durch Fehleingaben des Benutzers zustande kommen, liegen außerhalb gültiger Grenzen

Hierarchie des Testens

1. Modultest

Testen einzelner Module

2. Komponententest

Testen mehrerer zusammengefügter Module

3. Integrationstest

Testen aller Module in einer Testumgebung

4. Systemtest

Probebetrieb, Prüfung der Stabilität und Leistung beim Kunden

5. Abnahmetest

Programmanforderungen werden getestet

Mengenanforderungen

max. Anzahl der User bzw. von Datensätzen

Leistungsanforderungen

Durchschnittliche Bearbeitungszeit

Verfügbarkeitsanforderungen

Bürobetrieb 79 - 100 %. Echtzeitbetrieb 99.5 - 100 %

Genauigkeitsanforderungen

Anzahl der Kommastellen, Runden oder Abschneiden

Arten des Modultests

Ein-/Ausgabeanweisungen statt Parameter

Nachteil: Das Modul wird nach dem Testen nochmals verändert

über- und untergeordnete Simulationsmodule

Nachteil: aufwendig

Driver-Modul: ruft das Testmodul auf, versorgt es mit Parametern, enthält

Ergebnisse, wertet Daten aus.

Dummy-Modul: wird aufgerufen, muß Minimalfunktionen erfüllen

z.B. fixe Testdaten zurückliefern.

Kosten von Fehlern

Je später Fehler entdeckt werden, um so teurer sind diese

Zusammenhang zwischen Fehlerentstehung und Fehlererkennung

Fehler können nur auf der Ebene erkannt werden, auf der sie begangen

wurden.

Grundsätze

Test planen, nicht improvisieren

genügend Zeit vorsehen (ca. 40 % der Projektdauer)

gründlich Testen, nicht schummeln

nach Anderungen wieder alles durchtesten

nicht jeden Fehler sofort korrigieren, sondern zu Ende testen (wenn möglich)

Ein Programmierer sollte seine eigenen Module nicht testen (Wer gibt schon gerne zu, daß er einen Fehler gemacht hat?)

Ein Test kann über die Anwesenheit von Fehler Auskunft geben, aber nicht über Abwesenheit, d.h. man kann nicht beweisen, daß ein Programm fehlerfrei ist, sondern nur, daß ein Fehler vorhanden ist.

Jeder Test sollte mitprotokolliert werden. In diesen Berichten sollten die auftretenden Fehler und Probleme, Fehlerursachen und Lösungen beschrieben werden.

3. Hilfsmittel

Debugger

Breakpoints

Watches: Anzeigen von Variablenwerte

Trace-Modus: Programmablauf wird mitprotokolliert, Protokoll kann dann analysiert werden

Single-Step-Modus

Dump-Programme

Testdatengenerator

Ausgaben im Programm