Übersicht Einführung in das Software Engineering Softwareprozesse

Software-Qualitätssicherung und -Prüfung
Kapitel 6

Übersicht Einführung in das Software Engineering Softwareprozesse
Anforderungsanalyse und -Spezifikation Softwareentwurf Programmierung Software-Qualitätssicherung und -Prüfung Konfigurationsverwaltung Software-Wartung

Kapitelübersicht Einführung/Definition Begriffe
Dynamische Verfahren – Testen Statische Verfahren

Lernziele des Kapitels
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.

Dynamische Verfahren - Testen Teststrategien Vorgehen beim Testen Testautomatisierung Statische Verfahren

Murphy's Law 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 Europa's ganzer Stolz: Superrakete Ariane 5
Entwicklungskosten in 10 Jahren: 6024 Mill. € ! Jungfernflug am Gewicht: 740 t, Nutzlast: t mit 4 Cluster- Satelliten

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

Fehler- überprüfung abgeschaltet!
Die Fehlerquelle declare vertical_veloc_sensor: float; vertical_veloc_bias: integer; horizontal_veloc_sensor: float; horizontal_veloc_bias: integer; ... begin declare pragma suppress(numeric_error, horizontal_veloc_bias); 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_irs1(); end; end irs2; Fehler- überprüfung abgeschaltet! Bias = Ausrichtung

Die Folgen 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 = ... und erzeugte so einen Overflow. Zusammenbruch des Lenksystems, der Flug wurde instabil und die Triebwerke drohten abzubrechen.  Selbstzerstörung ...

Die Hintergründe 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 BackUp-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. 37 Sekunden nach Zünden der Rakete (30 Sekunden nach Liftoff) erreichte Ariane 5 in 3700 m Flughöhe eine Horizontal-Geschwindigkeit von (interne Einheiten). Dieser Wert lag etwa fünfmal höher als bei Ariane 4. Die Umwandlung in eine ganze Zahl führte daher zu einem Überlauf, der jedoch nicht abgefangen wurde. Der Ersatzrechner (Redundanz !) hatte das gleiche Problem schon 72 msec vorher und schaltete sich sofort ab. Daraus resultierte, daß Diagnose-Daten zum Hauptrechner geschickt wurden, die dieser als Flugbahndaten interpretierte. Daraufhin wurden unsinnige Steuerbefehle an die seitlichen, schwenkbaren Feststoff-Triebwerke, später auch an das Haupttriebwerk gegeben, um die großen Flugabweichungen (über 20 Grad) korrigieren zu können. Die Rakete drohte jedoch auseinanderzubrechen und sprengte sich selbst (39 sec). Ein intensiver Test des Navigations- und Hauptrechners wurde nicht unternommen, da die Software bei Ariane 4 erprobt war.

Der Schaden 128 Mill. € Startkosten Mill. € Cluster-Satelliten 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. Tragik: Der problematische Programmteil wurde nur für die Vorbereitung beim Start und den Start selbst gebraucht. Er sollte nur während einer Übergangszeit aktiv sein, aus Sicherheitsgründen: 50 sec, bis die Bodenstation bei einer Startunterbrechung die Kontrolle übernommen hätte. Trotz des ganz anderen Verhaltens der Ariane 5 wurde dieser Wert nicht neu überlegt. Optimierung: Nur bei 3 von 7 Variablen wurde ein Überlauf geprüft - für die anderen 4 Variablen existierten Beweise, daß die Werte klein genug bleiben würden (Ariane 4). Diese Beweise galten jedoch nicht für die Ariane 5 und wurden dafür auch gar nicht nachvollzogen. Problem der Wiederverwendung von Software ! Es wurde beim Programm-Design davon ausgegangen, daß nur Hardware-Fehler auftreten können! Daher hatte der Ersatzrechner auch die identische Software. Die System-Spezifikation legte fest, daß sich im Fehlerfall der Rechner abschalten soll und der Ersatzrechner einspringt. Ein Restart eines Rechners war nicht sinnvoll, da die Neubestimmung der Flughöhe zu aufwendig ist. PS: Der Versuch, neue 4 Cluster-Satelliten zu starten, gelang im Juli und August 2000 mit zwei russischen Trägerraketen.

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

Diskussion: Test-Ziele
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
Anforderungs-spezifikation  Die Eigenschaften des Programms sind durch die Spezifikation eindeutig festgelegt. Die Eigenschaften lassen sich durch Prüfung eindeutig und vollständig feststellen. ?

Betrachtung der Komplexität
Wir prüfen eine Prozedur, die ermittelt, ob zwei von drei Parametern des Typs Boolean TRUE sind: acht Ausführungsmöglichkeiten. Eine Funktion mit einem int-Parameter hat: 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 … 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! [Dij70] Faustregel: In einem (leidlich systematischen) Test fällt die Hälfte der Fehler auf.

Systematisch oder intuitiv Testen?
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? Sämtliche Gegebenheiten, die auf die Resultate Einfluss haben: Der Prüfling (das Programm selbst): Welches Programm, übersetzt von welchem Übersetzer, wird auf welchem BS getestet. Welche SW ist beteiligt? Wer hat wann getestet? Wie viel Speicher steht zur Verfügung? Welche Geräte sind angeschlossen, und in welchem Zustand sind sie? Spezifikation  Welche Eingaben muss das Programm akzeptieren und welche Reaktionen des Programms sind gefordert. Eingabedaten des Programms (im engeren Sinn) = Eingaben interaktiv (Tastatur, Maus), Dateien, DB (im weiteren Sinn) = Anfangsbelegung des Speichers und die beteiligten Geräte zu den Eingaben. Ausführung eines Programms  beeinflusst durch den Speicherzustand zu Beginn, die Eingabedaten und alle Randbedingungen, die aus der Umgebung wirken. In vielen Fällen wird angestrebt, dass sich nur die Eingabedaten auswirken. Das darf man aber nicht unterstellen. Wenn z.B. eine Variable nicht initialisiert wird, bedeutet das eine Abhängigkeit von der zufälligen Vorbelegung des Speichers. Evtl. haben Signale aus dem Netzwerk, an welches der Rechner angeschlossen ist, Folgen für die Programmausführung. Testresultate: im besten Fall kann man Soll-Werte vorher festlegen und dann gegen Ist-Werte vergleichen. In der Praxis kann man meist nur Kriterien definieren, die notwendig aber nicht hinreichend sind, um das Resultat als richtig zu beurteilen. Die Ist-Resultate werden gegen die Kriterien geprüft. Wird kein Fehler entdeckt  erfolgloser Test. Die Testumgebung sollte die Einsatzumgebung so simulieren, dass aus einem erfolglosen Test auf einen erfolgreichen Einsatz geschlossen werden kann. Beides ist wichtig!

Die psychologische Seite
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?
Anwendung Umfang der Software Zahl der Fehler Restfehler Schwer-wiegende Restfehler Autopilot zur Steuerung einer Rakete 30 000 1 500 60 6 Navigations-system des Space Shuttle 25 000 1 000 100 Flugkontroll Software (USA) 50 000 2 000 200 Software für Steuerung eines Kern-kraftwerks 75 000 3 000 300 Annahmen: # Fehler pro kLoC = 50 # Restfehler pro kLoC = 1 – 3 (hier angenommen: 2) # schwerwiegende Restfehler = 10 % der Restfehler Quelle???

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

Definition Testen 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 Standard Glossary of Software Engineering Terminology

Testen

Definition Test Test 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. To conduct an activity as in (1). IEEE Standard Glossary of Software Engineering Terminology

