Vorlesung Softwaretest und - debugging

Technische Fakultät
Universität Bielefeld
Vorlesung
Softwaretest und - debugging
Version 2012
Dr. Carsten Gnörlich
Rechnerbetriebsgruppe
Kap. 1 - Einführung
(≅Kap. 2 aus Riedemann und Kap. 1 aus Zeller)
Eine F-16
(nördliche Halbkugel)
Bildquelle: Zeller
Dr. Carsten Gnörlich: Softwaretestmethoden
2
Eine F-16
(südliche Halbkugel)
Bildquelle: Zeller
Dr. Carsten Gnörlich: Softwaretestmethoden
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
Dr. Carsten Gnörlich: Softwaretestmethoden
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/
Dr. Carsten Gnörlich: Softwaretestmethoden
5
Quellenhinweis zum Debugging
Die Inhalte zum Debugging basieren auf:
Andreas Zeller:
Why Programs Fail
A GuideTo Systematic Debugging
dpunkt.verlag, Heidelberg, 2005
Dr. Carsten Gnörlich: Softwaretestmethoden
6
Was ist Testen und Debuggen?
Dr. Carsten Gnörlich: Softwaretestmethoden
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
Dr. Carsten Gnörlich: Softwaretestmethoden
8
Nebeneffekt des destruktiven Ansatzes
Testen ist nicht nur:
• Bestätigen der Qualität der Software
sondern auch:
• Erzeugen der Qualität von Software
Dr. Carsten Gnörlich: Softwaretestmethoden
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!
Dr. Carsten Gnörlich: Softwaretestmethoden
10
Begriffsverwirrung?
Testen
Debuggen
Dr. Carsten Gnörlich: Softwaretestmethoden
11
Das kommt auch noch hinzu...
Testen
Optimieren
Debuggen
Dr. Carsten Gnörlich: Softwaretestmethoden
12
Unterschiede zwischen Testen und Debuggen
Aufdecken von Fehlfunktionen
während der Entwicklung
beim Produktionsystem
Dr. Carsten Gnörlich: Softwaretestmethoden
13
Unterschiede zwischen Testen und Debuggen
Aufdecken von Fehlfunktionen
während der Entwicklung
beim Produktionsystem
Softwaretestmethoden
→ unbekannte Fehlfkt finden
Dr. Carsten Gnörlich: Softwaretestmethoden
14
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
Dr. Carsten Gnörlich: Softwaretestmethoden
15
Unterschiede zwischen Testen und Debuggen
Aufdecken von Fehlfunktionen
während der Entwicklung
beim Produktionsystem
Softwaretestmethoden
→ unbekannte Fehlfkt finden
Debuggen
→ bekannte Fehlfkt beheben
Finden der Fehlfunktion teuer
Fehlerlokalisation billig
→ „Nebenprodukt“;
ergibt sich aus den Testfällen
Finden der Fehlfunktion gratis
Fehlerlokalisation teuer
→Hauptaufwand!
Reproduktion, Lokalisierung
Dr. Carsten Gnörlich: Softwaretestmethoden
16
Abgrenzung zum Debuggen im Entwickl.-Zyklus
Testmanager
erste
Version
Fehlerbericht
Testen
Kunde
Testen
korr.
Version
Debuggen
Entwicklungsumgebung
Dr. Carsten Gnörlich: Softwaretestmethoden
Produktivumgebung
17
Testfälle immer in einer Datenbank aufheben!
Testmanager
erste
Version
Fehlerbericht
Testen
Kunde
Testen
neue
Version
Debuggen
Datenbank für Regressionstests
Dr. Carsten Gnörlich: Softwaretestmethoden
18
Warum Regressionstests?
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
Dr. Carsten Gnörlich: Softwaretestmethoden
19
Testen und Optimieren
Programm V0.10
einfach, stabil, langsam
Programm V0.90
Programm V1.00
Anzahl
Testfälle
Optimierung
Programm V2.00
komplex, schnell, stabil!
Dr. Carsten Gnörlich: Softwaretestmethoden
20
Testen: Einordnung in die Softwaretechnologie
• 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
Dr. Carsten Gnörlich: Softwaretestmethoden
21
Kosten für Fehlerbehebung
Kodierfehler
Entwurfsfehler
Anforderungsfehler
50,0
37,5
25,0
12,5
0
Anforderung
Entwurf
Kodierung
Dr. Carsten Gnörlich: Softwaretestmethoden
Strukturtest
Funktionstest
22
an
W . In
alk sp
Si -th ekti
m ro on
st ula ugh
at tio
isc n
dy h
na e A
Ve m. na
rifi An lys
Re kat aly e
gr ion se
Te es
s s.
m
Testen im Software-Lebenszyklus
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
Dr. Carsten Gnörlich: Softwaretestmethoden
23
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
Dr. Carsten Gnörlich: Softwaretestmethoden
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?
Dr. Carsten Gnörlich: Softwaretestmethoden
25
Wie generell sind die Methoden der Vorlesung?
• 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
Dr. Carsten Gnörlich: Softwaretestmethoden
26
It‘s not a bug, it‘s a feature...
Dr. Carsten Gnörlich: Softwaretestmethoden
27
Der erste Bug (9. September 1947)
Bildquelle: Zeller
Dr. Carsten Gnörlich: Softwaretestmethoden
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
Dr. Carsten Gnörlich: Softwaretestmethoden
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
Dr. Carsten Gnörlich: Softwaretestmethoden
30
Vom Defekt zur Fehlfunktion
1. Der Programmierer erzeugt einen
Defekt (Fehler im Programmkode).
Variables
✘
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.
t
Bildquelle: Zeller
31
Vom Defekt zur Fehlfunktion
1. Der Programmierer erzeugt einen
Defekt (Fehler im Programmkode).
Variables
✘
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.
t
Bildquelle: Zeller
31
Vom Defekt zur Fehlfunktion
1. Der Programmierer erzeugt einen
Defekt (Fehler im Programmkode).
Variables
✘
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.
✘
t
Bildquelle: Zeller
31
Vom Defekt zur Fehlfunktion
1. Der Programmierer erzeugt einen
Defekt (Fehler im Programmkode).
Variables
✘
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.
✘
Bildquelle: Zeller
31
✘
t
Vom Defekt zur Fehlfunktion
1. Der Programmierer erzeugt einen
Defekt (Fehler im Programmkode).
Variables
✘
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.
✘
Bildquelle: Zeller
31
✘
t
Was ist überhaupt eine Fehlfunktion?
• Nichterfüllung einer festgelegten Forderung:
➞ Fehlfunktion
unser Metier !
• Nichterfüllung einer
- beabsichtigten Forderung
- angemessenen Erwartung
➞ Mangel
• Mithin gibt es also Grauzonen:
- Benutzerfreundlichkeit
- Programm zu langsam
- Schachprogramm spielt zu schlecht
Dr. Carsten Gnörlich: Softwaretestmethoden
32
Wodurch entsteht falsche Programmierung?
Kommunikationsprobleme:
• Unvollständiger Entwurf
• Ungenauer Entwurf
Raum für Murphys law
• falsch interpretierter Entwurf
➡ Beschreibe es genau oder es geht schief!
• Entwurf verstanden, aber falsch programmiert
Dr. Carsten Gnörlich: Softwaretestmethoden
typische „Bugs“
33
Fehlerklassen - wie sie der Entwickler sieht
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
Dr. Carsten
Gnörlich: Softwaretestmethoden
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
Dr. Carsten Gnörlich: Softwaretestmethoden
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!
Dr. Carsten Gnörlich: Softwaretestmethoden
36
Warum ist Software so kaputt?
Dr. Carsten Gnörlich: Softwaretestmethoden
37
Ursachen fehlerhafter Software
Menschliche Fehlleistungen beim
• Austauschen
• Verarbeiten
• Speichern
von Informationen, die zur Software-Entwicklung benötigt werden.
Dr. Carsten Gnörlich: Softwaretestmethoden
38
3 Hauptformen der Kommunikation
1. Intrapersonale Kommunikation
• Denken und Wahrnehmen
(Informationsverarbeitung innerhalb des Menschen)
- Identitätsirrtum:
Wert an Variable brutto statt netto zuweisen
Dr. Carsten Gnörlich: Softwaretestmethoden
39
3 Hauptformen der Kommunikation
2. Interpersonale Kommunikation
• Informationsaustausch zwischen Gesprächspartnern
Sprecher
Kodier.
Übermittlung
Dekodier.
Hörer
- 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
Dr. Carsten Gnörlich: Softwaretestmethoden
40
3 Hauptformen der Kommunikation
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)
Dr. Carsten Gnörlich: Softwaretestmethoden
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 ein
extrem kleines kognitives Fenster!
Dr. Carsten Gnörlich: Softwaretestmethoden
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
Dr. Carsten Gnörlich: Softwaretestmethoden
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
Dr. Carsten Gnörlich: Softwaretestmethoden
44
Mentale Aspekte der
Softwareentwicklung
Dr. Carsten Gnörlich: Softwaretestmethoden
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.
Dr. Carsten Gnörlich: Softwaretestmethoden
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
Dr. Carsten Gnörlich: Softwaretestmethoden
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.
Dr. Carsten Gnörlich: Softwaretestmethoden
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!
Dr. Carsten Gnörlich: Softwaretestmethoden
49
Was tun?
Dr. Carsten Gnörlich: Softwaretestmethoden
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
Dr. Carsten Gnörlich: Softwaretestmethoden
51
Ideale Möglichkeiten um Defekte zu finden
im Papierstadium:
• Review (gedankliches Durchspielen)
- auch wieder Kommunikationsprobleme
• Simulation
- teuer, keine umfassenden
Systematiken verfügbar
Dr. Carsten Gnörlich: Softwaretestmethoden
52
Ideale Möglichkeiten um Defekte zu finden
im Papierstadium:
im Programmstadium:
• Review (gedankliches Durchspielen) • Verifikation
- auch wieder Kommunikationsprobleme
- Korrektheit beweisen
• Simulation
- teuer, keine umfassenden
Systematiken verfügbar
• idealer Test
- für n Defekte reichen n Testfälle
• erschöpfender Test
- alle Eingabemöglichkeiten
durchprobieren
Dr. Carsten Gnörlich: Softwaretestmethoden
53
Ideale Möglichkeiten um Defekte zu finden
im Papierstadium:
im Programmstadium:
• Review (gedankliches Durchspielen) • Verifikation
- auch wieder Kommunikationsprobleme
- Korrektheit beweisen
• Simulation
- teuer, keine umfassenden
Systematiken verfügbar
• idealer Test
- für n Defekte reichen n Testfälle
• erschöpfender Test
- alle Eingabemöglichkeiten
durchprobieren
scheitert alles an Berechenbarkeit!
Dr. Carsten Gnörlich: Softwaretestmethoden
54
Ideale Möglichkeiten um Fehler zu finden
im Papierstadium:
im Programmstadium:
• Review (gedankliches Durchspielen) • Verifikation
- auch wieder Kommunikationsprobleme
- Korrektheit beweisen
• Simulation
- teuer, keine umfassenden
Systematiken verfügbar
• idealer Test
- für n Defekte reichen n Testfälle
• erschöpfender Test
- alle Eingabemöglichkeiten
durchprobieren
→ stichprobenhaftes Testen!
Dr. Carsten Gnörlich: Softwaretestmethoden
55
Stichprobenhaftes Testen
• statisch überprüfen oder
• dynamisch testen
Unser Thema!
➡ Anwesenheit bestimmter Fehler-/Defekttypen antizipieren und ausschließen
➡ hohe Kunst: an den „richtigen“ Stellen zu suchen / testen
Dr. Carsten Gnörlich: Softwaretestmethoden
56
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
Dr. Carsten Gnörlich: Softwaretestmethoden
57
Organisation
Dr. Carsten Gnörlich: Softwaretestmethoden
58
Umfang
• 2 V + 2Ü = 3 LP
• unbenoteter Schein, Kriterium ist Bearbeitung der Übungen
Dr. Carsten Gnörlich: Softwaretestmethoden
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
Dr. Carsten Gnörlich: Softwaretestmethoden
60
Ende der heutigen Vorlesung
Danke fürs Zuhören!
Bis nächste Woche :-)
Dr. Carsten Gnörlich: Softwaretestmethoden
61