Techniken im Software-Test

Transkript

1 Techniken im Software-Test München, 4. Juli 2000 Heiko Lötzbeyer Institut für Informatik Lehrstuhl für Technische Universität München

2 Inhalt Ziele des Software Tests Überblick Teststufen Unit-Test Integrationstest Systemtest Testverfahren manuelle Testverfahren Whitebox Blackbox Testfallermittlung Spezifikationsbasierte Testfallermittlung Schluß 4. Juli 2000 H. Lötzbeyer 2

3 Ziele Was ist Testen? G.J.Myers, 79: Testen ist der Prozeß, ein Programm mit der Absicht auszuführen, Fehler zu finden. Hetzel 83: Messung der Softwarequalität DieÜberprüfung, daß ein System die spezifizierten Anforderungen erfüllt. Ziele: Fehler finden auch: Fehler vermeiden (B. Beizer) nicht: Korrektheitsnachweis 4. Juli 2000 H. Lötzbeyer 3

4 Überblick Entstehung und Entdeckung von Fehlern (aus Balzert, IEEE Software, Jan. 1985, S.83) Eingebrachte Fehler Gefundene Fehler 60% 50% 40% 30% 20% 10% 0% Anforderungs- und Entwurfsphase Technische Entwurfsphase Konstruktions- und Systemphase Abnahmetest und Betriebsphase 4. Juli 2000 H. Lötzbeyer 4

5 Fehlerbeseitigung Relative Kosten zur Fehlerbeseitigung (H. Balzert, 1998; Boehm, 1976) Definition Entwurf Implementierung Entwicklungstest Abnahmetest Betrieb 4. Juli 2000 H. Lötzbeyer 5

6 Fehlerverteilung Fehlerverteilung (Dick Bender, 1993) Code 7% Other 10% Design 27% Requirements 56% 4. Juli 2000 H. Lötzbeyer 6

7 Fehlerverteilung Fehlerverteilung: (Beispiel von Hewlett-Packard, Grady 1997) Data handling 6% Other code 11% Computation 18% Documentation 19% Requirements 5% Hardware 4% Process/Interprocess 5% Logic 32% 4. Juli 2000 H. Lötzbeyer 7

8 Testdurchführung Testfälle Testfallermittlung Regressionstest Testtreiber Testobjekt Regressionstest Stubs Ablaufprotokolle Neues Testobjekt 4. Juli 2000 H. Lötzbeyer 8

9 Teststufen Unit-, Komponenten-, Modul- oder Klassentest Test einer einzelnen Einheit Integrationstest Überprüfung des fehlerfreien Zusammenwirkens von Systemkomponenten Systemtest abschließender Test des Gesamtsystems Funktion, Leistung (Massen-, Zeit-, Streßtest), Benutzbarkeit, Sicherheit, Interoperabilität Abnahmetest Test unter Mitwirkung des Auftraggebers Alpha-Test, Beta-Test 4. Juli 2000 H. Lötzbeyer 9

10 Integrationstest Integrationsstrategien: nicht-inkrementell: bigbang geschäftsprozeßorientiert inkrementell: top-down-integration bottom-up-integration funktionsorientiert nach Verfügbarkeit 4. Juli 2000 H. Lötzbeyer 10

11 Testverfahren Manuelle Prüfverfahren: Programminspektion, Review, Walkthrough effektiv: 30-70% (Myers, Balzert) Zeit- und Personalaufwendig Whitebox-Test (struktureller Test) Ausgangspunkt: Struktur des Prüflings Messung der Testüberdeckung mittels Metrik Blackbox-Test (funktionaler Test) Ausgangspunkt: Spezifikation des Prüflings Sicherstellung der gewünschten Funktionalität 4. Juli 2000 H. Lötzbeyer 11

