Kapitel 6 SOFTWAREQUALITTSSICHERUNG UND PRFUNG Software Engineering Prof

Kapitel 6 SOFTWARE-QUALITÄTSSICHERUNG UND -PRÜFUNG Software Engineering Prof. Dr. Wolfgang Schramm

Übersicht 1 1. Einführung in das Software Engineering 2. Softwareprozesse 3. Anforderungsanalyse und Spezifikation 4. Softwareentwurf 5. Programmierung 6. Software-Qualitätssicherung und Prüfung 7. Konfigurationsverwaltung 8. Software-Wartung

Kapitelübersicht 2 1. 2. 3. 4. Einführung/Definition Begriffe Dynamische Verfahren – Testen Statische Verfahren

Lernziele des Kapitels 3 Bedeutung Software-Qualität verstehen. Kennenlernen der Aufgaben der Testens. Verschiedene Teststrategien kennen- und einschätzen lernen. Den Test-Prozess kennenlernen. Statische QS-Verfahren kennenlernen.

Kapitelübersicht 4 1. 2. 3. Einführung/Definition Begriffe Dynamische Verfahren - Testen § Teststrategien § Vorgehen beim Testen § Testautomatisierung 4. Statische Verfahren

Murphy's Law 5 Wenn irgendein Teil einer Maschine falsch eingebaut werden kann, so wird sich immer jemand finden, der das auch tut Nach dem Auseinander- und Zusammenbauen einer Vorrichtung bleiben immer einige Teile übrig Bei einer beliebigen Berechnung wird die Zahl, deren Richtigkeit für alle offensichtlich ist, zur Fehlerquelle

Ariane 5 6 Europa's ganzer Stolz: Superrakete Ariane 5 Entwicklungskosten in 10 Jahren: 6024 Mill. € ! Jungfernflug am 04. 06. 96 Gewicht: 740 t, Nutzlast: 7 - 18 t mit 4 Cluster. Satelliten

Nach 37 Sekunden. . . 7 30 Sekunden nach dem Liftoff erreichte die Ariane 5 in 3700 m Flughöhe eine Horizontal-Geschwindigkeit von 32768. 0 [interne Einheiten] Dieser Wert lag etwa fünfmal höher als bei Ariane 4.

Die Fehlerquelle 8 declare vertical_veloc_sensor: float; vertical_veloc_bias: integer; horizontal_veloc_sensor: float; horizontal_veloc_bias: integer; . . . Fehlerüberprüfung abgeschaltet! begin declare pragma suppress(numeric_error, horizontal_veloc_bias); begin sensor_get(vertical_veloc_sensor); sensor_get(horizontal_veloc_sensor); vertical_veloc_bias : = integer(vertical_veloc_sensor); horizontal_veloc_bias : = integer(horizontal_veloc_sensor); . . . exception when numeric_error => calculate_vertical_veloc(); when others => use_irs 1(); end irs 2;

Die Folgen 9 Absturz des Bordcomputers 36, 7 Sekunden nach dem Start. Grund: Versuch der Umwandlung einer 64 Bit Gleitpunktzahl in ein 16 -Bit vorzeichenbehaftetes Ganzzahl-Format. Die entsprechende Zahl war größer als 215 = 32768. . . und erzeugte so einen Overflow. Zusammenbruch des Lenksystems, der Flug wurde instabil und die Triebwerke drohten abzubrechen. Selbstzerstörung. . .

Die Hintergründe 10 Die Software stammte von der Ariane 4. . . nur flog die Ariane 5 wesentlich schneller. Die Software war für den Flug überflüsssig, nur wichtig für einen evtl. Restart bei Countdownabbruch. Ein Back. Up-Rechner verwendete die gleiche Software und war Sekunden vorher abgestürzt! Die Prüfung der Zahlumwandlung war bewusst abgeschaltet! Niemand ahnte, dass die horizontale Geschwindigkeit so groß werden könnte.

Der Schaden 11 128 Mill. € Startkosten 434 Mill. € Cluster-Satelliten 306 Mill. € für nachfolgende Verbesserungen Verdienstausfall für 2 bis 3 Jahre. Der nächste Testflug konnte erst 17 Monate später durchgeführt werden – 1. Stufe beendete vorzeitig das Feuern. Der erste kommerzielle Flug fand im Dezember 1999 statt.

12 Wie stellen wir fest, ob es in der Software einen Fehler gibt? Wir prüfen, dass sie immer genau das richtige tut.

Diskussion: Test-Ziele 13 Diskutieren Sie mit einem Partner � � � Was ist Testen? Was kann durch Testen erreicht werden? Was kann durch Testen nicht erreicht werden? Dauer: 3 Minuten • Möglichst viele Fehler finden. • Aus fehlerfreier Ausführung mit Testdaten statistisch auf fehlerfreie Ausführung mit realen Daten im Einsatz schließen.

Zwei Dinge müssen dazu erfüllt sein 14 Anforderungsspezifikation 1. Die Eigenschaften des Programms sind durch die Spezifikation eindeutig festgelegt. 2. Die Eigenschaften lassen sich durch Prüfung eindeutig und vollständig feststellen. ?

Betrachtung der Komplexität 15 Wir prüfen eine Prozedur, die ermittelt, ob zwei von drei Parametern des Typs Boolean TRUE sind: Þ Eine Funktion mit einem int-Parameter hat: Þ acht Ausführungsmöglichkeiten. 2 32 ( 4 * 109)Ausführungsmöglichkeiten. Ein Programm das von drei Variablen mit je 32 Bit abhängt , hat Þ 2 96 ( knapp 1030) verschiedene Startzustände.

Also … 16 ⇒Wir wählen beim Testen immer eine Stichprobe. ⇒Wir testen systematisch. Program testing can be used to show the presence of bugs, but never to show their absence! [Dij 70] Faustregel: In einem (leidlich systematischen) Test fällt die Hälfte der Fehler auf.

Systematisch oder intuitiv Testen? 17 Systematisch Die Randbedingungen sind definiert oder präzise erfasst. Das sind sämtliche Gegebenheiten, die auf die Resultate Einfluss haben. Die Eingaben wurden systematisch ausgewählt. Die Testergebnisse werden dokumentiert und nach Kriterien beurteilt, die vor dem Test festgelegt wurden. Intuitiv …was könnte nicht funktionieren? Beides ist wichtig!

Die psychologische Seite 18 Jede Suche geht von einer Annahme nach dem Gesuchten aus: Wenn wir ein Programm untersuchen in der Annahme, dass es funktioniert, werden wir vermutlich auch keinen Fehler finden. Wenn sich ein Fehler nicht „enttarnen“ lässt, so liegt es häufig daran, dass wir uns den Fehler nicht vorstellen konnten. Wenn wir aber zeigen wollen, dass ein Programm fehlerhaft ist, werden unsere Testdaten eine höhere Wahrscheinlichkeit haben, Fehler aufzudecken.

Ist Software fehlerfrei? 19 Anwendung Autopilot zur Steuerung einer Rakete Navigationssystem des Space Shuttle Flugkontroll Software (USA) Software für Steuerung eines Kernkraftwerks Umfang der Software Zahl der Fehler Restfehler Schwerwiegende Restfehler 30 000 1 500 60 6 500 000 25 000 100 1 000 50 000 200 1 500 000 75 000 300

