• Keine Ergebnisse gefunden

- Nach der Implementierung (Programmierung): Analyse und Prüfung des Programms.

N/A
N/A
Protected

Academic year: 2022

Aktie "- Nach der Implementierung (Programmierung): Analyse und Prüfung des Programms."

Copied!
57
0
0

Wird geladen.... (Jetzt Volltext ansehen)

Volltext

(1)

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.

(2)

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)

(3)

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“.

(4)

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

(5)

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

(6)

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

(7)

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,

(8)

Bedeutung

Benutzer/

Erzeuger

Semiotik (Zeichenlehre)-basierte Betrachtung

Semantik

Metazeichen (Konstrukt) Syntaktische

Fehler

Pragmatik Syntaktik

(Syntax) Stigmatik

Bezeichnetes Stigmatische

Fehler

Zeichen Pragmatische

Fehler

Semantische Fehler

(9)

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

(10)

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

(11)

Testfallbezeichner: ____________________________________________________

Zweck: _____________________________________________________________

Voraussetzungen/Vorbedingungen: _______________________________________

Eingaben: ___________________________________________________________

Erwartete Ausgaben: __________________________________________________

Nachbedingungen: ____________________________________________________

Involvierte Testverläufe: _______________________________________________

Datum Ergebnis Getestete Software/Version Durchgeführt von

Typische Testfallbeschreibung

(12)

„Sammle erst die Fakten, dann kannst Du sie verdrehen,

wie es Dir passt.“

Mark Twain

(13)

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“)

(14)

Undesirable events

Faults

Failures

(15)

Non-occurence of unauthorized

disclosure / improper

alteration of Information

(Security) (Security)

Non-occurrence of catastrophic conse- quences onto environ- ment

(Safety)

Security / Safety

(Security)

(16)

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.

(17)

Programmbeweis: Nachweis von vollständig und mit mathematischen Mitteln.

( ) ( )

x f x fp = a

Nutzungprofilorientiert (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),

xE

Programmtest:

schliessen.

hypothesenbasiert

∀ ∈x E

(18)

- 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).

(19)

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

(20)

Funktionale Betrachtung

x aa AA

E A

EN

AN

e xn x an

x ea EA

P

P

e

x af

P x af

f x

testfall = (eingabe,erwartete ausgabe)

Beispiel: Testfälle: tf1 = (en,an), tf2 = (ea,aa), tf3 = (ef,a)

Testfall-Satz:= {(en,an ), (ea,aa), (ef,a)} (auch Test-Suite) genannt)

(21)

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)

(22)

= 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

(23)

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?

(24)

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

(25)

– 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.

(26)

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, ...}

(27)

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)+

(28)

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

(29)

A: switch (...) {

case 1: B;

case 2: C;

case 3: D;

}

Steuerungsstruktur

A

Selektion (Entscheidung)

A

B*

Wiederholung (Iteration/Rekursion)

Datenstruktur

A: while (...) B;

A: union ...

{

... B;

... C;

... D;

};

A: B[0] ... B[..];

Operation

(30)

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

(31)

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.

(32)

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.

(33)

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]

(34)

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

(35)

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)*)*]

(36)

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

. . .

(37)

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.)

(38)

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ß)

(39)

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

(40)

– Automatische Test-Driver (ADT), – Test-Sprachen,

– Testfall-Generator.

17.11 Test-Hilfsmittel

(41)

All TESTCASES SUCCEEDED STATEMENT EXECUTED : 100%

BRANCHES TRAVERSED : 100%

Bericht eines bestandenen Tests

(42)

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

(43)

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

(44)

Testverlauf - Fehlerentdeckung

Kosten bzw.

Anzahl der Fehler

Kosten pro entdecktem Fehler

Testterminierung

t kumulative Anzahl

entdeckter Fehler

17.12 Testverlauf und Testterminierung

(45)

Failure rate

Anzahl tatsächluich vorh. Fehler

t

1 t

Anzahl der Fehler

Gesamtanzahl entdeckter Fehler

Testterminierungsproblem

(46)

t

Reliability Prediction

Prediction Interval

t Period of

Observation

Prediction

t1

Approximation

o

Observed Errors

Failure Rate

Observed Failure Rate

Goal

Software Reliability

(47)

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)

(48)
(49)

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

(50)

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

(51)

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.

(52)

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!

(53)

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.

(54)
(55)

- Bedienelemente zur Steuerung

ƒ Ausführung bis zum nächsten Haltepunkt (1)

ƒ Abbruch des Programms (2)

ƒ Ausführung einer einzelnen Zeile (3)

ƒ

(56)

- Ansicht von Variablen

- Ansicht der Werte des aktuellen Zustands - Möglichkeit zur Manipulation der Werte

(57)

- 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

Referenzen

ÄHNLICHE DOKUMENTE

Das Zweite ist, dass mir im Umgang mit den Schülern im Laufe meiner 20-jährigen Berufstätigkeit doch be- wusster wird, dass beispielsweise die Anzahl der Schüler, die auch

Stochastic Processes I Winter term 2007/2008 (Stochastik

Use also the facts that R with the usual topology is second countable and that every family of pairwise disjoint nonempty open sets must be countable.)7. Let (X, τ ) be the

Fachbereich Mathematik und

Cloud Computing (SS2018) Faculty of Computer Science and Engineering Frankfurt University of Applied Sciences.. Your

What

The game Geography is played by two players on a directed graph G = (V, E) with a distin- guished starting position u. The first player starts at