Analytische Qualitätssicherung Die analytische Qualitätssicherung ist eine alle Phasen der Software-Entwicklung begleitende Tätigkeit, die außer den zur Fehlersuche und -behebung notwendigen Aktivitäten auch die zugehörigen organisatorischen Maßnahmen umfaßt. Software-Krise Software immer komplexer: 1960 5 Millionen Object-Code Instructions 1995 50 Millionen Object-Code Instructions Software fehlerhaft: 1977: 7-20 Defekte pro 1000 Zeilen Quellcode 1994: 0,2-0,05 Defekte Entwicklungszeit: Bei Technischen Programmen: 1975: 2,3 Jahre 1990: 6,5 Jahre Lebenszyklus von Software: Anwendungssoftware-Zyklus: 10-15 Jahre Hardware-Zykluszeit: 3 Jahre Qualität von Software: Korrektheit (entspricht Spezifikation) Robustheit (angemessen auf unvorhergesehenes reagieren) Erweiterbarkeit (geänderte Spezifikation) Wiederverwendbarkeit... Analytische Qualitätssicherung: Wasserfall-Modell mit permanenter Überwachung. Welche Form der analytischen Qualitätssicherung kennt Ihr? Testen

Klassifikation der Verfahren der analytischen Qualitätssicherung Verifizierend: Zielen auf Beweis der Korrektheit z.B. Z-Spezifikation, manueller Programmdurchlauf Analysierend: Zielen auf das Quantifizieren bestimmter Programmeigenschaften, z.B. Benchmarking, Software-Qualitätsmetriken Testen: Zielen auf das Aufdecken von Fehlern !!! Unterschied zur Verifikation Statisch: SW wird nicht ausgeführt Dynamisch: Setzt Ausführbarkeit voraus Strukturorientiert: White-Box-Testen Funktional, diversifizierend ...: Black-Box-Testen Testen

Kontrollflußbezogenes Testen Anhand der Kontrollstruktur des Prüflings werden Testfälle bestimmt. Testen „gegen sich selbst“. Zielt darauf ab, bestimmte Menge von Programmpfaden beim Test zu durchlaufen. Kontrollfluß bestimmt durch: Anweisungsfolgen Selektion Iteration Noch einmal Folie mit der Übersicht... White-Box-Testen: Struktur wird ausgenutzt Anweisungsfolgen: cout <<„hallo“<<endl; cout <<„Hi“<<endl; Selektion: if (i<4) {cout <<„hallo“<<endl; cout <<„hi“<<endl;} Iteration: for (int i=1;i<5;i++) cout <<„hallo“<<endl; Startanweisung: Erste ausgeführte Anweisung (z.B. nach Aufruf) Endanweisung: Ende (z.B. Return in Aufruf) Der Kontrollflußgraph eines Programms P ist ein gerichteter Graph G= (N, E, nstart, nfinal) mit: N = Menge der Anweisungen eines Programms, E  N x N Menge der gerichteten Kanten; beschreiben statischen Kontrollfluß von einem Knoten ni zu nj , nstart  N Startanweisung, nfinal  N Endanweisung. Testen

Problembeschreibung: Benötigt wird eine Prozedur, der als Parameter ein Ziffernstring übergeben wird, die den Wert der dadurch definierten (positiven) Zahl errechnet und diesen zurückliefert. Beispiel eines Programms, das heute von uns getestet wird. Spezifikation gegeben. Benutzung vom Modul TestVW mit dessen Prozeduren While-Schleife wird nur durchlaufen, wenn String inZiffernString>=1 Nach END; (*While*) nur noch für Nach-Komma-Position: Erst ab da wird das Komma richtig gesetzt. Z.B. wird 3,45 bis zu end (*while*) als 345 gehandelt, wobei genauigkeit allerdings dann 1/100 ist. Dieses Programm umsetzen in Kontrollflußgraph: Was sind Knoten? Was Startanweisung Was Endanweisung Testen