Kapitelübersicht 20 1. 2. 3. 4. Einführung/Definition Begriffe Dynamische Verfahren – Testen Statische Verfahren

Definition Qualität / Qualitätssicherung 21 Quality 1. The degree to which a system, component, or process meets specified requirements. 2. The degree to which a system, component, or process meets customer or user needs or expectations. Quality assurance (QA) 1. A planned and systematic pattern of all actions necessary to provide adequate confidence that an item or product conforms to established technical requirements. 2. A set of activities designed to evaluate the process by which products are developed or manufactured. IEEE 610 -1990 Standard Glossary of Software Engineering Terminology

Definition Testen 22 Testen ist die Vorführung eines Programms oder Systems mit dem Ziel zu zeigen, dass es tut, was es tun sollte Hetzel: The complete guide to software testing, 1984 Testen ist der Prozess ein Programm auszuführen mit der Absicht, Fehler zu finden Myers: The art of software testing, 1979 Testing. The process of operating a system or component under specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component. IEEE 610 -1990 Standard Glossary of Software Engineering Terminology

Testen 23

Definition Test 24 Test 1. An activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component. 2. To conduct an activity as in (1). IEEE 610 -1990 Standard Glossary of Software Engineering Terminology

Fehler, Fehler und noch mehr Fehler 26 Es gibt 3 zentrale Fehler-Begriffe, die leider nicht einheitlich verwendet werden: Irrtum/Fehlhandlung – error Fehler/Fehlerzustand – defect Fehlverhalten/Fehlerwirkung – failure

error, defect & failure 27 Die Fehlerursache/Irrtum (error) liegt im Kopf des Designers bzw. des Programmierers; sie bildet die Grundlage für den Fehler. Der Fehler (defect, fault) liegt in den Daten oder in einer Komponente/einem System und kann dort lokalisiert und behoben werden. Z. B. hat der Programmierer ein best. Programmkonstrukt nicht richtig verstanden (== vs. equals in Java). Z. B. inkorrekte Anweisung oder Datendefinition (z. B. Datenverlust bei Typkonversion). Kann Ursache für ein Fehlverhalten sein. Das Fehlverhalten (failure) wird beim Programmlauf sichtbar. Abweichung einer Komponente/eines Systems von der erwarteten Leistung, d. h. spezifizierter Sollwert und beobachteter Istwert stimmen nicht überein. Wirkung eines Fehlers, die bei der Ausführung der Komponente/des Systems nach „außen“ in Erscheinung tritt. Es ist ein Unterschied, ob man ein Fehlverhalten beseitigt oder sich über die Ursache Gedanken macht und den Fehler beseitigt.

Geht‘s auch andersrum? Mit Korrektheit? 28 Korrektheit ist eine binäre Eigenschaft, d. h. eine Software ist entweder korrekt oder nicht korrekt. Eine fehlerfreie Software ist korrekt. Eine Software ist korrekt, wenn sie konsistent zu ihrer Spezifikation ist. Existiert zu einer Software keine Spezifikation, so ist eine Überprüfung der Korrektheit unmöglich. Folgerung Ein Programm gilt bei der geringsten Abweichung von der Spezifikation als nicht korrekt ab einer bestimmten Komplexität, gibt es kaum noch ein korrektes Programm.

Testen – aber wie? 29 Da ein Test, der keine Fehler aufdeckt, im wesentlichen eine Verschwendung von Zeit und Geld ist, folgt : Þ Ein guter Test ist einer, der mit hoher Wahrscheinlichkeit einen bis jetzt unbekannten Fehler aufdeckt. Ein Test, der einen Fehler aufdeckt, ist keine überflüssige Mühe, da er dem Programm Wert hinzugefügt hat; daher gilt: Þ Ein erfolgreicher Test ist einer, der einen bis jetzt unbekannten Fehler aufdeckt.

Testfall (Definition) 30 A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. IEEE 610 -1990 Standard Glossary of Software Engineering Terminology Ein Testfall (test case) bezeichnet einen Satz von konkreten Eingaben (eventuell inklusive Startzustand) für ein Programm zur Durchführung eines bestimmten Tests zusammen mit der vom Programm erwarteten Ausgabe (eventuell inklusive Endzustand). IEEE 610 -1990 Standard Glossary of Software Engineering Terminology

Diskussion 31 Getestet werden soll die Steuerung für einen Frostwächter, der nachts in einem Gewächshaus dafür sorgen soll, dass die Temperatur nicht unter 0 Grad sinkt. Machen Sie zu jedem notwendigen Testfall alle relevanten Angaben.

Testen – was ist der Gewinn? 32 Beim Test wird die Qualität (die Verlässlichkeit, der Wert) eines Programms erhöht. Die Qualität erhöhen bedeutet Fehler zu finden und zu beseitigen. Daher sollte man nicht zeigen wollen, dass das Programm funktioniert sondern mit der Annahme beginnen, dass es Fehler enthält. Diese Annahme gilt ohnehin für die meisten Programme.

Großer Nachteil von Testen 33 Getestet werden können immer nur ausführbare Artefakte (Dokumente), das heißt Programmcode. Die Fehlerursache liegt aber meistens früher. Zum Beispiel szenariobasierte Analysen und Inspektionen helfen, Fehlern früher auf die Spur zu kommen.

Systematisch oder intuitiv Testen? 34 Systematisch Die Randbedingungen sind definiert oder präzise erfasst. Das sind sämtliche Gegebenheiten, die auf die Resultate Einfluss haben. Die Eingaben wurden systematisch ausgewählt. Die Testergebnisse werden dokumentiert und nach Kriterien beurteilt, die vor dem Test festgelegt wurden. Intuitiv …was könnte nicht funktionieren? Beides ist wichtig!

Was ist kein Test? 35 Irgendeine Inspektion eines Programms. Die Vorführung eines Programms. Die Analyse eines Programms, durch Software-Werkzeuge, z. B. zur Erhebung von Metriken. Die Untersuchung eines Programms mit Hilfe eines Debuggers.

Definition Testprozess 36 Spillner, Linz: Basiswissen Softwaretest, 2010

Testen – Wie läuft das ab? 37 Ein Programm ausführen (ggf. auch mehrfach), mit der Absicht Fehler zu finden. Testfälle Entwerfen der Testfälle Testdaten Erstellen der Testdaten Ausführen des Programms mit Testdaten Testergebnisse Vergleich der Ergebnisse mit Testfällen Testprotokolle

Definition K/I/S/A-Test 38 Component testing Testing of individual hardware or software components or groups of related components. Integration testing Testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them. System testing Testing conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements. Acceptance testing Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. IEEE 610 -1990 Standard Glossary of Software Engineering Terminology

K/I/S/A-Test im Entwicklungsprozess 39 Akzeptanztest Systemtest Integrationstest Komponententest

Was wird getestet? 40 Komponententest Integrationstest Inkrementell vs. "alles auf einmal" Fokus: Schnittstellen, Kommunikation Systemtest Fokus: Funktionalität, Sonderfälle, Performanz etc. In der realen Umgebung, ohne Auftraggeber Fokus: Vollständigkeit, Konfiguration, Interoperabilität, Performanz etc. Akzeptanztest (Abnahmetest) Beim Auftraggeber Fokus: Zeigen, dass die gestellten Anf. umgesetzt sind

Kapitelübersicht 41 1. 2. 3. Einführung/Definition Begriffe Dynamische Verfahren - Testen § Teststrategien § Vorgehen beim Testen § Testautomatisierung 4. Statische Verfahren

