Grundlagen der Programmierung 1 Softwaretechnik Modul ... · Modul: Programmierung B-PRG Grundlagen...

Modul: Programmierung B-PRG Grundlagen der Programmierung 1 – Teil 2

Softwaretechnik

Prof. Dr. O. DrobnikProfessur Architektur und Betrieb verteilter SystemeInstitut für InformatikFachbereich Informatik und Mathematik

Softwaretechnik

Kapitel 3 – Verifikation, Testen und Debugging

Grundlagen der Programmierung 1

3.1 Korrektheit der Software3.2 Testen3.3 Debugging

© J.W.G-Universität Frankfurt a.M.Praktikum Grundlagen der Programmierung Folie 3

Übersicht – 3. Verifikation, Testen und Debugging

3.1 Korrektheit der Software3.2 Testen

3.2.1 Glass-Box-Test3.2.2 Black-Box-Test3.2.3 Testbegriff und –vorgehen

3.3 Debugging


3.1 Korrektheit der Software:Vorgehensweisen: Beweisen, Testen, Debugging

Beweisen (statische Methode): Theoretischer Nachweisder Korrektheit für alle zugelassenen Eingabedaten(Problem: Beweise können fehlerhaft sein!).Testen (dynamische Methode):

Ausführung des Algorithmus mit einer bestimmtenDatenmenge, den Testdaten (Ablaufprotokoll). Verifikation durch Austesten ist nur bei einemüberschaubaren endlichen Definitionsbereich derEingabedaten möglich. Testen zeigt nur, daß Fehler vorliegen, nicht aber, daß der Algorithmus keine Fehler enthält.

Debugging (dynamische Methode): Finden und Beheben von Fehlern


Korrektheit Algorithmus

Begriff Korrektheit: Definieren über Spezifikation undNiederschrift eines Algorithmus (textuelle Repräsentation):

Spezifikation: Was wird vom Algorithmus erwartet?Niederschrift: Vorschrift zur Durchführung einzelner Aktionenin der bestimmten, dem Algorithmus entsprechendenReihenfolge.

Zerlegung der funktionalen Spezifikation in die Aussage P und Q:Vorbedingung P: alle Eigenschaften vor Ausführung.Nachbedingung Q: alle Eigenschaften nach derAusführung

Transformation von P zu Q :

QAlgorithmusP


Korrektheit Algorithmus

Verifikation: Nachweis der Korrektheit einesAlgorithmus gegenüber der Spezifikation: Algorithmuserfüllt Spezifikation.

Totale Korrektheit: Bei Eingangsgrößen gemäßVorbedingung kommt Algorithmus zum Ende, und Ausgangsgrößen entsprechen Nachbedingung.Partielle Korrektheit: Bei Eingangsgrößen gemäßVorbedingung entsprechen Ausgangsgrößen derNachbedingung, falls der Algorithmus terminiert.

Terminierung: Die Ausführung des Algorithmus endetnach endlicher Zeit.


Zum Begriff Zusicherung

Basis des Zustandsraumes: alle Variablen des Programms und deren möglichen WerteZustand der Variablen: Werte der VariablenZustand der Ausführung des Programms und damit der Berechnung:

alle Variablen des Programms und deren Werteaktuell betrachtete Anweisung

Vorbedingung, Nachbedingung:Zusicherung über Zustand


Nachweis der partiellen Korrektheit (1)

Grundidee: Zeige, dass, wann immer ein Algorithmus endet(oder eine Ausgabe erzeugt), das Ergebnis die Nachbedingung erfüllt.

Vorbedingung

Ausführung desAlgorithmus

Nachbedingung

P

A

Q


Vor- und Nachbedingung

A sei eine Anweisung in einer imperativen Programmiersprache (Prädikat) Die Zusicherungen P bzw. Q beschreiben den Zustand der Programmausführung vor bzw. nach der Anweisung A.Wenn die Ausführung von A in einem durch P beschriebenen Zustand nach endlich vielen Schritten zu dem durch Q beschriebenen Zustand führt, soll die Zusicherung