Partner-Diskussion Versuchen Sie mit einem Partner die folgenden Begriffe zu klären/zu definieren: Fehlverhalten (englisch: failure) Fehler (englisch: fault/defect) Fehlerursache (Irrtum, englisch: error) Guter Test Erfolgreicher Test Testfall (englisch: test case) Machen Sie sich Notizen! Dauer: 6 Minuten Fehlverhalten: zeigt sich dynamisch bei der Benutzung des Produktes//beeinträchtigt den Gebrauch des Produktes (der Software) Fehler: statisch im Programmcode vorhandene Ursache des Fehlverhaltens. Irrtum: Ursache eines Fehlers ist der Irrtum des Programmierers oder ein Tippfehler. Guter Test: Der Test hat eine hohe Chance einen vorher nicht bekannten Fehler zu entdecken Erfolgreich ist ein Test, wenn er einen vorher noch nicht bekannten Fehler entdeckt hat Testfall: Voraussetzungen, die erfüllt sein müssen, der Testeingabe und das Soll-Resultat Siehe Ludewig: Seite 448

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

error, defect & failure Die Fehlerursache/Irrtum (error) liegt im Kopf des Designers bzw. des Programmierers; sie bildet die Grundlage für den Fehler. Z.B. hat der Programmierer ein best. Programmkonstrukt nicht richtig verstanden (== vs. equals in Java). Der Fehler (defect, fault) liegt in den Daten oder in einer Komponente/einem System und kann dort lokalisiert und behoben werden. 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. Ein Codefehler kann zu unterschiedlichem Fehlverhalten führen. Durch Beseitigung eines defect können u.U. viele failures beseitigt werden. Beseitigung eines Denkfehlers (error), d.h. der Programmierer hat an (vielen Stellen auf die gleiche Weise) falsch gedacht  viele gleiche Codefehler können entdeckt werden Je näher man an die Wurzel (den Denkfehler) kommt, desto wirkungsvoller kann die Fehlerbeseitigung sein. 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?
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? 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)
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 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 Standard Glossary of Software Engineering Terminology

Diskussion 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?
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
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?
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? Sämtliche Gegebenheiten, die auf die Resultate Einfluss haben: Der Prüfling (das Programm selbst): Welches Programm, übersetzt von welchem Übersetzer, wird auf welchem BS getestet. Welche SW ist beteiligt? Wer hat wann getestet? Wie viel Speicher steht zur Verfügung? Welche Geräte sind angeschlossen, und in welchem Zustand sind sie? Spezifikation  Welche Eingaben muss das Programm akzeptieren und welche Reaktionen des Programms sind gefordert. Eingabedaten des Programms (im engeren Sinn) = Eingaben interaktiv (Tastatur, Maus), Dateien, DB (im weiteren Sinn) = Anfangsbelegung des Speichers und die beteiligten Geräte zu den Eingaben. Ausführung eines Programms  beeinflusst durch den Speicherzustand zu Beginn, die Eingabedaten und alle Randbedingungen, die aus der Umgebung wirken. In vielen Fällen wird angestrebt, dass sich nur die Eingabedaten auswirken. Das darf man aber nicht unterstellen. Wenn z.B. eine Variable nicht initialisiert wird, bedeutet das eine Abhängigkeit von der zufälligen Vorbelegung des Speichers. Evtl. haben Signale aus dem Netzwerk, an welches der Rechner angeschlossen ist, Folgen für die Programmausführung. Testresultate: im besten Fall kann man Soll-Werte vorher festlegen und dann gegen Ist-Werte vergleichen. In der Praxis kann man meist nur Kriterien definieren, die notwendig aber nicht hinreichend sind, um das Resultat als richtig zu beurteilen. Die Ist-Resultate werden gegen die Kriterien geprüft. Wird kein Fehler entdeckt  erfolgloser Test. Die Testumgebung sollte die Einsatzumgebung so simulieren, dass aus einem erfolglosen Test auf einen erfolgreichen Einsatz geschlossen werden kann. Beides ist wichtig!

Was ist kein Test? 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
Spillner, Linz: Basiswissen Softwaretest, 2010

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

Definition K/I/S/A-Test
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 Standard Glossary of Software Engineering Terminology

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

Was wird getestet? Komponententest Integrationstest Systemtest
Fokus: Funktionalität, Sonderfälle, Performanz etc. Integrationstest Inkrementell vs. "alles auf einmal" Fokus: Schnittstellen, Kommunikation Systemtest 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

Dynamische Verfahren - Testen Teststrategien Vorgehen beim Testen Testautomatisierung Statische Verfahren

Merkmale dynamischer Testtechniken
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 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 und undokumentierte Tests sind Zeitverschwendung. Testen findet Fehlersymptome (failures und defects), keine Fehlerursachen (errors). Nach dem Test: Fehlerursachen finden und beheben (Debugging).

Testaufwand 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 21. Vorlesung

Dynamische Verfahren - Testen Teststrategien Blackbox-Test Glassbox-Test Graybox-Test Vorgehen beim Testen Testautomatisierung Statische Verfahren

3 Teststrategien 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 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. x1 y1 x2 y2 x3 y1 = f( x1, x2) y2 = g(x2, x3)

Jede Anforderung muss getestet werden.
Blackbox-Test 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. Jede Anforderung muss getestet werden.

Blackbox-Tests: Erschöpfendes Testen
Wenn man versucht, mittels Blackbox-Tests alle Fehler zu finden, muss man erschöpfend testen. Erschöpfendes Testen bedeutet, jede mögliche Eingabe wird als Testfall vorgesehen und das Programm damit getestet. Dazu später mehr!

Blackboxtesten: Testfallbildung
Ein Sortierprogramm verwendet ShakerSort für Zahlenfolgen mit bis zu 15 Elementen, bei mehr als 15 Elementen wird QuickSort 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 [ ] sortArray ) { if ( sortArray.length <=15 ) shakerSort( sortArray ); else quickSort( sortArray ); } 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 QuickSort-Algorithmus bleibt völlig ungetestet.

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 [My77]
Finden Sie die Testfälle, die alle 3-ecks-Berechnungen abdecken.

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

Jede Anforderung muss getestet werden.
Blackbox-Test 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. Jede Anforderung muss getestet werden.

Auswertung nach Punkten 1/4
Haben Sie einen Testfall für ein zulässiges gleichseitiges Dreieck? Haben Sie einen Testfall für ein zulässiges gleichschenkliges Dreieck? (Ein Testfall mit 2,2,4 zählt nicht.) 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.) 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

Haben Sie einen Testfall, bei dem eine Seite gleich Null ist? Haben Sie einen Testfall, bei dem eine Seite einen negativen Wert hat? 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.) 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.) 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

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

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
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 Befehlen, einen Compiler oder auch nur ein gängiges Gehaltsabrechnungsprogramm zu testen.“ (1979) Heute: 1-10 MLoC 2.2 Funktionstest

Das wäre notwendig, um alle Fehler aufzudecken; Beispiele: Der Code im Dreiecksprogramm könnte wie folgt aussehen: ... // Einlesen der Strings von der Kommandozeile ... // Wandeln in ganze Zahlen if ( ( x == 4712 ) && ( y == 4712 ) ) { System.out.println( "gleichseitiges Dreieck" ); return; } ... // korrekte weitere Auswertung Diesen (bösartigen) Fehler würde man mittels Blackbox-Test sehr wahrscheinlich nicht entdecken. Folge: Das Dreiecksprogramm wird als "korrekt" freigegeben, liefert aber bei genau einer Eingabeklasse die falsche Ausgabe "gleichseitiges Dreieck", obwohl man ein solches nicht eingeben kann. ?????

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
Die gewählten Testziele mit möglichst wenig möglichst guten Testfällen umsetzen. Klassische Techniken: Äquivalenzklassenbildung Grenzwertanalyse Ursache-Wirkungsgraphen Statistisches Testen (random testing) im Folgenden betrachtet Blackbox-Tests sind nützlich und sehr verbreitet. Aber Blackbox-Tests können keine Fehlerfreiheit garantieren. Blackbox-Tests sind unökonomisch: Es sind (auch) Informationen über die Programmstruktur notwendig, um sinnvolle Testfälle zu finden. Es gibt Möglichkeiten, ihre Effizienz deutlich zu verbessern. Eine allgemeine Regel sollte beim Erstellen von Testfällen beachtet werden: Ein guter Testfall reduziert die Zahl von notwendigen weiteren Tests soweit wie möglich, um ein vordefiniertes Ziel für "vernünftiges" Testen zu erreichen. Das impliziert, dass es günstig ist, den Eingaberaum in Äquivalenzklassen aufzuteilen. Aus diesen Überlegungen folgt eine Technik namens Equivalence Partitioning, deutsch: Testklassen- oder Äquivalenzklassen-Bildung.

