Software Engineering I

1
Vorlesung Software Engineering I

• Qualitätssicherung II
• Analytische QS

2
Software-Qualitätssicherung (SW-QS)
Qualitätssicherung
Analytische QS
Konstruktive QS
Normen, Standards,Prozessmodelle,Projektleitung,
Software-Technik,Software-Architektur,Erfahrung
saustausch,Ausbildungsmaßnahmen...
Ergebnisse
Prozesse
Audits
Artefakte prüfen
Dokumente
Reviews,...
Software
Testen
3
Fragestellung beim Testen
4
Austesten?

• Ein einfaches Programm soll getestet werden, das
  drei ganzzahlige Eingabewerte hat. Übrige
  Randbedingungen haben keinen Einfluss auf das
  Testobjekt.
• Jeder Eingabewert kann bei 16 Bit Integerzahlen
  216 unterschiedliche Werte annehmen.
• Bei drei unabhängigen Eingabewerten ergeben sich
  216 216 216 248 Kombinationen.
• Jede dieser Kombinationen ist zu testen.
• Wie lange dauert es bei 100.000 Tests pro
  Sekunde?
• Es sind 281.474.976.710.656 TestfälleDauer ca.
  90 Jahre

5
Austesten?

• Ein einfaches Programm soll getestet werden,
  das aus vier Verzweigungen (IF-Anweisungen) und
  einer umfassenden Schleife besteht und somit
  fünf mögliche Wege im Schleifenrumpf enthält.
• Unter der Annahme, dass die Verzweigungen
  voneinander unabhängig sind und bei einer
  Beschränkung der Schleifendurchläufe auf
  maximal 20, ergibt sich folgende Rechnung
• 51 52 ... 518 519 520
• Wie lange dauert das Austesten bei 100.000
  Tests pro Sekunde?
• Es sind 119.209.289.550.780 TestfälleDauer ca.
  38 Jahre

6
Erste Übung zur Testfallanalyse

• Ein Programm ist zu testen, das 3 ganzzahlige
  positive Werte einliest und als Längen eines
  Dreiecks interpretiert.
• Das Programm gibt eine Meldung aus, ob es sich
  um ein ungleichseitiges, gleichschenkliges oder
  gleichseitiges Dreieck handelt.
• Welche Testfälle werden benötigt ?
• Welche Testdaten sind sinnvoll ?

7
Mögliche Testfälle (1)

• Testfälle bestehen aus Testdaten und dem
  Soll-Ergebnis
• 1. 2,3,4 - zulässiges ungleichseitiges Dreieck
• 2. 2,2,2 - zulässiges gleichseitiges Dreieck
• 3. 2,2,1 - zulässiges gleichschenkliges Dreieck
• 4./5. 1,2,2 / 2,1,22 weitere Testfälle mit
  Permutationen für gleichschenklige Dreiecke
• 6. 1,0,3 - kein Dreieck, eine Seitenangabe 0
• 7./8. 0,1,3 / 1,3,0 - Permutationen
• 9. 5,-5,9 - kein Dreieck, eine Seitenangabe lt 0
• 10./11. -5,5,9 / 5,9,-5 - Permutationen

8
Mögliche Testfälle (2)

• 12. 1,2,3 - kein Dreieck Summe der beiden
  kürzeren Seiten 3. Seitenlänge
• 13./14. 2,3,1 / 3,1,2 - Permutationen
• 15. 1,2,4 - kein Dreieck Summe der beiden
  kürzeren Seiten lt 3. Seitenlänge
• 16./17. 2,4,1 / 4,1,2 - Permutationen
• 18./19. 0,0,0 - kein Dreieck oder Fehlermeldung
  alle Seiten 0, zusätzlich 2 Seiten 0 -
  Permutationen?
• 20.-22. Max_int, Max_int, Max_int - zulässiges
  gleichseitiges Dreieck korrekte
  Dreiecksbestimmung beim Test mit maximalen
  Werten, zusätzliche Tests mit 2 oder 1 maximalem
  Wert

9
Mögliche Testfälle (3)

• 23.-25. 1,1,4.4567 - Fehlermeldung nicht
  ganzzahlige Werte Permutationen? - zusätzlich
  mit 2 oder 3 Werten
• 26.-28. 1,1, - Fehlermeldung Eingabe von
  Buchstaben oder Sonderzeichen Permutationen? -
  zusätzlich mit 2 oder 3 Werten