{P} A {Q} gelten: Zusicherung über den Ablauf:

P ist Vor- und Q Nachbedingung einer solchen Anweisung A.

Beispiel: Eine Zuweisung i:=8 liefert:{P: i beliebig } i:=8 {Q: i = 8 }

({P} Λ A → {Q} ) → {P} A {Q}


Nachweis der partiellen Korrektheit (2)

P

Q

A1

An

P1

Pn

Q1

Qn

Vorbedingung: P → P1

Vorbedingung: Qn-1 → Pn

Nachbedingung: Q1 → P2

Vorbedingung P

Nachbedingung Q

Nachbedingung: Qn → Q

Algorithmus A


Nachweis der Terminierung

Nichtterminierung: die Ausführung des Algorithmus benötigt unendliche Zeit.

Kritisch: die durch Iteration und Rekursion verursachten Wiederholungen

Terminierungsnachweis: durch vollständige Induktion:Induktionsannahme: Alle Einzelschritte terminieren.Induktionsschluß: Es treten im Algorithmus selbst keine unendliche Schleifen und keine unendlichen Rekursionen auf.

Formale Methoden: z.B. Hoare, Dijkstra


Beispiel Achterbahn-Zahlen

r ∈ Nat

while r > 1:if r % 2 == 0:

r = r / 2else:

r = 3 * r + 1


Beispiel Achterbahn-Zahlen

3, 10, 5, 16, 8, 4, 2, 1622, 11, 34, 17, 52, 26, 13, 40, 20, 10, 5, 16, 8, 4, 2, 174, 2, 18

16, 8, 4, 2, 152, 1410, 5, 16, 8, 4, 2, 1312-1

Werte von r bis zur Terminierungr zu Beginn

Terminierung:r = 2k ?Beliebige Werte ?


Verifikation – Niederschrift Algorithmus

Verifikation:Bezug zu Niederschrift des AlgorithmusAussage über alle möglichen Durchführungen, durchTests i.a. grundsätzlich nicht erreichbar. Zu solchenAussagen sind notwendig:

Abstraktion von den einzelnen möglichenAusführungen des Algorithmus.Ableitung von allgemeingültigen Bedingungen ausdem Verhaltensmuster, der Niederschrift des Algorithmus.

Anstelle der Aufzeichnung von spezifischen Wertenwährend jeder Ausführung tritt die Aufzeichnung vonallgemeingültigen Beziehungen zwischen Variablen (Ein-und Ausgabegrößen) nach jeder Aktion bzw. Anweisung.


Statische - dynamische Techniken

Statische Techniken: die Analyse der verfügbarenSystemrepräsentationen (also Anforderungs-dokumente, Entwurfsdiagramme oder Programmcode):Überprüfung der Übereinstimmung zwischen Programmund einer Spezifikationzu jedem Zeitpunkt des Entwicklungsprozesses

Dynamische Techniken: Durchführung anhand einerkonkreten Programmimplementierung (oder einesPrototypen): nur in fortgeschritteneren Phasen des Entwicklungsprozesses anwendbar, da eine lauffähigeImplementierung nötig istValidierung


Verifikation – Validation

Überprüfungen des Produkts :Verifikation: Inwieweit erfüllt das Produkt die in der Spezifikation zusammengefaßten Anforderungen? Validation (Validierung): Inwieweit erfüllt das Produkt die Erwartungen des Benutzers, die er mit dem Produkt verbindet und die u.U. nicht vollständig durch die Spezifikation abgedeckt sind?

Unterschied zwischen Verifikation und Validierung:Validierung: Bauen wir das richtige Produkt?Verifikation: Bauen wir das Produkt richtig?


3.2 Testen

Ausführen des Programms auf Rechner mit vorgegebenen EingabedatenVergleich der erhaltenen Werte, d. h. der Ausgabedaten, mit dem gemäß Spezifikation eigentlich zu erwartenden Ergebnis


