Technische Fakultät Universität Bielefeld Vorlesung ...cg/folien/st01.pdf · Technische Fakultät...

Technische FakultätUniversität Bielefeld

Vorlesung

Softwaretest und - debuggingVersion 2012

Dr. Carsten Gnörlich

Rechnerbetriebsgruppe

Kap. 1 - Einführung

(≅Kap. 2 aus Riedemann und Kap. 1 aus Zeller)

Dr. Carsten Gnörlich: Softwaretestmethoden

Eine F-16(nördliche Halbkugel)

Bildquelle: Zeller

2


Eine F-16(südliche Halbkugel)

Bildquelle: Zeller

3


Heute haben wir folgendes vor

• Übersicht über den Vorlesungsinhalt

- Was sind Testen, Debugging, Optimierung?

- Was ist überhaupt ein Fehler?

- Warum ist Software fehlerhaft?

- Mentale Aspekte des Testens

- Ausblick über die weiteren Vorlesungen

• Formalitäten klären:

• Übungstermin, Leistungspunkte

4


Quellenhinweis zum Testen

Die Inhalte zum Testen basieren auf:

Eike Riedemann:Testmethoden für sequentielle und nebenläufige Software-Systeme Teubner, Stuttgart, 1997

Momentan nur herunterladbar:

http://ls10-www.cs.uni-dortmund.de/~riedemann/

5




Quellenhinweis zum Debugging

Die Inhalte zum Debugging basieren auf:

Andreas Zeller: Why Programs Fail A GuideTo Systematic Debugging dpunkt.verlag, Heidelberg, 2005

6


Was ist Testen und Debuggen?

7


Was ist Testen?

„Testen ist der Prozeß, ein Programm mit der Intention auszuführen, Fehlfunktionen zu finden.“

→ destruktive Sichtweise

Erfolgreicher Testfall:

→ Eingabe t erzeugt falsches Verhalten

Nicht erfolgreicher Testfall:

→ Programm zeigt korrektes Verhalten

8


Nebeneffekt des destruktiven Ansatzes

Testen ist nicht nur:

• Bestätigen der Qualität der Software

sondern auch:

• Erzeugen der Qualität von Software

9


Ablauf des (dynamischen) Testens

1. Bestimme gültigen oder ungültigen Eingabewert

2. Bestimme das erwartete Verhalten

3. Führe das Programm aus und betrachte das Verhalten

4. Vergleiche tatsächliches Verhalten mit erwartetem Verhalten

Wenn irgendwie möglich: Automatisiere den Vergleich!

10


Begriffsverwirrung?

11

Testen

Debuggen


Das kommt auch noch hinzu...

12

Testen

OptimierenDebuggen

Dr. Carsten Gnörlich: Softwaretestmethoden 13

Unterschiede zwischen Testen und Debuggen

Aufdecken von Fehlfunktionen

während der Entwicklung beim Produktionsystem





Softwaretestmethoden→ unbekannte Fehlfkt finden





Debuggen→ bekannte Fehlfkt beheben = zufällige Fehlfkt b. Kunden






Debuggen→ bekannte Fehlfkt beheben

Finden der Fehlfunktion gratisFehlerlokalisation teuer→Hauptaufwand! Reproduktion, Lokalisierung


Finden der Fehlfunktion teuerFehlerlokalisation billig→ „Nebenprodukt“; ergibt sich aus den Testfällen


Abgrenzung zum Debuggen im Entwickl.-Zyklus

17

Testen

Fehlerbericht

Debuggen

Kunde

Entwicklungsumgebung Produktivumgebung

Testen

Testmanager

korr.Version

ersteVersion


Testfälle immer in einer Datenbank aufheben!

18

Testen

Fehlerbericht

Debuggen

Datenbank für Regressionstests

Kunde

Testen

Testmanager

neueVersion

ersteVersion


Warum Regressionstests?

19

Fehlfunktionen kommen manchmal wieder

• via Versionskontrolle: cvs, svn, mercurial

- mergen mit alten defekten Versionen

• via (de-)maskierung:

- Fehlfunktion A wird durch unkorrekte Programmänderung B „behoben“

→neuer Defekt B maskiert nun Fehlfunktion A

- Nachdem B gefixt ist tritt Fehlfunktion A wieder auf

→Fehlfunktion A schnell erkennen

→verhindere daß erneut der falsche Fix B angewandt wird


Testen und Optimieren

20

Programm V0.10

Programm V0.90

Programm V1.00

Programm V2.00

Optimierung

einfach, stabil, langsam

komplex, schnell, stabil!

AnzahlTestfälle


Testen: Einordnung in die Softwaretechnologie

21

• Konstruktive Methoden (Erstellung)

- Anforderungsdefinition, Entwurf, Programmierung

• Analytische Methoden (Messen, Bewerten)

