Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest."—  Präsentation transkript:

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

2 Folie 2 H. 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: scheint nicht mehr zu existieren...

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

4 Folie 4 H. 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%

5 Folie 5 H. 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) SpecificationProgram Test Suite

6 Folie 6 H. 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)

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

8 Folie 8 H. 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,...

9 Folie 9 H. 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

10 Folie 10 H. Schlingloff, Software-Qualitätssicherung 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

11 Folie 11 H. 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, …

12 Folie 12 H. 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

13 Folie 13 H. Schlingloff, Software-Qualitätssicherung Ein Beispiel Beispiel: Yoonsik Cheon, University of Texas at El Paso, 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)); }

14 Folie 14 H. 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?

15 Folie 15 H. 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()); }

16 Folie 16 H. 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)

17 Folie 17 H. 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)

18 Folie 18 H. Schlingloff, Software-Qualitätssicherung

19 Folie 19 H. Schlingloff, Software-Qualitätssicherung 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 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]

20 Folie 20 H. Schlingloff, Software-Qualitätssicherung Testfallauswahl im Komponententest Aus Komplexitätsgründen ist es nicht möglich, alle Eingabewerte(-folgen) zu testen 32-bit integer values (Tag, Monat, Jahr) 31*12*700= 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

21 Folie 21 H. Schlingloff, Software-Qualitätssicherung Ä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 [ ] [ ] [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

22 Folie 22 H. 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

23 Folie 23 H. Schlingloff, Software-Qualitätssicherung Kombination von Parameterwerten

24 Folie 24 H. Schlingloff, Software-Qualitätssicherung Vorgehensweise zur Testfallauswahl Vollständig: Kartesisches Produkt aller Klassen meist nicht praktikabel Paarweise: Vereinigung aller Par i x Par j 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)} Äq 1 Äq 2 Äq 3 … Par 1 Wert 1.1 Wert 1.2 Par 2 Wert 2.1 … … Par N

25 Folie 25 H. 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

26 Folie 26 H. 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

27 Folie 27 H. 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


Herunterladen ppt "Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 18.4.2013: Modultest."

Ähnliche Präsentationen


Google-Anzeigen