18.1.2006
Software-Engineering IIEingebettete Systeme, Softwarequalität, Projektmanagement
Prof. Dr. Holger SchlingloffInstitut für Informatik der Humboldt Universität
und
Fraunhofer Institut für Rechnerarchitektur und Softwaretechnik
Folie 2H. Schlingloff, Software-Engineering II 18.1.2006
Komponententest-Entwurf
• sehr entwicklungsnahe Testarbeit, oftmals direkt am ausführbaren Code Problematik der Spezifikation (Wozu eine
Spezifikation, wenn der Code selbst vorliegt?)
• fließender Übergang zum Debugging; oft von den Entwicklern selbst durchgeführt Problematik der Zielsetzung (Fehler finden oder
Ablauffähigkeit demonstrieren?) Problematik des Hintergrundwissens aus der
Entwicklung (für den Testentwurf oft notwendig, aber stillschweigende Annahmen behindern die Objektivität bzw. Abdeckung)
Folie 3H. Schlingloff, Software-Engineering II 18.1.2006
Beispiel
• geg. Funktion overlaps die als Eingabe zwei Zeitintervalle A und B (jeweils gegeben durch (start_X, ende_X)) bekommt und bestimmt, ob sie sich überlappen
• Schreiben Sie für diese Funktion Testfälle auf!(Jetzt!)
Folie 4H. Schlingloff, Software-Engineering II 18.1.2006
Auswertung nach Punkten (1)
1. Haben Sie einen Testfall für überlappende Intervalle?2. … und einen für nicht überlappende Intervalle?3. Haben Sie einen Testfall wo das erste Intervall vor
dem zweiten und einen wo das zweite vor dem ersten liegt?
4. Haben Sie einen Testfall wo ein Intervall vollständig innerhalb des anderen liegt?
5. Haben Sie einen Testfall wo die beiden Intervalle aneinander stoßen?
6. Haben Sie einen Testfall wo die beiden Intervalle mit dem selben Zeitpunkt beginnen?
7. Haben Sie einen Testfall wo die beiden Intervalle mit dem selben Zeitpunkt enden?
Folie 5H. Schlingloff, Software-Engineering II 18.1.2006
Auswertung nach Punkten (2)
8. Haben Sie für jeden der Fälle 4-7 einen symmetrischen Testfall wo die Intervalle vertauscht sind?
9. Haben Sie einen Testfall wo die beiden Intervalle gleich sind?
10.Haben Sie einen Testfall mit einem punktförmigen Intervall?
11.Haben Sie einen Testfall mit zwei gleichen punktförmigen Intervallen?
12.Haben Sie Testfälle mit ganzzahligen und nichtganzzahligen Werten?
13.Haben Sie Testfälle mit unzulässigen Intervallen?14.Haben Sie Testfälle mit Werten am Rande des
Zahlenbereichs (maxint / maxreal)?
Folie 6H. Schlingloff, Software-Engineering II 18.1.2006
Auswertung nach Punkten (3)
Zusatzpunkte:
16.Haben Sie zusätzlich in allen Testfällen die erwarteten Ausgabewerte angegeben?
17.Haben Sie wenigstens einen Testfall, in dem Sie eine falsche Anzahl von Werten angeben (z.B. drei statt vier ganzzahlige Werte)?
18.Haben Sie Testfälle mit negativen Eingabewerten?19.Haben Sie Testfälle die die Zahlbereichs-
Überlaufbehandlung testen?20.Haben Sie Tests mit unzulässigen Eingabezeichenfolgen?
Folie 7H. Schlingloff, Software-Engineering II 18.1.2006
Reflexion
• Durchschnittswerte erfahrener Programmierer: 7-8
• „Diese Übung sollte zeigen, dass das Testen auch eines solch trivialen Programms keine leichte Aufgabe ist. Und wenn das wahr ist, betrachten Sie die Schwierigkeit, ein Flugleitsystem mit 100.000 Befehlen, einen Compiler oder auch nur ein gängiges Gehaltsabrechnungsprogramm zu testen.“ (1979)
• Heute: 1-10 MLoC
Folie 8H. Schlingloff, Software-Engineering II 18.1.2006
Testentwurf im Komponententest
• Aus Komplexitätsgründen ist es nicht möglich, alle Eingabewerte(-folgen) zu testen
• Problem: Welche Untermenge aller denkbaren Testfälle bietet die größte Wahrscheinlichkeit, möglichst viele Fehler zu finden?
Techniken zur Testdaten- und Testfallbestimmung
• Äquivalenzklassenbildung Auswahl „repräsentativer“ Daten
• Grenzwertanalyse Wertebereiche und Bereichsgrenzen
• Entscheidungstabellen und Klassifikationsbäume
Folie 9H. Schlingloff, Software-Engineering II 18.1.2006
Äquivalenzklassenbildung
• 1. Schritt: Partitionierung des Eingabedatenraumes in eine endliche Zahl von Äquivalenzklassen (bezüglich des vermuteten Ausfallverhaltens) im Beispiel: „zwei echte, disjunkte Zeitintervalle“
• 2. Schritt: Auswahl der Testfälle anhand je eines Repräsentanten der Äquivalenzklasse im Beispiel: ((1,2),(3,4))
• 3. Schritt: Bildung von Testfällen durch Kombination von Testfällen für die verschiedenen Eingaben
• Grenzwertanalyse: Auswahl von Testfällen an den Rändern der Äquivalenzklassen Testfälle für die Grenzwerte selbst sowie die Werte
unmittelbar neben den Grenzwerten Bei strukturierten Daten kartesisches Produkt der Grenzwerte
- Achtung, kombinatorische Explosion!
Folie 10H. Schlingloff, Software-Engineering II 18.1.2006
Übungsbeispiel
• Bilden Sie Testfälle gemäß der Grenzwertmethode! (jetzt!)
• Welche Fälle wurden nicht erfasst? Warum?
public final class IMath {
public static int idiv (int x, y) { /* Returns the integer quotient of the two input values */ … }}
Folie 11H. Schlingloff, Software-Engineering II 18.1.2006
Äquivalenzklassenmethode – Vor- und Nachteile
• Vorteile systematische Vorgehensweise kalkulierbare Anzahl Testfälle und Überdeckung gut für kleine Funktionen mit Vor- und
Nachbedingungen
• Nachteile Testfallauswahl durch Heuristik Wechselwirkungen zwischen Parameterwerten
werden oft übersehen bei komplexen Kontrollstrukturen vergleichsweise
viele Klassen
Folie 12H. Schlingloff, Software-Engineering II 18.1.2006
Pause!
Folie 13H. Schlingloff, Software-Engineering II 18.1.2006
Abdeckung
• Oft ergeben sich „sehr viele“ Klassen und mögliche Testfälle
• Problematik „wie vollständig ist die Testsuite“?
Abdeckungskriterien im Code jedes Statement wird einmal ausgeführt jede Bedingung ist einmal wahr und einmal falsch jeder Pfad wird einmal durchlaufen jede Schleife wird mehrfach durchlaufen (wie oft?) …
• Kein Blackbox-Test!
Folie 14H. Schlingloff, Software-Engineering II 18.1.2006
Kontrollflussgraph
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
start
n1
n2
n4
n5
n6
ende
n3
Folie 15H. Schlingloff, Software-Engineering II 18.1.2006
Kontrollflussorientierte Tests
Überdeckungsmaße Anweisungsüberdeckung (statement
coverage, C0) Zweigüberdeckung (branch coverage, C1) Pfadüberdeckung (path coverage, C2) Bedingungsüberdeckung (condition
coverage, C3)- einfache Bedingungsüberdeckung
- mehrfache Bedingungsüberdeckung
- minimale Bedingungsüberdeckung
Folie 16H. Schlingloff, Software-Engineering II 18.1.2006
Anweisungsüberdeckung
• 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
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
}}
Folie 17H. Schlingloff, Software-Engineering II 18.1.2006
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
Folie 18H. Schlingloff, Software-Engineering II 18.1.2006
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
n4
n5
n6
ende
n3
Folie 19H. Schlingloff, Software-Engineering II 18.1.2006
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
Folie 20H. Schlingloff, Software-Engineering II 18.1.2006
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?
Folie 21H. Schlingloff, Software-Engineering II 18.1.2006
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
Folie 22H. Schlingloff, Software-Engineering II 18.1.2006
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)): alle Kombinationen atomarer Bedingungen
minimale Mehrfachbedingungsüberdeckung (MC/DC): Jede Entscheidung im Flussdiagramm unabhängig 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
}}
Folie 23H. Schlingloff, Software-Engineering II 18.1.2006
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)
Folie 24H. Schlingloff, Software-Engineering II 18.1.2006
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ß
Folie 25H. Schlingloff, Software-Engineering II 18.1.2006
minimale Mehrfachbedingungsüberdeckung
• Modified Condition/Decision Coverage MC/DC• 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• (A||B) wird durch (wf) (fw) und (ff) überdeckt• Modifikation: zusätzlicher Nachweis, dass jede atomare
Teilentscheidung relevant ist (z.B. durch positiven und negativen Testfall) DO-178B Standard für Avionik-Software:
“Every point of entry and exit has been invoked at least once, every condition in a decision has taken on all possible outcomes at least once, every decision has taken all possible outcomes at least once, and each condition in a decision has been shown to independently affect the decision’s outcome.”
Folie 26H. Schlingloff, Software-Engineering II 18.1.2006
Coverage Tools
Folie 27H. Schlingloff, Software-Engineering II 18.1.2006
Pause!
Folie 28H. Schlingloff, Software-Engineering II 18.1.2006
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
Folie 29H. Schlingloff, Software-Engineering II 18.1.2006
attributierter Kontrollflussgraph
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(VokalAnzahl)
def(Gesamtzahl)start
n1
n2
n4
n5
n6
ende
n3
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)
Folie 30H. Schlingloff, Software-Engineering II 18.1.2006
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
Folie 31H. Schlingloff, Software-Engineering II 18.1.2006
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 = …
y = …
Folie 32H. Schlingloff, Software-Engineering II 18.1.2006
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
Folie 33H. Schlingloff, Software-Engineering II 18.1.2006
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!
• Historisch seit 1963 etabliert, weit verbreitet
• Literaturempfehlung: How to Misuse Code Coverage; Brian Marick; http://www.testing.com/writings/coverage.pdf
Top Related