• 29./30. 1,2,3,4 / 2,3 - Fehlermeldung falsche
  Anzahl von Werten (wenn Eingabe möglich)
• 31. Max_int/2 1, Max_int/2 1, Max_int/2 10
  - zulässiges gleichschenkliges Dreieck (Überlauf
  oder richtige Berechnung? Bei altbltc Prüfung
  der Dreiecksbedingung mit abgtc, führt ab zum
  Überlauf, s.a. Testfall 20)
• Wie viele Tests hatten Sie überlegt?

in Anlehnung anGlenford J. Myers Methodisches
Testen von Programmen.7. Auflage 2001
10
Spitz-, stumpf- und rechtwinklige Dreiecke

• Werden spitz-, stumpf- und rechtwinklige
  Dreiecke zusätzlich berücksichtigt, ergeben sich
  insgesamt 47 Testfälle.
• Resümee Einfaches Problem, aber aufwendiger
  Test!

E. H. RiedemannTestmethoden für sequentielle
und nebenläufige Software-Systeme. Teubner
Verlag, Stuttgart 1997
11
Definition Qualität

• Die Erfüllung von Qualitätszielen, die durch
  Vorgaben für Qualitätsmerkmale und ihre
  Teilmerkmale definiert sind
• Qualität ist der Grad, in dem von einem Satz
  inhärenter Merkmale (eines Produkts) die
  Anforderungen erfüllt werden. (DIN EN ISO
  90002005)
• Qualitätsmerkmale beziehen sich immer auf
  Anforderungen
• Funktionale Anforderungen (Fachlichkeit,
  Funktionen, Schnittstellen, ...)
• Nicht-Funktionale Anforderungen(Qualitäts- und
  Realisierungsanforderungen,Projektspezifische
  Anforderungen, ...)

Angelehnt an DIN EN ISO 90002005
Qualitätsmanagementsysteme Grundlagen und
Begriffe. Beuth Verlag, Berlin, 2005
12
Validierung und Verifikation - Definition

• Validierung Prüfung, ob ein Entwicklungsergebnis
  die individuellen Anforderungen bezüglich einer
  speziellen beabsichtigten Nutzung erfüllt.
• Haben wir das richtige System realisiert?
• VerifikationPrüfung, ob die Ergebnisse einer
  Entwicklungsphasedie Vorgaben der
  Phaseneingangs-Dokumente erfüllen.
• Haben wir das System richtig realisiert?

13
Software-Qualität nach DIN/ISO/IEC 9126 (1)
Softwarequalität
ISO/IEC 91261991 Bewerten von Softwareprodukten,
Qualitätsmerkmale und Leitfaden zu ihrer
Verwendung (identisch mit DIN 66272, 94)
14
Software-Qualität nach DIN/ISO/IEC 9126 (2)
Softwarequalität
15
Analytische Qualitätssicherung

• Statischer Test

16
Zunächst ein Selbsttest

• Wie viele "F" kommen im folgenden Text vor?

FINISHED FILES ARE THE RE- SULT OF YEARS OF
SCIENTIF- IC STUDY COMBINED WITH THE EXPERIENCE
OF YEARS
17
Selbsttest

• Es sind sechs!
• Wie viele hatten Sie gezählt?
• Drei zu finden ist normal - sechs wirklich gut!
• Irren ist menschlich ?

FINISHED FILES ARE THE RE- SULT OF YEARS OF
SCIENTIF- IC STUDY COMBINED WITH THE EXPERIENCE
OF YEARS
18
Die magische Zahl Sieben

• Problem Begrenzte menschliche Wahrnehmungsfähigke
  it
• Die Millersche Zahl bezeichnet die von George A.
  Miller festgestellte Tatsache, dass ein Mensch
  gleichzeitig nur 72 Informationseinheiten
  (Chunks) im Kurzzeitgedächtnis präsent halten
  kann. Die Größe des Kurzzeitgedächtnisses ist
  genetisch determiniert und kann auch durch
  "Training" nicht gesteigert werden. Der
  diesbezüglich von Miller verfasste Artikel "The
  Magical Number Seven, Plus or Minus Two Some
  Limits on Our Capacity for Processing
  Information" ist einer der meistzitierten Artikel
  im Bereich der Psychologie.
• (Quelle http//de.wikipedia.org/wiki/Millers
  che_Zahl)