Test - Ziele

Ausführung der Software mit dem Ziel, Fehlerwirkungennachzuweisen. Ausführung der Software mit dem Ziel, die Qualität zubestimmen. Ausführung der Software mit dem Ziel, Vertrauen in die Software zu erhöhen.Analysieren der Software oder der Dokumente, um Fehlerwirkungen vorzubeugen.

Es sollte auch geprüft werden, dass die Software keineweitere, u. U. unerwünschte Funktionalität zur Verfügungstellt.


Auswahl der Testfälle

Entwickleri. a. Auswahl von Testfällen, die den erwartetenEingaben entsprechen.meist unbewußte Vermeidung von Testfällen, die dieHypopthese – das Programm läuft korrekt – wirklichbelasten, sie auf die Probe stellen bzw. siewiderlegen.Interesse keine Fehler zu finden.

Tests von fremden Personen duchführen zu lassen.Egoless Programming (selbstloses Programmieren): Korrektheit des Gesamtsystems sollte im Vordergrundstehen, und nicht welches Teammitglied welche Fehlermacht.


Testmethoden

Glass-Box-TestGrundlage: Spezifikation und ImplementierungBlack-Box-TestGrundlage: Spezifikation der Schnittstellen


3.2.1 Glass-Box-Test

Statische Programmanalysen:

Überprüfung des Programms auf Vollständigkeit und Konsistenz z.B. inkonsistente Datendeklarationen, Parameterfehler, Datentypverletzungen (wird i.a. durch Compiler im Rahmen der syntaktischen und semantischen Analyse durchgeführt).

Review, Code-Auditing, Walkthrough: Überprüfen, ob vorgegebene Programmierregeln eingehaltenwurden, z. B. Überprüfen der Modulgröße, derVerschachtelungstiefe der Ablauflogik, derVerwendung verbotener Konstrukte/Anweisungen(wie goto, Durchführung von Schreibtischtests) usw.


Dynamische Programmanalyse

Bsp:Berechnung des Maximums zweier ganzer Zahlen

def max(x, y):max = 0if x <= y : max = yreturn max

Anweisungsüberdeckung:Eine Testmenge T, bei der jede Anweisung mindestenseinmal durchlaufen wird, wäre: T = {(2, 5)} Programm ist inkorrekt. Dies wird durch T nicht erkannt.


Eigenschaften von Überdeckungsmaßen

Ablaufbezogenes Testen weist folgende Eigenschaften auf:Es lässt sich nur eine bestimmte Klasse von Fehlernauffinden, z. B. grobe Abbruchfehler, unerreichbareZweige, Irrpfade, endlose Schleifen.Nicht erkannt werden können z. B. Tippfehler, inkonsistente Schnittstellen, Abweichung von derSpezifikation.

Überdeckungsmaße (coverage):1. Anweisungsüberdeckung2. Ablaufzweigüberdeckung3. Ablaufpfadüberdeckung



Bsp: Berechnung des Maximums zweierganzer Zahlen

Anweisungsüberdeckung:

def max(x, y):max = 0if x <= y : max = yreturn max

Eine Testmenge T, bei der jede Anweisung mindestenseinmal durchlaufen wird, wäre: T = {(2, 5)} Programm ist inkorrekt. Dies wird durch T nicht erkannt.

Ablaufzweigüberdeckung (Entscheidungsüberdeckung):

Eine Testmenge T, bei der jeder Ablaufzweig überdecktwird, wäre:

T = {(2, 5), (7, 3)} Der Fall (7, 3) deckt obigen Fehler auf.© J.W.G-Universität Frankfurt a.M.Praktikum Grundlagen der Programmierung Folie 26

Bsp: Berechnung des Maximums von dreiganzen Zahlen

Die Testmenge {(2, 1, 3), (4, 10, 6)} reicht zur Entscheidungsüberdeckung aus.

