Qualitätssicherung von Software (SWQS)

Slides:



Advertisements
Ähnliche Präsentationen
Christian Scheideler SS 2009
Advertisements

Integrations- und Funktionstests im Rahmen des V-Modelles
Phasen und ihre Workflows
Analytische Qualitätssicherung
Grundlagen der Programmierung (GP)
Modellbasierte Software-Entwicklung eingebetteter Systeme
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
Qualitätssicherung von Software (SWQS)
Qualitätssicherung von Software (SWQS)
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
Software-Engineering II Eingebettete Systeme, Softwarequalität, Projektmanagement Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt.
Dynamische Testverfahren
LE LM 10 - LO3 Verfahren zur Qualitätssicherung
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 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
Proseminar „Algorithmen auf Graphen“
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.
Batch-Programmierung Grundlagen
DVG Ablaufsteuerung
Schleifen mit der Turtle
Whitebox Testen mit JUnit
Software Engineering 1 6. Übung
LS 2 / Informatik Datenstrukturen, Algorithmen und Programmierung 2 (DAP2)
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
Black Box Algorithmen Hartmut Klauck Universität Frankfurt SS
Effiziente Algorithmen Hartmut Klauck Universität Frankfurt SS
Hartmut Klauck Universität Frankfurt SS
Telecooperation/RBG Technische Universität Darmstadt Copyrighted material; for TUD student use only Grundlagen der Informatik I Thema 16: Ausnahmebehandlung.
Einführung in die Programmierung
Wiederholte Programmausführung
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, 7. April, 2005 Bedingte ProgrammausführungBedingte Programmausführung Algorithmische Grundlagen Vergleichsoperatoren, Wahrheitswerte.
Agenda für heute, 14. April, 2005 Wiederholte ProgrammausführungWiederholte Programmausführung Algorithmische Grundlagen Bedingungen zum Abbruch von Programmschleifen.
PHP: Operatoren und Kontrollstrukturen
1 Albert-Ludwigs-Universität Freiburg Rechnernetze und Telematik Prof. Dr. Christian Schindelhauer Informatik III Christian Schindelhauer Wintersemester.
Programmiervorkurs WS 2014/15 Schleifen
Korrektheit von Programmen – Testen
Analyse der Laufzeit von Algorithmen
Schleifen
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.
Java-Kurs - 4. Übung Hausaufgabe Weitere Kontrollstrukturen
Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer.
Java-Kurs - 4. Übung Hausaufgabe Weitere Kontrollstrukturen
Korrektheit von Programmen – Testen
Wann ist eine Funktion (über den natürlichen Zahlen) berechenbar?
Prüfungsbesprechung Barbara Scheuner Vorlesung: Programmieren und Problemlösen Prof. Hans Hinterberger.
Programmiersprachen II Vorbesprechung Klausur Prof. Dr. Reiner Güttler Fachbereich GIS HTW.
 Präsentation transkript:

Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 25.4.2013: strukturelle Tests

Fragen zur Wiederholung robuste vs. nicht-robuste Grenzwertanalyse? Was ist ein Ursache-Wirkungs-Graph, was ist eine Entscheidungstabelle? wie können Entscheidungstabellen repräsentiert werden? Was ist ein Klassifikationsbaum?

Wo stehen wir? Kapitel 2. Softwaretest Kapitel 1: Einleitung, Begriffe, Software-Qualitätskriterien Kapitel 2. Softwaretest 2.1 Testen im SW-Lebenszyklus 2.2 Funktionale Tests, Modultests, Testfallauswahl 2.3 Strukturelle Tests, Integrationstests 2.4 Modellbasierte Tests

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 !

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

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

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 } }

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

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

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

Ü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

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 } }

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)

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ß

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) „MC/DC“ z.B. für flugkritische Software erforderlich http://shemesh.larc.nasa.gov/fm/papers/Hayhurst-2001-tm210876-MCDC.pdf DO-178B/ED-12B includes the following definitions: Modified Condition/Decision Coverage - Every point of entry and exit in the program has been invoked at least once, every condition in a decision in the program has taken all possible outcomes at least once, every decision in the program has taken all possible outcomes at least once, and each condition in a decision has been shown to independently affect that decision's outcome. A condition is shown to independently affect a decision's outcome by varying just that condition while holding fixed all other possible conditions. Condition - A Boolean expression containing no Boolean operators. Decision - A Boolean expression composed of conditions and zero or more Boolean operators. A decision without a Boolean operator is a condition. If a condition appears more than once in a decision, each occurrence is a distinct condition. Decision Coverage - Every point of entry and exit in the program has been invoked at least once and every decision in the program has taken on all possible outcomes at least once.

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?

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

Übersicht: Abdeckungsmaße Anweisungsabdeckung / Statement Coverage (C0) Verhältnis von ausgeführten Anweisungen während des Tests zu allen Anweisungen im Code Zweigabdeckung / Branch Coverage (C1) Verhältnis von getesteten Zweigen zu allen vorhandenen Zweigen in einem Kontrollflussgraph eines Moduls Entscheidungsabdeckung / Decision Coverage Das Verhältnis von getroffenen Entscheidungen während des Tests zu allen möglichen Entscheidungen während der Programmausführung Bedingungsabdeckung / Condition Coverage Verhältnis von ausgewerteten atomaren Werten (Term, Bedingung, ...) innerhalb von Ausdrücken zu allen vorhandenen atomaren Werten in einem Modul Mehrfachbedingungsabdeckung / Multicondition Coverage Verhältnis von durchlaufenen atomaren Bedingungen während des Tests zu allen möglichen Kombinationen von atomaren Bedingungen innerhalb eines Ausdrucks in einem Modul Modified Condition / Decision Coverage (MC/DC) Verhältnis von Auswirkungen von bewerteten atomaren Werten auf den Gesamtausdruck, zu allen möglichen Auswirkungen von atomaren Werten innerhalb eines Moduls Pfadabdeckung / Path Coverage (C2) Verhältnis der getesteten Pfade (Wege im Kontrollflussgraph) zu allen möglichen Pfaden in einem Modul nach: http://robert.bullinger.over-blog.com/article-code-abdeckung-99961701.html

Coverage Tools

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

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)

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

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 = …

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

Hausaufgabe Erstellen Sie für das Beispiel Testsuiten, die die datenflussorientierten Abdeckungskriterien erfüllen! Wie unterscheiden sich die Testsuiten von den kontrollflussorientierten Testabdeckungen?

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! Lesen: Frank Büchner: Acht Irrtümer über Code Coverage; Fünf Irrtümer über Code Coverage http://www.elektronikpraxis.vogel.de/themen/embeddedsoftwareengineering/testinstallation/articles/247210/