9.1 Grundlagen Nochmals: Verifikation und Test in der SW-Entwicklung. Existenz von Fehlern. Herausforderungen. 9. Kapitel Test von Software

Transkript

1 Verlässliche Systeme Wintersemester 2015/2016 Nochmals: Verifikation und Test in der SW-Entwicklung Verlässliche Systeme Fehler Test 9. Kapitel Test von Software Vorstellung des Kunden Formale Spezifikation Anforderungsspezifikation Programmentwurf keine Fehler gefunden Prof. Matthias Werner Professur Betriebssysteme Verifikation korrekt Fehler WS 2015/2016 M. Werner 2 / 22 osg.informatik.tu-chemnitz.de Existenz von Fehlern Herausforderungen Merke Softwaretests beweisen nie die Korrektheit von Programmen, sondern höchstens die Existenz von Fehlern! Trotzdem werden Software-Tests häufiger eingesetzt als Software-Verifikation: Zu großer Aufwand für Verifikation Mangelnde Fähigkeit/Kenntnis der Verifikationsmethoden Keine klare Spezifikation (Programmierer weiß ja, was gemeint ist...) Neue Technologien vergrößern (auch) oft die Komplexität des Testens Dynamisches Verhalten Nebenläufige Ausführung Komplexe Sprachen Paradigmen wie Objektorientierung Nachnutzung getesteter Komponenten in einem anderen Kontext Vererbung... In diesem Kapitel Überblick Ansätze Testautomatisierung WS 2015/2016 M. Werner 3 / 22 osg.informatik.tu-chemnitz.de WS 2015/2016 M. Werner 4 / 22 osg.informatik.tu-chemnitz.de

2 Grundidee Erzeuge irgendwelchen Input Lasse Programm laufen Vergleiche Ergebnis mit dem erwarteten Ergebnis Fehler-Test-Korrelation Die Wahrscheinlichkeit für die Existenz von Fehlern nimmt nicht mit der Zahl der gefundenen Fehler ab Probleme: Welcher Input? Abdeckung? Wann genug? es ist i.d.r. unmöglich, alle möglichen Eingabevarianten zu testen (Komplexität!) Ausnahme: erschöpfendes Testen Testen findet üblicherweise spät im Projekt statt Achtung: Abstumpfungsgefahr Quelle: G.J. Myers, The Art of Software Testing, John Wiley & Sons (2004) WS 2015/2016 M. Werner 5 / 22 osg.informatik.tu-chemnitz.de WS 2015/2016 M. Werner 6 / 22 osg.informatik.tu-chemnitz.de Frühes Testen Je später ein Fehler entdeckt wird, deso höher sind die entstehenden Kosten Beispiel: Kostenfaktor für Fehleraufdeckung in verschiedenen Phasen des Entwicklungsprozesses * Phase im Entwicklungsprozess Spezifikation 1 Fehler in... Spezifikation Entwurf Implementation Entwurf 3 1 Implementation Systemtest Post-Release Whitebox vs. Blackbox Whitebox Unit-Tests Konzept: Bei möglichst kleinen Komponenten möglichst viele Pfade testen Vorteil: Kenntnis interner Vorgänge bringt höchste Fehleraufdeckung Nachteil: Test werden i.d.r. vom Programmierer entworfen (jemand anders durchschaut den Code nicht) Aber: Jemand, der einen Fehler macht, erkennt ihn selten (Vorbelastung) * Quelle: STEVE MCCONNELL, Code Complete (2nd ed.),microsoft Press, 2004 WS 2015/2016 M. Werner 7 / 22 osg.informatik.tu-chemnitz.de WS 2015/2016 M. Werner 8 / 22 osg.informatik.tu-chemnitz.de

3 Whitebox vs. Blackbox (Forts.) Whitebox vs. Blackbox (Forts.) Blackbox Funktionstests Konzept: Übereinstimmung mit externer Spezifikation testen Vorteil: Tester werden nicht durch die Kenntnis des internen Designs beeinflusst Nachteile: Explizite Spezifikation wird benötigt Deckt i.d.r. nur einen kleinen Teil der möglichen Fälle ab In der Praxis wird meist eine Mischung aus Blackbox- und Whitebox-Test angewendet Graybox Testing: Blackbox mit zusätzlichen Informationen über verwendete Algorithmen interne Datenstrukturen Modul-Strukturen und -abhängigkeiten WS 2015/2016 M. Werner 9 / 22 osg.informatik.tu-chemnitz.de WS 2015/2016 M. Werner 10 / 22 osg.informatik.tu-chemnitz.de Generierung von Testfällen und -kriterien Software testing still remains an art, since the first day. We still don t know how to make it a science. Dies gilt insbesondere für die Generierung von Testfällen Problem: Vorwissen Vorwissen hilft kritische Fälle zu erkennen und damit Fälle einzuschränken Vorwissen verhindert die Erkennung kritischer Fälle und eleminiert sie In der Regel ist die Komponente oder die Voraussetzung fehlerhaft, an der keiner gezweifelt hat. J. PAN, CMU Software-Engineering Ableitung vom FINAGLES 3. Korollar zu MURPHYS Gesetz WS 2015/2016 M. Werner 11 / 22 osg.informatik.tu-chemnitz.de Generierung von Testfällen und -kriterien (Forts.) Unabhängig von der nötigen Intuition und Kreativität gibt es Standardherangehensweisen, z.b.: WB BB Idea Szenario-basiertes Testen wähle Testfälle nach Einsatzszenarien aus Risikobasiertes Testen wähle Testfälle nach Auswirkung Bedingungstabellen beschreibe Ursache-Wirkungskorrelation mit Hilfe von Bedingungstabellen Pfadabdeckung wähle Testfälle so, dass jeder Ausführungspfad abgedeckt ist Statementabdeckung wähle Testfälle so, dass jedes Statement abgedeckt ist Branch-Abdeckung wähle Testfälle so, dass bei jeder Verzweigung jeder Weg mindestens einmal getestet wird Datenflußanalyse teste entlang des Datenflusses Grenzwertanalyse teste beide Seiten von Unstetigkeitspunkten All pairs teste für eine Menge von Features alle Zweierkombinationen Adhoc-Tests nutze Intuition und gesunden Menschenverstand WS 2015/2016 M. Werner 12 / 22 osg.informatik.tu-chemnitz.de

