Software - Testung ETIS SS05

Transkript

1 Software - Testung ETIS SS05

2 Gliederung Motivation Was ist gute Software? Vorurteile gegenüber Testen Testen (Guidelines + Prinzipien) Testarten Unit Tests Automatisierte Tests Anforderungen an Testframeworks Zusammenfassung 2

3 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 3

4 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 4

5 Refactoring: Tests + 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 5

6 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 6

7 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 7

8 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) 8

9 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,... 9

10 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 10

11 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 11

12 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 12

13 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 13

14 Literatur David J. Barnes, Michael Kölling, Objektorientierte Programmierung mit Java, Pearson Studium, 2003 Johannes Link, Softwaretests mit JUnit, dpunkt.verlag, Reiner Dumke, Software Engineering, Vieweg, 2003 ETIS-Skript 14