Kontrollflußgraph Block: Folge von Anweisungen, die immer in derselben Sequenz durchlaufen werden. If hat eine then-Kante und eine else-Kante Iteration hat zurückweisende Kante Anfangspunkt hat keine hinführend eKante und Endpunkt keine wegführende. Kante auch beliebig komplex (siehe letzte IF-Anweisung) Testen

Anweisungsüberdeckung (C0-Test) Ziel: Alle Anweisungen des Programms mindestens einmal auszuführen, d.h. alle Knoten des Kontrollflußgraphen mindestens einmal besuchen. Anweisungsüberdeckungsgrad := Anzahl der besuchten Knoten Anzahl aller Knoten Vollständige Anweisungsüberdeckung  Anweisungsüberdeckungsgrad=1. Gefunden werden nicht-ausführbare Programmteile. Empirisch belegt: Bei Überdeckungsgrad von 100% weniger als 20% der Programmfehler gefunden. Kontrollflußbezogenes Testen. Was interessiert z.B.? Wird jede Anweisung überhaupt gebraucht, ist jede Anweisung ausführbar ? C0-Test: Folge von Testmethoden (bis C4-Test) Wünschenswert: Anweisungsüberdeckungsgrad von 1 Beispielhaft für das gegebene Programm bei Eingabe von 7 (letzte Folie einfärben) Testen

Vollständige Anweisungsüberdeckung Linken Kontrollfluß verdecken: Eingabe von .9 nachvollziehen. Wie bekomme ich restliche Knoten hinzu? Z.B. Eingabe von leerem String: Welche Knoten kommen hinzu ? Nachvollziehen von Eingabe durch .. Testen

Zweigüberdeckung (C1-Test) Ziel: Alle Pfade des Programms mindestens einmal auszuführen, d.h. alle Kanten des Kontrollflußgraphen mindestens einmal besuchen. Zweigüberdeckungsgrad := Anzahl der besuchten Zweige Anzahl aller Zweige Vollständige Zweigüberdeckung  Zweigüberdeckungsgrad=1. Vollständige Zweigüberdeckung impliziert vollständige Anweisungsüberdeckung. Gefunden werden nicht-ausführbare Programmzweige. Empirisch belegt: Bei Überdeckungsgrad von 100% durchschnittlich 25% der Programmfehler gefunden. Weitere Forderung: Nicht nur alle Knoten besuchen, sondern alle Kanten !!! (C1) Beispielhaft an erster Folie (S. 6) Einfärben für Eingabe von 7 Es fehlen noch Kanten. Wenn alle Knoten durchlaufen wurden, heißt das noch nicht, daß das auch für alle Kanten gilt. Testen

Vollständige Zweigüberdeckung Nachvollziehen der drei Eingaben: Was fehlt alles beim ersten, was beim zweiten. Anhand von Source-Code nachvollziehen... Testen

Bedingungsüberdeckung Zweigüberdeckung ignoriert Struktur einer Bedingung: Atomare  Zusammengesetzte Prädikate. Deren Berücksichtigung führt zu Bedingungsüberdeckungstests Minimale Bedingungsüberdeckung (C2-Test): Alle atomaren Prädikate müssen einmal zu TRUE und einmal zu FALSE ausgewertet werden. Mehrfach-Bedingungsüberdeckung (C3-Test): Alle atomaren Prädikate müssen zu allen Werte-kombinationen ausgewertet werden. Minimale Mehrfach-Bedingungsüberdeckung: Kompromiß zwischen minimaler Bedingungsüber-deckung und Mehrfach-Bedingungsüberdeckung: Jedes Prädikat, ob atomar oder nicht atomar, wird einmal zu TRUE und einmal zu FALSE ausgewertet. Berücksichtigung der hierarchischen Struktur von Bedingungen. Beispiel einer fehlerhaften Bedingung: if ( (1==1) OR (x>=5460) ) if ( (1!=1) AND (x>=5460) ) Also Bedingung genauer anschauen: Deren Struktur berücksichtigen... Min.Bed: z.B. 1==1 zu FALSE auswerten Mehrfach: z.B. If (x<1) or (x>=1) noch Min.Bed. Realisierbar, aber nicht mehrfach Bed. da Wertekombination FALSE FALSE nicht möglich ist. Min.Mehrf.-Bed.: Hierarchische Struktur: z.B. große if-Anfrage in Beispielprogramm. Beispielhaft für Programm: Testen