Merkmale dynamischer Testtechniken 42 Ausführung des Programms mit konkreten Eingabewerten. Test in der realen Betriebsumgebung. Es sind Stichprobenverfahren. Beweisen nicht die Korrektheit der getesteten Software. → Testfälle sollten: repräsentativ, fehlersensitiv, redundanzarm und ökonomisch sein.

Testen - Grundlagen 43 Jeder Test ist eine Stichprobe. Korrektheit kann durch Testen nicht bewiesen werden. Beispiele: Addition von zwei 32 -Bit-Zahlen: 264 mögliche Testfälle Bearbeitung einer Zeichenkette mit 32 Zeichen: 2256 mögliche Testfälle Erwartete Ergebnisse müssen im Voraus bekannt sein. Testen gegen die Spezifikation. Testen gegen vorhandene Ergebnisse (Regressionstest). Unvorbereitete undokumentierte Tests sind Zeitverschwendung. Testen findet Fehlersymptome (failures und defects), keine Fehlerursachen (errors). Nach dem Test: Fehlerursachen finden und beheben (Debugging).

Testaufwand 44 Kleine Aufwandrechnung: 264 1, 8· 1019 Annahme 1: Manueller Test mit 1 Testfall/s Vollständiger Test dauert ca. 1, 8· 1019 s 58, 5 Milliarden Jahre Annahme 2: Automatisierter Test auf 1000 Rechnern parallel, 1 Testfall / μs → 109 Testfälle/s Vollständiger Test dauert ca. 1, 8· 1010 s 58, 5 Jahre

ST Software Engineering Prof. Dr. Wolfgang Schramm 22. 06. 2017 21. Vorlesung

Kapitelübersicht 46 1. 2. 3. Einführung/Definition Begriffe Dynamische Verfahren - Testen § Teststrategien § § § Blackbox-Test Glassbox-Test Graybox-Test § Vorgehen beim Testen § Testautomatisierung 4. Statische Verfahren

3 Teststrategien 47 Blackboxtest Benutzer – sie sehen das System nur von außen: Funktionalität. Grayboxtest Tester – schauen auch auf die Funktionalität, aber auch darunter z. B. ob die Daten in der DB korrekt abgelegt sind. Whiteboxtest Entwickler – kennen den Code und testen darauf hin, ob der Code richtig arbeitet. Alle 3 Sichten müssen berücksichtigt werden. Z. B. kann ein Whiteboxtest funktionieren, weil eine falsche Annahme getroffen wurde, die dann von den anderen Tests aufgedeckt wird.

Blackbox-Tests 48 x 1 x 2 x 3 y 1 y 2 y 1 = f( x 1, x 2) y 2 = g(x 2, x 3) Die innere Struktur des Programms interessiert nicht. Testfälle (engl: test cases) werden ausschließlich aus der Spezifikation abgeleitet. Der Tester ist interessiert am Finden von Umständen (Testfälle), in denen das Programm nicht mit seiner Spezifikation übereinstimmt. Andere Bezeichnungen: Data-driven Tests, I/O-driven Tests, funktionales Testen.

Blackbox-Test 49 Jede Anforderung muss getestet werden. Ein umfassender Blackbox-Test sollte: Alle Funktionen des Programms aktivieren (Funktionsüberdeckung). Alle möglichen Eingaben bearbeiten (Eingabeüberdeckung). Alle möglichen Ausgabeformen erzeugen (Ausgabeüberdeckung). Die Leistungen ausloten. Die spezifischen Mengengrenzen ausschöpfen. Alle Fehlersituationen herbeiführen.

Blackboxtesten: Testfallbildung 51 Ein Sortierprogramm verwendet Shaker. Sort für Zahlenfolgen mit bis zu 15 Elementen, bei mehr als 15 Elementen wird Quick. Sort verwendet. Die “interne Grenze” 15/16 hat sich der Implementierer ausgedacht (vielleicht gemessen), sie tritt in der Spezifikation nicht auf, ist also für den Blackbox-Tester völlig unvorhersehbar. void sort ( Object [ ] sort. Array ) { if ( sort. Array. length <=15 ) shaker. Sort( sort. Array ); else quick. Sort( sort. Array ); } Die Chance, diesen (nicht böswilligen!) Fehler mittels Blackbox-Tests zu entdecken, ist ziemlich gering. Folge: Vermutlich wird die sort-Methode nie mit mehr als 15 Objekten getestet und der Quick. Sort-Algorithmus bleibt völlig ungetestet.

Blackboxtesten: Testfallbildung 52 Problem: persistente Daten Ihr Verhalten ist nicht nur von den aktuellen Eingabedaten abhängig, sondern von ihrer Geschichte (besonders Reihenfolge!) Beispiel In einem Programm mit einer Kunden-Datenbank können aus der Datenbank heraus automatisch Rechnungen erstellt werden. Bezahlte Beträge werden in der Datenbank markiert. Rechnungen werden nur erstellt, wenn der Betrag noch nicht als "bezahlt" gekennzeichnet ist. Die Reihenfolge Rechnung drucken Betrag als "bezahlt" markieren. beeinflusst den Zustand, damit den Programmablauf und damit die Tests, die zustandsabhängig erfolgen müssen. Es müssen alle Reihenfolgen aller möglichen Eingaben getestet werden.

Übung: Testfälle für 3 -ecks-Programm [My 77] 53 Finden Sie die Testfälle, die alle 3 -ecks-Berechnungen abdecken.

Ein “klassisches” Beispiel (Myers) 54 Funktion mit drei int-Eingabewerten (x, y, z), die als Längen von Dreiecksseiten interpretiert werden. Berechnet, ob das Dreieck gleichseitig, gleichschenklig oder ungleichseitig ist. Schreiben Sie für diese Funktion Testfälle auf! (jetzt!) 2. 2 Funktionstest

Blackbox-Test 55 Jede Anforderung muss getestet werden. Ein umfassender Blackbox-Test sollte: Alle Funktionen des Programms aktivieren (Funktionsüberdeckung). Alle möglichen Eingaben bearbeiten (Eingabeüberdeckung). Alle möglichen Ausgabeformen erzeugen (Ausgabeüberdeckung). Die Leistungen ausloten. Die spezifischen Mengengrenzen ausschöpfen. Alle Fehlersituationen herbeiführen.

Auswertung nach Punkten 1/4 56 1. Haben Sie einen Testfall für ein zulässiges gleichseitiges Dreieck? 2. Haben Sie einen Testfall für ein zulässiges gleichschenkliges Dreieck? (Ein Testfall mit 2, 2, 4 zählt nicht. ) 3. Haben Sie einen Testfall für ein zulässiges ungleichseitiges Dreieck? (Beachten Sie, dass Testfälle mit 1, 2, 3 und 2, 5, 10 keine Ja-Antwort garantieren, da kein Dreieck mit solchen Seiten existiert. ) 4. Haben Sie wenigstens drei Testfälle für zulässige, gleichschenklige Dreiecke, wobei Sie alle drei Permutationen der beiden gleichen Seiten berücksichtigt haben? (z. B. 3, 3, 4; 3, 4, 3; 4, 3, 3) 2. 2 Funktionstest

