Qualitätssicherung von Software

Slides:



Advertisements
Ähnliche Präsentationen
der Universität Oldenburg
Advertisements

Integrations- und Funktionstests im Rahmen des V-Modelles
Phasen und ihre Workflows
Struktur-Funktions-Modelle von Pflanzen - Sommersemester Winfried Kurth Universität Göttingen, Lehrstuhl Computergrafik und Ökologische Informatik.
Informatik 12 | DAES Compilerbau Wintersemester 2010 / 2011 Dr. Heiko Falk Technische Universität Dortmund Lehrstuhl Informatik 12 Entwurfsautomatisierung.
Analytische Qualitätssicherung
Qualitätssicherung von Software Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FIRST.
Grundlagen der Programmierung (GP)
Modellbasierte Software-Entwicklung eingebetteter Systeme
Qualitätssicherung von Software (SWQS)
Qualitätssicherung von Software (SWQS)
Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Prof. Dr. Holger Schlingloff
Qualitätssicherung von Software (SWQS)
Qualitätssicherung von Software (SWQS)
Verifizieren versus Berechnen
Terminierung und Deadlocks Enkhbat Daginaa Betreuerin Prof. Heike Wehrheim Totale Korrektheit.
Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS : Software Model Checking.
Qualitätssicherung von Software Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FIRST.
Qualitätssicherung von Software
Prof. Dr. Holger Schlingloff
Qualitätssicherung von Software
Qualitätssicherung von Software
Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Management großer Softwareprojekte - Auswertung der Fragebögen - Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin, Institut für Informatik Fraunhofer.
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Qualitätssicherung von Software
Qualitätssicherung von Software
Der Einstieg in das Programmieren
Dynamische Testverfahren
Funktionalität Vorhandensein vor Funktionen mit festgelegten Eigenschaften. Diese Funktionen erfüllen die definierten Anforderungen. Richtigkeit - Liefern.
Java: Objektorientierte Programmierung
Algorithmentheorie 04 –Hashing
WS Algorithmentheorie 13 - Kürzeste (billigste) Wege Prof. Dr. Th. Ottmann.
Vorlesung Informatik 2 Algorithmen und Datenstrukturen (27 – Kürzeste Wege) Prof. Th. Ottmann.
Informatik II, SS 2008 Algorithmen und Datenstrukturen Vorlesung 2 Prof. Dr. Thomas Ottmann Algorithmen & Datenstrukturen, Institut für Informatik Fakultät.
Algorithmentheorie 12 – Spannende Bäume minimalen Gewichts
Testen, Analysieren und Verifizieren von Software
EINI-I Einführung in die Informatik für Naturwissenschaftler und Ingenieure I Kapitel 9 Claudio Moraga; Gisbert Dittrich FBI Unido
EINI-I Einführung in die Informatik für Naturwissenschaftler und Ingenieure I Kapitel 7 Claudio Moraga, Gisbert Dittrich FBI Unido
EINI-I Einführung in die Informatik für Naturwissenschaftler und Ingenieure I Vorlesung 2 SWS WS 99/00 Gisbert Dittrich FBI Unido
EINI-I Einführung in die Informatik für Naturwissenschaftler und Ingenieure I Vorlesung 2 SWS WS 99/00 Gisbert Dittrich FBI Unido
EINI-I Einführung in die Informatik für Naturwissenschaftler und Ingenieure I Vorlesung 2 SWS WS 99/00 Gisbert Dittrich FBI Unido
Zusammenfassung Vorwoche
Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Projektplan: m : Anforderungsanalyse Dokument m :
Projektplan: Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University.
Whitebox Testen mit JUnit
Software Engineering 1 6. Übung
LS 2 / Informatik Datenstrukturen, Algorithmen und Programmierung 2 (DAP2)
Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE LM 10 - LO4 Das JUnit Test Framework.
Design and analysis of GUI test-case prioritization using weight-based methods Samra Khan.
Zentralübung Automotive Software Engineering – Übungsblatt 8
Black Box Algorithmen Hartmut Klauck Universität Frankfurt SS
Effiziente Algorithmen Hartmut Klauck Universität Frankfurt SS
Effiziente Algorithmen
Christian Scheideler Institut für Informatik Universität Paderborn
Einführung in die Programmierung
C-Einstieg. Agenda 1Vorbereitung 2Aufbau eines Programms 2.1Header 2.2 Methoden 2.3Main 3Datentypen & Variablen 4Operatoren(+, -, *, /) 5Logik 5.1IF 5.2Switch.
Agenda für heute, 20. April, 2006 Wiederholte ProgrammausführungWiederholte Programmausführung Algorithmische Grundlagen Bedingungen zum Abbruch von Programmschleifen.
Agenda für heute, 14. April, 2005 Wiederholte ProgrammausführungWiederholte Programmausführung Algorithmische Grundlagen Bedingungen zum Abbruch von Programmschleifen.
1 Albert-Ludwigs-Universität Freiburg Rechnernetze und Telematik Prof. Dr. Christian Schindelhauer Informatik III Christian Schindelhauer Wintersemester.
Das Traveling Salesman Problem (TSP)
Modellbasierte Software-Entwicklung eingebetteter Systeme
Korrektheit von Programmen – Testen
Meta-Modell für Story-Diagramme und Expressions
Analyse der Laufzeit von Algorithmen
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Korrektheit von Programmen – Testen
 Präsentation transkript:

Qualitätssicherung von Software Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FIRST

Hinweis auf Umfrage wir, das Institut für Informatik der Humboldt-Universität, möchten mehr über Ihre Sorgen und Nöte im Studium herausfinden. Daher möchten wir Sie bitten, sich an der Umfrage zu beteiligen http://www.informatik.hu-berlin.de/fragebogen Studiendauer, Abbrecherquote: zu hoch? Wer sich nicht wehrt, lebt verkehrt! Abgabeendtermin ist der 3.12.2004 2.3 strukturelle Tests 24.11.2004

Kapitel 2. Testverfahren 2.1 Testen im SW-Lebenszyklus 2.2 funktionsorientierter Test Modul- oder Komponententest Integrations- und Systemtests 2.3 strukturelle Tests, Überdeckungsmaße 2.4 Test spezieller Systemklassen Test objektorientierter Software Test graphischer Oberflächen Test eingebetteter Realzeitsysteme 2.5 automatische Testfallgenerierung 2.6 Testmanagement und –administration http://qse.ifs.tuwien.ac.at/courses/skriptum/script.htm 2.3 strukturelle Tests 24.11.2004

2.3 strukturelle (white box) Tests kontrollflussorientiert Grundlage: Programmtext, Kontrollflussgraph oder ausführbares Modell Testfall = Pfad durch den Graphen datenflussorientiert Grundlage: Programmtext, Zugriffe auf Variablen bzw. Parameter Paare von schreibendem und lesendem Zugriff ! strukturelle Tests finden keine Auslassungsfehler ! 2.3 strukturelle Tests 24.11.2004

Kontrollflussgraph start n1 n2 n4 n5 n6 ende n3 void ZaehleZchn (int& VokalAnzahl, int& Gesamtzahl){ char Zchn; cin>>Zchn; while ((Zchn>=`A´) && (Zchn<=`Z´) && (Gesamtzahl<INT_MAX)){ Gesamtzahl+=1; if ((Zchn==`A´)|| (Zchn==`E´) || (Zchn==`I´) || (Zchn==`O´) || (Zchn==`U´)){ VokalAnzahl +=1; } cin>>Zchn } } Beispiel: Liggesmeyer (f) / Balzert 2.3 strukturelle Tests 24.11.2004

Kontrollflussorientierte Tests Überdeckungsmaße Anweisungsüberdeckung Zweigüberdeckung Bedingungsüberdeckung einfache Bedingungsüberdeckung mehrfache Bedingungsüberdeckung minimale Bedingungsüberdeckung Pfadüberdeckung 2.3 strukturelle Tests 24.11.2004

Anweisungsüberdeckung start n1 n2 n4 n5 n6 ende n3 auch C0-Test genannt (statement coverage) jede Anweisung muss durch mindestens einen Testfall erfasst werden Beispiel: (A,1) ergibt Pfad (start,n1,n2,n3,n4,n5,n6,n2,ende) Kante (n4,n6) wird nicht durchlaufen void ZaehleZchn (int& VokalAnzahl, int& Gesamtzahl){ char Zchn; cin>>Zchn; while ((Zchn>=`A´) && (Zchn<=`Z´) && (Gesamtzahl<INT_MAX)){ Gesamtzahl+=1; if ((Zchn==`A´)|| (Zchn==`E´) || (Zchn==`I´) || (Zchn==`O´) || (Zchn==`U´)){ VokalAnzahl +=1; } cin>>Zchn } } 2.3 strukturelle Tests 24.11.2004

Bewertung Anweisungsüberdeckung Oft ist „vollständige Anweisungsüberdeckung“ das minimale Kriterium bei der Konstruktion einer Testsuite Überdeckungsgrad einer Testsuite: Prozentsatz der mindestens einmal ausgeführten Anweisungen (erstrebenswert: 100%) Minimum z.B. in DO-178B (ab Stufe C) oft als Überdeckungsmaß verwendet schwaches Kriterium (18% aufgedeckte Fehler) Beispiel: (x>5) statt (x>=5) wird nicht entdeckt 2.3 strukturelle Tests 24.11.2004