Wenn x = max gilt, entsteht jedoch ein Fehler, der nicht erkannt wird.

Dieser kann nur mit Ablaufpfadüberdeckung erkannt werden.

def max(x,y,z):if x >= y: max = xelse: max = y;if z >= max: max = z else: max = yreturn max


Bsp: Berechnung des Maximums von dreiganzen Zahlen (2)

Nötige Fälle für die Ablaufpfadüberdeckung:

def max(x,y,z):if x >= y: max = xelse: max = yif z >= max: max = z else: max = yreturn max

y > x und y > z4z >= y > x3x >= y und x > z2z >= x >= y1EigenschaftenFall Beispiel:

T={(2,1,3),(3,2,1),(1,2,3),(1,3,2)}


Die Anzahl Überdeckungen wächst schnell

Beispiel

Mit jedem Schleifendurchgang entstehen viele neue Kombinationen.Für größere Programme ist ein vollständiger Test aller Überdeckungen nicht realisierbar.

def max(list):maxlist = []for i in range (len(list)):

x,y,z = list[i][0],list[i][1],list[i][2]if x >= y: max = xelse: max = yif z >= max: max = z else: max = ymaxlist.append(max)

return maxlist


Beispiele für sinnvolle Testfälle

Besonders auf die Grenzen des Eingabebereichs achtenBeispiel: Funktion auf [-1.0,1.0] definiert.

Testdaten: -1.0 und 1.0 sowie -1.001 und 1.001Ist bei einer Funktion der Ausgabebereich definiert, Werte suchen, die als Ergebnis die Grenzen des Ausgabe-bereichs treffen (und wenn möglich sogar verlassen).Bei komplexeren Datenstrukturen wie z.B. Listen oder Matrizen können die leere Liste und die 0-Matrix als Grenzfälle angesehen werden.Zusätzlich noch Tests mit sehr großen Zahlen, Strings oder Listen durchführen, um auch Puffer-, Datei- und Speichergrenzen zu testen.


Beispiel search_sort

def search_sort(list):sorted_list =[]

last_min = min(list)maximum = max(list)sorted_list.append(last_min)

for i in range(len(list)-1):next_min = maximumfor l in list:

if l > last_min and l < next_min:next_min = l

sorted_list.append(next_min)last_min = next_min

return sorted_list

search_sort sucht immer das nächst größere „Minimum“ und hängt es an die Ausgabeliste


Testen von search_sort

Testen auf beliebige Eingaben:>>> search_sort([7,6,2,9,4])[2, 4, 6, 7, 9]>>> search_sort([1234,856,3465,9067])[856, 1234, 3465, 9067]

führt zu keinen Fehlern.Das Testen einer trivialen Grenze

>>> search_sort([0,0,0,0,0,0,0])[0, 0, 0, 0, 0, 0, 0]

ergibt auch keinen Fehler.Erst bei besonderen „Grenzfällen“ treten Fehler auf:

>>> search_sort([1,2,3,3,4])[1, 2, 3, 4, 4]


Ablaufbezogenes Testen

Rechnergestütztes Erstellen eines Ablaufprotokolls.

Instrumentierung des Programms mit Meßpunkten:

Meßpunkt: Boolsche VariableInitialisierung: falsePassieren: true

Hilft bei der Überprüfung, ob z.B. alle intendierten Programmstellen durchlaufen werden.


Instrumentierung


Problematik des ablaufbezogenen Testens

Prozeß: Ein Prozeß ist die Ausführung einesProgramms in seinem Adreßraum.Adressraum: logisch in einem zusammenhängendenSpeicher organisiert mit folgender Struktur:

Programm.Statische Daten (z B. globale Variablen).Dynamische Daten:

Stack (Kellerprinzip): z. B. blocklokale Variablen, Speicher für Parameterübergabe an Funktionen.Heap (Haldenprinzip): z.B. dynamische Objekte, die blockübergreifend benötigt werden.


