Post on 05-Apr-2015
Qualitätssicherung von Software (SWQS)
Prof. Dr. Holger Schlingloff
Humboldt-Universität zu Berlinund
Fraunhofer FOKUS
18.4.2013: Modultest
Folie 2H. Schlingloff, Software-Qualitätssicherung
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...
Folie 3H. Schlingloff, Software-Qualitätssicherung
Wo stehen wir?
Kapitel 2. Softwaretest
2.1 Testen im SW-Lebenszyklus2.2 Funktionale Tests, Modultests,
Testfallauswahl2.3 Strukturelle Tests,
Integrationstests2.4 Modellbasierte Tests
Kapitel 1: Einleitung, Begriffe, Software-Qualitätskriterien
Folie 4H. Schlingloff, Software-Qualitätssicherung
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%
Folie 5H. Schlingloff, Software-Qualitätssicherung
Specification-based versus Code-based
• 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)
Specification Program
Test Suite
Folie 6H. Schlingloff, Software-Qualitätssicherung
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)
Folie 7H. Schlingloff, Software-Qualitätssicherung
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 – specification-
based test structural test – white-box-test – code-based test
Folie 8H. Schlingloff, Software-Qualitätssicherung
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, ...
Folie 9H. Schlingloff, Software-Qualitätssicherung
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
Folie 10H. Schlingloff, Software-Qualitätssicherung
Methodik des Modultests
• Jeder einzelne Baustein wird unabhängig von den anderen getestetVorteile: 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 zusammengebundenVorteile: SUT Umgebung (Variablen) kann durch Testprogramm leicht
beeinflusst werden Aufruf von SUT Funktionen mit entsprechenden Parametern Auswertung durch Vergleich von Variablenwerten
Folie 11H. Schlingloff, Software-Qualitätssicherung
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, …
Folie 12H. Schlingloff, Software-Qualitätssicherung
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
Folie 13H. Schlingloff, Software-Qualitätssicherung
Ein Beispiel
Beispiel: Yoonsik Cheon, University of Texas at El Paso, www.cs.utep.edu/~cheon/cs3331/notes/unit-testing.ppt
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)); }}
Folie 14H. Schlingloff, Software-Qualitätssicherung
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?
Folie 15H. Schlingloff, Software-Qualitätssicherung
JUnit (vgl. Übung!)
• Kontrollierte Testausführung und -auswertung
• Public domain (www.junit.org)
• sofort einsetzbar, in viele IDEs integriert
• unterstützt „Test durch Entwickler“ Paradigma
• Testautomatisierung!
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()); }}
Folie 16H. Schlingloff, Software-Qualitätssicherung
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)
Folie 17H. Schlingloff, Software-Qualitätssicherung
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)
Folie 18H. Schlingloff, Software-Qualitätssicherung
Folie 19H. Schlingloff, Software-Qualitätssicherung
Beispiel: Die TiM-Funktion
• 30+((m mod 2) xor (m div 8))-n*(n==2)
• if m==2 then 28else if m<7 and even(m) or m>7 and odd(m) then 30 else 31
• if m==2 then 28else 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]
Folie 20H. Schlingloff, Software-Qualitätssicherung
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
Folie 21H. Schlingloff, Software-Qualitätssicherung
Äquivalenzklassenbildung
• 1. Schritt: Partitionierung desEingabedatenraumes 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
Folie 22H. Schlingloff, Software-Qualitätssicherung
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
Folie 23H. Schlingloff, Software-Qualitätssicherung
Kombination von Parameterwerten
Folie 24H. Schlingloff, Software-Qualitätssicherung
Vorgehensweise zur Testfallauswahl
• 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 abdeckenBeispiel (Tag Monat):
{(1,1), (29,4), (30,2), (31,1), (0,0)}
Äq1 Äq2 Äq3…
Par1 Wert1.1 Wert1.2
Par2 Wert2.1…
…
ParN
Folie 25H. Schlingloff, Software-Qualitätssicherung
Übung
• Welche Testfälle ergeben sich aus der Äquivalenzklassenmethode?
• Welche wichtigen Fälle sind nicht abgedeckt?
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
Folie 26H. Schlingloff, Software-Qualitätssicherung
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
Folie 27H. Schlingloff, Software-Qualitätssicherung
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