Auswertung nach Punkten 2/4 57 5. Haben Sie einen Testfall, bei dem eine Seite gleich Null ist? 6. Haben Sie einen Testfall, bei dem eine Seite einen negativen Wert hat? 7. Haben Sie einen Testfall mit 3 ganzzahligen Werten, in dem die Summe zweier Zahlen gleich der dritten ist? (D. h. , wenn das Programm 1, 2, 3 als ungleichseitiges Dreieck akzeptiert, so enthält es einen Fehler. ) 8. Haben Sie wenigstens drei Testfälle für Punkt 7, wobei Sie alle drei Permutationen für die Länge jeweils einer Seite als Summe der beiden anderen Seiten berücksichtigt haben? (z. B. 1, 2, 3; 1, 3, 2; 3, 1, 2. ) 9. Haben Sie einen Testfall mit drei ganzzahligen Werten größer Null, bei dem die Summe aus zwei Zahlen kleiner als die dritte ist? (z. B. 1, 2, 4 oder 12, 15, 30) 2. 2 Funktionstest

Auswertung nach Punkten 3/4 58 10. 11. 12. 13. 14. Haben Sie wenigstens drei Testfälle für Punkt 9, wobei Sie alle drei Permutationen berücksichtigt haben? (z. B. 1, 2, 4; 1, 4, 2; 4, 1, 2. ) Haben Sie einen Testfall, in dem alle drei Seiten gleich Null sind (d. h. 0, 0, 0)? Haben Sie wenigstens einen Testfall mit nichtganzzahligen Werten? Haben Sie wenigstens einen Testfall, in dem Sie eine falsche Anzahl von Werten angeben (z. B. zwei statt drei ganzzahlige Werte)? Haben Sie zusätzlich zu jedem Eingangswert in allen Testfällen die erwarteten Ausgabewerte angegeben? 2. 2 Funktionstest

59 15. 16. 17. Auswertung nach Punkten (Zusatzpunkte) 4/4 Test mit maximalen Werten. Test auf Zahlbereichs-Überlaufbehandlung. Test mit unzulässigen Eingabezeichenfolgen. 2. 2 Funktionstest

Myers Ergebnisse + Folgerungen 60 Durchschnittswerte erfahrener Programmierer: 7 -8 „Diese Übung sollte zeigen, dass das Testen auch eines solch trivialen Programms keine leichte Aufgabe ist. Und wenn das wahr ist, betrachten Sie die Schwierigkeit, ein Flugleitsystem mit 100. 000 Befehlen, einen Compiler oder auch nur ein gängiges Gehaltsabrechnungsprogramm zu testen. “ (1979) Heute: 1 -10 MLo. C 2. 2 Funktionstest

Blackboxtesten: Testfallbildung 62 Erschöpfendes Testen bedeutet, jede mögliche Eingabe wird als Testfall vorgesehen und das Programm damit getestet. Das bedeutet eine riesige Menge an Testeingaben. Erschöpfende Blackbox-Tests sind nicht praktisch durchführbar. Die genannten Beispiele sind Mini-Probleme!

Problem der Testfall-Auswahl 63 Die gewählten Testziele mit möglichst wenig möglichst guten Testfällen umsetzen. Klassische Techniken: Äquivalenzklassenbildung im Folgenden betrachtet Grenzwertanalyse Ursache-Wirkungsgraphen Statistisches Testen (random testing)

Äquivalenzklassen 64 Zu einer Äquivalenzklasse gehören alle Eingabewerte, bei denen der Tester davon ausgeht, dass sich das Testobjekt bei Eingabe eines beliebigen Datums aus der Äquivalenzklasse gleich verhält. Der Test eines Repräsentanten einer Äquivalenzklasse wird als ausreichend angesehen, da davon ausgegangen wird, dass das Testobjekt für alle anderen Eingabewerte derselben Äquivalenzklasse keine andere Reaktion zeigt.

Äquivalenzklassen 65 Es gibt 2 Arten von Äquivalenzklassen: Gültige Äquivalenzklassen repräsentieren gültige Eingaben für ein Programm. Ungültige Äquivalenzklassen repräsentieren alle anderen Eingaben. Wie kommt man zu den Äquivalenzklassen? Þ Heuristische Regeln zur Identifizierung von Äquivalenzklassen.

Heuristik 66 Heuristik (altgr. εὑρίσκω heurísko ‚ich finde‘ zu heuriskein ‚(auf)finden, entdecken‘) Bezeichnet die Kunst, mit begrenztem Wissen und wenig Zeit zu guten Lösungen zu kommen. Es bezeichnet ein analytisches Vorgehen, bei dem mit begrenztem Wissen über ein System mit Mutmaßungen Aussagen über das System getroffen werden, die dann mit Hilfe empirischer Methoden verifiziert werden, um die Korrektheit der Vorstellung über das System (Systemmodell), auf Grund derer diese Aussagen entwickelt wurden, zu schärfen. Heuristik in der Informatik Anwendung von heuristischen Methoden, um mit geringem Rechenaufwand und kurzer Laufzeit zulässige Lösungen für ein bestimmtes Problem zu erhalten. Klassische Algorithmen versuchen, einerseits die optimale Rechenzeit und andererseits die optimale Lösung zu garantieren. Heuristische Verfahren verwerfen einen oder beide dieser Ansprüche, um bei komplexen Aufgaben einen Kompromiss zwischen dem Rechenaufwand und der Güte der gefundenen Lösung einzugehen. Dazu wird versucht, mithilfe von Schätzungen, „Faustregeln“, intuitivintelligentem Raten oder unter zusätzlichen Hilfsannahmen eine gute Lösung zu erzeugen, ohne optimale Eigenschaften zu garantieren. Bekannte heuristische Algorithmen: Evolutionäre Algorithmen in der Optimierung. Quelle: Wikipedia

Identifizierung von Äquivalenzklassen 67 Definitionsbereich der Eingabewerte Werte außerhalb des Definitionsbereichs der Eingabewerte Äquivalenzklassen alle unzulässigen Werte: für diese Werte muss auch überprüft werden, wie sich das Testobjekt verhält. Verfeinerung der Äquivalenzklassen Äquivalenzklasse alle zulässigen/erlaubten Werte: diese Werte muss das Testobjekt gemäß der Spezifikation verarbeiten Alle Äquivalenzklassenelemente, die laut Spezifikation unterschiedlich verarbeitet werden sollen (Unter-) Äquivalenzklasse. Die Äquivalenzklassen werden solange weiter aufgeteilt, bis sich alle unterschiedlichen Anforderungen mit den jeweiligen Äquivalenzklassen decken. Am Ende des Verfeinerungsprozesses ist für jede Äquivalenzklasse ein Repräsentant für einen Testfall zu wählen. Nicht vergessen: Zu jedem Repräsentanten muss auch das vorausgesagte Ergebnis (und ggf. die Vorbedingungen) festgelegt werden.

