Inhalt. 1. Sprachspezifische Fehlerrisiken C++ Java. Smalltalk. 2. Coverage - Modelle. Statement Coverage. Branch Coverage

Transkript

1 Inhalt 1. Sprachspezifische Fehlerrisiken C++ Java Smalltalk 2. Coverage - Modelle Statement Coverage Branch Coverage Inkrementelles Testen von Klassen Testen Polymorpher Bindungen Optimistischer Ausblick Grundsätze zum OO-Testing

2 C++ Viele Fehler sind zurückzuführen auf unsichere Merkmale der Sprache selbst Probleme mit Pointern Unintialisierte Werte unzulängliche Typkonvertierungen Speicherprobleme Fehlendes Verständnis für einige subtile Semantiken Beipiel: int (*v1[20])(register long int) void (*v3)(int)[20]

3 Java Ähnliche Syntax zwischen C++ und Java kann verwirren Beispielsweise der + Operator in Java (Addition von Skalaren oder Konkatenation von Strings) Applets können anfällig sein für Fehler, die durch Unterschiede in jeder JVM entstehen Fehlverhalten von Applets kann auf nichtstandardisierten oder inkorrekten Code zurückzuführen sein Probleme dieser Art resultieren auch aus der Java Language Specification Keine Spezifikation des Thread Scheduling Maximale Länge von Dateinamen nicht definiert

4 Coverage - Modelle und OO-Testing Als Coverage bezeichnet man den Überdeckungsgrad eines zu testenden Programms. Coverage-Ziele sind abhängig vom Fehlermodell Überdeckungsarten: Statement Coverage (Anweisungsüberdeckung) Branch Coverage (Zweigüberdeckung) Data Flow Coverage Von besonderer Bedeutung in OO-Tests: Inkrementelles Testen von Klassen Testen polymorpher Bindungen Grundsatz: Erprobung aller Elemente eines System

5 Statement Coverage Alle Anweisungen des Quellcodes (beispielsweise nummerierte Zeilen) werden mindestens einmal durchlaufen Ziel von Testumgebungen ist es, volle Anweisungsüberdeckung zu liefern Dient auch zur Feststellung, ob das Programm unerreichbaren Code enthält public int demo(int value) { int result = 0; [1] if (value < 0) { [2]... [3]... } else {... [i]... } return result; [n] }

6 Branch Coverage Erzeugen von Testfällen, welche jeden Entscheidungspfad erreichen Sicherstellung, daß Jeder Pfad in jeder Methode einer Klasse mindestens einmal ausgeführt wurde Alle binären Entscheidung mindestens einmal wahr bzw. falsch geliefert haben Jede Exception mindestens einmal geworfen wurde Alle möglichen Interrupts wenigstens einmal provoziert wurden

7 Optimistischer Ausblick Reduzierung der Notwendigkeit abgeleitete Klassen zu testen (vorausgesetzt die Basisklassen sind gründlich getestet) Testen von Basisklassen funktioniert ähnlich wie Unit-Testing in prozeduralen Sprachen Wiederverwendung von Testumgebungen Spekulation: Die Wiederverwendung von gründlich getesteten Klassen reduziert das Unit-Testing um 40 bis 70 Prozent.

8 Inkrementelles Testen Grundlage: Gründlich getestete Basisklassen existierende Testumgebung Anforderungen an Tests für abgeleitete Klassen werden bestimmt durch die Testgeschichte der Elternklasse Nur neue Merkmale werden getestet (inklusive ihrer Interaktionen) Vererbte Merkmale werden nicht zwingend neu getestet Ziel: Reduzierung der Tests, die für abgeleitete Klassen notwendig wären

9 Polymorphe Bindungen Stellen ein großes Problem der Überdeckung dar Alle Redefinitionen der aufgerufenen Methode müssen erprobt werden Jede Klasse eines SUT muß seperat gertestet werden Eine Klasse gilt als sicher, wenn: 1. Alle Pfade überdeckt sind 2. Alle Methodenaufrufe innerhalb einer Klassenhierarchie sowie zwischen Klassen getestet wurden 3. Alle Überladungen einer polymorphen Serverklasse getestet wurden

10 Coverage Checklist 1. Jede Operation wird ausgeführt 2. Jedes Attribut wird aktualisiert 3. Jeder Zustand wird erreicht 4. Jede Operation wird in jedem Zustand ausgeführt (korrekt, wenn bereitgestellt; ansonsten untersagt) 5. Jede Exception wird entsprechenderweise geworfen bzw. behandelt 6. Jeder Zustandsübergang wurde mindestens einmal durchlaufen 7. Entsprechende Belastungs-, Geschwindigkeits- und Verdachtstests werden durchgeführt

11 Einige Grundsätze zum OO-Testing Reduzierung des Testaufwandes in objektorientierten Systemen ist illusorisch Vererbung, Polymorphie, spätes Binden sowie Kapselung stellen neue Probleme für das Design der Testfälle dar Unter der Maßgabe, daß OO-Entwicklung inkrementell ist, sollte auch das Testdesign und dessen Ausführung inkrementell sein Das Testdesign sollte Fehlermodelle berücksichtigen, die einmalig für OO-Software sind Fehlende Testdesigns reduzieren die Effektivität von Tests Das Testen von Klassen sollte eng mit deren Programmierung verbunden werden Das Testen von Methoden muß im Kontext ihrer Klasse geschehen

12 Literaturhinweise C++: [Cargill 93], [Reed 93], [Sakkinen], [Shopiro 93] Java: [Green 98], [Hayes 97] Smalltalk: [Johnson 97], [Silverstein 99], [Skublics 96] Code Coverage: [Binder 94-97], [Harrold 92], [Perry 90] Analyse von Programmierparadigmen: [Watt 90] Object-Oriented Metrics: An Annotated Bibliography (Empirical SoftwareEngineering Research Group, DOC, Bournemouth University, UK)