3: Systematisches Testen

Transkript

1 Stefan Lucks 3: Systematisches Testen 70 E für Sichere Vert. Systeme (2007) 3: Systematisches Testen Testen ist ein Prozess, ein Programm mit der Absicht auszuführen, Fehler zu finden. Man muss destruktiv denken! Testen ist ungeeignet, die Fehlerfreiheit eines Programms nachzuweisen! Testen ist keine Form des Debuggens! Die systematische Auswahl von Testfällen ist eine schwierige kreative Arbeit. Testergebnisse sollen reproduzierbar sein. Das Durchführen von Tests kann man oft automatisieren. Und man sollte es automatisieren, wenn möglich.

2 Stefan Lucks 3: Systematisches Testen 71 E für Sichere Vert. Systeme (2007) Kein Testen, aber auch nützlich: Untersuchung des Source-Codes Code-Inspectionen (strenge Regeln, Entscheidung über die Freigabe des Source-Codes) Eine Anomalie wie if ((options == ( WCLONE WALL)) && (current->uid = 0)) retval = -EINVAL; hat in dem Source-Code für ein sicheres System nichts zu suchen! Walk-Throughs (weniger strikte Regeln) Programming in Pairs Formale Verifikation ( in ein paar Wochen)

3 Stefan Lucks 3: Systematisches Testen 72 E für Sichere Vert. Systeme (2007) Testpsychologie Man muss die Fehler finden wollen! Idealerweise Trennung zwischen Programmautoren und Testern. Auch hilfreich: Test-Driven Developement (zuerst die Black-Box-Tests, danach die Implementation). Es ist gut, wenn ein Test einen Fehler findet. Erfolg = Fehler gefunden!

4 Stefan Lucks 3: Systematisches Testen 73 E für Sichere Vert. Systeme (2007) Regressionstest Batterie von Blackboxtests und ggf. Tests, um Fehler zu erkennen, die schon einmal aufgetreten sind Änderungen werden nur nach einem Bestehen des Regressionstests freigegeben. Wenn ein neuer Fehler gefunden wird: Zuerst neuer Testfall für den Regressionstest. Dann Behebung des Fehlers. Denn: Fehler neigen dazu, wiederholt zu werden! Vermutlich die wichtigste Art von Tests.

5 Stefan Lucks 3: Systematisches Testen 74 E für Sichere Vert. Systeme (2007) Testfall Beschreibung einer Eingabe(-Bedingung) mit einem erwarteten Ergebnis Zweck Vorbedingung Erwartetes Ergebnis Aufräumarbeiten Bei der Durchführung des Tests: Vergleich des tatsächlichem mit dem Erwarteten Ergebnis, Protokollierung. Ggf. Verknüpfung mehrerer Testfälle zu einer Kette.

6 Stefan Lucks 3: Systematisches Testen 75 E für Sichere Vert. Systeme (2007) Beispiel: Wie sollte man diese Funktion testen? function Fibonacci(X: Positive) return Positive is Kind, Vater, Opa: Positive; begin if X <= 2 then return 1; else Vater := 1 Opa := 1; for Generation in 3.. X loop Kind := Vater + Opa; Opa := Vater; Vater := Kind; end loop; return Kind; end if; end Fibonacci;

7 Stefan Lucks 3: Systematisches Testen 76 E für Sichere Vert. Systeme (2007) 3.1: White-Box Tests 3.1: White-Box Tests Tests, die mit Hilfe der Kenntnis eines (Unter-)Programms definiert werden, mit Hilfe des Kokntrollflussgraphen: Knoten: Ausführbare Anweisung (Zuweisung, Prozeduraufruf) zusätzlich je ein Start- und Zielknoten ggf. Zusammenfassung mehrerer zusammenhängender Anweisungen zu einem Knoten Kante: möglicher Programmfluss zwischen zwei Anweisungen Pfad: Kombination von Kanten, die vom Start- zum Zielknoten laufen

8 Stefan Lucks 3: Systematisches Testen 77 E für Sichere Vert. Systeme (2007) 3.1: White-Box Tests Kriterien für White-Box Tests Anweisungsüberdeckung: Jeder Knoten des Kontrollflussgraphen wird mindestens einmal ausgeführt. Zweigabdeckung: Jede Kante des Kontrollflussgraphen wird mindestens einmal ausgeführt. Pfadabdeckung: Jeder Pfad im Kontrollflussgraphen wird mindestens einmal ausgeführt (theoretisches Kriterium, da meistens unendlich viele Pfade).

9 Stefan Lucks 3: Systematisches Testen 78 E für Sichere Vert. Systeme (2007) 3.1: White-Box Tests Mutationstesten Etwas unsystematische, aber wirkungsvolle Methode, die Vollständigkeit der Testbatterie zu testen. Grundlage: Kleine Änderungen ( Mutationen ) am Quelltext. Jeder Mutant enthält nur eine Abweichung, z.b. Ersetzen eines durch ein <, eines and durch ein or,... Vorzeichenfehler, Auskommentieren einzelner Statements, Vertauschen der Reihenfolge einzelner Statements,... Kriterium: Wenn irgend eine Mutation den Test besteht, hat man vermutlich nicht genug Testfälle, oder die falschen Testfälle.