Schritt 1: Identifizierung von Äquivalenzklassen 68 Eingabebedingung gibt einen Bereich von Werten (z. B. "gültige Eingaben sind 101. . 999") an: Eine gültige Äquivalenzklasse (test 1=500). Zwei ungültige Äquivalenzklassen (test 2=-100 und test 3= “ 1000“). Eingabebedingung spezifiziert, dass eine Anzahl von Werten (z. B. 3) einzugeben ist: Eine gültige Äquivalenzklasse (test 1=3 Werte). Zwei ungültige Äquivalenzklassen (test 2= 2 Werte und test 3= 4 Werte). Eingabebedingung spezifiziert eine Menge von Werten, die unterschriedlich zu behandeln sind (z. B. "Ampelfarben sind rot, gelb und grün") Eine gültige Äquivalenzklasse für jedes Mengenelement (test 1=rot, test 2=gelb, test 3=grün). Eine ungültige Äquivalenzklasse für ein Nicht-Element (test 4=blau). Eingabebedingung kennzeichnet eine Muss-Situation (z. B. "ein Bezeichner in Java muss mit einem Buchstaben beginnen"): Eine gültige Äquivalenzklasse (test 1="ein. Datum": Bezeichner beginnt mit einem Buchstaben). Eine ungültige Äquivalenzklasse (test 2="2 Daten": Bezeichner beginnt mit einer Zahl).

Schritt 2: Ableitung der Testfälle 69 Die Äquivalenzklassen sind eindeutig zu nummerieren. Für die Erzeugung von Testfällen aus den Äquivalenzklassen sind zwei Regeln zu beachten: 1. 2. Die Testfälle für gültige Äquivalenzklassen werden durch Auswahl von Testdaten aus möglichst vielen gültigen Äquivalenzklassen gebildet. Die Testfälle für ungültige Äquivalenzklassen werden durch Auswahl eines Testdatums aus einer ungültigen Äquivalenzklasse gebildet. Es wird mit Werten kombiniert, die ausschließlich aus gültigen Äquivalenzklassen entnommen sind.

Grenzwertanalyse 72 An den Grenzen zulässiger Datenbereiche treten erfahrungsgemäß häufig Fehler auf. Testfälle für solche Grenzfälle auswählen. Heuristik Beispiel: Multiplikation zweier ganzer Zahlen x und y Mögliche Grenzfälle für x und y -1 0 1 Produkt läuft positiv über Produkt läuft negativ über

Grenzwertanalyse + Äquivalenzklassenbildung 73 Anstatt aus einer Äquivalenzklasse einen beliebigen Wert als Repräsentanten für einen Testfall zu wählen, verlangt die Randwertanalyse, dass ein oder mehrere Werte so gewählt werden, dass die Enden der Wertebereiche jeder Äquivalenzklasse überprüft werden. Anstatt sich nur auf den Eingaberaum zu konzentrieren, wird auch der Ergebnisraum bei der Bildung der Testfälle beachtet.

Testfallgenerierung 74 1. 2. Für jede Eingabe Äquivalenzklassen bilden. Repräsentanten mit Grenzwertanalyse bestimmen 3. Bereiche: Grenzwert, Grenzwert „+ 1“, Grenzwert „- 1“. Aufzählungen: alle Elemente, ein ungültiges Element. Testfälle bilden. „gültige“ Testfälle: für jede Eingabe einen gültigen Repräsentanten wählen, jeder gültige Repräsentant mindestens einmal. „ungültige“ Testfälle: für genau eine Eingabe ungültigen Repräsentanten wählen, alle anderen Eingaben gültig, jeder ungültige Repräsentant mindestens einmal.

Grenzwertanalyse - Testfälle 75 Heuristisch gute Regeln zur Erstellung von Testfällen: Wenn eine Eingabebedingung einen Bereich oder eine Anzahl von Werten (z. B. 1 bis 999) angibt, entwirf Testfälle für die Enden des gültigen Wertebereiches (1 und 999) und für Werte, die direkt außerhalb liegen (0 und 1000). Wende diese Regel auf die Ausgabebedingungen an, d. h. entwirf Testfälle so, dass die Enden der gültigen Ausgabebereiche erreicht werden und versuche Testfälle so zu wählen, dass die Ergebniswerte gerade außerhalb des gültigen Wertebereichs liegen würden. Beispiel: Das Ergebnis einer Sinusfunktion sollte +1. 0 und -1. 0 erreichen (für die Eingabewerte 1/2 und 3/2 ). Wenn eine Eingabebedingung eine geordnete Liste von Werten spezifiziert, entwirf Testfälle, die sich auf das erste und das letzte Element der Menge konzentrieren.

Kapitelübersicht 77 1. 2. 3. Einführung/Definition Begriffe Dynamische Verfahren - Testen § Teststrategien § § § Blackbox-Test Glassbox-Test Graybox-Test § Vorgehen beim Testen § Testautomatisierung 4. Statische Verfahren

Glass-Box-Test 78 Synonyme: Whitebox-Test/Strukturelles Testen. Der Tester entwickelt Testfälle aus einer Betrachtung der Ablauflogik des Programms unter Berücksichtigung der Spezifikation. Ziel: Möglichst viele Pfade testen ( =Pfad)

Bestimmung von Verzweigungen/Pfaden 79 Bestimmung der Programmverzweigungen Bedingte Anweisungen und Schleifen: zwei Zweige if, while „if ohne else“: ebenso zwei Zweige Eine Fallunterscheidung: Zweige = Anzahl der Fälle Kontrollflussgraph Zweig switch if then-Fall else-Fall Ein Pfad ist eine Folge von Zweigen vom Start zum Ende Bestimmung aller Pfade: Alle Kombinationen aller Programmzweige bei Schleifen: aller möglichen Anzahlen von Durchläufen

Glassbox-Tests 80 a == 3 Yes No b >= 0 || c > 0 No b++; Yes println( 4/( b + 2*c ) ); Für den Glasbox-Test betrachtet man Pfade.

Überdeckungskriterien 1/2 82 Anweisungsüberdeckung / Statement Coverage / C 0 -Überdeckung Zweigüberdeckung / Branch Coverage / C 1 -Überdeckung Alle Anweisungen werden ausgeführt. Bei Verzweigungen werden alle möglichen Wege (Zweige) durchlaufen. Pfadüberdeckung (Path Coverage) Alle möglichen Wege werden durchlaufen.

Überdeckungskriterien 2/2 83 Termüberdeckung (Condition Coverage): Gründliche Überprüfung komplizierter, zusammengesetzter Entscheidungen. Simple Condition Coverage / Einfache Bedingungsüberdeckung / C 2 -Überdeckung Minimal Multiple Condition Coverage / Minimale Mehrfachüberdeckung / C 3 -Überdeckung Jeder logische Term, der eine Verzweigung steuert, wird mit den möglichen Werten (true oder false) belegt. Der gesamte logische Term, der eine Verzweigung steuert, wird mit den möglichen Werten (true oder false) belegt - verkürzte Auswertung der Teilausdrücke. Multiple Condition Coverage Jeder logische Term, der eine Verzweigung steuert, wird mit fast allen möglichen Werten (true oder false) belegt – völlständige Auswertung.

Überdeckungen - Zusammenfassung 84 Überdeckungen, besonders C 1 und C 2, spielen bei der Qualitätssicherung eine wesentliche Rolle. Vollständige Überdeckungen sind selten zu erreichen, was in der Vielfalt der Ablaufmöglichkeiten z. B. mit schwer zu testenden trycatch-Blöcken liegen kann. Da man sich bei Überdeckungen immer fragt, welche Auswirkung ein Befehl, eine Bedingung oder eine Variable haben kann, findet man durch solche Ansätze viele kleine Fehler. Um effizient mit Überdeckungstests arbeiten zu können, ist eine Automatisierung der wiederholten Testausführung mit der Berechnung und Analyse der Überdeckungen unerlässlich. Generell ist beim Überdeckungsansatz zu beachten, dass man zwar genau die inneren Details der Abläufe prüft, es aber nicht festgestellt werden kann, ob das Programm überhaupt seine ursprüngliche Aufgabenstellung erfüllt.