4 Testphasen Integrationstest Systemtest Idee: Stückweise Vergrößerung des Testobjekts Releasetest Integrationstest Komponententest Hauptansätze: Top-down Integrationstest Bottom-up Integrationstest Regressionstest typischerweise durchgeführt von: Entwickler Unabhängigen Testteams WS 2015/2016 M. Werner 13 / 22 osg.informatik.tu-chemnitz.de WS 2015/2016 M. Werner 14 / 22 osg.informatik.tu-chemnitz.de Top-down Integrationstest Bottom-up Integrationstest Steuerprogramm wird zuerst getestet Module werden nacheinander integriert Schwerpunkt auf Interfaces Vorteile: Es wird kein Test-Treiber (Integrationsframework) benötigt Interface-Fehler werden früh aufgedeckt Nachteile: Es werden Module-Stubs benötigt Kritische Komponentenfehler werden spät erkannt Frühe Erkennung der Funktionsfähigkeit Schwerpunkt auf (Modul-)Funktionalität und Performance Vorteile: Es werden keine Module-Stubs benötigt Kritische Komponentenfehler werden früh erkannt Nachteile: Es werden Test-Treiber (Integrationsframework) benötigt Interface-Fehler werden spät erkannt WS 2015/2016 M. Werner 15 / 22 osg.informatik.tu-chemnitz.de WS 2015/2016 M. Werner 16 / 22 osg.informatik.tu-chemnitz.de

5 Regressionstest Nichtfunktionale Eigenschaften Testet die Auswirkungen von neuen Änderungen auf gesamten bisher integrierten Code Gemeinhin werden zwei Testmengen definiert: Gesamttest und kritische Untermenge Gesamttest wird gelegentlich durchgeführt Kritische Untermenge bei jedem Durchlauf Vorteil: Schnellere Eingrenzung von Fehlerursache Nachteil: Es ist schwer zu entscheiden, was zur kritischen Untermenge gehört Neben der funktionalen Korrektheit spielen auch nichtfunktionale Eigenschaften eine Rolle Testkategorien in diesem Bereich: Performance-Tests Stresstests Lasttests Speichererschöpfungstests Sicherheitstest Robustheitstest 1 WS 2015/2016 M. Werner 17 / 22 osg.informatik.tu-chemnitz.de Automatisierung WS 2015/2016 M. Werner ADLT helps in the 18 implementation / 22 of new software osg.informatik.tu-chemnitz.de by generating header files containing declarations of the elements in the specified component the constituent functions, variables, constants, and type definitions. Since ADL specifications are not embedded in the components to be tested or documented, ADLT can be used with either new software or existing, already-compiled components. What ADLT Is Not Beispiel: ADL While ADLT is a powerful unit-testing tool, it cannot do all tasks associated with testing. ADLT was specifically designed not to be a test harness or debugger. ADLT relies upon the Test Environment Toolkit (TET) test harness to provide test management, building, execution, and clean-up structure. Assertion Definition Language (ADL) Translation System Testen beinhaltet häufig wiederkehrende Vorgänge Nur kleinere Projekte sollten zu Fuß getestet werden Formal Specification of Software Component (ADL File) Formal Test Data Description (TDD File) Automatisierung des Testvorganges Verschiedene Teile des Testvorganges können (semi-)automatisiert werden: ADLT Generierung von Test(mustern) Instrumentierung des Codes Testdurchführung und -protokollierung Testauswertung Es existieren jede Menge Tools, die eine Automatisierung von einer oder mehrere Phasen des Testvorgangs unterstützen Liste auf Implementation of Functions Under Test Test Code Test Program Data Factory and Auxiliary Functions Programmer-Supplied File ADLT-Generated File Executable File WS 2015/2016 M. Werner 19 / 22 osg.informatik.tu-chemnitz.de Figure 1-1 High-level view of ADLT test generation. WS 2015/2016 M. Werner 20 / 22 osg.informatik.tu-chemnitz.de

6 Beispiel: Testdurchführung in Java Verschiedene Tools, z.b. JUnit, TestNG, JTiger Dabei ist JUnit am ältesten und daher auch vermutlich am bekanntesten und hat die meisten Erweiterungen/Plugins, z.b. Cactus, DJUnit, Infinitest Vorgehen: Asserts werden abgefangen und ausgewertet Nutzung von Java-Annotationen zur Definition und der Verwebung von Test-Routinen Automatische Testdurchführung Integration in Eclipse Test von Ausnahmebedingungen Beispiel: Testdurchführung in Java (Forts.) Zusicherung (Assertion): import java.util.*;... public void test average simple () { Vector nums = new Vector(); nums.add(new Integer(3)); asserttrue(mathops.average(nums) == 3.0); } IndexOutOfBoundsException.class) public void empty() { new ArrayList<Object>().get(0); } mehr in der Übung WS 2015/2016 M. Werner 21 / 22 osg.informatik.tu-chemnitz.de WS 2015/2016 M. Werner 22 / 22 osg.informatik.tu-chemnitz.de