Zweigüberdeckung auch C1-Test genannt (branch coverage) jede Kante muss durch mindestens einen Testfall erfasst werden Beispiel: (A,B,1) ergibt Pfad (start,n1,n2,n3,n4,n5,n6,n2, n3,n4,n6,n2,ende) Überdeckungsgrad: Prozentsatz der durchlaufenen Kanten start n1 n2 n3 n4 n5 n6 ende 2.3 strukturelle Tests 24.11.2004

Bewertung Zweigüberdeckung subsumiert Anweisungsüberdeckung Schleifen werden ungenügend getestet (z.B. nur ein Mal durchlaufen) Problem der Gewichtung von Zweigen (Konvergenz der Überdeckungsrate mit Testfallanzahl, Fehleinschätzung) gut geeignet um logische Fehler zu finden, schlecht geeignet für Datenfehler Toolunterstützung durch Codeinstrumentierung 2.3 strukturelle Tests 24.11.2004

Übungsbeispiel int Fakultaet (int N){ if (N<0){ fak=-1 } else if (N==0 || N==1){ fak=1 else { fak=N; K=N-1; while(k<>0){ fak=fak*k; k=k-1 Fakultaet=fak; Start Stop N<0 k<>0 N==0 || N==1 fak=-1 fak=1 Fakultaet=fak fak=N k=N-1 fak=fak*K k=k-1 (a) (c) (b) (d) (e) (f) (g) (h) (j) (o) (p) (l) (k) (m) (n) j n 2.3 strukturelle Tests 24.11.2004

Bedingungsüberdeckung condition coverage test; Überprüfung der Entscheidungen im Programm Varianten: einfache Bedingungsüberdeckung (C2): Jede atomare Bedingung einmal wahr als auch einmal falsch mehrfache Bedingungsüberdeckung (C3 oder C2(M)): Kombinationen atomarer Bedingungen minimale Mehrfachbedingungsüberdeckung: Jede Entscheidung im Flussdiagramm wahr oder falsch void ZaehleZchn (int& VokalAnzahl, int& Gesamtzahl){ char Zchn; cin>>Zchn; while ((Zchn>=`A´) && (Zchn<=`Z´) && (Gesamtzahl<INT_MAX)){ Gesamtzahl+=1; if ((Zchn==`A´)|| (Zchn==`E´) || (Zchn==`I´) || (Zchn==`O´) || (Zchn==`U´)){ VokalAnzahl +=1; } cin>>Zchn } } 2.3 strukturelle Tests 24.11.2004

einfache Bedingungsüberdeckung jede atomare Bedingung mindestens in einem Testfall wahr und in einem Testfall falsch Problem: Ausführung teilweise compilerabhängig! (unvollständige Bedingungsauswertung) Problem, Programmfluss zur Bedingung zu steuern (Abhängigkeit der Variablenwerte) Problem, Gesamtentscheidung zu beeinflussen manchmal kombiniert mit Zweigüberdeckung zur Bedingungs/Entscheidungsüberdeckung (condition/decision coverage) 2.3 strukturelle Tests 24.11.2004

Mehrfachbedingungsüberdeckung alle Variationen der atomaren Bedingungen garantiert Variation der Gesamtentscheidung exponentiell viele Möglichkeiten Problem: Abhängigkeit von Variablen! (z.B. (Zchn==`A´)||(Zchn==`E´)) kann nicht beides wahr sein) Problem: kein vernünftiges Überdeckungsmaß 2.3 strukturelle Tests 24.11.2004

minimale Mehrfachbedingungsüberdeckung Evaluation gemäß Formelstruktur (jede Teilformel einmal wahr und einmal falsch) zusammengesetzte Entscheidungen werden zusammenhängend beurteilt Problem: ((A&&B)||C) wird durch (www) und (fff) vollständig überdeckt, aber nicht wirklich getestet Modifikation: zusätzlicher Nachweis, dass jede atomare Teilentscheidung relevant ist (z.B. durch positiven und negativen Testfall) z.B. für flugkritische Software erforderlich 2.3 strukturelle Tests 24.11.2004

Pfadüberdeckung Jeder Pfad durch den Kontrollflussgraphen Im Allgemeinen unendlich viele! (Überdeckungsmaß?) selbst falls endlich: „sehr viele“ strukturierter Pfadtest: Äquivalenzklassen von Pfaden (ähnlich Grenzwertanalyse) Schleife keinmal, einmal, mehr als zweimal ausgeführt (boundary oder interior condition) zusätzlich intuitiv ermittelte Testfälle Werkzeugunterstützung? 2.3 strukturelle Tests 24.11.2004

modifizierter boundary-interior Test (nach Liggesmeyer) alle Pfade die Schleifen nicht betreten Schleifen einmal ausführen, Unterschiede im Rumpf (aber nicht in eingeschachtelten Schleifen) werden berücksichtigt Schleifen zweimal ausführen, wie oben jede Schleife separat beurteilen alle Zweige berücksichtigen 2.3 strukturelle Tests 24.11.2004

Coverage Tools 2.3 strukturelle Tests 24.11.2004

Pause! 2.3 strukturelle Tests 24.11.2004

Datenflussorientierter Test Variablen und Parameter Lebenszyklus: erzeugen – (schreiben – lesen*)* – vernichten computational use versus predicate use Zuordnung von Datenflussattributen zu den Knotens des Kontrollflussgraphen Berechnung der Variablenzugriffe für jeden Definitionsknoten n für Variable x die Mengen dcu(x,n) und dpu(x,n) aller Knoten, in der x (berechnend oder prädikativ) verwendet wird 2.3 strukturelle Tests 24.11.2004

attributierter Kontrollflussgraph start n1 n2 n4 n5 n6 ende n3 def(VokalAnzahl) def(Gesamtzahl) void ZaehleZchn (int& VokalAnzahl, int& Gesamtzahl){ char Zchn; cin>>Zchn; while ((Zchn>=`A´) && (Zchn<=`Z´) && (Gesamtzahl<INT_MAX)){ Gesamtzahl+=1; if ((Zchn==`A´)|| (Zchn==`E´) || (Zchn==`I´) || (Zchn==`O´) || (Zchn==`U´)){ VokalAnzahl +=1; } cin>>Zchn } } def(Zchn) p-use(Zchn), p-use(Gesamtzahl) c-use(Gesamtzahl) def(Gesamtzahl) p-use(Zchn) c-use(VokalAzahl) def(VokalAnzahl) def(Zchn) c-use(VokalAzahl) c-use(Gesamtzahl) 2.3 strukturelle Tests 24.11.2004

Defs/Uses-Kriterien zur Testabdeckung Testfallerzeugung berechne Pfade zwischen Definition und Verwendung ungenutzte Definitionen markieren Fehler Kriterien all defs: Jeder Pfad von einer Definition zu mindestens einer Verwendung enthalten all p-uses: Jeder Pfad von einer Definition zu irgendeiner prädikativen Verwendung subsumiert Zweigüberdeckung all c-uses: analog, zu computational use all c-uses/some p-uses: jede berechnende oder mindestens eine prädikative Verwendung all uses: jede Verwendung du-paths: Einschränkung auf wiederholungsfreie Pfade 2.3 strukturelle Tests 24.11.2004

Datenkontexte Ein Datenkontext für einen Knoten ist eine Menge von Knoten, die für jede der im Knoten verwendeten Variablen eine Definition enthalten Datenkontext-Überdeckung: Alle Datenkontexte müssen vorkommen, d.h. jede Möglichkeit, den Variablen Werte zuzuweisen ggf. zusätzlich Berücksichtigung der Definitionsreihenfolge x = y+z y = … z = … 2.3 strukturelle Tests 24.11.2004

Diskussion Datenflussüberdeckung Mächtiger als Kontrollflussverfahren Besonders für objektorientierte Programme all c-uses besser als all p-uses besser als all-defs Werkzeugunterstützung essenziell wenig Werkzeuge verfügbar 2.3 strukturelle Tests 24.11.2004

Bewertung strukturelle Tests Auslassungsfehler (auch: fehlende Ausnahmebehandlung usw.) prinzipiell nicht erfasst Konstruktion von Testfällen kann beliebig schwierig sein „dead code“ (der nie ausgeführt werden kann) wird normalerweise entdeckt Toolunterstützung Möglichkeit der Code-Optimierung durch Testergebnisse (häufig durchlaufene Programmteile verbessern); aber: Regressionstest erforderlich! Literaturempfehlung: How to Misuse Code Coverage; Brian Marick; http://www.testing.com/writings/coverage.pdf 2.3 strukturelle Tests 24.11.2004

Hausaufgabe Erstellen Sie Testsuiten, die die datenflussorientierten Abdeckungskriterien erfüllen! Wie unterscheiden sich die Testsuiten von den kontrollflussorientierten Testabdeckungen? 2.3 strukturelle Tests 24.11.2004