12 Whitebox-Test Instrumentierung des Codes (Zähler einfügen) Tests durchführen Messung der verarbeiteten Anweisungen ausgewerteten Bedingungen Schleifendurchläufe Auswertung der erreichten Überdeckung anhand von Metriken kontrollflußorientiert datenflußorientiert 4. Juli 2000 H. Lötzbeyer 12

13 Kontrollflußorientiert 1 Function count(int x) { int z; if x < 0 then z = -x; else z = x; while z > 0 { z--; } } Programm YES X < 0 z = -x z = x 2 z > 0 NO 3 YES Flußdiagramm NO Z-- 4. Juli 2000 H. Lötzbeyer 13

14 Metriken: Anweisungsüberdeckung Kontrollflußorientiert jede Anweisung mind. 1 mal durchlaufen hier: 3 Anweisungen können mit 2 Testdurchläufen überdeckt werden Zweigüberdeckung jeder Zweig (jede Bedingung: true, false) hier: 2 Bedingungen mit jeweils 2 Möglichkeiten können mit 2 Testdurchläufen überdeckt werden Pfadüberdeckung jeder Pfad muß durchlaufen werden hier: unendlich viele Pfade Bedingungsüberdeckung, MC/DC 4. Juli 2000 H. Lötzbeyer 14 FT F T,F

15 Kontrollflußorientiert Es gilt: Anweisungsüberdeckung Zweigüberdeckung Modified Condition/Decision Coverage Bedingungsüberdeckung Pfadüberdeckung Probleme: Infeasible Paths (nicht erreichbare Pfade) z.b. if A do x; [...] if A doy; aus Redundanzen (z.b. Range-Checking-Code vom Compiler) bei Exceptions geeignete Testdaten zu finden 4. Juli 2000 H. Lötzbeyer 15

16 Datenflußorientiert Betrachtet werden Definition, lesende Zugriffe, schreibende Zugriffe von Variablen Defs/Uses-Verfahren: def: Wertzuweisung, auch Definitionen, Initialisierung c-use: berechnende Benutzung (computational use) p-use: prädikative Benutzung (predicate use) 4. Juli 2000 H. Lötzbeyer 16

17 Datenflußgraph Kontrollflußgraph mit Datenflußdarstellung: def x Function count(int x) { int z; if x < 0 then z = -x; else z = x; while z > 0 { z--; } } c-use x def z p-use z p-use x p-use z def z p-use x c-use z def z c-use x def z 4. Juli 2000 H. Lötzbeyer 17