Bestimmung von Zweigen und Pfaden 85 Bestimmung der Programmzweige: Betrachtung von Verzweigungen und Schleifen. Bei Programmiersprachen mit geschlossenen Ablaufkonstrukten: if-Anweisungen(auch die ohne else) und Schleifen haben je zwei Zweige. Eine case/switch-Anweisung: so viele Zweige wie Fälle. Bestimmung der Pfade: Alle Kombinationen aller Programmzweige bei maximalem Durchlauf aller Schleifen.

Beispiel (nach [Mye 79]) 86 VAR a, b, x: INTEGER; . . . BEGIN IF (a>1) AND (b=0) THEN x : = x DIV a; IF (a=2) OR (x>1) THEN x : = x+1; . . .

Übung 87 Überlegen sie sich die Testfälle für die drei Überdeckungskriterien: � � � Anweisungsüberdeckung Zweigüberdeckung Pfadüberdeckung

Notwendige Testfälle 88 Anweisungsüberdeckung mit dem Testfall: a=2 b=0 x=1 Zweigüberdeckung mit den Testfällen: a=3 b=0 x=3 (oben then-Zweig, unten else-Zweig) a=2 b=1 x=1 (oben else-Zweig, unten then-Zweig) Auch andere Zweigkombinationen sind zulässig. Jeder Zweig muss 1 x durchlaufen werden. Pfadüberdeckung mit den Testfällen: a=1 b=1 x=2 a=3 b=0 x=3 a=2 b=0 x=4 a=1 b=1 x=1

Glasbox-Tests 89 Die Anzahl der Pfade durch ein Programm ist meistens sehr hoch. Beispiel eines Programm-Ablaufplans

Übung 90 90 Bestimmen sie die Anzahl der Pfade durch das dargestellte Programm.

Lösung 91 Die eindeutigen Pfade durch dieses Programm entspricht der Anzahl der Möglichkeiten von A nach B zu kommen. Diese Zahl ist 51 (1 Durchlauf) + 52 +. . . + 520 (20 Durchläufe) wobei 5 die Zahl der Pfade durch den Schleifenrumpf ist Das ergibt ca. 1014.

Binäre Suche 92 Geben Sie den Kontrollflussgraphen an.

Kontrollflussgraph 93

Anweisungsüberdeckung 94 Überdeckung aller Anweisungen: C 0 -Test: Jede Anweisung (numerierte Zeile) des Programms wird mindestens einmal Man kann auch mit ausgeführt. einem einzigen Testfall die C 0 -Abdeckung Im Beispiel: erreichen. a = {11, 22, 33, 44, 55}, k = 33 überdeckt Anweisungen: 1, 2, 3, 4, 5, 9 a = {11, 22, 33, 44, 55}, k = 15 überdeckt Anweisungen: 1, 2, 3, 4, 6, 7, 8, 9 Beide Testfälle zusammen erreichen volle Anweisungsüberdeckung. Messen der Anweisungsüberdeckung: "Instrumentieren" des Codes (durch Werkzeuge) Einfügen von Zählanweisungen bei jeder Anweisung

Zweigüberdeckung 95 Überdeckung aller Zweige: C 1 -Test: Bei jeder Fallunterscheidung (einschließlich Schleifen) werden beide Zweige ausgeführt (Bedingung=true und Bedingung=false). Zweigtest zwingt auch zur Untersuchung "leerer" Alternativen: if (x >= 1) y = true; // kein else-Fall Im Beispiel: Die beiden Testfälle der letzten Folie überdecken alle Zweige. Messung/Instrumentierung von Anweisung i: Fallunterscheidung: if (. . . ) { b. T[i]++; . . . } else { b. F[i]++; . . . } While-Schleife: while (. . . ) { b. T[i]++; . . . } b. F[i]++;

Testgüte und Überdeckungsgrad 96 Die Testgüte hängt von gewählter Überdeckung und erreichtem Überdeckungsgrad ab. Überdeckungsgrad – Prozentuales Verhältnis der Anzahl überdeckter Elemente zur Anzahl vorhandener Elemente. Beispiel: Der Testfall a=3 b=0 x=3 erreicht 50% Zweigüberdeckung.

Testgüte und Überdeckungsgrad 97 Anweisungsüberdeckung ist ein schwaches Kriterium. Fehlende Anweisungen werden beispielsweise nicht entdeckt. Zweigüberdeckung wird in der Praxis angestrebt. Dennoch: falsch formulierte Bedingungsterme (z. B. x>1 statt x<1) werden nicht entdeckt. Pfadüberdeckung ist in fast allen Programmen, die Schleifen mit Verzweigungen enthalten, nicht testbar.

Kapitelübersicht 98 1. 2. 3. Einführung/Definition Begriffe Dynamische Verfahren - Testen § Teststrategien § § § Blackbox-Test Glassbox-Test Graybox-Test § Vorgehen beim Testen § Nicht-funktionale Tests 4. Statische Verfahren

Graybox-Test - Anwendungsszenario 99 Typischer Anwendungsbereich: Webanwendungen Über eine Webschnittstelle werden Daten in einer Datenbank verschoben. Man muss sich sowohl mit dem Datenbankcode als auch mit der Webschnittstelle befassen. Auditing und Logging prüfen: Bestimmte Daten sind nicht über das gewöhnliche UI verfügber Log-Analyse, Audit-Reporting, direkte Abfrage von best. Datenbanktabellen. Für andere System gedachte Daten: Ausgaben bzw. Ausgabeformate prüfen. Vom System generierte Information: Wenn Anwendungen z. B. Prüfsummern oder Hashwerte erzeugen manuell prüfen. Oder bei vom System erzeugten Zeitstempeln auf die richtige Zeitzone achten. Memory Leaks: Untersuchen, ob Daten, die gelöscht werden sollen auch tatsächlich gelöscht wurden, ob Registrierungseinträge korrekt durchgeführt wurden.

Illustration Graybox-Tests 100 Eingaben Korrekte Soll-Ausgabe?

Illustration Graybox-Tests 101 Eingaben Korrekte Soll-Ausgabe?

Illustration Graybox-Tests 102 Eingaben Korrekte Soll-Ausgabe?

Graybox-Test 103 Graybox-Tests versuchen, die Vorteile von Blackbox- und Glasbox-Testverfahren zu kombinieren. Vorgehen Soll-Überdeckungsgrad festlegen, z. B. Zweigüberdeckung. Zunächst Blackbox-Tests durchführen Zur Überprüfung der Funktionalität, Überdeckung wird (im Hintergrund) mitprotokolliert. Dann Glasbox-Test durchführen Analyse der nicht überdeckten Programmteile. Korrektur des Programms (Entfernen unnötiger Teile) oder Erstellen zusätzlicher Testfälle. Testen, bis der vordefinierte Überdeckungsgrad erreicht ist.

Kapitelübersicht 104 1. 2. 3. Einführung/Definition Begriffe Dynamische Verfahren - Testen § Teststrategien § § § Blackbox-Test Glassbox-Test Graybox-Test § Nicht-funktionale Tests § Vorgehen beim Testen 4. Statische Verfahren