Äquivalenzklassen 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 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 Äquivalenz- klassen.

Heuristik 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“, intuitiv-intelligentem 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
Definitionsbereich der Eingabewerte Äquivalenzklasse alle zulässigen/erlaubten Werte: diese Werte muss das Testobjekt gemäß der Spezifikation verarbeiten 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 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
Eingabebedingung gibt einen Bereich von Werten (z.B. "gültige Eingaben sind ") an: Eine gültige Äquivalenzklasse (test1=500). Zwei ungültige Äquivalenzklassen (test2=-100 und test3= “1000“). Eingabebedingung spezifiziert, dass eine Anzahl von Werten (z.B. 3) einzugeben ist: Eine gültige Äquivalenzklasse (test1=3 Werte). Zwei ungültige Äquivalenzklassen (test2= 2 Werte und test3= 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 (test1=rot, test2=gelb, test3=grün) . Eine ungültige Äquivalenzklasse für ein Nicht-Element (test4=blau). Eingabebedingung kennzeichnet eine Muss-Situation (z. B. "ein Bezeichner in Java muss mit einem Buchstaben beginnen"): Eine gültige Äquivalenzklasse (test1="einDatum": Bezeichner beginnt mit einem Buchstaben) . Eine ungültige Äquivalenzklasse (test2="2Daten": Bezeichner beginnt mit einer Zahl).

Schritt 2: Ableitung der Testfälle
Die Äquivalenzklassen sind eindeutig zu nummerieren. Für die Erzeugung von Testfällen aus den Äquivalenzklassen sind zwei Regeln zu beachten: 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.

Beispiel für Äquivalenzklassenbildung
Mit dem Befehl PING kann die Leitungsgeschwindigkeit in einem Datennetz getestet werden. PING schickt automatisch kleine Datenpakete an einen vorher angegebenen Rechner und misst die Zeit, bis eine Antwort von diesem Rechner zurückkommt. Je kürzer die PING-Zeit ist, desto schneller ist die Verbindung. Der Befehl hat einen Parameter, den Namen des Rechners, an den die Datenpakete geschickt werden sollen. Der Name des Rechners ist auf 8 Zeichen begrenzt. Weiterhin darf der Rechnername nur aus Buchstaben bestehen. Definieren Sie mit Hilfe der Äquivalenzklassenbildung Testfälle für den PING Befehl.

1. Schritt: Eingabefeld definieren
" Syntax: PING <Rechnername> " Rechnername: Zeichen (Länge), nur Buchstaben 2. & 3. Schritt: Äquivalenzklassen finden

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

Grenzwertanalyse + Äquivalenzklassenbildung
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 Für jede Eingabe Äquivalenzklassen bilden.
Repräsentanten mit Grenzwertanalyse bestimmen 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. Beispiel: Fkt. zur Steuerberechnung Eingabe 1: Steuerklasse ENUM (I, II, III, IV, V) Eingabe 2: Einkommen INT (größer 800€) Erweiterung: Eingabe 2b: Einkommen INT (zwischen 401€ und 800€)

Grenzwertanalyse - Testfälle
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.

Noch Fragen?

Dynamische Verfahren - Testen Teststrategien Blackbox-Test Glassbox-Test Graybox-Test Vorgehen beim Testen Testautomatisierung Statische Verfahren

Glass-Box-Test 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
Bestimmung der Programmverzweigungen Bedingte Anweisungen und Schleifen: zwei Zweige „if ohne else“: ebenso zwei Zweige Eine Fallunterscheidung: Zweige = Anzahl der Fälle  Kontrollflussgraph 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 if, while switch Zweig if then-Fall else-Fall

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

Diskussion a == 3 b >= 0 || c > 0 b++; println( 4/( b + 2*c ) ); Yes No Welche Fälle muss man bei einem Glasbox-Test für das Programm testen, um sicher zu sein, dass es korrekt ist? Welcher Fehler kann auftreten (falls überhaupt)? Mit welchem Testfall würden Sie den Fehler finden? Machen Sie sich Notizen Fehler: b>= 0 ODER c > 0

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

Überdeckungskriterien 2/2
Termüberdeckung (Condition Coverage): Gründliche Überprüfung komplizierter, zusammengesetzter Entscheidungen. Simple Condition Coverage / Einfache Bedingungsüberdeckung / C2-Überdeckung Jeder logische Term, der eine Verzweigung steuert, wird mit den möglichen Werten (true oder false) belegt. Minimal Multiple Condition Coverage / Minimale Mehrfachüberdeckung / C3-Überdeckung 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
Überdeckungen, besonders C1 und C2, spielen bei der Qualitäts- sicherung eine wesentliche Rolle. Vollständige Überdeckungen sind selten zu erreichen, was in der Vielfalt der Ablaufmöglichkeiten z. B. mit schwer zu testenden try- catch-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
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 [Mye79]) 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; Kontrollfluss an Tafel malen

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

Notwendige Testfälle 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 Die Anzahl der Pfade durch ein Programm ist meistens sehr hoch. Beispiel eines Programm-Ablaufplans

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

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

Geben Sie den Kontrollflussgraphen an.
Binäre Suche Geben Sie den Kontrollflussgraphen an.

Kontrollflussgraph

Anweisungsüberdeckung
Überdeckung aller Anweisungen: C0-Test: Jede Anweisung (numerierte Zeile) des Programms wird mindestens einmal ausgeführt. Im Beispiel: 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 Man kann auch mit einem einzigen Testfall die C0-Abdeckung erreichen.

Zweigüberdeckung Überdeckung aller Zweige: C1-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 (...) { bT[i]++; ... } else { bF[i]++; ... } While-Schleife: while (...) { bT[i]++; ... } bF[i]++;

Testgüte und Überdeckungsgrad
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
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.

Dynamische Verfahren - Testen Teststrategien Blackbox-Test Glassbox-Test Graybox-Test Vorgehen beim Testen Nicht-funktionale Tests Statische Verfahren

Graybox-Test - Anwendungsszenario
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
Eingaben Eingaben Eingaben Korrekte Soll-Ausgabe? Korrekte Soll-Ausgabe? Korrekte Soll-Ausgabe?

Graybox-Test 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.

Dynamische Verfahren - Testen Teststrategien Blackbox-Test Glassbox-Test Graybox-Test Nicht-funktionale Tests Vorgehen beim Testen Statische Verfahren

Nicht-funktionale Tests
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

Ableiten guter Testfälle
Einige Heuristiken: Konformität: Entspricht der Wert dem erwarteten Format? Reihenfolge: Sind die Werte geordnet oder ungeordnet? Wertebereich: Ist der Wert innerhalb vernünftiger Minimal- und Maximalwerte? Gibt es Invarianzen? Beziehungen: Bezieht sich der Quelletext auf Externes, worüber er keine unmittelbare Kontrolle hat? Existenz: Existiert der Wert? Kardinalität: Sind soviele Elemente vorhanden, wie erwartet? Zeit: Gibt es zeitliche Abhängigkeiten? Folgende Folien aus: Unit_tests mit Junit von Hunt und Thomas (Hanser – Pragmatisch Programmieren)

Konformität Daten müssen oft einem bestimmten Format entsprechen.
1. Beispiel: Firstname. Somewhere.com Sie programmieren eine Methode, um den Benutzernamen aus der Adresse herauszulesen. Was, wenn es gibt? Gibt es eine Exception? Muss man diese Randbedingung überhaupt beachten? 2. Beispiel: Es werden Daten eingelesen, die aus Kopfzeile, Datenzeile und einer Fußzeile bestehen? Wieviele Situationen müssen Sie testen?