Bedingungsüberdeckung Minimale Mehrfach- Bedingungsüberdeckung Bei Eingabe von 9 wird erstes Prädikat beim ersten Durchlauf TRUE und dann FALSE. Fehlerfrei bleibt immer TRUE, also neuer Testfall z.B. z Minimale Mehrfach-Bedingung bei If3 Einmal gesamtes If3 und einmal das separate, hierarchische AND3 Alle diese Testfälle sind nötig, um die vollständige Bedingungsüberdeckung zu gewährleisten. Testen

Vollständige Pfadüberdeckung (C4-Test) Analyse aller möglichen Pfade des Programms, d.h. aller Kantenfolgen, die mit dem Startknoten des Kontrollflußgraphen beginnen und dem Knoten nfinal enden. Boundary interior-Pfadtest Gezieltes Testen von Schleifen Für jede Schleife zwei Klassen von Testfällen: Boundary-Test: Alle Pfade, die den Schleifenrumpf genau einmal durchlaufen. Interior-Test: Alle Pfade, die genau eine Schleifen- wiederholung enthalten. Außerhalb von Schleifen werden alle Pfade unter- sucht. Umfaßt Zweigüberdeckungstest, Effektivität liegt aber um 100% darüber. Extremstes Test: Alle möglichen Programmdurchläufe. Bereits bei einer Schleife nach interaktiver Eingabe fast unmöglich. Boundary-Test: Schleife nicht betreten. Interior-Test: Schleife einmal durchlaufen. Bsp: cin >>i; for (int j=1; j<i; j++) cout <<„hallo“ <<j<<endl; Welche beiden Testfälle ? 1 2 Testen

Boundary interior-Pfadtest: interior-Pfade Wie boundary-Test bei While-Schleife (Source-Code auflegen) Wie Interior-Test Soviele Tests, da zusätzlich Pfadüberdeckung.