Nicht-funktionale Tests 105 Lasttest Last = Anzahl Nutzer, Anzahl Transaktionen, etc. Performance-Test Messung der Antwortzeit (i. d. R. lastabhängig) Volumen-Test Verhalten bei großen Datenmengen Stress-Test Verhalten bei Überlast Test der Sicherheit Test der Stabilität (im Dauerbetrieb) Test der Benutzerfreundlichkeit Test auf Kompatibilität andere Systeme, (alte) Datenbestände

Kapitelübersicht 114 1. 2. 3. Einführung/Definition Begriffe Dynamische Verfahren - Testen § Teststrategien § § § Blackbox-Test Glassbox-Test Graybox-Test § Nicht-funktionale Tests § Vorgehen beim Testen 4. Statische Verfahren

Vorgehen beim Testen 115 Wie wird getestet? Was wird getestet? Wann wird getestet? Wie wird dokumentiert? Wann ist man fertig mit testen?

Der Testprozess 116 Testfälle Entwerfen der Testfälle Testdaten Erstellen der Testdaten Ausführen des Programms mit Testdaten Testergebnisse Vergleich der Ergebnisse mit Testfällen Testprotokolle

Was wird getestet? 117 Testgegenstand sind Komponenten, Teilsysteme oder Systeme Komponententest, Modultest (Unit Test) Integrationstest (Integration Test) Systemtest (System Test) vgl. K/I/S/A

Wann wird getestet? 1/3 118 Akzeptanztest Systemtest Integrationstest Komponententest

Wann wird getestet? 2/3 119 Unit-Test, Modultest, Komponententest (auch: Klassentest) Integrationstest Inkrementell vs. "alles auf einmal" Fokus: Schnittstellen, Kommunikation Systemtest Fokus: Funktionalität, Sonderfälle, Performanz etc. In der realen Umgebung, ohne Auftraggeber Fokus: Vollständigkeit, Konfiguration, Interoperabilität, Performanz etc. Akzeptanztest (Abnahmetest) Beim Auftraggeber Fokus: Zeigen, dass die gestellten Anf. umgesetzt sind.

Wann wird getestet? 3/3 120 Regressionstests … dienen der Überprüfung bereits erreichter Testergebnisse nach einer Änderung. Testfälle und –ergebnisse werden protokolliert z. B. in einer Testdatenbank. nach einer Änderung werden die Testfälle wieder durchgespielt. sinnvoll&hilfreich: automatisches Testen. (Nur) Abweichungen werden gemeldet.

Testgegenstand 121 Abnahmetest (acceptance test) eine besondere Form des Tests: nicht: Fehler finden sondern: zeigen, dass das System die gestellten Anforderungen erfüllt, d. h. in allen getesteten Fällen fehlerfrei arbeitet. In der realen Umgebung durch den Auftraggeber oder In Form von Alpha- und Beta-Tests für einen anonymen Markt

Wann hat man genug getestet? 123 Wenn mit den in der Testvorschrift festgelegten Testdatensätzen keine Fehler mehr gefunden werden. Sinnvolles Kriterium, wenn der Umfang des Prüflings eine systematische Auswahl von Testfällen mit ausreichender Überdeckung ermöglicht. Übliches Kriterium bei der Abnahme. Wenn die Prüfkosten pro entdecktem Fehler eine im voraus festgelegte Grenze überschreiten. Sinnvolles Kriterium für das Beenden des Systemtests. Setzt die Erfassung der Prüfkosten und der Anzahl gefundener Fehler voraus. Achtung: bei „schlechten“ Testfälle: kein Fehler wird gefunden das System ist ausreichend fehlerfrei

Wann hat man genug getestet? 124 Abschätzung des Restrisikos Das Restfehlerrisiko kann aus den bekannten Daten informell geschätzt werden. mit Hilfe statistischer Verfahren analytisch abgeschätzt werden.

Vorgehen beim Testen 126 Wie wird getestet? Was wird getestet? Wann ist man fertig mit testen? Wie wird dokumentiert?

Wie wird dokumentiert? 1/2 127 Testspezifikation § IEEE 829 -1998 Standard for Software Test Documentation Testfallspezifikation 1. Id. / Nr. 2. Beschreibung 3. Autor 4. Vorbedingungen 5. Eingaben 6. Erwartete Resultate 7. Ergebnis (pass/fail) auch: gültige/ungültige Eingaben Art des Tests (Funktion, Last, Zeit, …) Exakt, z. B. „ 50“ nicht „einen Geldbetrag“ Reihenfolge der Testfälle u. U. wichtig! Testfälle werden zusammengefasst zu Testabschnitten für z. B. gleiche Art des Tests, gleiche Vorbedingungen, etc.

Wie wird dokumentiert? 2/2 128 Manuelle Testfälle Automatische Testfälle so genau beschreiben, dass sie eindeutig reproduzierbar sind, „abkürzen“ erlaubt (z. B. „wie oben, jedoch Eingabe 30, Ergebnis 60“), „Intuition“ nicht (z. B. „weitere sinnvolle Werte auch testen“), Dokumentation z. B. in Tabellen-Programm (OOo Calc, Excel). JUnit für Komponenten/Integrationstest. Dokumentation mit Java. Doc. Zweck der Dokumentation Review (sind die Testfälle „gut“). Vorgaben für Tester (manuell).

Testfall als Text – Teil 1 129

Testfall als Text – Teil 2 130 Aus: H. Sneed e. a. : Der Systemtest. 3. Aufl. , Hanser, 2012.

Testfall als Tabelle 131 Aus: H. Sneed e. a. : Der Systemtest. 3. Aufl. , Hanser, 2012.

IEEE 829 – Test Specification – Teil 1 132

IEEE 829 – Test Specification – Teil 2 133

Zusammenfassung 143 Testen kann nur die Anwesenheit von Fehlern aufzeigen, niemals deren Abwesenheit. Es ist (normalerweise) nicht möglich, ein Programm erschöpfend zu testen: das gilt für Blackbox- wie für Whitebox-Tests. Man unterscheidet Blackbox, Whitebox- und Graybox-Tests. Im zeitlichen Verlauf: Unit-/Modul-/Komponenten-Tests, Integrationstests, Systemtest, Abnahmetest, Bei wiederholtem Testen nach Änderungen: Regressionstests. Die Kombination verschiedener Verfahren liefert eine gute Überdeckung.

Kapitelübersicht 145 1. 2. 3. 4. Einführung/Definition Begriffe Dynamische Verfahren – Testen Statische Verfahren

Software-Reviews 146 Testen benötigt ausführbaren Code, d. h. kein Test von Anforderungsspezifikation, Entwurfsspezifikation, … möglich. Es besteht Bedarf an ergänzenden Methoden zur Entdeckung und Beseitigung von Fehlern: => Reviews können das Testen nicht ersetzen, und umgekehrt!

Software-Reviews 147 Ohne Reviews Fehler-Ursprung Fehler-Entdeckung Anford. Design Code Test Wartung Chaos Mit Reviews (ideal) Fehler-Ursprung Fehler-Entdeckung Anford. Design Code Test Wartung

Übersicht über Review-Techniken 148 Sehr formal Weniger formal Inspektion Team Review Walkthrough Pair Peer Ad-hoc Programming Desk-Checking Empirische Studien belegen Inspektionen als die zuverlässigste Review-Technik. Inspektionen finden 50% mehr Fehler als Walkthroughs. Inspektionen finden bis zu 6 x mehr Fehler als Ad-hoc Reviews.