- Qualitätssicherung, Testen

Wichtig:

- nicht erst konstruieren, dann testen

- sondern begleitend zu allen Ebenen des Softwarezyklus


Kosten für Fehlerbehebung

0

12,5

25,0

37,5

50,0

Anforderung Entwurf Kodierung Strukturtest Funktionstest

Kodierfehler Entwurfsfehler Anforderungsfehler

22


Testen im Software-Lebenszyklus

23

1. Anforderungsdefinition

• Korrektheit, Vollständigkeit, Konsistenz• Testfälle vorbereiten

2. Entwurf

• Konsistenz, Vollständigkeit Systemstruktur• fehlende Fälle, Schnittstellen, fehlerh. Logik•Testfälle für interne Funktionen angeben

3. Realisierung / Kodierung

• Kode überprüfen und ausführen

4. Wartung = Beginn klass. Debugging

• Fehler beseitigen ohne neue zu erzeugen

man. In

spek

tion

Walk

-thro

ugh

Simula

tion

statis

che A

nalys

e

dyna

m. Ana

lyse

Verifi

katio

n

Regres

s.-

Tests


Testen: Abgrenzung zu anderen Verfahren

Verifikation

• formaler Korrektheitsbeweis

+ theoretisch die ideale Methode

- automatisches Beweisen nicht möglich

- manuelles Beweisen stupide und fehleranfällig

Nachteile gegenüber Testen:

• Testen überprüft mehr als formale Korrektheit (Robustheit, Spezifikation)

• Testen überprüft auch die Programmumgebung

24


Testen: Abgrenzung zu anderen Verfahren

Simulation

• Modell der Software ausführen

+ früher Einsatz möglich

+ Systeme ohne reale Umgebung testbar (eingebettete Systeme, Kernenergie)

- Übereinstimmung Simulation / Realität?

- Korrektheit des Simulators?

25


Wie generell sind die Methoden der Vorlesung?

26

• Paßt auf bash, awk, C/C++, Java, Lisp, Excel,...

• anwendbar auf so gut wie jedes Menschenwerk(alles sollte man beizeiten testen!)

• unabhängig von

- bestimmten Softwarewerkzeugen

- anderen Vorlesungen

• Techniken des Testens sind zeitlos

- im Gegensatz zu Programmiertechniken, die „Modeerscheinungen“ sind


It‘s not a bug, it‘s a feature...

27


Der erste Bug (9. September 1947)

Bildquelle: Zeller

28


Software-Bugs entmystifiziert

Häufige Fehlwahrnehmungen:

• Fehler dringen von außen in das Programm ein

• Fehler entstehen zufällig / aus heiterem Himmel

➡ kompletter Unfug!

Stattdessen:

• Fehler sind von Anfang an im Programm

• oder durch spätere Koderevisionen erzeugt worden

➡ menschliche Fehlleistungen des Programmierers

29


Begriff des „Bugs“ ist zu breit gewählt

Defekt: Nicht korrekter Programmkode (ein Bug im Programmkode)

Infektion: Nicht korrekter Zustand (ein Bug im Zustand)

Fehlfunkion: Nicht korrektes Verhalten (ein Bug im Verhalten/Ausgabe)

Abgrenzung: flaw (Entwurfsfehler) - der richtig böse Fall

Psychologie:

• „bug“ / „issue“ klingen dem Kunden gegenüber verniedlichend

• „error“ / „fault“ für den verantwortlichen Programmierer belastend

30

31

✘

1. Der Programmierer erzeugt einen Defekt (Fehler im Programmkode).

2. Bei seiner Ausführung erzeugt der Defekt eine Infektion - einen Fehler im Programmzustand.

3. Die Infektion breitet sich aus.

4. Die Infektion erzeugt eine Fehlfunktion.

Vom Defekt zur Fehlfunktion

Variables

t

Bildquelle: Zeller

31

✘






✘

✘

Variables

t

Bildquelle: Zeller

31

✘






✘

✘

✘ ✘

Variables

t

Bildquelle: Zeller

31

✘






✘

✘

✘

✘ ✘

Variables

t

Bildquelle: Zeller


Was ist überhaupt eine Fehlfunktion?

• Nichterfüllung einer festgelegten Forderung: ➞ Fehlfunktion

• Nichterfüllung einer- beabsichtigten Forderung- angemessenen Erwartung➞ Mangel

• Mithin gibt es also Grauzonen:

- Benutzerfreundlichkeit

- Programm zu langsam

- Schachprogramm spielt zu schlecht

32

unser Metier !


Wodurch entsteht falsche Programmierung?

Kommunikationsprobleme:

• Unvollständiger Entwurf

• Ungenauer Entwurf

• falsch interpretierter Entwurf

➡ Beschreibe es genau oder es geht schief!

