Systematisches Testen in der Software-Entwicklung

Präsentation zum Thema: "Systematisches Testen in der Software-Entwicklung"—  Präsentation transkript:

1 Systematisches Testen in der Software-Entwicklung
Prof. Dr. Andreas Spillner Institut für Informatik und Automation Hochschule Bremen Neustadtswall 30, Bremen (FAX)

2 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 ad hoc - Test Tester “… es läuft!” “… gestern den wirklich allerletzten Fehler gefunden!”

4 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 weitere Begriffsdefinitionen
Test, Analyse gezielte 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 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 Statische manuelle Prüfverfahren
Review-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 Fagan Inspektion 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, der für den Autor (Analytiker, Designer, Programmierer ...) die Basis für Korrekturen darstellt.

9 Fagan Inspektion 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!)

10 Statische werkzeuggestützte Prüfverfahren
schnell und kostengünstig durchführbar mit 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 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 Beispiel - Datenflußanomalie
Anomalieaufdeckung Analyse des Gebrauchs einzelner Variablen: definiert (d), referenziert (r), undefiniert (u) … VAR Hilf: INTEGER; BEGIN IF Min > Max THEN Max := Hilf; dd-Anomalie von Max Max := Min; ur- und du-Anomalie Hilf := Min; von Hilf END;

13 Beispiel - Metrik von McCabe
Analyse des Programmtextes Ermittlung von Metriken z.B. McCabe - zyklomatische Zahl (Programmtext in Kontrollflußgraphen überführt) v(G) = e - n + 2p v(G) - zyklomatische Zahl des Graphen G e - Anzahl der Kanten des Kontrollflußgraphen n - Anzahl der Knoten des Kontrollflußgraphen p - Anzahl der verbundenen Komponenten (wenn Programm aus Unterprogrammen besteht)

14 Beispiel - Metrik von McCabe
Programmstück … IF a>b THEN IF b>c THEN p(a,b) ELSE p(b,c); print(a,b,c); Kontrollflußgraph (G) … n 1 Berechnung der Metrik e (Kanten) = 8 n (Knoten) = 7 p (Teile) = 1 v(G) = 8-7+2*1= 3 zyklomatische Zahl = 3 (Anzahl der unabhängigen Pfade im Programmstück) n 2 Beispiel zur zyklomaischen Zahl an dem einfachen Beispiel, was wir schon kennen! Ergebnis = 3 = Anzahl der Testläufe, um eine Zweigabdeckung zu erreichen! Zyklomatische Zahl = Testaufwand! und eigentlich nicht Komplexität, wie es oft in der Literatur verwendet wird (und sein Artikel leider auch so betitelt ist!) Was ist Komplexität bei SW? n 3 n 4 n 5 … Knoten Kontrollfluß

15 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 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 Testplanung & Kontrolle
Testplan Auswahl der Prüflinge, der zu testenden Merkmale (Funktionalität, Lesbarkeit),der zu erfüllenden Kriterien, des Testabbruch und der -wiederaufnahme Testentwurf Teststrategie, Auswahl der Methoden, Konkretisierung der Kriterien Testfallermittlung automatisch oder manuell Testvorgangsplanung Detailplanung, Reihenfolge der Testfälle Testdurchführung Testauswertung Entscheidung ob das Testobjekt den Test bestanden hat oder nicht

18 Teststufen Modultest (Testen im Kleinen) Funktionen, Programmteile, Module Integrationstest (Testen im Großen) Montage der fertig getesteten Module Test des Zusammenspiels der Module (Schnittstellentest) Systemtest (Test des kompletten Systems) Außenverhalten des Gesamtsystems Laufzeit- und Streßtests, Benutzungsfreundlichkeit

19 Entwicklungsphasen und Teststufen
Anforderungs- definition Systemtest nicht alles aufeinmal testen grobe Schritte sind: Modultest - Entwickler Intgerationstest - Entwerfer Systemtest - extra Gruppe QS in allen Stufen begleitend Bei der Ermittlung der Anforderungen bereits Tests für den Systemtest konzipieren! hier wieß ich, was das System leisten soll und kann gleich Gedanken zur Überprüfung vornehmen. Gilt für Integrations- und Modultest analog Systementwurf Integrationstest Modulspezifikation und Implementierung Modultest zeitlicher Ablauf Test erfolgt auf Grundlage von