18 Datenflußmetriken Metriken: (Statistiken aus Girgis, Woodware `86) all defs: (24%, keine Kontrollflußfehler) jede Definition muß in einer Berechnung oder Bedingung benutzt werden all p-uses: (34%, identifiziert sicher Kontrollflußfehler) Jede Kombination aus Variablendefinition und deren prädikative Nutzung muß getestet werden Beinhaltet Zweigüberdeckung all c-uses: (48%, identifiziert Berechnungsfehler) Jede Kombination aus Variablendefinition und deren berechnende Benutzung muß getestet werden all uses: (insgesamt ca. 70% der Programmierfehler) c-uses und p-uses zusammen 4. Juli 2000 H. Lötzbeyer 18

19 Testfallermittlung Whitebox-Test: Abstraktion Modell Überdeckung: Anweisungsüberdeckung, MC/DC Code Automatische Verfahren: Model-Checker, KI Konkretisierung Test Testfälle und Testdaten 4. Juli 2000 H. Lötzbeyer 19

20 Blackbox-Test Blackbox-Test: Ermittlung der Testfälle ausschließlich aus der Spezifikation Ziel ist eine möglichst umfassende und redundanzarme Prüfung der Funktionalität Techniken: Äquivalenzklassenbildung Grenzwertanalyse Testsequenzermittlung aus Use-Cases Beispielabläufen Zustandsdiagrammen 4. Juli 2000 H. Lötzbeyer 20

21 Äquivalenzklassen Äquivalenzklassenbildung: Definitions- und Wertebereich in Äquivalenzklassen zerlegen gültige Äquivalenzklassen => Funkionstests ungültige Äquivalenzklassen => Stabilitätstests Bsp: Monat : [1..12] zerlegen in eine gültige Äquivalenzklasse : 1 <= Monat <= 12 2 ungültige Äquivalenzklassen: Monat < 1, Monat > 12 Testfallauswahl: Auswahl eines Repräsentanten aus jeder Äquivalenzklasse max. 1 ungültige Äquivalenzklasse Grenzwertanalyse: Werte an Rändern der Äquivalenzklassen spezielle Werte: z.b. 0 bei int, Sonderzeichen usw. 4. Juli 2000 H. Lötzbeyer 21

22 CTE Classifaction Tree Editor: Klassifikationsbaum Kombination von Äquivalenzklassen Kombinationstabelle 4. Juli 2000 H. Lötzbeyer 22

23 Zustandsautomaten Ableitung von Testfällen aus Zustandsautomaten: über Graphen: Transitionsüberdeckung (Transitionstour) Zustandsüberdeckung Pfadüberdeckung durch Simulation manuell mit Aufzeichnung symbolische Ausführung logikbasiert Transformation in Aussagenlogik/Prädikatenlogik, deklarative Beschreibung der Testfälle 4. Juli 2000 H. Lötzbeyer 23

24 Testfallermittlung Blackbox-Test: Spezifikation Testziel Testobjekt Automatische Verfahren: Model-Checker, KI Test Testfälle und Testdaten 4. Juli 2000 H. Lötzbeyer 24

25 Mealy-Automaten Methoden: Transitionstour, W-Methode, UIO-Methode Vorteile: vollautomatisch auch Korrektheitsbeweis Nachteile: 1/0 0/ /1 0/1 nur endliche Systeme Korrektheitsbeweise erfordern starke Annahmen über Testobjekt 4. Juli 2000 H. Lötzbeyer 25

26 Transitionstour Findet den kürzesten Pfad durch den Automaten, der alle Transitionen überdeckt Vorteile: vollautomatisch Nachteile: Automat muß bestimmte Eigenschaften haben: stark zusammenhängend errechnete Transitionssequenz muß wirklich durchführbar sein 4. Juli 2000 H. Lötzbeyer 26

27 Model-Checking Methode: Verwendung von Gegenbeispielen vom Model-Checker Ermittlung der Systemläufe durch die Lösung aussagenlogischer Formeln Vorteile: vollautomatisch Einschränkungen nur zustandsendliche Systeme sonst Abstraktion notwendig 4. Juli 2000 H. Lötzbeyer 27

28 Aussagenlogik Testziel AF-Spezifikation SATO (Aussagenlogik) Testfall (EET) Übersetzung Rückübersetzung 4. Juli 2000 H. Lötzbeyer 28

29 CLP Methode: Codierung in regelbasierte Systeme mit Constraint-Mechanismen (CLP = Constraint Logic Programming) symbolische Simulation Vorteile: vollautomatisch auch unendliche Systeme Einschränkungen Datentypen / Arithmetik Schwierigkeiten mit nichtlinearen Prädikaten 4. Juli 2000 H. Lötzbeyer 29

30 Constraintlogik Testziel AF-Spezifikation Prolog/CLP (Regeln, Constraintlogik) Testfall (EET) Übersetzung Rückübersetzung 4. Juli 2000 H. Lötzbeyer 30

31 Schluß Weitgehend gelöst: Metriken für Whitebox-Tests Problematisch: Testziele definieren Aktuell: automatische Testfallermittlung aus Use-Cases, graphischen Beschreibungstechniken Generierung von Testtreibern, Stubs 4. Juli 2000 H. Lötzbeyer 31

32 ENDE Next Events: Steinheil Alex B. Schmidt: Anwendungen der Relationenalgebra Dienstag , Uhr, Raum1546