Übersicht über Review-Techniken 149 Ad-hoc Review Wenn man ein Problem nicht lösen kann bittet man einen Mitarbeiter spontan um Hilfe Ergebnis hängt vollständig von der Erfahrung des einen Mitarbeiters ab Peer Desk-Checking Ähnlich Ad-hoc Review Der Mitarbeiter “führt das zu überprüfende Produkt auf dem Papier aus” (meistens Code)

Übersicht über Review-Techniken 150 Pair-Programming Zwei Entwickler teilen sich einen PC-Arbeitsplatz und arbeiten gemeinsam an einem Stück Code. Eine der Praktiken des e. Xtreme Programming Walkthrough Der Autor eines Dokuments präsentiert es Mitarbeitern, um ein allgemeines Verständnis zu erlangen und die Qualität des Dokuments zu verbessern. Kein vorgegebener Prozess und keine Anleitung, wie Fehler zu finden sind. Risiko: Der Autor vergisst während der Präsentation leicht auf die wesentlichen Teile des Dokuments zu fokussieren.

Übersicht über Review-Techniken 151 Team-Review Ähnlich der Inspektion-Technik aber weniger formal. Mehrere Mitarbeiter überprüfen individuell ein Produkt. Die Ergebnisse werden in einen Treffen mit dem Autor besprochen.

Inspektion – Eigenschaften 152 Welche Aktivitäten werden innerhalb des Inspektionsprozesses ausgeführt? Welche Rollen sind in den Inspektions- Rollen prozess involviert? Prozess Inspektion Lesetechniken Dokumente Welche Dokumente werden in einer Inspektion verwendet? Welche Techniken können eingesetzt werden, um Fehler in einem Softwaredokument zu finden?

Der Prozess und die Rollen 153 Planung Kick-off Vorbereitung Meeting Korrektur Follow-up Teilnehmer einladen, Terminvereinbarung von allen Inspektionsaktivitäten, Räume festlegen Organisator Suche nach und Dokumentation von Problemen (d. h. potentielle Fehlern / Fragen / Verbesserungsvorschläge) Inspektoren Sammeln der Fehler. Entscheiden, ob ein Befund ein tatsächlicher Fehler ist. Suche nach weiteren Fehlern. Entscheiden über Re-Inspektion. Moderator//Autor/Inspektoren Korrektur der Fehler Autor

Zu inspizierendes Dokument Inspektion - Dokumente 154 Organisationsliste � Problemliste � Dokumentation der Befunde (potentielle Fehler/Fragen/Verbesserungsvorschläge) sowie des Aufwands für die Fehlersuche. Fehlerliste � Liste aller geplanten Inspektionsaktivitäten (innerhalb eines Projekts oder projektübergreifend). Dokumentation der tatsächlichen Fehler, sowie des Aufwandes für das Meeting. Korrekturliste � Dokumentation der Fehlerkorrektur (oft in Fehlerliste integriert).

Bedeutung der Dokumente 155 Ergebnisse einer Inspektion � � Verbessertes Softwaredokument Dokumentierte Information zur Charakterisierung des inspizierten Dokumentes des Inspektionsprozesses des Software-Entwicklungsprozesses Verwendung der Ergebnisse � � Hilfe für den Autor bei der Überarbeitung seines Dokumentes Charakterisierung / Beurteilung / Vorhersage / Verbesserung des Inspektions- und Softwareentwicklungsprozesses und nicht der daran beteiligten Personen!

Aktivitäten der Vorbereitungsphase 156 Dokument wird von den Inspektoren nach Befunden durchsucht (Individulaktivität). Fehler werden dokumentiert. Ziel: möglichst viele schwere Fehler finden.

Inspektion – Lesetechniken 1/2 157 Anwendung in der Vorbereitungsphase (Individualaktivität) Häufiges Problem � Es gibt oft keine konkrete Anleitung für Inspektoren… was in einem Softwaredokument zu überprüfen ist. wie ein Softwaredokument nach Fehlern zu durchsuchen ist. � Motto: Jeder Inspektor überprüft alles. Ineffiziente Inspektion (#gefundene Fehler / Zeit)

Lesetechniken 2/2 158 Ad-hoc Checklisten: Keine weitere Unterstützung für Inspektor. Der Inspektor bekommt eine Checkliste mit Fragen, die er beim Lesen beantworten soll. Perspektivenbasiertes Lesen/Szenariobasiertes Lesen: Der Inspektor folgt einem Leseszenario. Dieses gibt bestimmte Aktivitäten vor, die während der Fehlersuche durchzuführen sind und fokussiert den Inspektor auf bestimmte Aspekte.

Checklisten 159 No. Fragen das gesamte Dokument betreffend 1 Existiert zu jedem Use Case im Use Case Diagramm genau ein formell beschriebener Use Case und umgekehrt? 2 Ist das gewünschte System durch die Gesamtheit der Use Cases vollständig beschrieben? Auszug aus einer Checkliste für Anforderungsdokumente

Perspektivenbasiertes Lesen (PBR) 164 Leseszenarien geben konkrete Anleitung bei der Fehlersuche. Inspektoren nehmen verschiedene Blickwinkel (Perspektiven) ein, die Aufmerksamkeit auf verschiedene Aspekte fokussieren weniger Überlappung. Der Einfluss der Erfahrung von Inspektoren auf die Effektivität der Inspektion wird geringer. Während der Inspektion wird aktiv mit dem Dokument gearbeitet Verständnis erhöht, Ergebnisse kontrollierbar.

Leseszenarien 165 Jeder Dokumentnutzer hat Qualitätsanforderungen an das Dokument. Diese hängen von der Rolle des Dokumentennutzers im Entwicklungsprozess ab. Kunde System Tester Dokument Entwickler

Beispiel-Szenario für Perspektivenbasiertes Lesen 166 You should read the document from the perspective of a module tester. In doing so, take the code document and extract a control flow graph: Aggregate suitable sequences of code, e. g. , a sequence of statements. Make sure that all branches can be identified in your control flow graph. For building the control flow graph use the symbols on the form “ symbols for test scenarios”. Document your control flow graph on the form “Results Module Test Scenario”. Use the control flow graph to derive test cases: For each branch of the control flow graph and each calculation, develop a test or a set of tests that allow you to ensure the internal correctness of the code module. Document your test cases on the form “Results Module Test Scenario”. While performing the activities, ask yourself the following questions: 1. Do you have all the information that is necessary to identify a test case (e. g. , are all constant values and interfaces defined) ? 2. Are all data values used in a correct way? ( Quelle : Walter Tichy, KIT)

Abdeckung und Überlappung 168 Dokument mit Fehlern hohe Überlappung geringe Abdeckung z. B. alle Inspektoren gleiche Checkliste geringe Überlappung hohe Abdeckung z. B. gut gewählte Szenarien

Zusammenfassung: Testen versus Inspektionen 172 Test benötigt ablauffähigen Code/ Inspektionen können auch auf Dokumenten durchgeführt werden. Testen ist erst spät möglich/Inspektionen können bereits in der Anforderungsphase durchgeführt werden. Testen entdeckt Fehlverhalten/ Inspektionen entdecken die Fehler selbst. Testen: Isolation des Fehlers kostet zusätzlichen Aufwand. Inspektionen fördern den Wissenstransfer zwischen Mitarbeitern.