• Entwurf verstanden, aber falsch programmiert

33

Raum für Murphys law

typische „Bugs“


1. Funktionsfehler- Funktionalität falsch spezifiziert (→ neuer Entwurf!)

2. Schnittstellenfehler- Programmkomponenten interagieren falsch (z.B. falsche Parameterlisten)

3. Algorithmusfehler- Implementierung ist falsch oder uneffizient

4. Zuweisungsfehler- Berechnungsfehler bei Startwerten oder Zuweisungen

5. Abfragefehler- fehlerhafte oder fehlende Abfragen zerstören die Programmlogik

6. Synchronisations- / Zeitfehler- Zugriff auf gemeinsam Ressourcen

7. Konfigurationsfehler- Verwendung von Bibliotheken der falschen Version- Probleme im Änderungsmanagement / Versionskontrolle

8. Dokumentationsfehler- korrekt realisiert, aber falsch dokumentiert

Fehlerklassen - wie sie der Entwickler sieht

34


Einstufung von Fehlern nach ihrer Schwere- wie es der Projektmanager sieht

0. Katastrophal - Weltuntergang

1. Kritisch- Produktionsausfall; Aufgabe nicht mehr erfüllbar

2. Hoch- Produktion / Leistung herabgesetzt

3. Mittel- Verhinderung der vollen Ausnutzung der Programmöglichkeiten; Workaround existieren

4.Niedrig- kosmetische Probleme; Leistung bleibt erhalten

5. Unproblematisch- nicht geforderte Softwareverbesserung

35


Küchenschaben-Theorie

➡ Eine Küchenschabe kommt selten allein

• Fehler treten gehäuft auf

- manche Module sind fehlerfrei

- andere sehr fehlerbehaftet

‣ in der Umgebung eines Fehlers nach weiteren suchen!

36


Warum ist Software so kaputt?

37


Ursachen fehlerhafter Software

Menschliche Fehlleistungen beim

• Austauschen

• Verarbeiten

• Speichern

von Informationen, die zur Software-Entwicklung benötigt werden.

38


3 Hauptformen der Kommunikation

1. Intrapersonale Kommunikation

• Denken und Wahrnehmen (Informationsverarbeitung innerhalb des Menschen)

- Identitätsirrtum:

Wert an Variable brutto statt netto zuweisen

39



2. Interpersonale Kommunikation

• Informationsaustausch zwischen Gesprächspartnern

- Erklärungsirrtum: A gesagt, aber B gemeint

- Übermittlungsirrtum: Mitarbeiter gibt entgegengenommen Anruf falsch wieder

- Entschlüsselungsirrtum:- Information falsch gelesen / gehört- Unterschiedliche Sprache / Fachsprache

- Inhaltsirrtum: Mißverständnis über qualitative/quantitative Eigenschaften

40

Sprecher HörerÜbermittlung Dekodier.Kodier.



3. Mediengebundene Kommunikation

• kleine Gruppe von Kommunikatoren (z.B. Journalisten)

• große Gruppe von Rezipienten (z.B. Zeitungsleser)

➝ gleiche Probleme wie bei interpersonaler Kommunikation

Typische Ausprägungen bei der Softwareentwicklung:

•große Projekte mit Projektleitern und Programmierern

•Online-Medien (Wikis, Foren, Online-Dokumentationen)

41


Kognitive Einschränkungen

Zu wenig RAM im Gehirn!

• zwar einige TB Langzeitgedächnis

• aber nur 5 - 9 Token / Worte Kurzzeitgedächtnis!

→ reicht maximal für 2 Schleifen inklusive Kontext!

→ erhebliches Handicap beim Nachvollziehen von Programmkode!

Genau wie ein Maurer das Haus Stein für Stein baut

• schreiben wir Programme Zeile für Zeile

• wir betrachten/manipulieren Programme durch einextrem kleines kognitives Fenster!

42


Nicht-kommunikative Fehlerquellen

• Komplexität der Systeme

- „Denken wie ein Computer“(vorherige Folie: Alle beteiligten Variablen etc. im Kopf behalten)

- Verstehen von Nebenläufigkeiten

• mangelndes Problemverständnis

- algorithmische Lösung unzutreffend / unbekannt

• fehlende Information der Beteiligten

• Streß, Übermüdung, fehlende Motivation

43


Ein paar Statistiken

• Anzahl Defekte im Entwicklungszyklus:

30 - 100 pro 1000 Zeilen Programmkode

• Anzahl Defekte im fertigen Produkt:

1.5 bis 5 pro 1000 Zeilen Programmkode (95% der Defekte werden gefunden)

• Verteilung:

2/3 im Entwurf; 1/3 bei der Programmierung

15% aller Defekte sind schwerwiegend

44


Mentale Aspekte der Softwareentwicklung

45


Psychologisches Problem