Reihenfolge Die Position einzelner Daten in einer Datenmenge spielt eine Rolle – insbesondere bei Suchroutinen. Beispiel – Restaurantbestellung: Auch wenn die Bestellung in der Reihenfolge Dessert, Hauptspeise und Vorspeise eingegeben wird, sollen die Ausgabe der Speisen in der „gewohnten“ Reihenfolge erfolgen. Was, wenn aber ein Kunde doch eine Eis vor dem Salat haben will?

Wertebereiche Die gültigen Wertebereiche zweier Eingabeparameter können voneinander abhängen x,y sind die Kanten eines Rechtecks, dessen Kanten nicht länger als 100 Einheiten sein können. Invarianten: Zusicherungen an die Objekte einer Klasse Strukturelle Invarianten (jeder Artikel muss zu einer Bestellung gehören). Mathematische Invarianten. Beispiel - Implementierung eines Stacks mit Hilfe eines Arrays (next_index >= 0 && next_index < stack.length)

Wertbereiche public void checkInvariant () throws InvariantException { if (! next >= index >= 0 && next_index< stack.length)) { throw new InvariantException ( ‘‘next_index out of range : ‘‘ + next_Index + ‘‘for stack length‘‘ + stack.length); }

Beziehungen Für jeden Wert, der übergeben wird, sollte überlegt werden, was passiert, wenn dieser Wert nicht existiert, wenn er null, leer oder Null ist. Was passiert, wenn Sie null anstatt CustomerRecord bekommen? Was passiert, wenn eine Datei nicht existert oder die Netzwerkverbindung unterbrochen ist? Dinge aus der Systemumgebung können „verschwinden“ – Dateien, Lizenzschlüssel, Benutzerdaten, ...

Kardinalität Zaunpfahl-Fehler
Ähnlich dem Existenz-Problem – 0-1-n-Regel: keine ein oder mehr als ein Element (n) Beispiel: Pizza-Service mit einer Top-10-Liste, Liste soll mit jeder Bestellung aktualisiert werden: Kann die Liste auch mit weniger als 10 Bestellungen erstellt werden? Kann eine Liste geliefert werden, auch wenn nichts bestellt wurde? Kann eine Liste geliefert werden, wenn ein Belag bestellt wurde?

Zeit Relative Zeit (zeitliche Reihenfolge) Absolute Zeit (Uhrzeit)
login() vor logout() Wie lange wird ihre Methode warten, bis eine Ressource verfügbar ist? Absolute Zeit (Uhrzeit) Eher selten Hat jeder Tag 24 h? Was ist mit Sommerzeit und Winterzeit Umstellungen? Nebenläufigkeitsprobleme Mehrere Threads greifen zu selben Zeit auf dieselbe Instanz der Klasse zu.

Dynamische Verfahren - Testen Teststrategien Blackbox-Test Glassbox-Test Graybox-Test Nicht-funktionale Tests Vorgehen beim Testen Statische Verfahren

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

Der Testprozess Testfälle Testdaten Test-protokolle Test-ergebnisse
Entwerfen der Testfälle Erstellen der Testdaten Vergleich der Ergebnisse mit Testfällen Ausführen des Programms mit Testdaten

Was wird getestet? Testgegenstand sind Komponenten, Teilsysteme oder Systeme Komponententest, Modultest (Unit Test) Integrationstest (Integration Test) Systemtest (System Test) 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 vgl. K/I/S/A

Wann wird getestet? 1/3 Akzeptanztest Systemtest Integrationstest
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 Komponententest

Wann wird getestet? 2/3 Unit-Test, Modultest, Komponententest (auch: Klassentest) Fokus: Funktionalität, Sonderfälle, Performanz etc. Integrationstest Inkrementell vs. "alles auf einmal" Fokus: Schnittstellen, Kommunikation Systemtest 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 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 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 ist man fertig mit Testen
Diskutieren sie mit ihrem Partner mögliche Kriterien an Hand derer man entscheiden kann, ob man genug getestet hat

Wann hat man genug getestet?
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?
Abschätzung des Restrisikos Das Restfehlerrisiko kann aus den bekannten Daten informell geschätzt werden. mit Hilfe statistischer Verfahren analytisch abgeschätzt werden.

Diskussion Wie können die Testergebnisse bzw. die Fehlerdaten zur Steuerung von Tests eingesetzt werden? Spillner S. 136 (Teststeuerung) Wo einige Fehler sind, sind auch noch mehr Tests der fehleranfälligen Teile intensivieren Tests abbrechen und an die Entwickler zurückgeben Wo keine Fehler sind, fehlen Testfälle -- evlt. Ist nicht das Produkt besser, sondern die Tests schlechter --- Änderungshistorie betrachten, evtl. wurde an dieser Komponente lange nichts gemacht (hier jetzt Testfälle reduzieren) Fehlertrendkurve zeigt das Testende an

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

Wie wird dokumentiert? 1/2
Testspezifikation IEEE Standard for Software Test Documentation Testfallspezifikation Id. / Nr. Beschreibung Autor Vorbedingungen Eingaben Erwartete Resultate 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
Manuelle 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). Automatische Testfälle JUnit für Komponenten/Integrationstest. Dokumentation mit JavaDoc. Zweck der Dokumentation Review (sind die Testfälle „gut“). Vorgaben für Tester (manuell).

Testfall als Text – Teil 1

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

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

IEEE 829 – Test Specification – Teil 1

IEEE 829 – Test Specification – Teil 2

Testdokumentation Das wichtigste Dokument für Testvorbereitung und - durchführung ist die Testvorschrift. Die Testvorschrift kann gleichzeitig als Testprotokoll dienen, wenn zu jedem Testfall das Testergebnis notiert wird. Eine Testzusammenfassung bildet den Nachweis über die Durchführung und das Gesamtergebnis eines Tests. Es gibt Normen mit sehr umfangreichen Vorschriften für Testplanung und -dokumentation (IEEE 1987, 1988, 1998a, 1998b). Für den Test kritischer Software sollten diese verwendet werden. Für gewöhnliche Software genügen die hier genannten Dokumente.

Testvorschrift 1. Einleitung 1.1 Zweck Art und Zweck des im Dokument beschriebenen Tests 1.2 Testumfang Welche Konfigurations-Einheiten der entwickelten Lösung getestet werden 1.3 Referenzierte Unterlagen Verzeichnis aller Unterlagen, auf die im Dokument Bezug genommen wird 2. Testumgebung 2.1 Überblick Testgüte, Annahmen und Hinweise 2.2 Testmittel Test-Software und -Hardware, Betriebssystem, Testgeschirr, Werkzeuge

Testvorschrift 2.3 Testdaten, Testdatenbank
Wo die für den Test benötigten Daten bereit liegen oder bereitzustellen sind 2.4 Personalbedarf Wieviel Personen zur Testdurchführung benötigt werden 3. Annahmekriterien Kriterien für erfolgreichen Test-Abschluss Test-Abbruch Unterbrechung und Wiederaufnahme des Tests 4. Testfälle (wie gehabt)

Testfalldokumentation
Aufbau eines Testfalls Testfall-Nummer Eingabe Erwartetes Resultat Feld zum Eintragen des Befunds Gliederung der Testfälle Testfälle mit gemeinsamen Vorbereitungsarbeiten werden zu Testabschnitten zusammengefasst Zu jedem Testabschnitt werden Zweck (was wird getestet), Vorbereitungs- und Aufräumarbeiten dokumentiert Zur Verbesserung der Übersicht werden Testabschnitte untergliedert in Testsequenzen

Testplanung Qualitätsprüfung muss geplant werden: Für das Testen:
Was - wann - nach welcher Strategie prüfen Für das Testen: welche Testverfahren einsetzen welche Testdokumente erstellen wann – welche Tests – mit welchen Leuten durchführen