19
Statischer Test vs. dynamischer Test

• Im Entwicklungsprozess werden unterschiedliche
  Produkte (Artefakte) erstellt
• Informelle Texte
• Modelle
• Formale Texte
• Programmcode
• Maschinencode
• Programme sind statische Beschreibungen von
  dynamischen Prozessen.
• Dynamische Tests prüfen die durch
  Interpretation (Ausführung) der Beschreibung
  resultierenden Prozesse.
• Statische Tests untersuchen die Beschreibung als
  solche, sie wird nicht ausgeführt.
• Im Gegensatz zum dynamischen Test finden
  statische Tests eher Fehlerzustände als
  Fehlerwirkungen

20
Statischer Test

• Analyse des Testobjekts (meist ein Dokument)
  durch intensive Betrachtung
• Ziel Finden von Fehlerzuständen (Defekten) im
  Dokument
• Verstöße gegen Spezifikationen oder einzuhaltende
  Standards, Fehler in Anforderungen, Fehler im
  Design, unzureichende Wartbarkeit und falsche
  Schnittstellenspezifikationen
• Nachweis der Verletzung von Projektplänen
• Ergebnisse der Untersuchungen werden darüber
  hinaus dazu benutzt, den Entwicklungsprozess zu
  optimieren
• Grundidee Prävention!
• Fehlerzustände und Abweichungen sollen so früh
  wie möglich erkannt werden, noch bevor sie im
  weiteren Verlauf der Softwareentwicklung zum
  Tragen kommen und aufwändige Nach- oder
  Verbesserungen nach sich ziehen

21
Prüfende Verfahren

• Reviews überprüfen am Ende jeder
  Entwicklungsphase Umfang und Qualität der
  Zwischenprodukte. Projektpersonal,
  Auftragnehmer-management und Auftraggeber
  entscheiden gemeinsam, ob die nächste Phase
  angegangen werden kann
• Audits sind offizielle Reviews zur Verifikation
  besonders kritischer Teile durch das QS-Personal
• Ziel eines Walk-Throughs ist, Problembereiche zu
  entdecken, sie aber erst nach Abschluß des
  Walk-Throughs und nach Zustimmung des Erstellers
  zu beheben
• Peer Review entspricht dem Walk Through. Es geht
  dabei um eine methodische Examinierung der
  Ergebnisse durch sachkundige Kollegen (Peers).
  Ziel ist, Fehler zu finden und Bereiche, in denen
  Änderungen erforderlich sind
• Inspection ist eine sehr formale Gruppensitzung,
  in der die zu inspizierende Unterlage vom Autor
  vorgelesen und sequentiell Wort für Wort
  durchgearbeitet wird

22
Manuelle vs. automatisierte Prüfung

• Betrachtung des Prüfobjekts durch Mensch oder
  Werkzeug
• Reviews
• Manuelle Prüfungen durch eine oder mehrere
  Personen
• Menschliche Analyse- und Denkfähigkeit wird
  genutzt, um komplexe Sachverhalte zu prüfen und
  zu bewerten
• Kann bei allen Dokumenten durchgeführt werden,
  die während des Softwareentwicklungsprozesses
  erstellt oder verwendet werden (z. B. Vertrag,
  Anforderungsspezifikation, Designspezifikation,
  Quelltext, Testkonzepte, Testspezifikationen,
  Testfälle, Testskripte oder Anwenderhandbücher)
• Statische Analyse
• Automatisierte Prüfungen durch entsprechende
  Werkzeuge
• Nur bei Dokumenten mit formaler Struktur (z.B.
  Programmtext,UML-Diagramme)

23
Zielsetzung statische Analyse

• Aufdeckung vorhandener Fehlerzustände oder
  fehlerträchtiger Stellen in einem formalen
  Dokument.
• Durch werkzeuggestützte Prüfung, z.B.
• Rechtschreibprüfprogramme als eine Art statische
  Analysatoren, die (Rechtschreib- und
  eingeschränkt Grammatik-) Fehler in Texten
  nachweisen und damit zur Qualitätsverbesserung
  beitragen
• Ermittlung von Metriken (Messgrößen), um eine
  Qualitätsbewertung durchführen und somit Qualität
  messen und nachweisen zu können.

24
Statische Analyse und Werkzeugunterstützung