20 Entwicklungsphasen und Teststufen
Anforderungs- definition Systemtest nicht alles aufeinmal testen grobe Schritte sind: Modultest - Entwickler Intgerationstest - Entwerfer Systemtest - extra Gruppe QS in allen Stufen begleitend Bei der Ermittlung der Anforderungen bereits Tests für den Systemtest konzipieren! hier wieß ich, was das System leisten soll und kann gleich Gedanken zur Überprüfung vornehmen. Gilt für Integrations- und Modultest analog Systementwurf Integrationstest Modulspezifikation und Implementierung Modultest zeitlicher Ablauf Test-Überlegungen

21 Testverfahren Testfall = Testdaten + erwartete Ergebnisse muß 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 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 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) Beispiel Punktevergabe 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 Glass-Box - Testverfahren Grundlage ist der Quelltext des Testobjekts
strukturorientierter Test kontrollflußbezogen Anweisungsabdeckung Zweigabdeckung Bedingungsabdeckung Pfadabdeckung datenflußbezogen Defs/Uses - Kriterien Datenkontext-Abdeckung

25 kontrollflußbezogener Test Grundlagen
Testkriterien anhand des Kontrollflusses Kontrollflußgraph Darstellungsform des Programmtextes Instrumentierung zur Ermittlung der erreichten Abdeckung

26 Abdeckungsmaße Anweisungsabdeckung Jede Anweisung im Testobjekt soll in der Testphase mindestens einmal ausgeführt werden. Maß (C0) Anzahl der ausgeführten Anweisungen Anzahl aller Anweisungen Zweigabdeckung Jede 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 Zweige Anzahl aller Zweige Pfadabdeckung Alle möglichen unterschiedlichen Abläufe des Testobjektes sollen in der Testphase einmal ausgeführt werden.

27 Beispiel … … Kontrollflußgraph Programmstück …
IF a>b THEN IF b>c THEN p(a,b) ELSE p(b,c); print(a,b,c); Kontrollflußgraph … n 1 Zweigabdeckung: n 1 2 3 5 4 Anweisungs- abdeckung: Beipiel Programm Kontrollflußgraph und Testfälle für Anweisungsabdeckung (C0) und Zweigabdeckung (C1) (umfaßt C0!) n 2 n 3 n 4 n 5 … Knoten Kontrollfluß

28 kontrollflußbezogener Test Zusammenfassung
Konzentration auf Ablaufprüfung Ausführung von Kombinationen von Programmteilen unterschiedliche Abstufungen Werkzeugunterstützung notwendig

29 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 Systemtest Aufgaben des Systemtests Funktionstest
Leistungsprüfung (Streßtest) Mengengerüst Verfügbarkeit Sicherheit Konfiguration Kompatibilität Benutzungsfreundlichkeit …

31 A fool with a tool is still a fool.
Werkzeuge Tools können das Denken nicht abnehmen! A fool with a tool is still a fool.

32 Zusammenfassung & Ausblick
Prüf- und Testverfahren sind in der Praxis von entscheidender Bedeutung Systematisches, strukturiertes Vorgehen kein ad hoc - Test sinnvolle Kombination unterschiedlicher Verfahren auswählen (statische und dynamische Verfahren, auch in Abhängigkeit des Testobjektes) Werkzeugunterstützung erforderlich

33 State of the practice der 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-Entwicklung Ergebnisse einer empirischen Untersuchung bei Softwareunternehmen in Deutschland, Universität Köln, 1998

34 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, / 1998 GI-Fachgruppe 2.1.7: Test, Analyse & Verifikation von Software Arbeitskreise, Literaturhinweise, Treffen, Tagungen und andere Informationen

35 Ein Vortrag des Instituts für Informatik und Automation der Hochschule Bremen
Institut für Informatik & Automation Hochschule Bremen Neustadtswall 30 28199 Bremen Prof. Dr. Andreas Spillner (FAX) informatik.hs-bremen.de

36 Lösung Aufgabe (Folie 2) Testfälle
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. 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 Testfälle 14. 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 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

39 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 ≤ ) Anzahl < 1 10) Anzahl > 9999 Auftragsnr. 11) erstes Zeichen H 12) erstes Zeichen kein H

40 Beispiel Äquivalenzklassentest
Testfälle nach der Äquivalenzklassenanalyse Testfall 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 Anzahl Auftragsnr. H1 H1 H1 H1 H1 H1 H1 H1 J2

41 Beispiel Äquivalenzklassentest
Testfälle nach der Äquivalenzklassenanalyse und der Grenzwertanalyse Testfall getestete 1) 2) 3) 4) 6) O 7) U 9) O 10) U 12) ÄK 5) U 5) O 8) U 8) O 11) Holzart Eiche Buche Kiefer Stahl Buche Buche Buche Buche Buche Länge Anzahl Auftragsnr. H1 H1 H1 H1 H1 H1 H1 H1 J2

42