Testdokumentation nach IEEE 829
Laut dem Standard IEEE 829 gehören zu einer vollständigen Testdokumentation folgende Unterlagen: Testplan: Beschreibt Umfang, Vorgehensweise, Terminplan, Testgegenstände. Testdesignspezifikation: Beschreibt die im Testplan genannten Vorgehensweisen im Detail. Testfallspezifikationen: Beschreibt die Umgebungsbedingungen, Eingaben und Ausgaben eines jeden Testfalls. Testablaufspezifikationen: Beschreibt in Einzelschritten, wie jeder Testfall durchzuführen ist.

Testdokumentation nach IEEE 829
Testobjektübertragungsbericht: Protokolliert, wann welche Testgegenstände an welche Tester übergeben wurden. Testprotokoll: Listet chronologisch alle relevanten Vorgänge bei der Testdurchführung. Testvorfallbericht: Listet alle Ereignisse, die eine weitere Untersuchung erforderlich machen. Testergebnisbericht; Beschreibt und bewertet die Ergebnisse aller Tests.

Kapitelübersicht Einführung/Definition Testen Statische Verfahren
Teststrategien Vorgehen beim Testen Testautomatisierung Statische Verfahren

Programmierte Testvorschriften
An Stelle textuell beschriebener Testfälle können auch programmierte Testfälle verwendet werden: Jeder Testfall ist ein Objekt. Enthält Testdaten und erwartetes Resultat. Ruft den Testling auf. Vergleicht erwartetes und geliefertes Resultat. Eingebettet in ein passendes Laufzeitsystem sind teilautomatisierte Tests möglich. Geeignet vor allem für Komponenten- und Integrationstest. Nützlich als kontinuierlicher Regressionstest bei inkrementeller Entwicklung. In Java-Umgebungen: Junit.

Zusammenfassung 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.

Noch Fragen?

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

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

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

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)

Pair-Programming Zwei Entwickler teilen sich einen PC-Arbeitsplatz und arbeiten gemeinsam an einem Stück Code. Eine der Praktiken des eXtreme 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.

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
Welche Aktivitäten werden innerhalb des Inspektionsprozesses ausgeführt? Prozess Welche Dokumente werden in einer Inspektion verwendet? Welche Rollen sind in den Inspektions-prozess involviert? Dokumente Rollen Lesetechniken Im restlichen Teil dieser ersten Trainingseinheit wollen wir uns im Detail mit den wesentlichen Charakteristika des Inspektionsprozesses sowie Inspektionen im Allgemeinen beschäftigen. Diese Graphik soll Ihnen als eine Art Gedankenstütze dienen, welche Aspekte im Zusammenhang mit Inspektionen von Bedeutung sind. Die wesentlichen Elemente sind: der Prozess, die Rollen, die Lesetechnik und die Inspektionsdokumente. Im weiteren Verlauf dieser Trainingseinheit wollen wir jedes dieser vier Elemente genauer betrachten. Beginnen wir mit dem Prozess => Nächste Folie Welche Techniken können eingesetzt werden, um Fehler in einem Softwaredokument zu finden?

Der Prozess und die Rollen
Planung 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 Kick-off Vorbereitung Meeting Der Inspektionsprozess ist in die vier Phasen Planung, Vorbereitung, Meeting und Korrektur unterteilt. In jeder dieser Phasen hat die verantwortliche Person bestimmte Aufgaben zu erledigen: Während der Planung werden Teilnehmer bestimmt, Räume reserviert, Einladungen verschickt, notwendige Dokumente vorbereitet und verteilt, all weiteren Aktivitäten geplant. Es wird sicher gestellt, dass das zu inspizierende Dokument gewisse Entry-Kriterien erfüllt, die die Vorraussetzung für einen Reibungslosen Verlauf der Inspektion ermöglichen. In der Vorbereitungsphase, häufig auch Fehlersuche genannt, geht es darum das zu inspizierende Dokument auf Fehler und Fragen zu durchsuchen und diese zu dokumentieren. Dies ist die Kernaktivität einer jeden Inspektion da hier die eigentliche Fehlersuche statt findet. Diese Aktivität wird von den einzelnen Teilnehmern individuell durchgeführt. Sie ist auch zeitlich meist einige Tage von der folgenden Meetingphase abgesetzt. Während der Meetingphase geht es darum in der Gruppe alle gefundenen Fehler zusammenzutragen und zu klären, welche der Probleme nun wirkliche Fehler sind, die weiterer Maßnahmen bedürfen. Dabei geht es alleine darum die Fehler als solche zu identifizieren und nicht darum Lösungen zu erarbeiten. Dieses Meeting sollte die Dauer von 2 h nicht überschreiten. In der folgenden Korrekturphase werden die Fehler durch den Besitzer des Dokumentes behoben. Vom Besitzer werden Lösungen zu den beschriebenen Fehlern erarbeitet und diese umgesetzt. Das hier beschriebene Vorgehen, kann je nach Bedarf auch noch um weitere Aktivitäten erweitert werden. So kann zum Beispiel vor der Vorbereitungsphase noch ein sogenanntes “Kick-off” Meeting oder Overview statt finden, nach der Korrekturphase kann sich ein sogenanntes “Follow-up” anschließend. Während des Kick-off Meetings können die Teilnehmer auf Ihre Aufgaben vorbereitet werden, Dokumente können ausgeteilt werden, es kann alles diskutiert werden ,was dazu beiträgt die Vorbereitungs-- und Meetingphasen effizienter zu gestalten. Dieses Meeting sollte insbesondere dann statt finden wenn das zu inspizierende Dokument sehr groß und komplex ist oder aber ein Teil eines größeren Softwaresystems ist oder wenn neue Teammitglieder an der Inspektion beteiligt sind Unter Follow-up können die Aktivitäten zusammen gefasst werden, die noch einmal überprüfen, ob alle Fehler vom Besitzer entsprechend behandelt wurden, dass Verbesserungsvorschlage bei den Verantwortlichen angekommen sind und alle Daten erfasst und zusammengetragen wurden. Korrektur Follow-up

Inspektion - Dokumente
Zu inspizierendes Dokument Organisationsliste Liste aller geplanten Inspektionsaktivitäten (innerhalb eines Projekts oder projektübergreifend). Problemliste Dokumentation der Befunde (potentielle Fehler/Fragen/Verbesserungsvorschläge) sowie des Aufwands für die Fehlersuche. Fehlerliste Dokumentation der tatsächlichen Fehler, sowie des Aufwandes für das Meeting. Korrekturliste Dokumentation der Fehlerkorrektur (oft in Fehlerliste integriert). Zur strukturierten Verwaltung der notwendigen Information schlagen wir die folgende Listen vor. Diese Listen lassen sich im wesentlichen den einzelnen Phasen der Inspektion zuordnen: Die Organisationsliste enthält alle Daten, Informationen/Ergebnisse der Planungsphase. Die Problemliste wird von den Inspektoren während der Vorbereitungsphase ausgefüllt. Die Fehlerliste fasst Daten und Ergebnisse der Meetingphase zusammen ist also Zusammenfassung aller Problemlisten Und in der Korrekturliste dokumentiert der Autor alle Fehlerkorrekturen. Das Dokument, das die Lesetechnik beschreibt, nimmt in der aufgeführten Reihe von Dokumenten in sofern eine Sonderstellung ein, dass es nicht Ergebnisse erfasst, sondern der Vorbereitung und Anleitung einer Phase dient. Diese Listen werden in einer weiteren Trainingseinheit noch im Detail besprochen. Man könnte nun die Frage stellen, wozu man überhaupt andere Dokumente benötigt? Das primäre Ziel der Inspektion ist es Fehler im Dokument zu finden um dessen Qualität zu verbessern. Dies kann nur dann effizient geschehen, wenn auch entsprechend dokumentiert wird, welche Fehler gefunden wurden und wo sie gefunden wurden. Diese Dokumentation ist zum einen eine Hilfe für die Inspektoren sich im Meeting daran zu erinnern, welche Probleme sie während der Vorbereitungsphase gefunden haben zum anderen dienen sie dem Autor als Grundlage bei der Überarbeitung des Dokuments. Des weiteren ist die Inspektion in den gesamten Entwicklungsprozess integriert. Sie ist eine Aktivität die Ressourcen bindet. Es muss somit nachvollziehbar sein, was hat sie gekostet, was hat sie gebracht, wie kann sie verbessert werden. All diese Fragen können nur beantwortet werden, wenn sie durch entsprechende Daten fundiert werden. Mit diesen Daten ist dann eine Charakterisierung des inspizierten Dokuments, des Inspektionsprozesses und des gesamten Entwicklungsprozesses möglich. Wie bei jeder Art der Dokumentation, so ist es auch hier besonders wichtig sicher zu stellen, dass die Daten nicht missbraucht werden. Sie dürfen auf keinen Fall herangezogen werden, um Personen zu beurteilen. Geschieht dies, so wird sich sehr großer Widerstand gegen die Dokumentation im Allgemeinen ergeben und damit den Erfolg der Inspektion im Ganzen gefährden.

