17. Programmprüfung
Ziele dieser Einheit:
- Nach der Implementierung (Programmierung): Analyse und Prüfung des Programms.
Systematisches Testen, Testtheorie.
Elementarbegriffe aus Verlässlichkeit und Automa- tentheorie (ergänzend zu Turing-Maschinen).
- Einige Beispiele für Messung der Testüberdeckung zur Be-
stimmung der Testgüte.
Vorbemerkungen: Historisches
- Im Laufe der letzten 40 Jahre wurde über Programm-Testen viel diskutiert. Eine kernige Aussage ist:
„Program testing can be used to show the presence of bugs, but never to show their absence.“ (Dijkstra, 1971)
- Aber es ist auch wahr, dass:
„We prove a fundamental theorem showing that properly structured tests are capable of demonstrating the absence of errors in a program.“
(Goodenough/Gerhart, 1975)
„... it is possible to use testing to formally prove the correctness of programs ...“ (Howden, 1978)
Vorbemerkungen: Warum Testen?
Beispiel: (nach G. Myers)
- Gegeben: Ein Program P, das drei ganze Zahlen a, b, c als Seiten eines Dreiecks
∆ einliest und angibt, ob es - schiefwinklig,
- gleichschenklig, oder - gleichseitig
ist.
- Gesucht: Testfälle (Eingabedaten + erwartete Ausgabedaten), um das Programm P „auszutesten“.
2,2,3
3,2,2 (a = b v b = c v a = c) führt zu ∆ gleichschenklig 3,2,3
2,2,2 (a = b Λ b = c) führt zu ∆ gleichseitig
Testfälle: I. Reguläre Tesfälle (erwünschte Ereignisse)
(Eingabe führt zu Ausgabe)
2,3,4 (a = b = c) führt zu ∆ schiefwinklig
2,2,4 (a + b = c)
2,4,2 (a + c = b) Fehlermeldung 2
4,2,2 (b + c = a)
0,2,3 (eine Kante = 0)
2,0,3 (eine Kante = 0) Fehlermeldung 3 2,3,0 (eine Kante = 0)
0,0,3 (zwei Kanten = 0)
0,3,0 (zwei Kanten = 0) Fehlermeldung 4 3,0,0 (zwei Kanten = 0)
0,0,0 (drei Kanten = 0) Fehlermeldung 5
Testfälle: II. Irreguläre Testfälle (unerwünschte Ereignisse)
2,2,5 (a + b < c) 2,5,2 (a + c < b)
5,2,2 (b + c < a) Fehlermeldung 1
Testfälle: II. Irreguläre Testfälle (Fortsetzg.):
-2, 3, 4 (negative Zahl)
2,-3, 4 (negative Zahl) Fehlermeldung 6
2, 3,-4 (negative Zahl) -2,-3, 4 (negative Zahlen)
-2, 3,-4 (negative Zahlen) Fehlermeldung 7
2,-3,-4 (negative Zahlen)
-2,-3-4 (negative Zahlen) Fehlermeldung 8
1.2,3 ,2 (keine Integers)
1 ,3.1.,2 (keine Integers) Fehlermeldung 9
1 ,3 ,2.1 no integers) 1,2,# (keine Zahlen)
1,B,3 (keine Zahlen) Fehlermeldung 10
X,2,3 (keine Zahlen)
1,2 (nur zwei Eingaben)
1 (nur eine Eingabe) Fehlermeldung 11
17. Programmprüfung
Klassisches Wasserfallmodell des Software-Erstellungs-
Prozesses
(nach B. Boehm, 1976)
Anforderungen an die Software
Validation
Grobentwurf Verifikation
Codierung/
„Debuggen“
Modultest
Integrations- test Validation Anforderungen
an das System Validation
Nutzung und Wartung Revalidation/
Regression Test Feinentwurf
Verifikation
17.1 Software-Erstellungsprozess
Literaturhinweise:
− F. Belli, Anleitung zur systematischen Pro-
grammierung und Konstruktion zuverlässiger Pro- gramme, Band III: Programmierpraxis,
Hochschultaschenbücher 640, BI Wissen- schaftsverlag (1989)
- E. H. Riedemann, Testmethoden für sequentielle und neben-läufige Software-Systeme, Teubner (1997)
- R.V. Binder, Testing Object-Oriented Systems,
Bedeutung
Benutzer/
Erzeuger
Semiotik (Zeichenlehre)-basierte Betrachtung
Semantik
Metazeichen (Konstrukt) Syntaktische
Fehler
Pragmatik Syntaktik
(Syntax) Stigmatik
Bezeichnetes Stigmatische
Fehler
Zeichen Pragmatische
Fehler
Semantische Fehler
Fehlerwirkungsmodell (nach Pressman, 1987)
Wirksam- keit der Prüfung Unverändert
weitergegebene Fehler
Im Verlauf 1:x verstärkte Fehler
neu generierte Fehler
(nicht entdeckte) Fehler zum
nächsten Schritt Fehler vom
Vorherigen Schritt
17.2 Fehlerquellen
Aktuelle Phase
Programm mit bekannten und unbekannten Mängeln („Fehlerlawine“, nach DGQ, 1986)
Bedarfs-
ermittlung Bedarf
Test und
Integration korrigierte unbekannte Fehler
Fehler korrektes
Verhalten
bekannte, unkor- rigierte Fehler Anforderungs-
definition/
Problemanalyse
korrekte Anforderung
Anforderungs- fehler
Realisierung korrektes Programm
Programm-
fehler aus Anforderungen aus Spezifikation induzierte Fehler
aus Entwurf System-
Spezifikation korrekte Spezifikation
Spezifikations- fehler
induzierte Fehler aus Anforderungen
Entwurf korrekter
Entwurf Entwurfsfehler
aus Anforderungen aus Spezifikation induzierte Fehler
Testfallbezeichner: ____________________________________________________
Zweck: _____________________________________________________________
Voraussetzungen/Vorbedingungen: _______________________________________
Eingaben: ___________________________________________________________
Erwartete Ausgaben: __________________________________________________
Nachbedingungen: ____________________________________________________
Involvierte Testverläufe: _______________________________________________
Datum Ergebnis Getestete Software/Version Durchgeführt von
Typische Testfallbeschreibung
„Sammle erst die Fakten, dann kannst Du sie verdrehen,
wie es Dir passt.“
Mark Twain
17.3 Verlässlichkeit und Prüfung technischer Systeme Verlässlichkeit („dependability“)
Fehler („faults“) Störungen
(„errors“) Versagen
(„malfunctions“) Ausfälle
(„failures“) Abweichungen
(„deviations“)
. . .
Gegenmaßnahmen/Mittel („means“)
Messungen („measures“) Unerwünschte Zustände/
Ereignisse („Impairments“)
Zuverlässigkeit/
Überlebens-/Korrekt- heitswahrscheinlich- keit(„reliability“)
Verfügbarkeit („availability“) Sicherheit(„safety“) Integrität
(„security“) . . .
Bewährung/
Bewertung („assessment“)
. . .
Beschaffung/ Erstellung
(„procurement“)
Undesirable events
Faults
Failures
Non-occurence of unauthorized
disclosure / improper
alteration of Information
(Security) (Security)
Non-occurrence of catastrophic conse- quences onto environ- ment
(Safety)
Security / Safety
(Security)
17.4 Prüfen und Testen
- Die Konstruktion eines Systems und seine Prüfung setzen eine Beschreibung der Aufgabenstellung voraus, die i. Allg. der Lösung eines Problems dient.
- a sei eine Aufgabenstellung (Problem). a ließe sich durch eine Funktion fa beschreiben (Spezifikation) als
fa: E → A mit E: Menge aller Fragestellungen als Eingabebereich A: alle Antworten auf diese Fragen als Ausgabebereich des vorgegebenen Problems a.
- Das Ziel der Programmkonstruktion ist die Erstellung eines Programms, dessen berechnete Funktion fp der Spezifikation fa entspricht:
fp: E → A mit fp(x) = fa(x), für alle x Є E .
- Erfolgt der Beweis für fp(x) = fa(x) für alle x und formal, so heißt die Prüfung formale Verifikation.
- Geht man jedoch von einer endlichen Testmenge T E aus, so spricht man von Test.
⊆
Programmbeweis: Nachweis von vollständig und mit mathematischen Mitteln.
( ) ( )
x f x fp = aNutzungprofilorientiert (Operational Profile)
überdeckend Implementierungsorientiert
Spezifikationsorientiert Steuerfluss Datenfluss (white-box)
(black-box)
(coverage) ...
Programmkonstruktion: Erstellung eines Programms p mit der berechneten A
E
fp : → fp
( )
x = fa( )
x ,Funktion und mit .
) ( ) ( )
Von t Є T
(
T:Testmenge E , fp t =fa t auffa(x) = fp(x),∀ x ∈ E
Programmtest:
schliessen.
hypothesenbasiert
⊆
∀ ∈x E
- Die „Kunst“ des Testens besteht darin, eine endliche Testmenge T so zu konstruieren, dass von fp(x) = fa(x) für x ЄT auf fp = fa geschlossen werden kann.
- Zu einer konkreten Eingabe x Є T liefert dann fa(x) = y Є A eine konkrete Antwort. Dieser konkrete Fall (x, fa(x)) wird Testfall genannt.
Unter Test verstehen wir :
Ein dynamischer (d.h. am laufenden System durchgeführter) Vorgang, um - Fehler zu erkennen, zu lokalisieren und zu korrigieren (im engeren
Sinne),
- die Leistungsfähigkeit bzgl. relevanter Merkmale (Richtigkeit, Effizienz, Zuverlässigkeit etc.) des Systems nachzuweisen (im weiteren Sinne).
Wartbarkeit
(Kann ich es „reparieren“?)
Flexibilität (Kann ich es ändern?)
Testbarkeit (Kann ich die Performance prüfen?)
Portabilität (Kann ich es auf einer anderen
Maschine Benutzen?)
Wiederverwendbarkeit (Kann ich Teile davon
wiederbenutzen?)
Interoperabilität (Kann ich es an ein anderes System
anschließen ?
Produkt-Operation
Korrektheit (Tut es was ich will?) Zuverlässigkeit (Tut es dies „immer“ so?)
Effizienz (Läuft es auf HW „am Wirksamsten“?)
Integrität (Ist es sicher? /Schützend/
geschützt, ...)
Benutzbarkeit (Kann ich es „gut fahren“?)
Qualitätsanforderungen / Entwicklungstätigkeiten
Funktionale Betrachtung
x aa AA
E A
EN
AN
e xn x an
x ea EA
P
P
e
x af P´
P x af
f x
testfall = (eingabe,erwartete ausgabe)
Beispiel: Testfälle: tf1 = (en,an), tf2 = (ea,aa), tf3 = (ef,af´)
Testfall-Satz:= {(en,an ), (ea,aa), (ef,af´)} (auch Test-Suite) genannt)
17.5 Software-Prüfung
Analyse (statisch) Test (dynamisch)
Semi-formale/Empirische Methoden
(Hybride Methoden) (Durchsichtsorientiert:
Review/Walkthrough/
Inspection, ...) Formale Verfahren
Nichtformale Verfahren (Korrektheitsbeweis, Symbolisches Testen, Algebraische Methoden,
(Dynamic)Assertions, ...) Implementierungsorientierter Test
Grey-Box-Test
Spezifikationsorientierter Test
(Black-Box-Test/Functional Test)
(White-Box-Test/Structural Test)
∑= n i
d
1
– Allgemein: p := i p : Anzahl Pfade
d : Anzahl Entscheidungen n : Anzahl Ausführungen
Implementierungsorientierung -->
Pfadorientierung
– 2 Entscheidungen, 1-malige Ausführung:
{abe, ace} → 21 = 2 Pfade – 2 Entscheidungen, 2-malige
Ausführung:
{abe, ace, abdbe, abdce, acdbe, acdce} → 22 + 21 = 6 Pfade
– 2 Entscheidungen, 3-malige Ausführung:
{...} → 23 + 22 + 21 = 14 Pfade
Beispiel
bed1
bed2
anw1 anw2
J J N
N
Programmablaufplan
b c
d
e a
Steuerflussgraph
325 + 324 + ... 31 = 1,2*1012 → 1 Billion Pfade!
ANFANG
ENDE Kessel- temperatur
höher als150°C Über-
druckventil hat sich ein- geschaltet?
Druck größer als
10 bar?
Ersatz- kühlsystem einschalten
Druck erhöhen
Temperatur erhöhen
N
J J
J
N
N
Wie viele Pfade entstehen bei diesem Programm bei 25-malige Wiederholung?
17.6 Darstellung des Steuer- und Datenflusses durch reguläre Ausdrücke
– Reguläre Ausdrücke können gebildet werden über eine Eingabemenge (Alphabet), z.B. X = {a,b,...,c} mit Hilfe der infix/postfix Operatoren
• Konkatenation (Sequenz): z. B. ab („b folgt a“)
• Selektion (Entscheidung): z. B. a+b („a oder b“)
• Iteration (Wiederholung): z. B. a* („null- oder mehrmals a“)
– λ : das leere Zeichen: das Leer-/unmögliche Ereignis;
λ* =: Ω: das leere Wort
– Die einzelnen Zeichen können als
• elementare Symbole oder
• Aktionen, Einzel- oder aggregierte Ereignisse/Zustände etc.
interpretiert werden.
– Beispiele: w1 = (ab)*, w2 = a(bc+d*)e
– Ein regulärer Ausdruck w stellt Regeln zur Bildung von
Zeichenketten (Wörtern) dar, d. h. w generiert die Sprache L(w).
– Beispiele:
w1 = (ab)* ⇒ L(w1) = {λ, ab, abab, ababab, ... }
w2 = a(bc+d*)e ⇒ L(w2) = {ae, abce, ade, adde, addde, ... }
– Endliche Automaten (Zustandautomaten) und reguläre Ausdrücke sind äquivalent in ihrer Mächtigkeit (erkennend bzw. generierend);
sie können ineinander überführt werden.
– Steuerflussgraphen können durch endliche Automaten dargestellt werden.
Beispiele zu regulären Ausdrücken und entsprechenden Endlichen Automaten
Notation: L (<regulärer Ausdruck>): die von <regulärer Ausdruck> erzeugte Sprache.
Regulärer Ausdruck
a
b c 1. L ((a+b)c) = {ac,bc}
Entsprechender Automat
a
c
e d
3. L (a ((bc) + d* )e) = {ae, ade, abce, adde, addde, ...} b
a b
2. L ((ab)*) = {λ, ab, abab, ababab, ...}
Elementare reguläre Ausdrücke und entsprechende Programmkonstrukte
Programm-Code Regulärer Ausdruck ohne Bedingung mit Bedingung
P (statement) S S
if P0 then P1 else P2 S1 + S2 S0 (S1 + S2) case P0 of
Q1: P1; ... Qn: Pn (S1 + ... + Sn) S0 (S1 + ... + Sn)
for i:=1 to n do P S* S*
while P0 do P S* S0 (S S0)*
repeat P until P0 SS* oder: S+ (S S0) (S S0)*
oder: (SS0)+
17.7 Dualität der Steuer- und Datenstrukturen und Operationen zu deren Manipulation
{
B;
C;
D;
}
Steuerstruktur
B D
A C Sequenz (Konkatenation)
Datenstruktur
A: struct ...
{
... B;
... C;
... D;
};
Operation
Operative Sprachkonstrukte - Sequenz
- Selektion
- Wiederholung
A: switch (...) {
case 1: B;
case 2: C;
case 3: D;
}
Steuerungsstruktur
B° D°
A C°
Selektion (Entscheidung)
A
B*
Wiederholung (Iteration/Rekursion)
Datenstruktur
A: while (...) B;
A: union ...
{
... B;
... C;
... D;
};
A: B[0] ... B[..];
Operation
a, b, c: reguläre Ausdrücke; λ: das leere Ereignis; Ω: das leere Wort := λ *
+: mindestens eine Ausführung/Erscheinung, d.h. a+ := a*a
A1: a + (b + c) = (a + b) + c A2: a (bc) = (ab) c
A3: a + b = b + a A4: a (b + c) = ab + ac A5: (a + b) c = ac + bc A6: a + a = a
A7: λ + a = a A8: λ a = λ
A9: λ *a = Ω a = a
A10: a* = λ * + a*a = Ω + a+ A11: a* = (λ * + a) *
Axiome der Ereignisalgebra
Pfadorientiertes Testen – Überführung in reguläre Ausdrücke
Beispiel
bed1
bed2
anw1 anw2
J J N
N
b c
d
e
Bestimme den regulären Ausdruck, a
der diesem Steuerflussgraphen entspricht.
Merging signals (inputs, outputs) and states leads to events for simpler analysis and test.
We focus on event sequences, that can also be generated as strings of L(G), or L(RegEx).
The result is an event sequence graph (ESG) the nodes of which are events and edges event sequences.
State Transition Diagram (STD) of the Finite-State Automaton
(FSA), e.g., Moore Machine
Event Sequence Graph (ESG) of the FSA
Both the FSA and ESG above are represented as the regular expression ab.
• Event sequence graphs (ESG) graphically visualize the behavior of the system under consideration (SUC) in accordance with the user expectations (specification) in that
– nodes represent user inputs/system reactions, or modules to realize system (sub)functions (responsibilities),
– connecting arcs (edges) represent neighbored events (event pairs, EPs).
• An initial event (“[”, entry) reaches each of other events, and a final one (“]”, exit) can be reached from all each of other events.
• Any event sequence (ES) that starts at the entry and reaches the exit is a complete event sequence (CES) that is a positive test case.
Example of an ESG:
T = [(ab(c+d)+)*] with
ab : b follows a
a+b: either a or b occurs (is executed) a* : arbitrary number of occurrences of a a+: a occurs at least once
Its algebraic Representation:
Example for a positive test case (CES): [abc]
• The inversion (complement) of an ESG includes all nodes of the ESG given and the arcs missed to make it a completely connected graph.
• The completed ESG includes the ESG given and its inversion (complement).
• Arcs of the inverted ESG are faulty EPs (FEPs), leading to fault model.
• To construct a negative test case, we extend an FEP “to the left”, i.e., add an appropriate ES or a CES as a prefix (starter ), making up a faulty complete event sequence (FCES).
Completed ESG
Inverted ESG
Example for a negative test case (CES): [abcb
Example of an elementary GUI (Graphical User Interface) application (copy-paste):
[ a b
a
] c
An example for an copy-paste (specification) :
Illegal (faulty) event sequences (FES) of length 2:
[ [, [b, [c, a[ , bb, b[, c [, cb.
Legal event sequences (ES) of length 2:
[a, ab, [ ], b], ba, bc, aa, cc, b], ba, ca, .. [a,
Test Coverage/Optimization problem:
- Determine a minimal set of copy-paste sequences as complete paths (walks) as positive tests of minimal total length to cover all ES of length n (n=2,3,4,...).
- Determine a minimal set of sub-complete paths (sub-walks) as negative tests of minimal total length to cover all FES of length n=2.
[ : entry menu; ]: exit menu,
a: click an object; b: copy an object, c: paste an object
[ (ab(a+c)*)*]
Coverage-Oriented „Debugging“
Module Test Sub-System Test Integration Test System Test . . .
„Bottom-up“-Test
„Top-down“-Test
„Sandwich“-Test
Hypothesis/ Method Selection Component Level Direction
Test Strategies
Control Flow-oriented (C0-,C1-, ..., C-Test) Data Flow-oriented (dd-, dk-, kk-, ... -Test)
. . .
White-Box(Implementation/Structure-oriented)
Black-Box(Specification/Function-oriented) Operational Profile
Sensitive
Cause-Effect Analysis
Equivalence Classes/Partition Test Special Value-/Domain Test
Diversity:Mutations-/Back-to-Back Test Statistic: Random-/Anti-Random Testing Goal-oriented
Acceptance/Release Test Regression Test
. . .
Einige bekannte Überdeckungskriterien (Coverage criteria)
– Anweisungsüberdeckung (C0): erfordert die mindestens einmalige Ausführung aller Anweisungen eines Programms.
– Zweigüberdeckung (C1): erfordert die Ausführung aller Zweige des Steuerflußgraphen eines Programms.
– Pfadüberdeckung (C): erfordert die Ausführung aller unterschiedlichen, vollständigen Pfade des Steuerflusses eines Programms.
– Es gilt: C > C1 > C0 mit der Relation „ >“(„mächtiger“)
- Bedeutung: Ci > Cj bedeutet, dass alle Testfälle, die durch das Kriterium Cj generiert werden, in der Menge der Testfälle enthalten sind, die durch das Kriterium C generiert werden.)
17.10 Allgemeine Test-Terminologie: Zusammenfassung des daten- und steuerflussorientierten Testens
Operationen in Pfaden
(1= suspicious : verdächtig; 2= bug : Fehler; 3= buggy : verdächtig)
*: don´t care (nothing of interest happens)
*k: ?anomalous? k*: normal
*d: normal d*: ?anomalous?
*u: ?anomalous? u* normal
dd: suspicious1 kd: normal ud: bug? normal?
dk: ?bug?2 kk: ?buggy?3 uk: normal
du: normal ku: bug3 uu: normal
d: defined, created, initialized, etc. (eingeführt) k: killed, undefined, released (freigegeben) u: used for something (benutzt)
c: used in a calculation (in arithmetischen Operation(en)) (Datenfluß) p: used in a predicate (in logischen Operation(en)) (Steuerfluß)
All *cuses All*c/some*p>
All paths >All dupaths > All uses > All defs(d´s) > Decisions > Basic Blocks All*p/some*c>
All *puses
x > y (x Stronger y) : <=> {a|a: test case produced by x} → {b|b: test case produced by y}
All *puses
>
branch
>
statement
– Automatische Test-Driver (ADT), – Test-Sprachen,
– Testfall-Generator.
17.11 Test-Hilfsmittel
All TESTCASES SUCCEEDED STATEMENT EXECUTED : 100%
BRANCHES TRAVERSED : 100%
Bericht eines bestandenen Tests
VERIFY FAILURE IN TEST CASE 2 AFTER TERMINATION
(SUB1: K.EQ.8.AND.SUB1: N.EQ.29) OUTPUT ERROR ON RECORD 3 OF LUN 10 IN TEST CASE 3
STATEMENTS EXECUTED ...
...
Report eines nichtbestandenen Tests
Test- Instrumentor
Sruktur- informa- tionen dekla- rationen
Statische Prüfung
Testtreiber/
Komparator
Testfall- Generator
Test- fälle
Test-Tool
Test- ergebnisse
Struktur- bericht Test-
Bericht
Testumgebung
Testverlauf - Fehlerentdeckung
Kosten bzw.
Anzahl der Fehler
Kosten pro entdecktem Fehler
Testterminierung
t kumulative Anzahl
entdeckter Fehler
17.12 Testverlauf und Testterminierung
Failure rate
Anzahl tatsächluich vorh. Fehler
t
1 t
Anzahl der Fehler
Gesamtanzahl entdeckter Fehler
Testterminierungsproblem
t
Reliability Prediction
Prediction Interval
t Period of
Observation
Prediction
t1
Approximation
o
Observed Errors
Failure Rate
Observed Failure Rate
Goal
Software Reliability
Selected/Recommended Reliability Models
– Jelinski-Moranda-Model,
– Bayesian Jelinski-Moranda-Model, – Schneidewind-Model,
– Geometric-Model,
– Generalized Poisson-Model, – Goel-Okumoto-Model,
– Musa-Okumoto-Model, (Basic Execution Model) – Yamada Delayed S-Shape-Model,
– Littlewood-Model,
– Littlewood Nonhomogeneous Poisson-Prozess-Model, – Littlewood-Verall-Model,
– Keiller-Littlewood-Model, – Brooks-Motley-Model, – Duane-Model.
(See also ANSI/AI AA R013-1992)
500 450 400 350 300 250 200 150 100 50 0
observed Errors
Optimistic Estimation
Commulative nb.
of observed/
estimated errors
1000 2000 3000 4000 5000 nb. of tests/time starting
Estimation
REALITY?
Pessimistic Estimation
Fault “Management”
Exception Handling
Plausibility Checks ...
. . .
Process Restart/Check- pointing
Recovery Block Techn.
Process Replication Fault Recovery
Formal Methods . . .
Non-formal Methods . . .
...
Consensus Recovery Block Technique
N-Version Programming
...
Watchdog
Diversitary Programming Defensive Programming
Fault Masking Fault Avoidance
Analysis Fault Removal/Test Construction
Fault Exclusion Fault Tolerance
Fault-Intolerant Development Fault-Tolerant Operating Quantification
Metrics/Reliability
Mathematical Methods Software Engineering Methods
...
Metrics/Reliability
Software Engineering Methods
Mathematical Methods
17.13 Exkurs: „Testen im Kleinsten“ – „Debugging“ während der Programmierung
- Programmierfehler werden auch als „Bugs“ bezeichnet (wörtlich übersetzt „Käfer/Wanzen“ (vergl.: „Es ist der ‚Wurm‘ drin!“).
- Gegenmaßnahme: „Debugging“ („Entwurmen“), d.h Fehler („Würmer“) herausnehmen.
- Programm-Instrumentierung: In Programmen werden
zusätzliche Befehle in den Programmcode aufgenommen – im einfachsten Fall printf-Anweisungen, die den momentanen Wert ausgewählter Variablen ausgeben.
- Damit die zusätzlichen Anweisungen oder Berechnungen nicht ständig ausgeführt bzw. compiliert werden, nutzt man die
„bedingte Compilierung“ mit Hilfe von Makros.
- Debugging ist keine Maßnahme im Sinne des „Systematischen“
Testens, sondern eher eine „Error-and-Trial“-Aktion während der Programmierung.
Beispiel: Bedingtes Kompilieren mit Makros
#include <stdio.h>
#define DEBUG void main () {
int erg;
erg = ...;
#ifdef DEBUG
printf("Wert der Variablen erg: %d \n", erg);
#endif }
Nur wenn das Makro DEBUG existiert, wird die printf-Anweisung compiliert und somit beim Programmstart ausgeführt!
Beispiel: Debugging mit Eclipse
- Komfortables Debugging eines Programms ist mit Eclipse möglich
- Start des Debuggers bzw. des Programms erfolgt über das „Käfer“-Symbol.
- Eclipse wechselt nun in die Debug-Perspektive (s. nächste Folie) - das Programm kann nun zeilenweise durchlaufen werden.
- Bedienelemente zur Steuerung
Ausführung bis zum nächsten Haltepunkt (1)
Abbruch des Programms (2)
Ausführung einer einzelnen Zeile (3)
…
- Ansicht von Variablen
- Ansicht der Werte des aktuellen Zustands - Möglichkeit zur Manipulation der Werte
- Anzeige des Quellcodes
Haltepunkte dienen dazu, die Ausführung an ausgewählten Punkten zu stoppen
die aktuell auszuführende Zeile wird angezeigt
Haltepunkt Aktuelle Zeile