Qualitätssicherung von
Software (SWQS)
Prof. Dr. Holger Schlingloff
Humboldt-Universität zu Berlin
und
Fraunhofer FOKUS
18.4.2013: Modultest
Fragen zur Wiederholung
•
•
•
•
•
•
Unterschied blackbox / whitebox Test?
Was ist eine Testsuite?
Notationsmöglichkeiten für Testfälle?
Was vesteht man unter einem Testorakel?
Was sind Testziele?
Vor- und Nachteile von “test your own program”?
Nachtrag: www.testingfaqs.org scheint nicht mehr zu existieren...
H. Schlingloff, Software-Qualitätssicherung
Folie 2
Wo stehen wir?
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
H. Schlingloff, Software-Qualitätssicherung
Folie 3
Software Engineering Fakten
• Typische Verteilung der Entwicklungskosten: 10%
•
•
•
•
Anforderungen, 10% Architektur, 20% Entwurf, 15%
Implementierung, 45% Integration und Test
Siemens: 7% der Entwicklungsaktivität ist Kodierung
Qualitätssicherung beansprucht 30-80% der
gesamten Entwicklungskosten
Unit-Testen benötigt 40-70% des gesamtem
Implementierungsaufwandes
In sicherheitskritischen Systemen bis zu 90%
H. Schlingloff, Software-Qualitätssicherung
Folie 4
Specification-based versus Code-based
Specification
Program
Test Suite
• Test case derivation source: specification or code?
• Specification-based testing checks whether the
•
specified behaviour is implemented; it cannot find
unspecified program behaviours (e.g. viruses)
Program-code-based testing checks whether the
implemented behaviour is correct (with respect to
the specification); it cannot find unimplemented
requirements (e.g. missing features)
H. Schlingloff, Software-Qualitätssicherung
Folie 5
Black-box versus White-Box
• White-Box: Structure is openly accessible and visible
•
•
to the tester; e.g. reading and writing of program
variables during test execution
Black-Box: Internals are hidden (e.g. for copyright
reasons); access only through documented external
interfaces
Grey-Box: Some internal details are revealed for
testing purposes (e.g. special testing monitors)
H. Schlingloff, Software-Qualitätssicherung
Folie 6
Functional versus Structural Testing
• Focus on
 “functional”: performed function, i.e. actions or
activities of the SUT, “what” (external view)
- e.g. relation between input and output values
 “structural”: designed structure, i.e. components
or implementation, “how” (internal view)
- e.g. data and data types or algorithmic idea
• Often used synonymously:
 functional test – black-box-test – specificationbased test
 structural test – white-box-test – code-based test
H. Schlingloff, Software-Qualitätssicherung
Folie 7
Codebasierter Test: Modultest
weitgehend synonym: Modultest, Unit-Test, Komponententest
• Oftmals mit „dem Test“ gleichgesetzt
 erste Teststufe im analytischen Teil des V-Modells
• erstmaliger Test der ausführbaren Softwarebausteine nach
der Programmierung
 Prozeduren, Funktionen (imperativ)
 Module, Units, Klassen, Interfaces (objektorientiert)
 Blöcke (in der modellbasierten Entwicklung)
• Oftmals die selbe Entwicklungsumgebung wie das SUT
 Compiler, Linker, IDE, ...
H. Schlingloff, Software-Qualitätssicherung
Folie 8
Modultest: Vorgehensweise
• Wer?
 Theorie: Programmierer ungleich Tester
 Praxis: Unit-test durch die Entwickler
• Wann?
 Theorie: Parallel zur Implementierung
 Praxis: Nach Fertigstellung des Moduls
- “Teste es bevor jemand anderes es sieht”
 eXtreme programming: Testfälle vor der Implementierung
- Testfälle sind während der Implementierung verfügbar
- Designfehler werden erkannt bevor überhaupt mit der
Implementierung begonnen wird
H. Schlingloff, Software-Qualitätssicherung
Folie 9
Methodik des Modultests
• Jeder einzelne Baustein wird unabhängig von den anderen
getestet
Vorteile:
 keine externen Einflüsse oder Wechselwirkungen
 klare und einfache Fehlereingrenzung und –lokalisierung
 Bausteine dürfen auch verschachtelt sein, keine zusätzlichen Probleme
• SUT wird mit Testumgebung zusammengebunden
Vorteile:
 SUT Umgebung (Variablen) kann durch Testprogramm leicht
beeinflusst werden
 Aufruf von SUT Funktionen mit entsprechenden Parametern
 Auswertung durch Vergleich von Variablenwerten
H. Schlingloff, Software-Qualitätssicherung
Folie 10
Ziele des Komponententests
• Aufdeckung von Fehlern im Modul
 falsche Berechnungen, falsche Ausgaben
- falsche Instuktionen, Schleifen, Grenzen, Pointerarithmetik, ...
 fehlende Programmpfade
- fehlende Fälle, insbesondere fehlende Sonderfallbehandlung
- Reaktion auf unzulässige Eingabewerte, Ausnahmebehandlung
- Robustheit gegenüber falscher Benutzung
 Redundante Fälle und Berechnungen