Datenflußbezogene Testverfahren Neben Kontrollflußfehlern auch Datenfehler möglich wie z.B. Variablenbenutzung vor Initialisierung, nicht benutzte aber definierte Variablen ... Datenflußorientierte Testverfahren verwenden die Zugriffe auf Variablen zur Erzeugung von Testfällen Drei Zugriffe werden unterschieden: - zur Definition einer Variablen (def) - zur Werteberechnung (computational-use , c-use) - zur Prädikatsauswertung (predicate-use, p-use) Datenflußdarstellung eines Kontrollflußgraphen entsteht durch Ergänzen der def-, c-use und p-use-Informationen:  def- und c-uses an Knoten  p-uses an alle von Knoten ausgehenden Kanten Bisher nur Kontrollflußfehler. Häufiger: Datenflußfehler (z.B. SQL *instanz; ... Instanz-->open() Absturz, wenn nicht gesetzt. Kontrollflußgraph anreichern um die drei Verwendungsarten Testen

Kontrollflußgraph in Datenflußdarstellung Prädikate sowohl an THEN als auch an ELSE-Zweig. Methodenaufrufe und Auswertungen nicht im Datenflußmodell! Testen

Test nach dem all uses-Kriterium Das all uses-Kriterium fordert für jede Definition einer Variablen den vollständigen Test der von ihr erreichbaren prädikativen und berechnenden Variablenzugriffe. Wird in einem Knoten ni des Kontrollflußgraphen eine Variable v definiert, so ist die Menge du (v, ni) definiert als: du (v, ni) enthält alle Knoten nk für die gilt: v  c-use(nk) oder v  p-use( (nl, nk) ), nk ist ohne Neudefinition von v per Pfad erreichbar. Ein dynamischer Test nach dem all uses-Kriterium bedeutet, daß für jeden Knoten ni und jeder darin definierten Variable mindestens ein definitionsfreier Pfad von ni zu allen Elementen in du(v, ni) ausgeführt wird. Umfaßt Zweigüberdeckungstest. Mittels der DU-Menge entsteht Menge von Knoten, die definitionsfrei erreichbar sind. Testfälle nun so ausrichten, daß alle Pfade einmal durchlaufen werden. Beispiel anhand Datenflußdarstellungsgraph: du (inZiffernstring, nstart)= {nif1, nfinal, nif1, nif3, nthen3, nelse3} Pfade definiert durch: nstart  nif1: nstart, ninit, nwhile, nif1 nstart  nfinal: nstart, ninit, nwhile, nif3 , nthen3, nfinal .... Für jede Variablendefinition! Testdaten so wählen, daß alle Teilpfade mindestens einmal durchlaufen werden. Dabei darf ein Testdatum mehrer Teilpfade abdecken. Es ist durchaus nicht ungewöhnlich, wenn zu einigen Teilpfaden aufgrund der Programmlogik keine Testdaten existieren. Testen

Funktionale Verfahren Strukturorientierte Verfahren betrachten nicht die Spezifikation. Hier: Programm als black-box: Überprüfung der in der Spezifikation festgelegten Funktionalität. Zwei Stufen: 1) Definitionsbereiche der Eingaben bzw. die Werte- bereiche der Ausgaben in Äquivalenzklassen zer- legen. 2) Aus jeder Äquivalenzklasse nach bestimmter Strategie Testfälle auswählen. Äquivalenzklassenbildung: Jede Klasse repräsentiert eine spezifizierte Teil- funktionalität. Alle Werte einer Äquivalenzklasse verursachen identisches, funktionales Verhalten. Testdatenselektion: Zufallstest Grenzwertanalyse Z.B. Äquivalenzklassenbildung bei String->Zahl-Umrechnungsprogramm: Definieren z.B. mittels regulärer Ausdrücke: C1:= [0-9]\{1,4\} C2:= [0-9]\{1,4\} \ . C3:= [0-9]\{1,4\} \ . [0-9]\{1,4\} C4:= \. [0-9]\{1,4\} C5:= [0-9]* \.\{2,4\} [0-9]* Zufallstest z.B. 34; 34. ; 34.56; .34; 234...4 Grenzwertanalyse: 9999; 0000; 0000. Usw. Testen

Diversifizierende Verfahren Test verschiedener Programmversionen gegeneinander. Mutationentest: In Ursprungsprogramm typische, einfache Fehler einbauen  Mutanten. Für jeden Mutanten Testfälle bestimmen, die eine Unterscheidung vom Original erlauben. Back to Back-Test: Verschiedene Versionen werden unabhängig voneinander aus der Spezifikation gewonnen  identische Funktionalität. Z.B. im Berechnungsprogramm Fehler einbauen: In Initialisierung: Wert:=5. Wo später Fehler ? Wert immer +5 Genauigkeit:=0 Keine Nachkommastellen! Position:=2 Erste Ziffer unterschlagen! Back-To-Back-Test: Fertige Routine z.B. mit fertigen Routinen wie in C die int atoi(char*). Bei Datenbankprojekt Programme gegeneinander starten! Keine Verifikation! Testen

Statische Verfahren A review is a process or meeting during which a work product, or a set of work products, is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. (IEEE, 1990) Als spezielle Reviews werden unterschieden: A walkthrough is a static analysis technique in which a designer or programmer leads members of the development team and other interested parties through a segment of documentation or code, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems. (IEEE, 1990) An inspection is a static analysis technique that relies on visual examination of development products to detect errors, violations of developing standards, and other problems. (IEEE, 1990) An audit is an independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria. (IEEE, 1990). Thema im Hauptdiplom! Schwierig, da Software für Entwickler etwas ganz intimes! Review allgemein, walkthrough häufig beim Debuggen, inspection z.B. bei Gruppentreffen, oder bei Übergang in nächste Phase. Audit z.B. Abnahmetest beim Auftraggeber (ich z.B. bei Abnahmetest). Fließender Übergang zwischen den drei Unterarten! Testen