Software - Testung ETIS SS05

Gliederung Motivation Testen (Guidelines + Prinzipien) Testarten Was ist „gute“ Software? Vorurteile gegenüber Testen Testen (Guidelines + Prinzipien) Testarten Unit Tests Automatisierte Tests Anforderungen an Testframeworks Zusammenfassung Unit Tests ETIS SS05 Nadine Fröhlich

Was ist „gute“ Software? Praktisch jede Software hat Fehler, „gute“ Software ist: fehlerarm und so strukturiert, dass Fehler leicht korrigierbar sind Wie erreichbar? Konventionen/Regeln für Quelltexterstellung: z.B. Namens-, Struktur-, Identitätskonventionen Kommentierung einfacher Quelltext Anwendung von Pattern geeignete Testung als Voraussetzung für Fehlerkorrektur zur Kontrolle nach Refactoring Unit Tests ETIS SS05 Nadine Fröhlich

Tests + Fehlerkorrektur „Testen dient der Suche nach Fehlern, die durch Irrtum entstanden sind und zu Fehlverhalten führen können.“ (Dumke) Fehlerkorrekturphasen: Testen, um Fehler zu bestimmen Fehlerbehandlung, d.h. Lokalisierung und Korrektur des Fehlers + Kontrollmaßnahmen entwickeln Nachtesten, d.h. Test ob neue Fehler durch Korrektur entstanden je eher Fehler entdeckt, desto einfacher, kostengünstiger und weniger zeitaufwendiger Korrektur Unit Tests ETIS SS05 Nadine Fröhlich

Tests + Refactoring Refactoring: Umstrukturierung, Verbesserung existierenden Codes Ziel: einfacheres Design zur Verbesserung von Lesbarkeit und Wartbarkeit (kleine) Änderungen interner Struktur ohne externes Verhalten, d.h. die Funktionalität, zu ändern Zur Qualitätssicherung vorhandenen Codes nach Refactoring: (Automatisierte) Test, speziell Unit - Tests, notwendig Tests vermeiden neue Fehler Unit Tests ETIS SS05 Nadine Fröhlich

Vorurteile gegenüber Testen SOMIT: Testen wichtig!!! ABER: oft vernachlässigt, da Vorurteile... zeitaufwendig, ABER: Tests stabilisieren Code  Zeiteinsparung :) langweilig, stupide, ABER: automatisierte Tests vermeiden manuelle Wiederholungen, erstellen ist kreativ+ schafft Vertrauen zum Programm mein Code ist fehlerfrei, ABER: Wie wirken sich Verbesserungen des alten Codes aus? Testabteilung testet, ABER: Je früher Fehler erkannt, desto besser + Test des Gesamtsystems nicht ausreichend, um Fehler in Komponenten aufzudecken Unit Tests ETIS SS05 Nadine Fröhlich

Testen I Oft Probleme aufgrund mangelnder Testfallqualität Ursachen: Erfahrungsmangel Vorurteile (s.o.) + psychologische Ursachen - Entwickler übersieht oft Fehler im eigenen Programm Ziel: Testcode gleiche Qualität wie restlicher Code Mögliche Test – Guidelines: Testname soll Funktionalität beschreiben Testmethode soll kurz sein So wenig Logik wie möglich in einem Testfall Unit Tests ETIS SS05 Nadine Fröhlich

Testen II Nicht möglich, alle möglichen Werte einer Eingabegröße testen Ausgewählte wichtige Test - Prinzipien: Jede typische Verwendung eines Objektes testen Prüfen von Grenzwerten (dort treten die meisten Fehler auf) Äquivalenzklassen (Wertebereich in Eingabeintervalle mit gleichwertigen Eigenschaften unterteilt) Positives und negatives Testen (Testen, was das System tun soll und was es nicht tun soll) Unit Tests ETIS SS05 Nadine Fröhlich

Testarten statisch: Codeausführung nicht erforderlich Codeanalyse-Werkzeuge, Reviews, ... dynamisch: Codeausführung erforderlich Black-Box vs. White-Box (außerdem: Grey-Box) Black-Box: Testfälle aus Spezifikation, Implementierung nicht betrachtet White-Box: Implementierung betrachtet Nutzertests vs. Entwicklertests Nutzertests: Akzeptanztests Entwicklertests: Unit Tests, Integrationstests, Performance- und Lasttests, ... Unit Tests ETIS SS05 Nadine Fröhlich

Unit Tests auch Modultests oder Komponententests Test einzelner Einheiten Testet Programmeinheiten isoliert Einheit: eine Methode, eine Klasse oder Gruppe von Klassen Test vor Fertigstellung gesamter Anwendung möglich im Kontext agiler Software-Entwicklung Test vor zu testendem Code geschrieben (Test First) Automatisierung der Unit-Tests Tests müssen 100%ig funktionieren Unit Tests ETIS SS05 Nadine Fröhlich

Automatisierte Tests automatische Ausführung von Unit-Tests möglich und anzustreben Ziel: Test selbstprüfend, d.h. Mensch greift nur noch ein, wenn Test Problem signalisiert höhere Anfangskosten Wiederholungen in gleicher Qualität beliebig oft ausführbar Konzentration auf kreative Testfallerstellung bei Vermeidung langwieriger, wiederholender Aufgaben manueller Tests ständiges Refactoring ermöglicht Anfangskosten schnell amortisiert Unterstützung durch Testframeworks z.B. JUnit: Framework für automatische Unit-Tests in Java Unit Tests ETIS SS05 Nadine Fröhlich

Anforderungen an Testframeworks Sprache für Testcode = Sprache für Anwendungscode gleiche Werkzeuge verwendbar (Versionsverwaltung) Test- und Anwendungscode getrennt bessere Übersicht Testfälle unabhängig ausführbar Fehler schneller finden Testfälle müssen zusammengefaßt werden können zusammengehörige Tests organisieren Testergebnis schnell erkennbar Zeitgewinn Unit Tests ETIS SS05 Nadine Fröhlich

Zusammenfassung Testen Voraussetzung für „gute“ Software existieren viele falsche Vorurteile gegenüber Testen alles zu testen nicht möglich, daher: Prinzipien anwenden Guidelines entwickeln und einhalten Unit-Test (Komponententests): wichtige Entwicklertests automatisierte Unit Tests effektiv Investition in die Zukunft JUnit: Framework für Test von Java - Programmen Unit Tests ETIS SS05 Nadine Fröhlich

Literatur David J. Barnes, Michael Kölling, Objektorientierte Programmierung mit Java, Pearson Studium, 2003 Johannes Link, Softwaretests mit JUnit, dpunkt.Verlag, 2005 http://www.frankwestphal.de/UnitTestingmitJUnit.html Reiner Dumke, Software Engineering, Vieweg, 2003 ETIS-Skript Unit Tests ETIS SS05 Nadine Fröhlich