• Statische Analyse mit Werkzeugunterstützung kann
  nur auf einem formal strukturierten Dokument
  durchgeführt werden.
• Formale Dokumente können z. B. sein
• Technische Anforderungen
• Softwarearchitektur-Modelle
• Softwareentwurf-Modelle
• Programmcode
• Informeller Text kann unterhalb der
  Oberflächenstruktur (Rechtschreibung und
  elementare Grammatik) nur mit Methoden der KI
  (künstliche Intelligenz) analysiert werden
• Linguistische semantische Analyse ist aktueller
  Forschungsgegenstand
• Aber Einführung einer Normsprache ermöglicht
  auch hier einfachere Analysen

25
Statische Analyse und Reviews

• Stehen in einem engen Zusammenhang
• Wird vor dem Review eine statische Analyse
  durchgeführt, können bereits eine Anzahl von
  Fehlern und Unstimmigkeiten nachgewiesen werden
  und die Menge der im Review zu berücksichtigenden
  Aspekte ist erheblich geringer
• Da statische Analysen werkzeuggestützt
  durchgeführt werden, ist der Aufwand wesentlich
  niedriger als beim Review
• Also
• Statische Analyse und
• Review
• Problem

26
Statische Analyse von Programmcode

• Fehler(zustände) bzw. fehlerträchtige
  Situationen, die mit der statischen Analyse von
  Programmcode nachgewiesen werden können, sind
  beispielsweise
• Verletzung der Syntax
• Abweichungen von Konventionen und Standards
• Kontrollflussanomalien
• Datenflussanomalien
• Alle Compiler führen eine statische Analyse des
  Programmtextes durch, indem sie die Einhaltung
  der Syntax der jeweiligen Programmiersprache
  prüfen
• Die meisten modernen Compiler bieten darüber
  hinaus noch zusätzliche statische Analysen
• Neben den Compilern gibt es spezielle Werkzeuge,
  sogenannte Analysatoren, die zur Durchführung
  bestimmter Analysen eingesetzt werden

27
Statische Analysewerkzeuge