Problematik des ablaufbezogenen Testens

Prozess: hängt von der Ablaufumgebung ab, d. h. von Hardware, Betriebssystem und weiteren Prozessen, mitdenen der Prozess kommuniziert bzw. interagiert oderum Betriebsmittel (Ressourcen) konkurriert.

Ablaufbezogenes Testen kann daher erheblicherschwert werden, da u. U. Fehlerzustände nurschwierig oder gar nicht reproduziert werden können.


3.2.2 Black-Box-Test

Das System wird als nicht einsehbares System aufgefasst, dessen Verhalten nur über das Beobachten seiner Ein- und Ausgaben ermittelt werden kann.

Testfälle werden aus der Spezifikation eines Systems oder einer Komponente abgeleitet.

Die Eingabedaten eines Programms lassen sich unterschiedlichen Klassen mit gemeinsamen Charakteristika zuordnen (z.B. positive Zahlen, negative Zahlen, Strings ohne Leerzeichen). Die verschiedenen Elemente einer solchen Klasse weisen meist äquivalentes Verhalten auf.


Black-Box-Test

Ziel: die Menge der Eingabedaten so partitionieren, dass das System für die Elemente einer einzelnen Partition zueinander äquivalente Ergebnisse berechnet. Die Partitionen können sich dabei auch überlappen.

Richtlinien bei der Auswahl von Testfällen sind:1.Man berücksichtige Testfälle im Partitionszentrum (d.

h. typische Werte). 2.Man berücksichtige Testfälle an Partitionsgrenzen.

Dies sind oft atypische Werte, deren korrekteBehandlung von Programmierern manchmalvernachlässigt werden.


Beispiel: Die Spezifikation eines Programms schreibtEingabewerte vor, die aus einer 5-stelligen Integerzahl, die größer als 10000 ist, bestehen.

Hinweis: In der Praxis wird beim Testen oft eine Mischung aus Glass- und Black-Box-Test-Vorgehen gewählt.


3.2.3 Systematisches Testen

Begriffe:

Zur Präzisierung des Testbegriffs führen wir folgende Begriffe ein:Fehler: die Nichterfüllung einer festgelegten Anforderung, eine Abweichung zwischen dem Istverhalten und dem Sollverhalten (Spezifikation)Mangel: wenn eine gestellte Anforderung oder eine berechtigte Erwartung nicht angemessen erfüllt wird. z. B. die Beeinträchtigung der Verwendbarkeit bei gleichzeitiger Erfüllung der Funktionalität oder die Nichterfüllung einer angemessenen Erwartung.Fehlerwirkung (engl. failure):

die Wirkung eines Fehlerzustands, die bei der Ausführung des Testobjekts nach außen in Erscheinung tritt.die Abweichung zwischen spezifiziertem Sollwert und beobachtetem Istwert.

Weitere Bezeichnungen für Fehlerwirkung sind Fehlfunktion,äußerer Fehler oder Ausfall.


Fehlerwirkung, Auftreten und Ursache

Zwischen dem Auftreten einer Fehlerwirkung und derenUrsache muss unterschieden werden:

Eine Fehlerwirkung hat ihren Ursprung in einemFehlerzustand (engl. fault): Defekt, innerer Fehler, oderengl. bug. Dies ist z. B. eine falsch programmierte odervergessene Anweisung im Programm. Ein Fehlerzustand kann möglichereise durch einen odermehrere andere Defekte in anderen Teilen der Software kompensiert sein, d. h. es liegt eine Fehlermaskierung vor. Eine Fehlerwirkung wird dann u. U. erst nach der Korrekturder maskierenden Fehlerzustände erkennbar.Ursache für das Vorliegen eines Fehlerzustands oder Defektsist die vorangegangene Fehlhandlung (engl. error) einerPerson, z. B. die fehlerhafte Programmierung durch den Entwickler.


Systematisches Testen (1)