10 Stefan Lucks 3: Systematisches Testen 79 E für Sichere Vert. Systeme (2007) 3.2: Black-Box Tests 3.2: Black-Box Tests Tests, die anhand der Spezifikation eines (Unter-)Programms definiert, werden, ohne das Programm selbst zu kennen. Techniken zur Erzeugung von Testfällen: Äquivalenzklassenbildung (sowohl für gültige, als auch für ungültige Eingaben) Grenzwertanalyse Beispiel: Wie testet man die ein (Unter-)Programm, das ein Datum in der Form (Tag, Monat, Jahr) einlesen und bei ungültigen Daten eine Ausnahme auslösen soll:

11 Stefan Lucks 3: Systematisches Testen 80 E für Sichere Vert. Systeme (2007) 3.2: Black-Box Tests Beispiel Kaffeeautomat package Kaffee_Automat is type Zustand is private; type Benutzer_Handlung is (Cent10, Cent20, Knopf); type Aktionen is (Muenze_Angenommen, Muenze_Abgelehnt, Alle_Muenzen_Zurueck, Gib_Kaffee_Aus);

12 Stefan Lucks 3: Systematisches Testen 81 E für Sichere Vert. Systeme (2007) 3.2: Black-Box Tests Kaffeeautomat (2) procedure Initialisiere (X: in out Zustand); procedure Agiere(X: in out Zustand; Eingabe: Benutzer_Handlung; Aktion: out Aktionen); private type Zustand is range ; end Kaffee_Automat;

13 Stefan Lucks 3: Systematisches Testen 82 E für Sichere Vert. Systeme (2007) 3.2: Black-Box Tests Wie testen wir den Kaffeeautomaten? Spezifikationen, wie für derartige Automaten üblich. Insbesondere: Eingabe 10-Cent und 20-Cent Münzen Kaffee für 50 Cent, kein Überbezahlen Geldrückgabeknopf Gibt es Äquivalenzklassen, die wir hier nutzen können?

14 Stefan Lucks 3: Systematisches Testen 83 E für Sichere Vert. Systeme (2007) 3.3: Automatisches Testen 3.3: Automatisches Testen Manuelles Testen ist arbeitsaufwändig, langweilig und... fehlerträchtig. Und wer will nach jeder (kleinen) Änderung den kompletten Regressionstrest durchführen... Um die Reproduzierbarkeit der Test zu gewährleisten, muss bei jeder Wiederholung des Tests (z.b. Regressionstest), der gleiche Input eingegeben werden.

15 Stefan Lucks 3: Systematisches Testen 84 E für Sichere Vert. Systeme (2007) 3.3: Automatisches Testen Der Test-Driver Generator testgen Ein einfach zu handhabendes Werkzeug, um Test-Driver zu erzeugen ist der Test-Driver Generator testgen (eine Weiterentwicklung von tg. Er dient als Beispiel für ein Werkzeug beim Testen. Für anspruchsvollere Aufgaben würde man z.b. AUnit verwenden.

16 Stefan Lucks 3: Systematisches Testen 85 E für Sichere Vert. Systeme (2007) 3.3: Automatisches Testen Arbeitsweise von testgen Eingabe von testgen ist ein Test-Script (z.b. beispiel.ts), Ausgabe der Quelltest eines Ada-Programms (z.b. beispiel.adb). Typische Test-Scripts bestehen aus 1. Einer globalen Kontext-Vereinbarung, bestehend aus with und use -Klauseln für Ada.Text_IO und dem getesteten Modul, und 2. einzelnen Testfällen.

17 Stefan Lucks 3: Systematisches Testen 86 E für Sichere Vert. Systeme (2007) 3.3: Automatisches Testen Die Syntax eines Test-Scripts Context with Ada.Text_IO; use Ada.Text_IO; with Datum_Manager; use Datum_Manager; ***** 30. Juni 2003 (kein Schaltjahr) Define Dat: Datum; Test Dat := Setze(30, Juni, 2003); Pass (Tag(Dat)=30) and (Monat(Dat)=Juni) and (Jahr(Dat)=2003) ***** 31. Juni 2003 (kein Schaltjahr) Define Dat: Datum; Test Dat := Setze(31, Juni, 2003); Pass exception Falsches_Datum

18 Stefan Lucks 3: Systematisches Testen 87 E für Sichere Vert. Systeme (2007) 3.3: Automatisches Testen Die Syntax eines Testfalls Testfall-Name, Define-, Test- und Pass-Vereinbarungen: ***** Mai, alle Tage, 2003 (kein Schaltjahr) Define Fehler: Natural := 0; Dat: Datum; Test for T in Tag_Typ loop Dat := Setze(T, Mai, 2003); if (Tag(Dat) /= T) or (Monat(Dat) /= Mai) or (Jahr(Dat) /= 2003) then Fehler := Fehler + 1; end if; end loop; Pass Fehler = 0

19 Stefan Lucks 3: Systematisches Testen 88 E für Sichere Vert. Systeme (2007) 3.3: Automatisches Testen Verhalten eines Test-Scripts (1) pass. (2) pass. (3) pass. (4) Februar, 1..28, 2003 (kein Schaltjahr) Script name: dat_man.ts ; Line:34... FAIL. (path => was taken, but predicate is FALSE) (5) pass. (6) pass. (7) pass. Script name dat_man.ts ; total test result: FAIL. Hurra! Der Test war erfolgreich Fehler gefunden!