• Einige freie Werkzeuge zur statischen Codeanalyse
• CCCC (http//sourceforge.net/projects/cccc/)
• JUtils (http//www.jutils.com/)
• PyChecker (http//c2.com/cgi/wiki?PyChecker)
• Einige kommerzielle Werkzeuge zur statischen
  Codeanalyse
• PC-Lint
• Klocwork
• Coverity
• http//en.wikipedia.org/wiki/List_of_tools_for_sta
  tic_code_analysis

28
Analytische Qualitätssicherung

• Dynamischer Test

29
Statischer Test vs. dynamischer Test

• Programme sind statische Beschreibungen von
  dynamischen Prozessen
• Statische Tests untersuchen die Beschreibung als
  solche, sie wird nicht ausgeführt
• Artefakte des Entwicklungsprozesses, z.B
  informelle Texte, Modelle, formale Texte,
  Programmcode, ...
• Dynamische Tests prüfen die durch
  Interpretation (Ausführung) der Beschreibung
  resultierenden Prozesse.
• Das Testobjekt wird im dynamischen Test auf
  einem Prozessor ausgeführt
• Bereitstellen von Eingangsdaten
• Beobachten der Ausgangsdaten

30
Ziele des dynamischen Tests

• Nachweis der Erfüllung der festgelegten
  Anforderungen durch das Testobjekt
• Aufdeckung von eventuellen Abweichungen und
  Fehlerwirkungen
• Mit möglichst wenig Aufwand (Testfällen)
  möglichst viele Anforderungen überprüfen bzw.
  Fehler nachweisen
• Aber Dynamische Tests sind immer nur
  Stichproben!

31
Dynamischer Test Begriffe und Zusammenhänge
32
Dynamischer Test in unteren Teststufen

• Die Ausführung dynamischer Tests erfordert ein
  ablauffähiges Programm
• Einzelne Klassen, Module/Komponenten und
  Teilsysteme sind jedoch in der Regel für sich
  alleine nicht lauffähig
• Bieten oft Operationen/Dienste für andere
  Softwareeinheiten an
• Haben kein Hauptprogramm zur Koordination des
  Ablaufes
• Stützen sich oft auf Operationen/Diensten anderer
  Softwareeinheiten ab
• In den unteren Teststufen Klassen-/Modultest,
  Komponententest und Integrationstest muss das
  Testobjekt also in einen entsprechenden
  Testrahmen eingebettet werden
• ? Oft als Unit-Test bezeichnet

33
Unit Test Begriffe

• Testrahmen (test bed)
• Sammlung aller Programme (u. a. Testtreiber und
  Platzhalter), die notwendig sind, um Testfälle
  auszuführen, auszuwerten und Testprotokolle
  aufzuzeichnen
• Testumgebung
• Gesamtheit aller Hardware- und Softwarekomponenten
  (auch der Testrahmen), die notwendig sind, um
  Testfälle durchzuführen
• Platzhalter (stub)
• Platzhalter werden beim dynamischen Komponenten-
  und Integrationstest benötigt, um noch nicht
  implementierte Komponenten für die
  Testdurchführung zu ersetzen bzw. zu simulieren
• Dummy
• Platzhalter mit rudimentärer Funktionalität
• Mock
• Platzhalter mit erweiterter Funktionalität für
  Testzwecke (Logging, Plausibilitätsprüfung)
• Simulator
• Werkzeug, mit dem die Einsatz- bzw.
  Produktivumgebung nachgebildet wird

34
Aufbau eines Testrahmens
Point of Control Schnittstelle, über die das
Testobjekt mit Testdaten versorgt wird
PoC
Testausgaben Vergleich Protokoll
Testobjekt
PoO
Point of Observation Schnittstelle, an der die
Reaktionen und Ausgaben des Testobjekts
beobachtet und aufgezeichnet werden
Laufzeitumgebung, Analysewerkzeuge, Simulatoren,
Monitore
Prozessor
35
Fragestellungen beim Entwurf von Testfällen

• Wie viele Tests sind notwendig ?
• Welche Testdaten sollen verwendet werden ?
• Wie können fehler-sensitive Tests gefunden werden
  ?
• Wie vermeidet man redundante Test ?
• Wurden Testfälle übersehen ?
• Wann kann man mit Testen aufhören ?

36
Dynamischer Test Testentwurfsverfahren

• Testentwurfsverfahren (synonym
  Testfallentwurfsverfahren)
• Eine Vorgehensweise, nach der Testfälle
  abgeleitet oder ausgewählt werden
• Black-Box (Spezifikationsorientierte)
  Testentwurfsverfahren
• Systematische Herleitung und Auswahl von
  Testfällen basierend auf einer Analyse der
  funktionalen oder nichtfunktionalen Spezifikation
  einer Komponente oder Systems ohne
  Berücksichtigung der internen Struktur.
• Keine Informationen über den Programmtext und den
  inneren Aufbau
• Beobachtet wird das Verhalten des Testobjekts von
  außen (PoO - Point of Observation liegt außerhalb
  des Testobjekts)
• Steuerung des Ablaufs des Testobjektes nur durch
  die Wahl der Eingabetestdaten (PoC - Point of
  Control liegt außerhalb des Testobjektes)
• White-Box (Strukturorientierte)
  Testentwurfsverfahren
• Systematische Herleitung und Auswahl von
  Testfällen basierend auf der internen Struktur
  einer Komponente oder Systems

37
Black-box Test vs. White-box Test
38
Übersicht Testentwurfsverfahren
39
Testfall- und Testdatenermittlung
Y F (X)
WertebereicheGültige AusgabenUngültige Ausgaben
WertebereicheGültige EingabenUngültige Eingaben
Parameter
Ergebnisse
Funktion
40
Äquivalenzklassenbildung

• Die Definitionsbereiche der Ein- und Ausgaben
  werden so in Äquivalenzklassen (ÄK) zerlegt
  (partitioniert), dass alle Werte einer Klasse
  äquivalentes Verhalten des Prüflings ergeben
• Wenn ein Wert der ÄK einen Fehler aufdeckt, wird
  erwartet, dass auch jeder andere Wert der ÄK
  diesen Fehler aufdeckt
• Wenn ein Wert der ÄK keinen Fehler aufdeckt, wird
  erwartet, dass auch kein anderer Wert der ÄK
  einen Fehler aufdeckt
• Aus jeder Äquivalenzklasse wird dann nur ein
  Repräsentant getestet!
• engl. Partition Testing

Äquivalenzklasse
Definitionsbereich
Ein beliebiger Wertder Äquivalenzklasse
41
Äquivalenzklassenbildung
Äquivalenzklassenbildung in der Schlangenschule
42
Analytische Qualitätssicherung

• Strukturorientierter Test

43
White-Box Tests
44
Beispiel Kontrollflussgraph von ggT()

1. public int ggt (int m, int n) // pre m gt 0 and
   n gt 0// post return gt 0 and //
   m_at_pre.mod(return) 0 and //...
2. int r
3. if (n gt m)
4. r m
5. m n
6. n r
7. r m n
8. while (r ! 0)
9. m n
10. n r
11. r m n
12. return n

45
Strukturorientierte Testverfahren

• Kontrollflussbasiert
• Anweisungsüberdeckung (statement coverage)
• (C0-Überdeckung, alle Knoten des
  Kontrollflussgraphen)
• Entscheidungsüberdeckung (decision coverage)
• (C1-Überdeckung, Zweigüberdeckung, d.h. bei
  Knoten mit mehr als einer ausgehenden Kante alle
  diese Kanten)
• Pfadüberdeckung (path coverage)
• (C?-Überdeckung, alle Pfade)
• Datenflussbasiert
• Alle Definitionen (all defs)
• Alle Definition-Benutzung-Paare (all def-uses)
• Bedingungsbasiert
• Einfache Bedingungsüberdeckung (branch condition
  testing)
• Mehrfachbedingungsüberdeckung (branch condition
  combination testing)
• Minimale Mehrfachbedingungsüberdeckung (modified
  branch condition decision testing)

46
Beispiel Anweisungsüberdeckung für ggt()

1. public int ggt(int m, int n) // pre m gt 0 and
   n gt 0// post return gt 0 and //
   m_at_pre.mod(return) 0 and //...
2. int r
3. if (n gt m)
4. r m
5. m n
6. n r
7. r m n
8. while (r ! 0)
9. m n
10. n r
11. r m n
12. return n

Pfad (1, 2-3, 4-6, 7, 8, 9-11, 8, 12, 13)
47
Beispiel Entscheidungsüberdeckung für ggt()

1. public int ggt (int m, int n) // pre m gt 0 and
   n gt 0// post return gt 0 and //
   m_at_pre.mod(return) 0 and //...
2. int r
3. if (n gt m)
4. r m
5. m n
6. n r
7. r m n
8. while (r ! 0)
9. m n
10. n r
11. r m n
12. return n

Pfad 1 (1, 2-3, 4-6, 7, 8, 9-11, 8, 12,
13) Pfad 2 (1, 2-3, 7, 8, 12, 13)
48
Beispiel Pfadüberdeckung für ggt()
1
2-3
4-6
7
8
9-11
12
13
49
Testfall zur Anweisungsüberdeckung
Pfad (1, 2-3, 4-6, 7, 8, 9-11, 8, 12,
13) Logischer Testfall n gt m ? n m ? 0 ? n
(n m) 0 ggt(m, n) Konkreter Testfall
m 4, n 6 2

1. public int ggt(int m, int n)
2. int r
3. if (n gt m)
4. r m
5. m n
6. n r
7. r m n
8. while (r ! 0)
9. m n
10. n r
11. r m n
12. return n

m n r
4 6 ?
50
Testfall zur Entscheidungsüberdeckung
Pfad (1, 2-3, 7, 8, 12, 13) Logischer Testfall
n ? m ? m n 0 ggt(m, n) Konkreter
Testfall m 4, n 4 4
1
2-3
4-6

1. public int ggt(int m, int n)
2. int r
3. if (n gt m)
4. r m
5. m n
6. n r
7. r m n
8. while (r ! 0)
9. m n
10. n r
11. r m n
12. return n

7
m n r
4 4 ?
8
9-11
12
13
51
White-Box Tests und Instrumentierung

• Bei den White-box Verfahren wird gefordert, dass
  bestimmte Programmteile zur Ausführung kommen
  bzw. Bedingungen unterschiedliche Wahrheitswerte
  annehmen
• Um den Test auswerten zu können, muss ermittelt
  werden, welche Programmteile bereits ausgeführt
  wurden und welche noch nicht zur Ausführung
  gekommen sind
• Dazu muss das Testobjekt an strategisch wichtigen
  Stellen vor der Testausführung instrumentiert
  werden
• Es werden zusätzlich Anweisungen wie z.B. Zähler
  eingebaut und mit Null initialisiert, die dann
  beim Durchlauf an den entsprechenden Stellen
  inkrementiert werden
• Ist ein Zähler auf Null geblieben, so sind die
  entsprechenden Programmteile nicht ausgeführt
  worden
• Instrumentierung größerer Programme nur mit
  Werkzeugen sinnvoll!

52
Bewertung der White-Box-Techniken
Überdeckungsmaß Leistungsfähigkeit Bewertung
Anweisungsüberdeckung (C0) Niedrig Entdeckt knapp ein Fünftel der Fehler Notwendig, aber nicht hinreichend Entdeckt dead-code Mit anderen Verfahren kombinieren!
Entscheidungsüberdeckung (Zweigüberdeckung, C1) Mittel, schwankt aber stark Entdeckt ca. 30 aller Fehler und ca. 80 der Kontrollfluss-Fehler Minimales Testkriterium Entdeckt nicht ausführbare Zweige Zielt auf Verzweigungen
Bedingungsüberdeckung (C2) Niedrig Umfasst i.Allg. nicht die Anweisungs- und Entscheidungsüberdeckung
Mehrfach-Bedingungsüberdeckung Hoch Zielt auf komplexe Bedingungen Umfasst Entscheidungsüberdeckung Aufwand wächst stark
Datenflusstest Mittel bis hoch, All c-uses ca. 50, All p-uses ca. 34, all defs ca. 25 (keine Berechnungsfehler!) Zielt auf Variablen-Verwendung c-uses findet viele Berechnungsfehler Kaum Tools verfügbar
Pfadüberdeckung (C?) Sehr hoch Entdeckt über 70 der Fehler In den meisten Fällen nicht praktikabel
53
Analytische Qualitätssicherung

• Bewertung Testverfahren

54
Bewertung Testverfahren
55
Zusammenfassung

• Testen hat zum Ziel, Fehler zu finden
• Testfälle sind stichprobenhafte Eingaben an das
  System mit definierten erwarteten Ergebnissen
• Testfall-Spezifikationsmethoden sind
  strukturierte Anweisungen zur Generierung von
  qualitativ hochwertigen Testfällen mit vielen
  Vorteilen gegenüber zufälligen Tests
• Eine Teststrategie hat zum Ziel, die wichtigsten
  Fehler so früh wie möglich mit geringen Kosten zu
  finden
• Testen ist ein Prozess, der den gesamten
  Software-Lebenszyklus begleitet
• Der Testprozess basiert auf vier Eckpfeilern
• Phasenmodell
• Passende Methoden
• Ressourcen und Infrastruktur
• Organisatorische Einbettung

56
Lehrbuch zum Certified Tester - Foundation Level

• Andreas Spillner, Tilo LinzBasiswissen
  SoftwaretestAus- und Weiterbildung zum Certified
  Tester Foundation Level nach ISTQB-Standard
• 4. überarbeitete Auflage
• dpunkt.verlag, 2010
• 308 Seiten, Gebunden
• 39,90 Euro (D)
• ISBN 978-3-89864-642-0
• Leseproben etc. unterhttp//www.dpunkt.de/bueche
  r/2679.html

57
Nützliche Links

• Stickymindshttp//www.stickyminds.com/Portal
  mit vielen Informationen zum Test von SQE
• Web Site Test obsessedhttp//www.testobsessed.c
  om/Information for people with a passion for
  software testing
• Center for Software Testing Education Research
  http//www.testingeducation.com/ Artikel zum
  Thema Testen sowie Vorlesungsunterlagen
• Atlantic Systems Guildhttp//www.systemsguild.com
  /Artikel zum Testen von Anforderungen und vieles
  mehr
• Introduction to Software Testing
• http//www.cs.gmu.edu/offutt/softwaretest/

58
Nützliche Links

• Web Sites von bekannten Testfachleuten meist mit
  Literaturempfehlungen, Links, lesenswerten
  Artikeln, Tool-Hinweisen u.a.
• Brian Marickhttp//www.exampler.com/
• James Bachhttp//www.satisfice.com/
• Elisabeth Hendricksonhttp//www.qualitytree.com/
  
• Hans Schäferhttp//home.c2i.net/schaefer/
• Bret Pettichord (ed.)http//www.io.com/wazmo/qa/
  
• ISTQB/GTB Test-Glossar
• http//www.german-testing-board.info/downloads/pd
  f/CT_Glossar_DE_EN_V21.pdf