- sich überschneidende Fälle, toter Code, unnötige Ausgaben
 sinnvolle Fehlermeldungen bzw. Ausnahmebehandlung
- falsche oder unzutreffende (Fehler-)meldungen, fehlende Meldungen
 timing und Synchronisationsprobleme (schwierig!)
• nichtfunktionale Gesichtspunkte sind sekundär
 Effizienz, Platz- und Zeitverbrauch
 Spezifikation und Dokumentation
 Wartbarkeit, Änderbarkeit, …
H. Schlingloff, Software-Qualitätssicherung
Folie 11
Vorgehensweise
• Bottom-up Ansatz
 Start mit Klassen die von keinen anderen abhängen
 Alle Funktionen der Klasse müssen getestet werden, alle Datenfelder
verwendet und alle Zustände durchlaufen werden
 Dann Test von Klassen die auf bereits getesteten aufbauen
• Schichtenartige Architektursicht
 Aggregation von Einzeltests in Testsuiten
H. Schlingloff, Software-Qualitätssicherung
Folie 12
Ein Beispiel
public final class IMath {
/*
* Returns an integer approximation
* to the square root of x.
*/
public static int isqrt(int x) {
int guess = 1;
while (guess * guess < x) {
guess++;
}
return guess;
}
}
/** A class to test the class IMath. */
public class IMathTestNoJUnit {
/** Runs the tests. */
public static void main(String[] args) {
printTestResult(0);
printTestResult(1);
printTestResult(2);
printTestResult(3);
printTestResult(4);
printTestResult(7);
printTestResult(9);
printTestResult(100);
}
private static void printTestResult(int arg) {
System.out.print(“isqrt(“ + arg + “) ==> “);
System.out.println(IMath.isqrt(arg));
}
}
Beispiel: Yoonsik Cheon, University of Texas at El Paso, www.cs.utep.edu/~cheon/cs3331/notes/unit-testing.ppt
H. Schlingloff, Software-Qualitätssicherung
Folie 13
Fragen zum Beispiel
• Was ist die Ausgabe der Tests?
• Vorteile gegenüber manuellem Test?
• Welche Fehler werden (nicht) gefunden?
• Probleme mit dieser Art zu testen?
• Was kann verbessert werden?
H. Schlingloff, Software-Qualitätssicherung
Folie 14
JUnit (vgl. Übung!)
import junit.framework.*;
public class IMathTest extends TestCase {
public void testIsqrt() {
assertEquals(0, IMath.isqrt(0));
assertEquals(1, IMath.isqrt(1));
…
assertEquals(10, IMath.isqrt(100));
}
public static Test suite() {
return new TestSuite(IMathTest.class);
}
public static void main (String[] args) {
junit.textui.TestRunner.run(suite());
}
}
H. Schlingloff, Software-Qualitätssicherung
• Kontrollierte
•
•
•
•
Testausführung und auswertung
Public domain
(www.junit.org)
sofort einsetzbar, in
viele IDEs integriert
unterstützt „Test
durch Entwickler“
Paradigma
Testautomatisierung!
Folie 15
JUnit (Forts.)
• Typisch für eine Reihe ähnlicher Tools
• Vorteile der Verwendung






automatisierte, wiederholbare Tests (nach jedem „Build“!)
kombinierbar zu Testklassen und Testsuiten
Einbeziehung von Testdaten
automatische Testauswertung
Möglichkeit des Tests von Ausnahmen
Möglichkeit der Verwendung interner Schnittstellen
• Was JUnit dem Tester nicht abnimmt
 Testentwurf (Auswahl und Beurteilung der Testfälle)
H. Schlingloff, Software-Qualitätssicherung
Folie 16
Modultest als “der Softwaretest”?
• Unit-Tests sind
 nahe an der Implementierung, dem “tatsächlichen Produkt”
 sehr flexibel durch vollständige Zugriffsmöglichkeit auf das SUT
 oft durch die Entwickler durchgeführt, diese kennen den Code und können
daher effizient Testfälle entwickeln
 hilfreich zum Debuggen auf Grund der schnellen Fehlerlokalisierung; ebenso
zur Demonstration der Lauffähigkeit des SUT
• Probleme mit Unit-Tests
 fehlende Redundanz, Rollentrennung
 Die Spezifikation ist oft nur von sekundärer Bedeutung (Wozu eine
Spezifikation, wenn der Code selbst vorliegt?)
 Problem der impliziten Annahmen: Hintergrundwissen aus der Entwicklung ist
