Fehlerarten, teststrategien

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 Modultest Testen einzelner Module   Komponententest Testen mehrerer zusammengefügter Module   Integrationstest Testen aller Module in einer Testumgebung   Systemtest Probebetrieb, Prüfung der Stabilität und Leistung beim Kunden   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            

Suchen artikel im kategorien
Schlüsselwort    Kategorien    - kategorien - astronomiebiographienbiologiechemiedeutschenglischfranzosischgeographiegeschichtehauswirtschaftinformatikitalienischkunstlateinliteraturmathematikmusikphilosophiephysikpolitikpsychologierechtsozialkundesporttechnikwirtschaft	•  Zusammenfassung Der Vorleser  •  sachtextanalyse  •  interpretation zwist  •  Fabel interpretation  •  literarische charakteristik  •  interpretation bender heimkehr  •  felix lateinbuch  •  interpretation der taucher von schiller  •  textbeschreibung  •  charakterisierung eduard selicke

Anmerkungen: * Name: * Email: URL: * Diskussion: (NO HTML)

| impressum | datenschutz