Bedeutung der Dokumente
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! Man könnte nun die Frage stellen, wozu man überhaupt andere Dokumente benötigt? Das primäre Ziel der Inspektion ist es Fehler im Dokument zu finden um dessen Qualität zu verbessern. Dies kann nur dann effizient geschehen, wenn auch entsprechend Dokumentiert wird, welche Fehler gefunden wurden und wo sie gefunden wurden. Diese Dokumentation ist zum einen eine Hilfe für die Inspektoren sich im Meeting daran zu erinnern, welche Probleme sie während der Vorbereitungsphase gefunden haben zum anderen dienen sie dem Autor als Grundlage bei der Überarbeitung des Dokuments. Des weiteren ist die Inspektion in den gesamten Entwicklungsprozess integriert. Sie ist eine Aktivität die Resourcen bindet. Es muss somit nachvollziehbar sein, was hat sie gekostet, was hat sie gebracht, wie kann sie verbessert werden. All diese Fragen können nur beantwortet werden, wenn sie durch entsprechende Daten fundiert werden. Mit diesen Daten ist dann eine Charakterisierung des inspizierten Dokuments, des Inspektionsprozesses und des gesamten Entwicklungsprozesses möglich. Wie bei jeder Art der Dokumentation, so ist es auch hier besonders wichtig sicher zu stellen, dass die Daten nicht missbraucht werden. Sie dürfen auf keinen Fall herangezogen werden, um Personen zu beurteilen. Geschieht dies, so wird sich sehr großer Widerstand gegen die Dokumentation im Allgemeinen ergeben und damit den Erfolg der Inspektion im Ganzen gefährden.

Aktivitäten der Vorbereitungsphase
Dokument wird von den Inspektoren nach Befunden durchsucht (Individulaktivität). Fehler werden dokumentiert. Ziel: möglichst viele schwere Fehler finden. Diese Folie fasst die eben genannten Dinge noch einmal zusammen. In diesem Zusammenhang empfehlen wir, dass die Aktivität der Fehlersuche stets individuell von den Inspektoren durchgeführt werden soll und nicht wie manchmal in der Literatur empfohlen als Gruppenaktivität. Der häufig propagierte Synergieeffekt ist im Bereich der Inspektion von SW-Dokumenten statistisch nicht nachweisbar während das Gegenteil empirisch belegt wurde. Ein weiterer sehr wichtiger Vorteil des Inspektionsprozesses ist die Dokumentation der gefundenen Probleme in einer Problemliste. Diese explizite Dokumentation stellt die Bearbeitung aller Probleme sicher und erleichtert auch die Überarbeitung des inspizierten Dokuments im Hinblick auf die gefunden Probleme. In diesem Zusammenhang ist ebenfalls zu erwähnen, dass die Problemliste nicht nur Probleme im Sinne von Fehlern enthalten darf, sondern auch Fragen an den Autor bzgl. Unklarer Zusammenhänge und Verbesserungsvorschläge die der Autor berücksichtigen könnte. Auch Verbesserungsvorschläge die nicht nur das inspizierte Dokument betreffen sonder daraus abgeleitete Verbesserungsvorschläge zum Entwicklungsprozess werden in der Problemliste dokumentiert. Dadurch wird die Notwendikeit der expliziten Dokumentation noch verdeutlicht, denn Verbesserungsvorschläge am Dokument und an den Prozessen werden meist über einen längeren Zeitraum bearbeitet und machen daher eine schriftliche Fixierung notwendig.

Inspektion – Lesetechniken 1/2
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) Um die Frage zu beantworten, warum es überhaupt nötig ist Lesetechniken zu verwenden, werfen wir einen näheren Blick auf Probleme die in Inspektionsprozessen immer wieder festgestellt werden können. Ein Hauptproblem ist, dass Inspektoren bei ihrer Arbeit nicht immer sehr effizient vorgehen. Das bedeutet, dass sie mit einem recht hohen Aufwand im Verhältnis wenige Fehler finden. Dadurch wird aber der Nutzen von Inspektionen in Frage gestellt, da sich dieser genau darüber definiert, dass mit möglichst geringem Aufwand möglicht viele Fehler in einem Softwaredokument entdeckt werden. Die Ursachen für diese Ineffizienz sind allerdings meist sehr offensichtlich. In vielen Inspektionsprozessen erhalten die Inspektoren keinerlei Anleitung wie sie das Dokument nach Fehlern durchsuchen sollen und vor allem auch keinerlei Hinweise darauf was sie in dem Dokument überprüfen sollen. Dies führt dann dazu, dass all beteiligten Inspektoren all das untersuchen was Ihnen wichtig erscheint, sprich jeder Inspektor überprüft alles. Ein weiterer Grund warum Inspektionen häufig ineffizient sind ist die Tatsache, dass heutige Softwareprodukte sehr groß und komplex sind und dass solche Produkte ohne Anleitung nur sehr schwierig in effizienter Weise untersucht werden können. So startet ein Inspektor meist durch Lesen von Seite zu Seite und somit ist es ihm oder ihr nahezu unmöglich den logischen Zusammenhang des Systems zu erfassen. Außerdem werden die ersten Seiten intensiver inspiziert da dort der Inspektor noch genügend Aufmerksamkeit besitzt. Diese Probleme zeigen dass die Arbeit der Inspektoren unterstützt werden muss und eine solche Unterstützung bieten die Lesetechniken. Lesetechniken zeichnen sich dadurch aus, dass die wichtigsten Aspekte eines Dokumentes inspiziert werden und dass jede Information die im Dokument enthalten ist mit dem gleichen Maß an Aufmerksamkeit untersucht wird.

Lesetechniken 2/2 Ad-hoc Checklisten:
Keine weitere Unterstützung für Inspektor. Checklisten: 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. Hier noch einmal die Übersicht der Lesetechniken die in der industriellen Praxis angewendet werden. Das Ad-hoc Lesen beschreibt dabei genau die Art von Lesetechnik die zu den eben genannten Problemen führt. Das Ad-hoc Lesen zeichnet sich nämlich dadurch aus, dass der Inspektor keine Anweisungen erhält wie er das Dokument lesen und auf was er dabei achten soll. Die anderen Techniken wurden ja bereits kurz vorgestellt. Es ist noch zu erwähnen, dass sowohl das Fehlerklassenbasierte Lesen als auch das Perspektivenbasierte Lesen zu der Oberklasse der Szenariobasierten Lesetechniken gehören. Der zentrale Aspekt dieser Techniken ist, dass der Inspektor ein Szenario erhält, das ihm genaue Anweisungen gibt, wie er im Dokument nach Fehlern suchen soll. Diese Szenarien werden ergänzt durch spezielle Fragen die den Inspektor anleiten auf was er bei der Inspektion achten soll, also etwa auf welche Fehlerklassen oder welche Qualitätskriterien er untersuchen soll. Auf die Bedeutung der Szenarien werden wir am Ende der Einheit noch näher Eingehen, wenn wir die Technik des perspektivenbasierten Lesen diskutieren.

