Vorlesung Programmieren

Transkript

1 Vorlesung Programmieren 13 Testen und Assertions Prof. Dr. Ralf H. Reussner Version 1.1 LEHRSTUHL FÜR SOFTWARE-DESIGN UND QUALITÄT (SDQ) INSTITUT FÜR PROGRAMMSTRUKTUREN UND DATENORGANISATION (IPD), FAKULTÄT FÜR INFORMATIK sdq.ipd.kit.edu KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft

2 Wichtige Termine Programmieren Übungsschein: Anmeldungszeitraum zwischen und Programmieren Abschlussaufgaben: Anmeldungszeitraum zwischen und Anmeldung jeweils über das Campus Management Portal : 2

3 Literaturhinweis - Weiterlesen Dietmar Ratz, Jens Scheffler, Detlef Seese und Jan Wiesenberger Grundkurs Programmieren in Java, 7. Auflage, 2014 (mit Java 8), Hansa-Verlag Kapitel 10 Exceptions and Errors Abschnitt 10.3 Assertions 3

4 Murphy s Law Everything that can go wrong, will go wrong! 4

5 Softwarefehler ( Bugs ) Mark II Aiken Relay Calculator Grace Hopper 5

6 Berühmte Software-Fehler Therac-25 Bestrahlungsgerät Fehlerhafte Dosierung ( ) Toyota Camry Ungewollte Beschleunigung ( ) Hackerangriffe / Cyberwar Angriff aus China auf Google Server (2009) Blackout Nordamerika 55 Millionen Menschen für zwei Tage ohne Strom (2003) 6

7 Was lernen wir daraus? Umfassende Fehlerbehandlung erforderlich Jede Benutzereingabe sollte überprüft werden Jeder mögliche Fehlerfall behandelt Ausgiebiges Testen unerlässlich! 7

8 Software testers always go to heaven; they ve already had their fair share of hell. [Anonymous] Aber auch: Testing can only show the presence of bugs, not their absence. [E. Dijkstra] 8

9 Software-Fehler Wann können wir sagen, dass ein Programm fehlerhaft ist? Erster Versuch einer Definition: Die Software tut nicht das, was sie soll! Besser: Abweichung von Spezifikation, Anforderungen (requirements) Def. Anforderung: Eine Anforderung ist eine Aussage über eine zu erfüllende Eigenschaft oder zu erbringende Leistung eines Programms/Systems. Mögliche Gründe für fehlerhafte Software: Programm ist fehlerhaft (Exception geworfen, fehlerhafte Ausgabe,...)...) Anforderungen unvollständig, widersprüchlich, unmöglich zu implementieren Falsche Interpretation der Anforderungen Dokumentation falsch Verhalten des Programms nicht richtig beschrieben Testen hilft, Software-Fehler zu finden! 9

10 Testen Jedes Programm muss getestet werden! Typischerweise zweistufiges Vorgehen: 1. Auswahl der Testfälle Klassifizierung der möglichen Eingabedaten Standardsituationen und Randfälle betrachten 2. Auswahl der Testdaten Repräsentative Daten zu jedem Testfall Man muss versuchen, alle Situationen abzudecken, in denen das Programm potentiell schiefgehen kann 10

11 Beispiel: Klassifikation Dreiecke Der Benutzer gibt drei ganze Zahlen ein. Diese repräsentieren Seitenlängen eines Dreiecks. Das Programm soll das Dreieck klassifizieren als gleichseitig gleichschenklig weder-noch Was sind gute Testfälle? 11

12 Testfälle Gültiges weder-noch-dreieck Gültiges gleichseitiges Dreieck Gültiges gleichschenkliges Dreieck (plus Permutationen, z.b. 4,3,3; 3,4,3; 3,3,4) Genau eine Seite Länge Null Eine Seite negative Länge Summe zweier nichtnegativer Seiten ergibt dritte Seite Summe zweier Seiten ist kleiner als dritte Seite Alle Seiten Länge null... 12

