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

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

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%

Specification-based versus Code-based 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)

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)

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

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, ...

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

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 SUT Umgebung (Variablen) kann durch Testprogramm leicht beeinflusst werden Aufruf von SUT Funktionen mit entsprechenden Parametern Auswertung durch Vergleich von Variablenwerten

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

Vorgehensweise Bottom-up Ansatz Schichtenartige Architektursicht 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

Ein Beispiel public final class IMath { /* /** 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)); 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; Beispiel: Yoonsik Cheon, University of Texas at El Paso, www.cs.utep.edu/~cheon/cs3331/notes/unit-testing.ppt

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?

JUnit (vgl. Übung!) Kontrollierte Testausführung und -auswertung 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()); Kontrollierte Testausführung und -auswertung Public domain (www.junit.org) sofort einsetzbar, in viele IDEs integriert unterstützt „Test durch Entwickler“ Paradigma Testautomatisierung!

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)

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)

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]

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

Ä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

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

Kombination von Parameterwerten

Vorgehensweise zur Testfallauswahl Äq1 Äq2 Äq3 … Par1 Wert1.1 Wert1.2 Par2 Wert2.1 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)}

Übung Welche Testfälle ergeben sich aus der Äquivalenzklassenmethode? Parameter: x (int) Klassen: [-minint, -1] [0] [1,maxint] Repräsentanten: -1, 0, 1 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; Welche Testfälle ergeben sich aus der Äquivalenzklassenmethode? Welche wichtigen Fälle sind nicht abgedeckt?

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

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