Lecture 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12? | 13? | Index

To add a question because something is unclear or was not understood, just insert the question and add the prefix %q% for each addition (q like question). This is the "question-style". Like this: 

* %q% What kind of problems could have decentralized nature?
  • What kind of problems could have decentralized nature?

If you want to answer a question or add a comment please put a %a% in front. This is thea "answer-style" (a lilke answer). An example: 

* %a% This is an addition to something that I consider important.
  • This is an addition to something that I consider important.

For citations or references to the slides of Prof. Suri pleas add the lecture and slide number in braces: (<lecture>.<slide>).

Please make sure that you enter an author name, else your changes will not be saved!

Lecture 9 - Basiswissen Softwaretest

  • Fakten
    • Erschöpfendes Testen nicht praktikabel
    • Testen ist nicht Debuggen (9.11)
    • Testaufwand beträgt zwischen 25% und 50% des Entwicklungsaufwandes (9.15)
    • Ohne Risiko ist Testen unnötig (9.15)
  • Begriffe
    • Fehler: Nichterfüllung einer festgelegten Anforderung (9.8)
    • Mangel: Nicht angemessene Erfüllung einer gestellten Anforderung oder berechtigten Erwartung (9.8)
  • Ursachenkette für Fehler (9.9)
    1. Fehlerzustand, Defekt (fault)
    2. Fehlerhandlung (error)
    3. Fehlerwirkung, Aufall (failure)
  • Qualitätsmerkmale für Software (9.12)
    • Funktionalität
    • Zuverlässigkeit
    • Benutzbarkeit
    • Effizienz
    • Änderbarkeit
    • Übertragbarkeit
  • Testen (9.15)
    • Positiv-/Negativtests
    • Testen auf Funktionalität, die nicht gefordert ist
    • Priorisierung der Tests nach (9.16)
      • Kombination von Schwere und Eintrittswahrscheinlichkeit
      • Priorität und Gewichtung durch den Kunden
    • Testprozess (9.19)
      • Eng mit Softwareentwicklung verbunden
      • Aber eigenständiger Prozess
  • Psychologie des Testens (9.23)
    • Entwicklung = Konstruktion, Test = Destruktion?
    • Keiner gibt gerne Fehler zu
    • Wenn Entwickler sein eigenes Programm testet: (9.24)
      • Erkennt eigene Fehler u. U. nicht
      • Muss sich allerdings nicht erst in Projekt einarbeiten
  • Testverfahren
    • Statische vs. dynamische Tests (9.27)
    • Black-box vs. White-box (9.28)
    • Bildung von Äquivalenzklassen (9.31)
      • Grenzwertanalyse (9.35)
    • Zustandstest (9.39)
      1. Erstellen des Zustandsbaumes (9.43)
      2. Aufbau des Übergangsbaumes (9.44)
      3. Erweitern des Übergangsbaumes um Fehlerzustände (=> Robustheit) (9.45)
      4. Generieren der Testfälle (9.46)
      5. Ausführen der Tests (9.49)
    • Kontrollflussbezogene Tests (9.54)
      • Anweisungsüberdeckung (C0-Überdeckung) (9.55)
        • Nicht immer erreichbar (z. B. Ausnahmebehandlung)
      • Zweigüberdeckung (9.58)
      • Pfadüberdeckung (9.59)
  • Testwerkzeuge (9.61)
    • Testroboter (9.63)

Nach oben

Lecture 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12? | 13? | Index

Recent Changes

Nach oben

Zuletzt geändert am 06 März 2005 18:42 Uhr von chrschn