Fragen das gesamte Dokument betreffend
Checklisten No. Frage 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? Diese Folie fasst die wesentlichen Richtlinien zusammen, die bei der Erstellung einer Checkliste beachtet werden sollten. Es ist sehr wichtig, dass der Inspektor durch die Checkliste nicht überfordert / „erschlagen“ wird. Daher sollte eine Checkliste niemals mehr als eine Seite umfassen. Dieser Wert hat mit psychologischen Gründen zu tun, da eine Seite von den meisten Menschen als überschaubar und zu bewältigend angesehen wird. Die Formulierung der Fragen muss so gewählt sein, dass jede Frage mit Ja oder Nein beantwortet werden kann und dass stets eine Antwortklasse (Ja oder Nein) bedeutet dass ein Fehler gefunden wurde. Wie bereits erwähnt ist es sehr wichtig, dass die Fragen fundiert sind, d.h. aus Guidelines, Projekterfahrungen und projektspezifischen Qualitätskriterien abgeleitet wurden und nicht aus der Luft gegriffen sind. In diesem Zusammenhang ist es ebenfalls sehr wichtig, dass Beispiele in der Literatur wirklich nur als Beispiele verwendet werden können um Anregungen zu bekommen wie eine Checkliste aussehen könnte. Die Checklisten für Ihr Projekt müssen aber stets an Ihren Projekt und Organisationskontext angepasst werden. Ein weiterer sehr wichtiger Punkt der allerdings nicht direkt etwas mit der Erstellung der Checkliste zu tun hat ist, dass Checklisten gepflegt werden müssen, d.h. sie müssen stets an das Projekt angepasst werden aber auch an sich verändernde Qualitätsanforderungen, neu identifizierte Fehlerquellen usw. Anderen Falls verliert die Checkliste Ihre Anwendbarkeit, da sie an aktuellen Problemen vorbei geht. Auszug aus einer Checkliste für Anforderungsdokumente

Hinweise zur Checklistenerstellung
Formulierung von Fragen Die Beantwortung der Frage mit „Nein“ bedeutet Fehler Nicht länger als eine Din A4 Seite (15 Fragen) Gliederung der Fragen nach Qualitätsaspekten/Struktur Die Fragen beziehen sich auf häufige/wichtige Fehler Die Fragen können von „Richtlinien“ oder Qualitätszielen abgeleitet werden Aus der Literatur können nur Anregungen/Beispiele entnommen werden  Die Checkliste muss angepasst werden Diese Folie fasst die wesentlichen Richtlinien zusammen, die bei der Erstellung einer Checkliste beachtet werden sollten. Es ist sehr wichtig, dass der Inspektor durch die Checkliste nicht überfordert / „erschlagen“ wird. Daher sollte eine Checkliste niemals mehr als eine Seite umfassen. Dieser Wert hat mit psychologischen Gründen zu tun, da eine Seite von den meisten Menschen als überschaubar und zu bewältigend angesehen wird. Die Formulierung der Fragen muss so gewählt sein, dass jede Frage mit Ja oder Nein beantwortet werden kann und dass stets eine Antwortklasse (Ja oder Nein) bedeutet dass ein Fehler gefunden wurde. Wie bereits erwähnt ist es sehr wichtig, dass die Fragen fundiert sind, d.h. aus Guidelines, Projekterfahrungen und projektspezifischen Qualitätskriterien abgeleitet wurden und nicht aus der Luft gegriffen sind. In diesem Zusammenhang ist es ebenfalls sehr wichtig, dass Beispiele in der Literatur wirklich nur als Beispiele verwendet werden können um Anregungen zu bekommen wie eine Checkliste aussehen könnte. Die Checklisten für Ihr Projekt müssen aber stets an Ihren Projekt und Organisationskontext angepasst werden. Ein weiterer sehr wichtiger Punkt der allerdings nicht direkt etwas mit der Erstellung der Checkliste zu tun hat ist, dass Checklisten gepflegt werden müssen, d.h. sie müssen stets an das Projekt angepasst werden aber auch an sich verändernde Qualitätsanforderungen, neu identifizierte Fehlerquellen usw. Anderen Falls verliert die Checkliste Ihre Anwendbarkeit, da sie an aktuellen Problemen vorbei geht.

Übung Entwickeln sie eine Checkliste zur Inspektion eines Anforderungsdokumentes. Nehmen sie zur Entwicklung dieser Checkliste ihre Unterlagen zum Thema „Anforderungen“ zur Hand und rufen sie sich ins Gedächtnis, was ein gutes Anforderungsdokument ausmacht. Beachten sie auch die Hinweise zur Erstellung von Checklisten.

Fehlersuche mit Checklisten
Vorgehen: Anhand der Checklisten-Fragen das Dokument untersuchen Markieren eines Befundes im Dokument Eintragen der Nummer des Befundes in die Problemliste Nummer des Befundes zum Fehler im Dokument schreiben Auf der Problemliste das Dokument, die Seite und die Zeile eintragen, in der sich der Befund befindet Eine kurze Beschreibung des Befundes durchführen. Diese Folie fasst die wesentlichen Richtlinien zusammen, die bei der Erstellung einer Checkliste beachtet werden sollten. Es ist sehr wichtig, dass der Inspektor durch die Checkliste nicht überfordert / „erschlagen“ wird. Daher sollte eine Checkliste niemals mehr als eine Seite umfassen. Dieser Wert hat mit psychologischen Gründen zu tun, da eine Seite von den meisten Menschen als überschaubar und zu bewältigend angesehen wird. Die Formulierung der Fragen muss so gewählt sein, dass jede Frage mit Ja oder Nein beantwortet werden kann und dass stets eine Antwortklasse (Ja oder Nein) bedeutet dass ein Fehler gefunden wurde. Wie bereits erwähnt ist es sehr wichtig, dass die Fragen fundiert sind, d.h. aus Guidelines, Projekterfahrungen und projektspezifischen Qualitätskriterien abgeleitet wurden und nicht aus der Luft gegriffen sind. In diesem Zusammenhang ist es ebenfalls sehr wichtig, dass Beispiele in der Literatur wirklich nur als Beispiele verwendet werden können um Anregungen zu bekommen wie eine Checkliste aussehen könnte. Die Checklisten für Ihr Projekt müssen aber stets an Ihren Projekt und Organisationskontext angepasst werden. Ein weiterer sehr wichtiger Punkt der allerdings nicht direkt etwas mit der Erstellung der Checkliste zu tun hat ist, dass Checklisten gepflegt werden müssen, d.h. sie müssen stets an das Projekt angepasst werden aber auch an sich verändernde Qualitätsanforderungen, neu identifizierte Fehlerquellen usw. Anderen Falls verliert die Checkliste Ihre Anwendbarkeit, da sie an aktuellen Problemen vorbei geht.

Kurze Beschreibung des Problems Verbesserungsvorschlag
Die Problemliste Inspektor: _______________ Startzeit:__________________ Endzeit: __________________ Aufwand: _________________ Dokument: ________________ Nummer Seite Zeile # Kurze Beschreibung des Problems Verbesserungsvorschlag Um die Frage zu beantworten, warum es überhaupt nötig ist Lesetechniken zu verwenden, werfen wir einen näheren Blick auf Probleme die in Inspektionsprozessen immer wieder festgestellt werden können. Ein Hauptproblem ist, dass Inspektoren bei ihrer Arbeit nicht immer sehr effizient vorgehen. Das bedeutet, dass sie mit einem recht hohen Aufwand im Verhältnis wenige Fehler finden. Dadurch wird aber der Nutzen von Inspektionen in Frage gestellt, da sich dieser genau darüber definiert, dass mit möglichst geringem Aufwand möglicht viele Fehler in einem Softwaredokument entdeckt werden. Die Ursachen für diese Ineffizienz sind allerdings meist sehr offensichtlich. In vielen Inspektionsprozessen erhalten die Inspektoren keinerlei Anleitung wie sie das Dokument nach Fehlern durchsuchen sollen und vor allem auch keinerlei Hinweise darauf was sie in dem Dokument überprüfen sollen. Dies führt dann dazu, dass all beteiligten Inspektoren all das untersuchen was Ihnen wichtig erscheint, sprich jeder Inspektor überprüft alles. Ein weiterer Grund warum Inspektionen häufig ineffizient sind ist die Tatsache, dass heutige Softwareprodukte sehr groß und komplex sind und dass solche Produkte ohne Anleitung nur sehr schwierig in effizienter Weise untersucht werden können. So startet ein Inspektor meist durch Lesen von Seite zu Seite und somit ist es ihm oder ihr nahezu unmöglich den logischen Zusammenhang des Systems zu erfassen. Außerdem werden die ersten Seiten intensiver inspiziert da dort der Inspektor noch genügend Aufmerksamkeit besitzt. Diese Probleme zeigen dass die Arbeit der Inspektoren unterstützt werden muss und eine solche Unterstützung bieten die Lesetechniken. Lesetechniken zeichnen sich dadurch aus, dass die wichtigsten Aspekte eines Dokumentes inspiziert werden und dass jede Information die im Dokument enthalten ist mit dem gleichen Maß an Aufmerksamkeit untersucht wird.