13 Klassifikation Dreiecke: Spezifikation enum TriangleKind { Equilateral, Isosceles, Other, ; Invalid ; class Triangle { // Specification: Classify a triangle... as equilateral, isosceles, other, or invalid. static // classifytriangle TriangleKind classify(int returns a, int b, int c) { //... a) Equilateral: if If all sides (a, b, c) are equal in length and // b) Isosceles: if all two of sides a, b, are c are equal strictly in length positive. // c) b) Other: Isosceles: if If all two sides have (e.g., different a, b) are lengths equal in length (and > 0), static // TriangleKind and classify(int the triangle a, int is neither b, int c) Equilateral { nor Invalid. //... c) Other: If all sides have different lengths > 0 and the triangle // is not Invalid. // d) Invalid: If at least one side s length is <= 0, or if the largest // side s length is larger or equal to the sum of the // other sides. static TriangleKind classify(int a, int b, int c) {... Spezifikation ist Grundlage der Testfall-Erstellung 13

14 Klassifikation Dreiecke: Testfälle class TriangleTest { static void test_1() { // Test case: equilateral int a = 5, b = 5, c = 5; TriangleKind tk = Triangle.classify(a, b, c); assert tk == TriangleKind.Equilateral; static void test_2() { // Test case: isosceles int a = 3, b = 1, c = 3; TriangleKind tk = Triangle.classify(a, b, c); assert tk == TriangleKind.Isosceles;... static void test_27() { // Test case: largest side greater equals sum of other sides int a = 4, b = 4, c = 8; TriangleKind tk = Triangle.classify(a, b, c); assert tk == TriangleKind.Invalid; 14

15 Kriterien für gute Testfälle Prüfen genau eine (möglichst spezifische) Eigenschaft ab Sind möglichst kurz und prägnant Können isoliert ausgeführt werden (d.h. keine Abhängigkeiten zwischen Tests) Sind gut dokumentiert Stellen Bezug zur Spezifikation klar dar Nutzen existierende Testing-Frameworks (z.b. JUnit) Möglichst vorausschauend (bzgl. Änderungen am Programm) Folgen häufig dem Schema: 1. Initialisierung 2. Durchführung (z.b. Methodenaufruf) 3. Prüfung (z.b. mittels assert) 4. Finalisierung ( aufräumen ; nicht immer notwendig) 15

16 Was Testen ist... Dynamischer Vergleich von tatsächlichem und erwünschtem (= spezifiziertem) Verhalten Ziele: Nachweis, dass Funktionalität erfüllt ist Fehlerdetektion Unterschied psychologisch wesentlich! Testfall: Sollten Programmierer ihre eigenen Programme testen? Im allgemeinen: nein; aber manchmal aus organisatorischen oder Kostengründen erforderlich Ein Testfall besteht immer aus Eingabe und erwarteter Ausgabe (plus ggf. Ausführungsbedingungen). Für jeden Testfall sollte auch eine Begründung existieren, warum er ausgewählt wurde In Windows XP waren Testfälle die (einzige) Spezifikation! 2004: EU-Kommission verlangte, Schnittstellen offenzulegen 16

17 Failure vs. Fault Failure ( Versagen / Fehlfunktion ) System/Programm verhält sich nicht gemäß der Spezifikation/Anforderungen Manifestation zur Laufzeit Fault ( Fehler ) Inkorrekter Schritt in einem Programm Tatsächliche (oder vermutete) Ursache des Versagens Kann in einem Programm auch unentdeckt vorhanden sein Grob: Fault = Ursache Failure = Wirkung 17

18 Failure vs. Fault vs. Error Error Unterschied zwischen tatsächlichem und erwünschtem internen Programmzustand Kann, muss aber nicht zu einer Failure führen Kann zur Laufzeit repariert werden (z.b. durch Redundanz) Kann mit Assertions überprüft werden 18

19 Beispiel: Failure vs. Fault // Specification: Search for element x in array a, starting // at index p. The method returns the smallest i >= p, for which // a[i] == x. If no such i exists, -1 is returned. static static int int search(int[] search(int[] a, a, int int p, p, int int x) x) { for for (int (int i = 0; 0; i <= <= a.length; a.length; i++) i++) { if if (a[i] (a[i] == == x) x) { return return p; p; return return -1; -1; Fault 1: Should read: i = p Fault 2: Should read: return i Fault 3: Should read: i < a.length static void test_1() { // Test case: element to search for occurs multiple times int[] a = { 2, 5, 4, 3, 2, 3 ; int p = 4, x = 3; int r = search(a, p, x); assert r == 5; Failure! (r = 4) 19

20 Was Testen nicht ist Fehlerlokalisierung (fault localization) Fehler beheben Alternative Methoden Statische Codeanalyse, ob manuell oder automatisiert Mathematische Beweise Reviews, Inspections, Walkthroughs 20

21 Warum Testen so schwierig ist Was macht einen Testfall zu einem guten Testfall? Fähigkeit, Fehler zu finden (Fehler nur mit Spezifikation!) Dann aber kein guter Testfall für ein fehlerfreies Programm Fähigkeit, wahrscheinliche Fehler mit angemessenem Aufwand zu finden Kosten, Tests zu schreiben / auszuführen / auszuwerten Kosten verbleibender Fehler, je nach Schwere Testsuiten sollen aus Managementgründen so klein wie möglich (so groß wie nötig) sein und so kurze Testfälle wie möglich (so lang wie nötig) enthalten. Leichte Fault-Lokalisierung Erwartete Ausgabe ist essentiell. Also benötigen wir eine Spezifikation Möglicherweise nur keine Exception : robustness testing. Dann aber nur sehr oberflächlicher Test der Funktionalität 21

22 Testselektion Approximation guter Testfälle Zentrales Problem: Lösung: Mögliche Eingabedaten in Blöcke gruppieren, so dass (möglichst) jedes Element eines Blocks denselben Fehler provoziert Auf der Basis von Anforderungen Auf der Basis von Wissen um typische Fehler Zufällig (gleichverteilt oder gemäß Nutzerprofilen) Strukturbasiert ( jede Zeile einmal ausführen, jede Bedingung einmal zu wahr und einmal zu falsch auswerten etc.) 22

23 Wann sind wir fertig? Wenn die Zeit um ist! Nutzlos. Einfach gar nichts tun. In der Praxis Kriterium #1. Wenn keine weiteren Fehler mit existierenden Tests gefunden werden Nutzlos. Wähle irrelevante Tests Wenn ein strukturelles Kriterium erfüllt ist Etwa: Jede Zeile einmal ausgeführt Nützlich, wenn es einen Zusammenhang zwischen diesen strukturellen Kriterien und Fehlerdetektion gibt. (Dafür gibt es aber keine empirische Evidenz und gute Gründe, dass es dafür keine Evidenz gibt.) Wenn eine vorher spezifizierte Anzahl Fehler gefunden wurde Großartig. Erfordert aber gute Abschätzungen 23

24 Teststrategien Datenbasiert, auf Basis der Eingabeparameter Gruppierung von Daten, die zu vergleichbarem Verhalten führen (wie im Dreieck-Beispiel) Grenzwerte Beispiel natürliche Zahlen: -1, 0, 1, Integer.MAX_VALUE, Beispiel Liste: leere Liste, null-referenz, einelementige Liste Beispiel Array: null-referenz, Länge 0, Länge 1 Programmbasiert (z.b. Coverage Criteria) Jede Zeile (mind.) einmal ausgeführt Jede Bedingung (mind.) einmal zu wahr und zu falsch ausgewertet 24

25 f u cn rd ths, u cn gt a gd jb n sftwr tstng. 25

26 Assertions class TriangleTest { static void test_1() { // Test case: equilateral int a = 5, b = 5, c = 5; TriangleKind tk = Triangle.classify(a, b, c); assert tk == TriangleKind.Equilateral; Assertions erlauben es, angenommene erforderliche Bedingungen zur Laufzeit zu prüfen Syntax: assert Bedingung; assert Bedingung : Detaillierte Fehlermeldung ; 26 26

27 Zusicherungen Beispiel: Berechne das Skalarprodukt zweier Vektoren u und v double dotproduct(double[] u, double[] v) { assert u.length == v.length; double s = 0; for (int i = 0; i < u.length; i++) { // Vorbedingung // hier gilt immer: s = // Schleifeninvariante s += u[i] * v[i]; // hier gilt immer: s = // Nachbedingung return s; Zusicherungen: Vorbedingung: muss vor Aufruf der Methode gelten Nachbedingung: muss nach Aufruf der Methode gelten Schleifeninvariante: muss bei jeder Schleifeniteration gelten 27

28 Assertions Zusicherungen (assertions) sind ein weiteres wichtiges Hilfsmittel für die Entwicklung von Software und zur Vermeidung von Fehlern Sie werden verwendet, um Restriktionen für Parameter und globale Variablen von Methoden anzugeben Vorbedingungen (preconditions) den Effekt von Methoden formal zu beschreiben Nachbedingungen (postconditions) an zentralen Programmpunkten wichtige Eigenschaften (z.b. mögliche Werte von Variablen) explizit festzuhalten Mit Hilfe von Zusicherungen ist es möglich, Korrektheitsaussagen bzgl. eines gegebenen Programmes mathematisch zu beweisen 28

29 Zusicherungen in Java Java bietet die Möglichkeit, Zusicherungen mittels assert direkt in den Programmtext zu schreiben Vorteil: Kann zur Laufzeit von der JVM nachgeprüft werden Nachteil: Es kann nur Java-Syntax verwendet werden, um die Bedingung auszudrücken Häufig ist es einfacher, Zusicherungen in Kommentare zu schreiben Vorteil: Volle sprachliche Freiheit Nachteil: Kann nicht (oder nur eingeschränkt) automatisiert überprüft werden In jedem Fall: Assertions sind gute Dokumentation der Verantwortlichkeiten zwischen Methodennutzer und Methodenimplementierer. ( Design by contract) Assertions werden standardmäßig nicht ausgewertet und überprüft! Aktivieren beim Programmstart mit der enable-assertions -Option: java -ea MyClass 29

30 Pre- und Postconditions, Invarianten Eine Zusicherung gibt eine Eigenschaft an, die bei der Ausführung des Programms an der entsprechenden Stelle erfüllt sein muss Eine Precondition muss vor der Abarbeitung des entsprechenden Methodenrumpfs erfüllt sein Eine Postcondition muss erfüllt sein, nachdem die Methode abgearbeitet wurde Eine Klassenininvariante beschreibt den gültigen Zustand eines Objekts. Sie muss sowohl vor als auch nach jedem Methodenaufruf (Ausnahme: private Hilfsmethoden) des zugehörigen Objekts gültig sein Beispiel: int length; /* ASSERT length >= 0 */ Eine Schleifen-Invariante ist eine Zusicherung, die am Anfang und Ende eines jeden Durchlaufs der zugehörigen Schleife erfüllt sein muss 30

31 Beispiel Invarianten public class Time { int hour; int minute; // invariant: 0 <= hour && hour < 24 // invariant: 0 <= minute && minute < 60 public Time(int h, int m) { assert 0 <= h && h < 24; assert 0 <= m && m < 60; hour = h; minute = m; private void normalizetime() { if (minute >= 60) { minute -= 60; hour += 1; if (hour >= 24) { hour -= 24;... public void addtime(time t) { minute += t.minute; hour += t.hour; assert normalizetime(); 0 <= h && h < 24; assert 0 <= m h && m h < 60; 24; assert 0 <= m && m < 60;... Postcondition / Klasseninvariante kann verletzt sein! 31 31

32 assert oder if-abfrage? assert if-abfrage + Exceptions Annahme des Programmierers zur Korrektheit des Programms Auch zur Dokumentation Für nicht zur Laufzeit behandelbare Fehler Abschaltbar Beispiel: void setbalance(double b) { assert b >= 0; this.balance = b; Prüfung von Eingabedaten des Benutzers Für Sonderfälle Für von aufrufenden Funktionen behandelbare Fehler Nicht abschaltbar Beispiel: void setbalance(double b) { if (b < 0) { throw new llegalargumentexception(); this.balance = b; 32

33 Statische Analyse Wenn Auswahl der Testfälle so schwierig ist, warum nicht alle Eingaben testen? Viel zu viele! Management der Testfälle nicht mehr praktikabel Laufzeit der Testfälle zu groß Oder geht es doch? Idee: Transformiere Programm in logische Formel und versuche Einhaltung der Spezifikation zu beweisen Verschiedene Logiken: Dynamische Logik, Bit-Vektor-Logik,... Spezifikation: muss in formaler Logik vorliegen Beweisen: manuell, Rechner-unterstützt, vollautomatisch Statische Programm-Analyse 33