Ein einfaches Vorgehensmodell für das systematischeTesten von Software könnte wie folgt strukturiert sein:1. Testplanung: Festlegung der Reihenfolge des Testens

einzelner Programmabschnitte, Prozeduren usw.:Aufruffolge: z. B. erst Prozeduren testen, die keineweiteren aufrufen.Datenfluss: Prozeduren, die Daten erzeugen, vordenen testen, die diese Daten benötigen.



2. Testvorbereitung:Testmenge ermittelnfür jedes Element der Testmenge SollergebnissebeschreibenTestumgebung (Testbett) erstellen: Nachbildung derUmgebung des Testobjekts (Programm- Abschnitt, Prozedur, usw.)

Prozeduren, die das Testobjekt aufruft, liegenentweder bereits getestet vor oder werden durchPlatzhalter mit gleicher oder ähnlicher Funktionersetzt (Dummy). i. a. sehr komplex, Testumgebung testen.



3. Testdurchführung: Dabei geht man nach folgenden Punkten vor:

Vortesten des Programms: Schreib- und andereSyntaxfehler eliminieren.Schreibtischtest: Zuerst wird die Programmlogiküberprüft, dann manuell ein Ablaufprotokoll erstellt. Testläufe mit den geplanten Testmengendurchführen und protokollieren: Instrumentierungdes Testobjekts.



4. Testauswertung:Testläufe auswerten: Vergleich der Ergebnisse mitden Sollergebnissen.Fehlerlokalisierung und Fehlerbeseitigung.Schrittweise Ersetzung von Platzhaltern durch die echten, bereits getesteten Testobjekte und erneutesTesten: RegressionstestsErkenntnisse aus Verifikation für Testen nutzen: Man fügt Zusicherungen (Assertionen) in den Programmtext (z. B. Schleifeninvarianten) ein und sieht an diesen Stellen entsprechendeÜberprüfungen bzw. Ausgabeanweisungen vor.


3.3 Debugging

Begriff bug:in der Informatik: ”bug“ als Synonym für Programmfehlerim 19. Jahrhundert: Bezeichnung für kleinen Fehler in mechanischen und elektronischen Teilen bezeichnet (Th. Edison 1878). 9.9.1945: Computerpionierin Grace Hopper kommentierteim Logbuch des Mark II Aiken Relay Calculator mit den Worten ”first actual case of bug being found”, dass eineMotte das Schließen eines Relais verhindert und damiteine Fehlfunktion des Rechners verursacht hatte.Dijkstra: Begriff als Synonym für Programmfehler nichtadäquat, da für Programmfehler der Programmierer und nicht irgendeine Wanze verantwortlich gemacht werdenkönne.


The First Computer Bug (1)


The First Computer Bug (2)


Debugging

weitere Bezeichnungen: Fehlerbereinigung, FehlerkorrekturAuffinden, Diagnostizieren und Eliminieren von FehlerzuständenMeistens ist von einem Fehler nur die Wirkung ersichtlich, jedoch nicht die eigentliche UrsacheDie Aufgabe des Debugging ist es, von der Wirkung auf den eigentlichen Fehler zurückzuschliessen. Dies setzt die Vertrautheit mit dem Programm und seiner Ablauf-umgebung voraus.Unterscheidung:

PrimärfehlerSekundärfehler


Testen vs. Debugging

Testen: auf Defekte hinweisende Fehlerwirkungen gezielt und systematisch aufdecken. Debugging: Defekte lokalisieren, analysieren und beheben.Testen und Debugging sind unterschiedliche und getrennte Aufgabenund unterscheiden sich vor allem in der Art der mit ihr assoziiertenAktivitäten.Testen erzeugt Testfälle sowie -berichte über Erfolg oder Misserfolgvon Tests und ist damit eine konstruktive Aktivität, die – wie z. B. die Konstruktion von Software als Resultat Code liefert – darauf abzielt, greifbare Ergebnisse zu produzieren. Debugging ist primär eine kognitive Tätigkeit, denn das Ergebnis istkonkretes Wissen über das Programm, seines Ablaufs und derWechselwirkung mit seiner Umgebung:

Warum eine gegebene Menge von Eingabedaten einnichtakzeptables Verhalten eines Programms verursacht undWas geändert werden muss, um das Verhalten akzeptierbar zumachen.


Debugging

Debugging lässt sich grob als iterierendeAbfolge von Schritten strukturieren:

Erkennen eines FehlerzustandsEingrenzen und Isolieren des Defekts. Erstellen einer Hypothese über die Ursache für den Defekt.Testen der HypotheseKorrigieren des Programms.Testen des korrigierten Programms


Maßnahmen und Prinzipien (1)

Die einzelnen Schritte können durch folgende Maßnahmenund Prinzipien wirksam unterstützt werden:

Überprüfen, ob die Fehlerzustände reproduzierbar sind, d. h. z. B. ein- und denselben Testfall mehrfachdurchführe.Reduktion von Testmengen: Bestimmen der kleinstenEingabemenge, die den Fehlerzustand zuverlässigverursacht (dient auch zur Eingrenzung des Fehlers).


Maßnahmen und Prinzipien (2)

Experimentieren: Ändere Bedingungen der Tests graduell, um zu ermitteln, ob der Fehlerzustandverschwindet.

Erfahrung sammeln im systematischenProgrammverstehen (Verifikation, Testen und Debugging).

Hartnäckigkeit in der Suche nach den Fehlerursachen.


Möglichkeiten zur Visualisierung

Ausgabe von interessanten Variablen:print-AnweisungRealisierung solcher Anweisungen durch bedingteAusdrückeif <Bedingung>:

print "DEBUG: %s" % variable_01Assert AnweisungEntwicklung einer eigenständigen Testumgebung (Testbed) für den AlgorithmusWerkzeug: Debugger


Debugger (1)

Unterstützung der Visualisierung von internenProgrammstrukturen während der Laufzeitspezifisch für Programmiersprachenintegraler Bestandteil der verwendetenEntwicklungsumgebungUntersuchung von ProgrammzuständenReproduktion von Fehlerzuständen


Debugger (2)

Kontrollierter Ablauf des ProgrammcodesAblaufverfolgung (tracing) in einzelnen Schritten (single-stepping) zwischen definierten Haltepunkten (breakpoints)Haltepunkt:

Überprüfung ob Variablen geforderte Werte aufweisenexplizites Setzen von Werten für Variablen

Schrittweise Fortschreitung:Untersuchung der Nachbarschaft der Programmstelle:Eingrenzung, Lokalisierung, Isolierung der Fehlerstelle

Unterprogramme : gezielt untersuchen oder überprüfenOrientierung: herausfinden, welche Stelle des Programms gerade aktuell ist.


Debugger (3)

oft mehrere Debugger für eine Programmiersprache mit unterschiedliche Stärken und Schwächen.Python:

Python Debugger (in IDLE enthalten)pdbddderic3

Probleme beim Debugging:Programm weist unter der Kontrolle eines Debuggers ein anders Zeitverhalten auf als ohne Debugger.Analyse von Threads oder parallelen Prozessen.


Beispiel: Debuggen von search_sort

Python Debugger starten


Beispiel: Debuggen von search_sort (2)

Das Debugger-Fenster öffnet sich

Dann Python-Programm öffnen



Programm ausführen (F5)Der Debugger übernimmt die Kontrolle



Im unteren Bereich werden alle globalen und lokalen Variablen angezeigt, somit kann festgestellt werden an welcher Stelle der Fehler entsteht.

Mit dem Befehl Step wird genau ein Schritt des Programms ausgeführt

Grundlagen der Programmierung 1 Softwaretechnik Modul ... · Modul: Programmierung B-PRG Grundlagen...

Documents

Transcript of Grundlagen der Programmierung 1 Softwaretechnik Modul ... · Modul: Programmierung B-PRG Grundlagen...