für den Testentwurf oft notwendig, aber stillschweigende Annahmen
behindern die Objektivität bzw. Abdeckung
 als Korrektheitsnachweis nur bedingt geeignet (die trügerische Sicherheit des
grünen Balkens)
H. Schlingloff, Software-Qualitätssicherung
Folie 17
H. Schlingloff, Software-Qualitätssicherung
Folie 18
Beispiel: Die TiM-Funktion
• 30+((m mod 2) xor (m div 8))-n*(n==2)
• if m==2 then 28
else if m<7 and even(m) or m>7 and odd(m)
then 30 else 31
• if m==2 then 28
else if m in {4,6,9,11} then 30 else 31
• array
TiM=[31,28,31,30,31,30,31,31,30,31,30,31]
return TiM[month]
H. Schlingloff, Software-Qualitätssicherung
Folie 19
Testfallauswahl im Komponententest
• Aus Komplexitätsgründen ist es nicht möglich, alle
Eingabewerte(-folgen) zu testen
 32-bit integer  1010 values
 (Tag, Monat, Jahr)  31*12*700=260.000 Kombinationen
• 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
H. Schlingloff, Software-Qualitätssicherung
Folie 20
Äquivalenzklassenbildung
• 1. Schritt: Partitionierung des
Eingabedatenraumes in eine
endliche Zahl von Äquivalenzklassen
(bezüglich des vermuteten Ausfallverhaltens)
 im Triangle-Beispiel: Gleichseitiges Dreieck,
d.h. „drei gleiche Eingaben größer Null“
 z.B. für Integer [-maxint,-1] [0] [1,3] [4, maxint]
 z.B. für Tag [1,28] [29] [30] [31] und Monat [1 3 5 7 8 10 12] [4 6 9 11] [2]
• 2. Schritt: Auswahl der Testfälle anhand je eines Repräsentanten der
Äquivalenzklasse
 im Beispiel: {(2,2,2)}
 oder: {-17396,0,2,72586}
 oder {17,29,30,31} und {7, 9, 2}
• 3. Schritt: Kombination der Repräsentanten in Testfälle
 nur “sinnvolle” Kombinationen
H. Schlingloff, Software-Qualitätssicherung
Folie 21
Vorgehensweise zur Äquivalenzklassenbildung
• Betrachten der Definitionsbereiche für Ein-/Ausgabewerte
• Für jeden Wert ergeben sich gültige und ungültige Klassen
 Wertebereiche, Aufzählungen: enthalten oder nicht enthalten
 Eingabewerte, die (möglicherweise) unterschiedlich verarbeitet
werden: für jeden Wert eine gültige und insgesamt eine ungültige
Klasse
 Ausgaben, die auf verschiedene Weise berechnet werden: je eine
Klasse, die auf diese Ausgabe führt
 Eingabebedingungen, die vorausgesetzt werden: je eine gültige und
eine ungültige Klasse
• Aufspaltung einer Klasse in kleinere Klassen, falls Grund zur
•
Annahme besteht, dass nicht alle Elemente gleich behandelt
werden
Tabellierung der zu jedem Parameter gehörigen Klassen
H. Schlingloff, Software-Qualitätssicherung
Folie 22
Kombination von Parameterwerten
H. Schlingloff, Software-Qualitätssicherung
Folie 23
Vorgehensweise zur Testfallauswahl
Par1
Par2
…
Äq1
Äq2
Wert1.1 Wert1.2
Wert2.1
…
Äq3
…
ParN
• Vollständig: Kartesisches Produkt aller Klassen
 meist nicht praktikabel
• Paarweise: Vereinigung aller Pari x Parj
• Heuristisch: Auswahl gemäß folgender Strategie
 Bildung von Testfällen, die möglichst viele noch nicht behandelte
gültige Klassen abdecken
 Bildung von Testfällen, die genau eine ungültige Klasse abdecken
Beispiel (Tag Monat):
{(1,1), (29,4), (30,2), (31,1), (0,0)}
H. Schlingloff, Software-Qualitätssicherung
Folie 24
Übung
public final class IMath {
/*
* Returns an integer approximation
* to the square root of x.
*/
public static int isqrt(int x) {
/* precondition x>=0 */
int guess = 1;
while (guess * guess < x) {
guess++;
}
return guess;
}
}
Parameter: x (int)
Klassen: [-minint, -1] [0] [1,maxint]
Repräsentanten: -1, 0, 1
• Welche Testfälle ergeben sich aus der Äquivalenzklassenmethode?
• Welche wichtigen Fälle sind nicht abgedeckt?
H. Schlingloff, Software-Qualitätssicherung
Folie 25
Diskussion Äquivalenzklassenmethode
• Pro
 systematisches Vorgehen
 Überschaubare Anzahl Testfälle
 gut geeignet für “kleine” Funktionen mit Vor- und Nachbedingungen
• Contra
 Auswahl der Testfälle durch eine Heuristik
 Abhängigkeiten zwischen Parameterwerten werden nicht
berücksichtigt
 bei komplexen Parametern ergeben sich viele Äquivalenzklassen
H. Schlingloff, Software-Qualitätssicherung
Folie 26
Verbesserungsmöglichkeiten
• Grenzwertanalyse
 Fehler häufig an der Rändern einer
Äquivalenzklasse
 Neue Klassen für den Grenzwert selbst sowie die
Werte direkt daneben
• Entscheidungstabellenmethoden
 Klassifikationsbaummethode, CTE
H. Schlingloff, Software-Qualitätssicherung
Folie 27

ppt