|
1. Fehlerarten
r /
. 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
2. 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
Fehlerentstehung Fehlererkennung
Codierung Übersetzung
Feinentwurf Modultest
Grobentwurf Komponententest
Spezifikation System- und
Integrationstest
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 Änderungen 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
|