• Spezifikation, Entwurf, Programmierung: konstruktiver Prozeß

• Testen: destruktiver Prozeß (alles kaputtmachen)

Typischer Lernprozeß:

1. Optimismus: Mein Programm ist perfekt, Testen nicht nötig!

2. Bockigkeit: Oh, mein Programm ist falsch. Ich teste aber trotzdem nicht!

3. Resignation: Ich teste nur noch und gebe das Programm nie mehr frei.

4. Goldener Mittelweg: Ich weiß wann man mit dem Testen aufhören kann.

46


Folgerungen aus der Psychologie des Testens

• „Selbstloses“ (egoless) Programmieren

➡ nicht „mein“ Programm testen, sondern

➡ Produkt testen und verbessern

➡ jeder gefundene Fehler ist einer weniger

• Programm nicht durch die Entwickler testen lassen

- persönliche Distanz

- Mißverständnisse beim Interpretieren der Spezifikation

- Zielkonflikte wie z.B. Einhalten der Zeitvorgaben vermeiden

47


Täuschungen bei der Inspektion von Programmkode

• Trick- oder Ablauftäuschung

- Programmausdruck tut nicht das was man erwartet

- *c++ = *++a + b[*a]

• Erwartungstäuschung

- Kommentar sagt nicht das aus was das Programm tut

- /* Den Wert n-mal aufaddieren */for (i=1; i<n; i++) ...

• Überdeckungstäuschung

- Nicht alle Software-Testmethodon finden subtile Fehler.

48


Täuschungen bei der Inspektion von Programmkode

• Hemmungstäuschung

- in einem vorherigen Kontext gelernte Zusammenhänge gelten nicht mehr:

- Morgenstern, Abendstern, Zwergelstern

• Wiederholungstäuschung

- scheinbar gleiche Vorgänge haben unterschiedliche Ergebnisse

- Kopierte und leicht veränderte Programmteile!

49


Was tun?

50


Vermeidung oder Behebung von Fehlern?

Erinnerung - Fehlerursachen sind:

• Kommunikative Fehler

• sonstige (Komplexität, mangendes Verständnis/Info/Motivation, Streß, etc.)

➡ Ausschluß dieser Ursachen praktisch unmöglich

➡ Defekte wird es immer geben

➡ Defekte durch analytische Prozesse finden und beheben

51


Ideale Möglichkeiten um Defekte zu finden

52

im Papierstadium:

• Review (gedankliches Durchspielen) - auch wieder Kommunikationsprobleme

• Simulation - teuer, keine umfassenden Systematiken verfügbar



53

im Papierstadium:



im Programmstadium:

• Verifikation- Korrektheit beweisen

• idealer Test- für n Defekte reichen n Testfälle

• erschöpfender Test- alle Eingabemöglichkeiten durchprobieren



54

im Papierstadium:



im Programmstadium:




scheitert alles an Berechenbarkeit!


Ideale Möglichkeiten um Fehler zu finden

55

im Papierstadium:



im Programmstadium:




→ stichprobenhaftes Testen!


Stichprobenhaftes Testen

• statisch überprüfen oder

• dynamisch testen

➡ Anwesenheit bestimmter Fehler-/Defekttypen antizipieren und ausschließen

➡ hohe Kunst: an den „richtigen“ Stellen zu suchen / testen

56

Unser Thema!


Ausblick

• Statisches Testen (Quellkode analysieren)

➡ Defekte direkt aufdecken; Lernen „sicher“ zu programmieren

• Dynamisches Testen (Programm mit Testfällen ausführen)

➡ Lernen Testfälle zu generieren (= wonach man suchen muß)

• Techniken zum Debugging

➡ Lernen Defekte zu finden

• Methoden um Programme besser testbar / debugbar zu machen

➡ spezielle Entwurfs- und Programmiertechniken

57


Organisation

58


Umfang

• 2 V + 2Ü = 3 LP

• unbenoteter Schein, Kriterium ist Bearbeitung der Übungen

59


Wer hat Interesse an den Übungen?

• Inhalt der Übungen:

- Spielen mit einer Software 2D/3D-Engine

- 2 Aufgaben pro Woche, 1-2h Bearbeitungszeit

➡ Testen / Debuggen

➡ Interesse an C und Computergrafik auf niedrigem Abstraktionsniveau

• Wer hat Interesse an den Übungen?

• Termin: Freitag 12:30 (wegen Mittagessen ;-) im GZI, V2-222

60


Ende der heutigen Vorlesung

Danke fürs Zuhören!

Bis nächste Woche :-)

61

Technische Fakultät Universität Bielefeld Vorlesung ...cg/folien/st01.pdf · Technische Fakultät...

Documents

Transcript of Technische Fakultät Universität Bielefeld Vorlesung ...cg/folien/st01.pdf · Technische Fakultät...