Upload
inglebert-adelsperger
View
109
Download
1
Embed Size (px)
Citation preview
1© A. Spillner
Systematisches Testen
in der Software-Entwicklung
Prof. Dr. Andreas Spillner
Institut für Informatik und Automation Hochschule Bremen
Neustadtswall 30, 28199 Bremen
0421 5905-467 -412(FAX)[email protected]
www.fbe.hs-bremen.de/spillner
2© A. Spillner
Zum Einstieg
Ein Programm ist zu testen, das 3 ganzzahlige Werte einliest und als Längen eines Dreiecks interpretiert. Das Programm gibt eine Meldung aus, ob es sich um ein ungleichseitiges, gleichschenkliges oder gleichseitiges Dreieck handelt.
Meine Tests:
3© A. Spillner
ad hoc - Test
Tester
“… es läuft!”
“… gestern den wirklich allerletzten Fehler gefunden!”
4© A. Spillner
Qualitätssicherungsmaßnahmen
• konstruktive Qualitätssicherung
Einsatz von Methoden und Techniken zur Fehlervermeidung, vorbeugende Qualitätssicherung
– Einhaltung von Standards und Richtlinien
– ingenieurgemäße Software-Entwicklung (Software-Lebenszyklus-Modell)
– einheitliche Dokumentenerstellung
– …
• analytische Qualitätssicherung
Einsatz von Methoden und Techniken zur Fehlererkennung, prüfende Qualitätssicherung
– Prüf- und Kontrollmaßnahmen
– Analyse- und Testverfahren
– …
5© A. Spillner
weitere Begriffsdefinitionen
• Test, Analysegezielte Suche nach Fehlern (in sämtlichen Dokumenten der Software-Entwicklung)
• Fehlerlokalisierung (Debugging)Behebung der gefundenen Fehler
• Verifikation(mathematischer) Beweis der Korrektheit(auf Grundlage einer formalen Spezifikation)
• ValidationÜberprüfung einer allgemeinen Aussage(z.B. Prüfung der Kundenanforderungen)
6© A. Spillner
Statische Prüfverfahren
• Nachweisverfahren der Eigenschaften der Software oder des Dokuments
• Prüfling wird nicht ausgeführt
• erkannt werden nicht nur fehlerhaftes Verhalten sondern auch Fehlerursachen
• Korrektheit des Prüflings (bzgl. seiner Spezifikation) wird nicht bewiesen
• auf sämtliche Dokumente anwendbar
7© A. Spillner
Statische manuelle PrüfverfahrenReview-Techniken, allgemeine Inspektionstechnik [Fagan 1976]
Diese Technik ist
• seit Jahren bewährt
• erfolgreich, weil typischerweise ca. 80 % der Fehler kurz nach der Entstehung gefunden werden (Quelle: IEEE Software July 1996, p.99)
Kernpunkte
• Klassifikation der Fehler nach Art und Schwere
• Auswertung von Statistiken, um häufige Fehler zu erkennen (und zukünftig zu vermeiden)
• Einrichten von Checkpoints entlang eines Entwicklungspfads. Ein Checkpoint korrespondiert mit der Fertigstellung eines (Teil-)Produkts/ Dokuments.
• Für jeden Checkpoint werden Kriterien entwickelt, die eine Entscheidung erlauben, ob die Prüfung bestanden wurde.
Fangan, M.E.: Design and Code Inspections to Reduce Errors in Program Development.IBM Systems Journal, 15(3), 1976
8© A. Spillner
Beteiligte Personen
• Moderator - bereitet die Inspektion vor und führt den Vorsitz
• Autor
• ca. zwei weitere Personen
Ablauf
1. Der Autor versorgt vorher alle Teilnehmer mit Kopien des Dokuments und ggf. weiterem Material.
2. Die Teilnehmer bereiten sich vor, ggf. nicht nur ihre Erfahrung einsetzend, sondern auch Inspektions-Richtlinien, die die Erfahrung der Firma widerspiegeln, wo Fehler häufig auftreten.
3. Die eigentliche Inspektion findet statt. Eine vom Moderator benannte Person geht das Dokument durch, die Teilnehmer weisen auf (mögliche) Fehler hin. Der Moderator klassifiziert sie nach Schwere und Art und notiert sie. Er sorgt dafür, daß sich die Gruppe nicht in Diskussionen über Lösungen u.a. verliert, um Zeit zu sparen.
4. Nach der Inspektion verfaßt der Moderator den Inspektionsbericht, derfür den Autor (Analytiker, Designer, Programmierer ...) die Basis für Korrekturen darstellt.
Fagan Inspektion
9© A. Spillner
• Das Prüfobjekt soll in seiner Größe so bemessen sein, daß nicht mehr als zwei Stunden für das Review notwendig sind.
• Der Moderator ist dafür verantwortlich, daß alle gefundenen Punkte wirklich korrigiert werden.
• Wenn die Nacharbeit mehr als ca. 5% beträgt, soll das Prüfobjekt einer Re-Inspektion unterzogen werden.
• Die gefundenen Fehler dienen der Organisation, die Inspektions-Richtlinien zu verbessern.
Positive Nebeneffekte
• Verbreitung von Wissen und Verständnis im Team
• dadurch leichtere Übernahme der Aufgabe, falls der Autor das Team verläßt (Beförderung, anderes Projekt)
• Erhöhung der Verantwortlichkeit des Teams, ohne sie dem Autor zu nehmen
• besserer Team-Geist (falls gut gemanaged!)
Fagan Inspektion
10© A. Spillner
Statische werkzeuggestützte Prüfverfahren
• schnell und kostengünstig durchführbarmit Analysatoren (Werkzeuge)
• meist beschränktes Spektrum der auswertbaren Eigenschaften (bei Quellcodeanalyse sprachabhängig)
• gut dokumentiert und reproduzierbar
• Ergebnisse in Form von
– Listen
– Metriken
– Graphiken
11© A. Spillner
Statische werkzeuggestützte Prüfverfahren
• Analyse des Programmtextes(oder der formalen Spezifikation)
• Überprüfung der Einhaltung von Standards und Programmierrichtlinien(z.B. Schachtelungstiefe von Abfragen, Umfang der Module)
• Anomalieaufdeckung(z.B. nicht initialisierte Variablen, Nichtbenutzung von Werten, unerreichbarer Programmtext, Endlosschleifen)
12© A. Spillner
Beispiel - Datenflußanomalie
• Anomalieaufdeckung
Analyse des Gebrauchs einzelner Variablen:definiert (d), referenziert (r), undefiniert (u)…VAR Hilf: INTEGER;BEGIN
IF Min > MaxTHEN Max := Hilf; dd-Anomalie von Max
Max := Min; ur- und du-Anomalie Hilf := Min; von Hilf
END;
13© A. Spillner
Beispiel - Metrik von McCabe
• Analyse des ProgrammtextesErmittlung von Metriken
z.B. McCabe - zyklomatische Zahl(Programmtext in Kontrollflußgraphen überführt)
v(G) = e - n + 2p
v(G) - zyklomatische Zahl des Graphen Ge - Anzahl der Kanten des Kontrollflußgraphenn - Anzahl der Knoten des Kontrollflußgraphenp - Anzahl der verbundenen Komponenten(wenn Programm aus Unterprogrammen besteht)
14© A. Spillner
Beispiel - Metrik von McCabe
Berechnung der Metrik
e (Kanten) = 8n (Knoten) = 7p (Teile) = 1
v(G) = 8-7+2*1= 3
zyklomatische Zahl = 3
(Anzahl der unabhängigen Pfade im Programmstück)
Kontrollflußgraph (G)
n 1
n 2
n 3
n 5
n 4
…
…
Knoten Kontrollfluß
Programmstück
…
IF a>b
THEN IF b>c
THEN p(a,b)ELSE p(b,c);
print(a,b,c);
…
15© A. Spillner
Zusammenfassung
statische Prüfverfahren
• werden in der Praxis selten angewendet und
• oft in ihrer Wirksamkeit unterschätzt
• decken jeweils unterschiedliche Fehler(möglichkeiten) auf
16© A. Spillner
Dynamische Testverfahren
Testumgebung und Testdurchführung
• Test im eigentlichen Sinne: Ausführung mit Testdaten
• Testrahmen muß vorhanden sein
– Treiber (driver) zum Aufrufen des Testobjektes und zur Versorgung mit Eingabedaten
– Stellvertreter (stubs) zur Simulation der externen Funktionen, die von anderen Modulen bereitgestellt werden
Tests müssen
• wiederholbar sein (Regressionstests)
• nachvollziehbar sein
• dokumentiert werden
d.h. geplant und kontrolliert werden
17© A. Spillner
Testplanung & Kontrolle
• TestplanAuswahl der Prüflinge, der zu testenden Merkmale (Funktionalität, Lesbarkeit),der zu erfüllenden Kriterien, des Testabbruch und der -wiederaufnahme
• TestentwurfTeststrategie, Auswahl der Methoden, Konkretisierung der Kriterien
• Testfallermittlungautomatisch oder manuell
• TestvorgangsplanungDetailplanung, Reihenfolge der Testfälle
• Testdurchführung
• TestauswertungEntscheidung ob das Testobjekt den Test bestanden hat oder nicht
18© A. Spillner
Teststufen
• Modultest(Testen im Kleinen)Funktionen, Programmteile, Module
• Integrationstest(Testen im Großen)Montage der fertig getesteten ModuleTest des Zusammenspiels der Module (Schnittstellentest)
• Systemtest(Test des kompletten Systems)Außenverhalten des GesamtsystemsLaufzeit- und Streßtests, Benutzungsfreundlichkeit
19© A. Spillner
Entwicklungsphasen und Teststufen
Anforderungs-definition
IntegrationstestSystementwurf
Systemtest
Modulspezifikation und Implementierung Modultest
zeitlicher Ablauf Test erfolgt auf Grundlage von
20© A. Spillner
Entwicklungsphasen und Teststufen
Anforderungs-definition
IntegrationstestSystementwurf
Systemtest
Modulspezifikation und Implementierung Modultest
zeitlicher Ablauf Test-Überlegungen
21© A. Spillner
Testverfahren
• Testfall = Testdaten + erwartete Ergebnissemuß vor der Testdurchführung überlegt werden!
• Testobjekt wird mit konkreten Testdaten ausgeführt
• Testobjekt wird in der realen Umgebung getestet
• Stichprobenverfahren, welche die Korrektheit nicht beweisen können
• unterschiedliche Verfahren zur Aufdeckung von unterschiedlichen Fehlern
– Black-Box - Verfahren
– Glass-Box - Verfahren
22© A. Spillner
Black-Box - Testverfahren
Grundlage ist die Spezifikation des Testobjekts
• funktionaler Test
– funktionale Äquivalenzklassenbildung
• diversifizierender Test
– Mutationen-Test
– Back to Back-Test
• Zufallstest
• Test spezieller Werte
• Grenzwertanalyse
23© A. Spillner
funktionale Äquivalenzklassenbildung
• funktionale Eingabe- bzw. Ausgabeäquivalenzklassen
Definitionsmenge der Eingaben und die Wertemenge der Ausgaben werden so aufgeteilt, daß zu jeder Klasse genau eine spezifizierte Teilfunktionalität gehört und umgekehrt (Testdaten aus einer Klasse verursachen identisches funktionales Verhalten des Testobjektes)
BeispielPunktevergabe und Bußgeldbescheide bei Geschwindigkeitsübertretungen
Geschwindigkeitsüberschreitung> 10 km/h bewirkt Bußgeldbescheid über 20 DM> 20 km/h bewirkt Bußgeldbescheid über 50 DM und 1 Punkt in Flensburg> 30 km/h bewirkt Bußgeldbescheid über 100 DM und 2 Punkte in Flensburg…4 Klassen mit folgenden Testdaten: 5 km/h, 15 km/h, 28 km/h, 31 km/h, …
24© A. Spillner
Glass-Box - TestverfahrenGrundlage ist der Quelltext des Testobjekts
strukturorientierter Test
• kontrollflußbezogen
– Anweisungsabdeckung
– Zweigabdeckung
– Bedingungsabdeckung
– Pfadabdeckung
• datenflußbezogen
– Defs/Uses - Kriterien
– Datenkontext-Abdeckung
25© A. Spillner
kontrollflußbezogener Test Grundlagen
• Testkriterienanhand des Kontrollflusses
• KontrollflußgraphDarstellungsform des Programmtextes
• Instrumentierungzur Ermittlung der erreichten
Abdeckung
26© A. Spillner
Abdeckungsmaße
• AnweisungsabdeckungJede Anweisung im Testobjekt soll in der Testphase mindestens einmal ausgeführt werden.
Maß (C0) Anzahl der ausgeführten AnweisungenAnzahl aller Anweisungen
• ZweigabdeckungJede Bedingung im Testobjekt, die zur Änderung des Ablaufs führt, soll in der Testphase mindestens einmal den Wert TRUE und einmal den Wert FALSE liefern.
Maß (C1) Anzahl der ausgeführten ZweigeAnzahl aller Zweige
• PfadabdeckungAlle möglichen unterschiedlichen Abläufe des Testobjektes sollen in der Testphase einmal ausgeführt werden.
27© A. Spillner
Beispiel
Kontrollflußgraph
Knoten Kontrollfluß
Programmstück
…
IF a>b
THEN IF b>c
THEN p(a,b)ELSE p(b,c);
print(a,b,c);
…
n 1
n 2
n 3
n 5
n 4Zweigabdeckung:
n 1 n 2 n 3 n 5n 1 n 2 n 4 n 5
n 1 n 5
Anweisungs-abdeckung:
…
…
28© A. Spillner
kontrollflußbezogener TestZusammenfassung
• Konzentration auf Ablaufprüfung
• Ausführung von Kombinationen von Programmteilen
• unterschiedliche Abstufungen
• Werkzeugunterstützung notwendig
29© A. Spillner
Integrationstest
• Testen “im Großen”
• Test der Schnittstellen zwischen den Modulen / Komponenten
• Integrationsstrategien beim inkrementellen Integrationstest
– top-down
– bottom-up
– outside-in / inside-out
– hardest first
– nach Verfügbarkeit
• Integrationstestmethoden
– statische Integrationstest (Datenflußanomalien)
– dynamischer Integrationstest
• funktionsbezogen
• wertbezogen (Randwertprüfung)
• kontrollflußorientiert (Aufrufabdeckung)
• datenflußorientiert (Parameterverwendungsabdeckung)
30© A. Spillner
Systemtest
Aufgaben des Systemtests
• Funktionstest
• Leistungsprüfung (Streßtest)
• Mengengerüst
• Verfügbarkeit
• Sicherheit
• Konfiguration
• Kompatibilität
• Benutzungsfreundlichkeit
• …
31© A. Spillner
Tools können das Denken nicht abnehmen!
A fool with a tool is still a fool.
Werkzeuge
32© A. Spillner
Zusammenfassung & Ausblick
• Prüf- und Testverfahren sind in der Praxis von entscheidender Bedeutung
• Systematisches, strukturiertes Vorgehenkein ad hoc - Test
• sinnvolle Kombination unterschiedlicher Verfahren auswählen (statische und dynamische Verfahren, auch in Abhängigkeit des Testobjektes)
• Werkzeugunterstützung erforderlich
33© A. Spillner
State of the practiceder Prüf- und Testprozesse in der Software-Entwicklung
Ergebnisse einer Umfrage vom Herbst 1997, (74 Unternehmen):
• “Die Maßnahmen und Richtlinien des Prüfen und Testen werden nur in den wenigsten Unternehmen detailliert beschrieben, außerdem werden sie oft nicht eingehalten.
• Es wird nur ein Teil der geplanten Tests durchgeführt, da nicht genügend Mittel bereitgestellt werden. Die Einhaltung des finanziellen Budgets hat meist eine höhere Priorität als die komplette Prüf- und Testdurchführung.
• Die Prüf- und Testmethoden und -Techniken werden nur in wenigen Unternehmen eingesetzt. Die Testfälle werden intuitiv erstellt.
• Zum Einsatz der Werkzeuge ist anzumerken, daß der Debugger immer noch das weitverbreitetes Tool ist. Neuere Werkzeuge, z.B. Capture-Replay Tools, werden nur selten eingesetzt.
• Der Einsatz von Kennzahlen ist ein großer Problembereich. Nur wenige der teilnehmenden Unternehmen setzen Kennzahlen zur Verfolgung der Prüf- und Testdurchführung ein. Somit stehen kaum Planzahlen für spätere Projekte zur Verfügung.”
U. Müller, Th. Wiegmann: “State of the practice” der Prüf- und Testprozesse in der Software-EntwicklungErgebnisse einer empirischen Untersuchung bei Softwareunternehmen in Deutschland, Universität Köln, 1998
34© A. Spillner
Literaturhinweise
E.H. Riedemann:Testmethoden für sequentielle und nebenläufige Software-Systeme.B.G. Teubner Verlag 1997
VDI-GIS (Hrsg.):Software-Zuverlässigkeit: Grundlagen, konstruktive Maßnahmen, Nachweisverfahren.VDI - GIS (Gemeinschaftsausschuß Industrielle Systemtechnik) VDI-Verlag, 1993
P. Liggesmeyer: Modultest und Modulverifikation - State of the Art. B.I.- Verlag 1990
G.J. Myers: Methodisches Testen von Programmen.Oldenbourg Verlag 1995
E. Wallmüller: Software-Qualitätssicherung in der Praxis. Hanser Verlag 1990
B.-U. Pagel, H.-W. Six:Software Engineering (Band 1)Addison-Wesley Verlag 1994
H. Balzert:Lehrbuch der Software-Technik(Band 1 und 2) Spektrum Verlag, 1996 / 1998
GI-Fachgruppe 2.1.7:Test, Analyse & Verifikation von Software
www.fbe.hs-bremen.de/spillner/gi.htm
Arbeitskreise, Literaturhinweise, Treffen, Tagungen und andere Informationen
35© A. Spillner
Ein Vortrag desInstituts für Informatik und Automation der Hochschule Bremen
IIA
Institut für Informatik & AutomationHochschule BremenNeustadtswall 3028199 Bremen
0421 5905 [email protected]
Prof. Dr. Andreas Spillner
0421 5905 -467 -412(FAX)spillner@ informatik.hs-bremen.dewww.fbe.hs-bremen.de/spillner
I2A
36© A. Spillner
Lösung Aufgabe (Folie 2)
TestfälleEin Programm ist zu testen, das 3 ganzzahlige Werte einliest und als Längen eines Dreiecks interpretiert. Das Programm gibt eine Meldung aus, ob es sich um ein ungleichseitiges, gleichschenkliges oder gleichseitiges Dreieck handelt.
Testfälle = Testdaten + erwartetes Ergebnis
1. zulässiges ungleichseitiges Dreieck (2,3,4)
2. zulässiges gleichseitiges Dreieck (2,2,2)
3. zulässiges gleichschenkliges Dreieck (2,2,1)
4./5. 2 weitere Testfälle mit Permutationen für gleichschenklige Dreiecke (1,2,2), (2,1,2)
6. kein Dreieck (1,0,3) eine Seitenangabe = 0 (Permutationen?)
7. kein Dreieck (1,-5,9) eine Seitenangabe < 0 (Permutationen?)
8. kein Dreieck (1,2,3) Summe der beiden kürzeren Seiten = 3. Seitenlänge
9./10. Permutationen von Fall 8 (2,3,1), (3,1,2) (weitere möglich)
11. kein Dreieck (1,2,4) Summe der beiden kürzeren Seiten < 3. Seitenlänge
12./13. Permutationen von Fall 11 (2,4,1), (4,1,2) (weitere möglich)
37© A. Spillner
Testfälle14. kein Dreieck oder Fehlermeldung (0,0,0) alle Seiten = 0 (2 Seiten =0?)
15. Test mit maximalen Werten (Max_int,Max_int,Max_int) usw.
Test der Benutzungsschnittstelle
16. Fehlermeldung (1,1,4.4567) nichtganzzahlige Werte (Permutationen?)
17. Fehlermeldung (1,2,3,4) oder (2,3) falsche Anzahl von Werten
Wieviel hatten Sie sich überlegt?
aus G.J. Myers: Methodisches Testen von Programmen. 5. Auflage, R. Oldenbourg Verlag, München 1995
Werden spitz-, stumpf- und rechtwinklige Dreiecke zusätzlich berücksichtigt,
ergeben sich insgesamt 47 Testfälle.
E. H. Riedemann:Testmethoden für sequentielle und nebenläufige Software-Systeme. Teubner Verlag, Stuttgart 1997
Resümee: Einfaches Problem aber aufwendiger Test
38© A. Spillner
Beispiel Äquivalenzklassentest
Spezifikation
Ein Programm zur Lagerverwaltung einer Baustoffhandlung besitzt eine Eingabemöglichkeit für die Registrierung von Anlieferungen.
Werden Holzbretter angeliefert, so wird die Holzart (Eiche, Buche, Kiefer) eingegeben. Ferner wird die Länge in cm angegeben, die stets zwischen 100 und 500 liegt. Als Anzahl kann ein Wert zwischen 1 und 9999 angegeben werden. Außerdem erhält die Lieferung eine Auftragsnummer, die bei Holzlieferungen mit dem Buchstaben H beginnt.
aus Liggesmeyer: Modultest und Modulverifikation, S. 154-155
39© A. Spillner
Beispiel Äquivalenzklassentest
Äquivalenzklassenaufstellung
Eingabe gültige ÄK ungültige ÄK
Holzart 1) Eiche 4) Stahl
2) Buche
3) Kiefer
Länge 5) 100 ≤ Länge ≤ 500 6) Länge < 100
7) Länge > 500
Anzahl 8) 1 ≤ Anzahl ≤ 9999 9) Anzahl < 1
10) Anzahl > 9999
Auftragsnr. 11) erstes Zeichen H 12) erstes Zeichen kein H
40© A. Spillner
Beispiel Äquivalenzklassentest
Testfälle nach der Äquivalenzklassenanalyse
Testfall 1 2 3 4 5 6 7 8 9
getestete 1) 2) 3) 4) 6) 7) 9) 10) 12)ÄK 5)
8)11)
Holzart Eiche Buche Kiefer Stahl Buche Buche Buche Buche Buche
Länge 200 300 300 300 50 1000 200 200 200
Anzahl 100 200 100 100 100 100 0 50000 100
Auftragsnr. H1 H1 H1 H1 H1 H1 H1 H1 J2
41© A. Spillner
Beispiel Äquivalenzklassentest
Testfälle nach der Äquivalenzklassenanalyse und der Grenzwertanalyse
Testfall 1 2 3 4 5 6 7 8 9
getestete 1) 2) 3) 4) 6) O 7) U 9) O 10) U 12)ÄK 5) U 5) O
8) U 8) O11)
Holzart Eiche Buche Kiefer Stahl Buche Buche Buche Buche Buche
Länge 100 500 300 300 99 501 200 200 200
Anzahl 1 9999 100 100 100 100 0 10000 100
Auftragsnr. H1 H1 H1 H1 H1 H1 H1 H1 J2
42© A. Spillner