Perspektivenbasiertes Lesen (PBR)
Leseszenarien geben konkrete Anleitung bei der Fehlersuche. Inspektoren nehmen verschiedene Blickwinkel (Perspektiven) ein, die 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. Wie bereits erwähnt ist das wesentliche Merkmal des Perspektivenbasierten Lesen die Verwendung von Szenarien die den Inspektor beim Lesen des Dokumentes unterstützen. Die Erfahrung zeigt, dass eine wesentliche Voraussetzung zum finden von Fehlern ein fundamentales Verständnis des gelesenen Dokumentes ist. Im PBR wird versucht ein solches Verständnis durch die Idee der Perspektiven zu erzielen. Die Inspektoren nehmen während der Inspektion eine bestimmte Perspektive (Blickwinkel) ein. Dadurch wird Ihre Aufmerksamkeit auf ganz bestimmte für diesen Blickwinkel wichtigen Aspekte gelenkt und der mentale Overhead, d.h. das Gefühl alles lesen und verstehen zu müssen wird reduziert. Damit wird für die untersuchten Aspekte ein sehr hohes Verständnis erzeugt und das Finden von einzigartige und versteckten / nicht offensichtlichen Fehlern wird wahrscheinlicher. Mögliche Perspektiven sind etwa: User, Tester, System, Maintainer, Designer, etc. Im Folgenden werden wir nun näher auf die Szenarien eingehen

Leseszenarien Jeder Dokumentnutzer hat Qualitätsanforderungen an das Dokument. Diese hängen von der Rolle des Dokumentennutzers im Entwicklungsprozess ab. Kunde System- Tester Diese Folie visualisiert die Säule die das was behandelt. Die verschiedenen Stakeholder eines Softwaredokumentes haben natürlich verschiedene Anforderungen an dieses Dokument. So ist es z.B. für den Kunden von größter Wichtigkeit dass alle seine Anforderungen im Anforderungsdokument enthalten sind und dass diese Anforderungen dort richtig wiedergegeben wurden. Der Tester interessiert sich vielmehr dafür, dass er die beschriebenen Anforderungen überhaupt testen kann und einfach Testfälle aus dem Anforderungsdokument ableiten kann. Indem die Inspektoren beim PBR diese verschiedenen Perspektiven einnehmen konzentrieren sie sich natürlich genau auf die Anforderungen der jeweiligen Stakeholder. Somit steht jeder Inspektor in der Verantwortung die mit seiner Perspektive verbundenen Qualitätsaspekte zu überprüfen und relevante Fehler aufzuspüren. Die Inspektoren können sich somit auch im Meeting nicht in der „Masse“ verstecken, da jeder die Verantwortung für seine Perspektive hat und die aus dieser Perspektive heraus gefundenen Probleme berichten soll. Man kann hier einen sehr guten Vergleich zu einer Fußballmannschaft ziehen. Jeder Spieler hat dort eine ganz bestimmte Aufgabe die er zu erfüllen hat (Verteidiger, Torwart, Stürmer). Erfüllt er diese Aufgabe nicht oder nicht richtig so leidet das ganze Team darunter oder um zu Inspektionen zurück zu kommen es leidet der Nutzen der Inspektion. Dokument Entwickler

Beispiel-Szenario für Perspektivenbasiertes Lesen
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)

Übung Welche Perspektiven, würden sie zur Inspektion eines Architekturdokumentes empfehlen Welche Aktivitäten sollten durch die entsprechenden Szenarien beschrieben werden, auf welche Qualitätsaspekte sollten die verschiedenen Inspektionen achten?

Abdeckung und Überlappung
Dokument mit Fehlern hohe Überlappung geringe Abdeckung geringe Überlappung hohe Abdeckung z.B. alle Inspektoren gleiche Checkliste Die roten Punkte im Dokument deuten auf Fehler im inspizierten Dokument hin. Das linke untere Bild verdeutlicht die Situation, dass die Inspektoren sehr viele identische Fehler während Ihrer Arbeit finden. Dadurch entsteht ein sehr großer Overlap. Dies kann z.B. bei der Verwendung von Checklisten passieren, da bei dieser Technik alle Inspektoren die gleiche Checkliste erhalten und somit nach den gleichen Fehlern im Dokument suchen. Das rechte untere Bild verdeutlicht eine Inspektion in der eine sehr geringe Überlappung erzielt wurde. Darüber hinaus wurden hier auch weit mehr Fehler abgedeckt als in der Situation die links dargestellt ist. Ein Beispiel für eine Lesetechnik die solche Ergebnisse unterstütze ist das perspektivenbasierte Lesen. In dieser Technik fokusieren die Inspektoren auf verschiedene Aspekte und erreichen so eine sehr hohe Abdeckung und einen geringen Overlap da die einzelnen Inspektoren auf verschiedene Dinge fokusieren. Fakt ist, dass die Überdeckung sehr viel wichtiger ist als die Überlappung, denn der Erfolg einer Inspektion wird an der Anzahl der gefundenen Fehlern gemessen. Daher ist eine Lesetechnik die eine recht hohe Überlappung aber gleichzeitig auch eine sehr hohe Abdeckung erzielt zwar in ihrer Effizienz noch zu verbessern aber als erfolgreich zu bewerten. z.B. gut gewählte Szenarien

Reviews durch Inspektion – Zusammenfassung
Fehler- suche Korrektur Planung Meeting Prozess Organisator Moderator Inspektor Autor (Schriftführer) Organisations- liste Problemliste Fehlerliste Korrekturliste Dokumente Rollen Lesetechniken Ad-hoc Checklistenbasiertes Lesen Perspektivenbasiertes Lesen Diese Folie soll Ihnen noch einmal verdeutlichen was Sie in dieser ersten Trainingseinheit kennen gelernt haben.

Zusammenfassung Reviews tragen bei zur Verbesserung und Bewertung
der Dokumentqualität, der Prozessqualität und zur Kostenreduktion, plus: weitere Vorteile (z.B. Wissenstransfer). Reviews sind auf allen Dokumenten im SW-Lifecycle möglich. Lesetechniken sind der zentraler Bestandteil von Inspektionen. Inspektionen und Testen gemeinsam anwenden. Zusammenfassung der Trainingseinheit

Diskussion Vergleichen sie die beiden Methoden Testen und Inspektionen als Methoden der Qualitätssicherung. Nennen sie mindestens vier Unterschiede/Vor- oder Nachteile der einen oder anderen Methode.

Zusammenfassung: Testen versus Inspektionen
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.

Noch Fragen?

Übersicht Einführung in das Software Engineering Softwareprozesse

Ähnliche Präsentationen

Präsentation zum Thema: "Übersicht Einführung in das Software Engineering Softwareprozesse"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

Übersicht Einführung in das Software Engineering Softwareprozesse

Ähnliche Präsentationen

Präsentation zum Thema: "Übersicht Einführung in das Software Engineering Softwareprozesse"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback