Programmieren I. Übersicht. Vorlesung 12. Handout S. 1. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011

Größe: px

Ab Seite anzeigen:

Download "Programmieren I. Übersicht. Vorlesung 12. Handout S. 1. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011"

Paul Zimmermann
vor 8 Jahren
Abrufe

1 Programmieren I Martin Schultheiß Hochschule Darmstadt Wintersemester 2010/ Übersicht Testen ist eine der wichtigsten, aber auch eine der Zeitaufwändigsten Arbeitsschritte der Softwareentwicklung. Wegen dem hohen Arbeitsaufwand wird im Bereich des Testens oft gespart, was jedoch häufig große Folgekosten durch die Fehlersuche und -Behebung zu einem späten Projektzeitpunkt verursacht. Dieses Kapitel soll einen Überblick über die verschiedenen Arten von Tests und eine Einführung in ein Framwork zum Durchführen von Unit-Test in Java, JUnit, geben. Handout S. 1

Wegen dem hohen Arbeitsaufwand wird im Bereich des Testens oft gespart, was jedoch häufig große Folgekosten durch die Fehlersuche und

2 Blackbox/Whitebox-Tests Unter einem Whitebox-Test versteht man einen Test, bei welchem der Tester genaue Informationen über die zu testende Komponente besitzt, d.h. mit der Struktur und Funktionsweise des Systems vertraut ist. Ein Blackbox-Test dagegen ist ein Test, bei dem nur die Schnittstellen nach Außen der Komponente oder des Systems bekannt sind, d.h. der Tester kennt die Struktur bzw. Funktionsweise des Systems nicht. Testarten im Software-Entwicklungsprozess Unit-Test oder Modultest: Testen einer einzelnen fertig gestellten Systemkomponente Integrationstest: Test der Schnittstellen und des Zusammenwirkens mehrerer Systemkomponenten Systemtest: Test des vollständig integrierten Systems in der Zielumgebung gegen die Anforderungen Abnahmetest: Systemtest des Auftraggebers in der realen Einsatzumgebung und mit echten Daten Testarten: Unit-Test Handout S. 2

3 Testarten: Integrationstest Voraussetzung: Unit-Tests der beteiligten Komponenten ist erfolgt Aufgabe des Integrationstests: Tests der Schnittstellen und des Zusammenwirkens der Komponenten -> White-Box-Test Integrationsstrategien inkrementell: sukzessive Integration nach einer gewählten Reihenfolge nicht-inkrementell: big-bang oder geschäftsprozessorientiert Testarten: Systemtest Voraussetzung: Integrationstest für das vollständig integrierte System ist abgeschlossen Aufgaben des Systemtests: Black-Box-Test des fertigen Systems gegen die festgelegten Qualitätsziele, beinhaltet Funktionstest Leistungstest Benutzbarkeitstest Sicherheitstest Interoperabilitätstest Installationstest Wiederinbetriebnahmetest Unit-Tests: Ermittlung der Testfälle Im folgenden konzentrieren wir uns auf Unit-Tests. Die Frage ist, nach welchem Schema die Testfälle bestimmt werden können. Eine Möglichkeit ist, das Programm als Automaten darzustellen und daraus die Testfälle zu ermitteln bzw. zu generieren. Handout S. 3

Voraussetzung: Integrationstest für das vollständig integrierte System ist abgeschlossen Aufgaben des Systemtests: Black-Box-Test des fertigen Systems gegen die festgelegten Qualitätsziele,

4 Kurze Einführung in die Automatentheorie Ein Computerprogramm kann oftmals auch als endlicher Automat beschrieben werden. Dieser besteht aus einem Startzustand, einem oder mehreren Endzuständen, beliebig vielen sonstigen zuständen sowie Übergängen zwischen den Zuständen. Die Darstellung eines solchen Automaten ist als Graph möglich. Beispiel -> Tafel! Wie können aus einem solchen Automaten Testfälle generiert werden? Knoten vs. Kantenüberdeckung Bei der Knotenüberdeckung wird darauf geachtet, jeden Knoten mindestens einmal zu besuchen. Bei der Kantenüberdeckung wird jede Kante mindestens einmal durchlaufen. Kantenüberdeckung impliziert Knotenüberdeckung. (Warum?) Testen von Grenzfällen Funktionen sind oft partiell oder abschnittweise definiert. In diesem Fall sollten die Grenzwerte auf jeden Fall getestet werden! Beispiel: Wurzelfunktion, 0 und -1 sind Testkandidaten. Handout S. 4

Die Darstellung eines solchen Automaten ist als Graph möglich. Beispiel -> Tafel! Wie können aus einem solchen Automaten Testfälle generiert werden? Knoten vs.

5 Unit-Tests allgemein Unit-Test-Realität (häufig) es wird gar nicht getestet es wird mit println etc. getestet Tests aktivieren/deaktivieren im Code aufwändige Testauswertung Ziele Tests müssen modular sein außerhalb der zu testenden Klasse Tests müssen sich selbst auswerten Testprogramm vergleicht tatsächliche Ergebnisse mit erwarteten Ergebnissen Überblick JUnit Open-Source-Framework in Java, für Java Autoren: Kent Beck, Erich Gamma (1998) aktuell: Version (April 2010) Achtung: Architektur hat sich von JUnit3.8.x zu JUnit4.0 stark verändert, bei Literaturrecherche darauf achten! Prinzipien von JUnit: Tests sind separat erstellbar frei kombinierbar wiederholt anwendbar automatisiert durchführbar automatisch auswertbar Testfälle erstellen Testfall: separate Test-Methoden mit Konvention test<methodenname> Zusammenfassung zusammengehöriger Testfälle in einer Test-Klasse optional: Setup- und TearDown-Methoden, die vor bzw. nach jedem Testfall ausgeführt werden zum Setzen von Umgebungsparametern, Erzeugen von Testdaten und Freigeben von Ressourcen Konvention setup() bzw. teardown() darüber hinaus jeweils eine Setup- und TearDown-Methode möglich, die nur einmal pro Testklasse ausgeführt werden Handout S. 5

tatsächliche Ergebnisse mit erwarteten Ergebnissen Überblick JUnit Open-Source-Framework in Java, für Java Autoren: Kent Beck, Erich Gamma (1998)

6 Assertions Ausdrücke, die immer wahr sein müssen wenn nicht, meldet das Framework einen Fehler für den aktuellen Testfall... und macht mit dem nächsten Testfall weiter Varianten (Auswahl) assertequals(... expected,... actual) Gleichheit der Parameter hinsichtlich ëquals()methode viele überladene Varianten (double, long, Object, delta, message) asserttrue(boolean b)und assertfalse(boolean b) assertsame(object expected, Object actual) Identität: Parameter verweisen auf das selbe Objekt... für alle Assertions immer auch Varianten mit String message als zusätzlichem ersten Argument Beispiel (1/2) p u b l i c c l a s s Euro { p r i v a t e f i n a l double amount ; p u b l i c Euro ( double amount ) { t h i s. amount = amount ; p u b l i c double getamount ( ) { r e t u r n t h i s. amount ; p u b l i c Euro add ( Euro summand) { r e t u r n new Euro ( t h i s. amount + summand. getamount ( ) ) ;... Beispiel (2/2) p u b l i c c l a s s EuroTest { p r i v a t e Euro two p u b l i c v o i d setup ( ) { two = new Euro ( ) p u b l i c v o i d testamount ( ) { a s s e r t T r u e ( == two. getamount ( ) ) p u b l i c v o i d t e s t A d d i n g ( ) { Euro sum = two. add ( two ) ; Euro t e s t = new Euro ( ) ; a s s e r t T r u e ( "sum", t e s t. getamount()==sum. getamount ( ) ) ; Handout S. 6

.. actual) Gleichheit der Parameter hinsichtlich ëquals()methode viele überladene Varianten (double, long, Object, delta, message) asserttrue(boolean b)und assertfalse(boolean b) assertsame(object

7 Testen von Exceptions Es ist auch möglich, das Auftreten von erwarteten Exceptions zu testen: p u b l i c c l a s s EuroTest p u b l i c v o i d testnegativeamount ( ) { t r y {Euro minustwo = new Euro ( ) ; f a i l ( " Should r a i s e I l l e g a l A r g u m e n t E x c e p t i o n " ) ; c a t c h ( I l l e g a l A r g u m e n t E x c e p t i o n e x p e c t e d ) { Was muss in der Klasse Euro verändert werden, damit dieser Test fehlerfrei läuft? Testen privater Methoden Private Methoden können mit JUnit nicht getestet werden (warum?) Ist es überhaupt sinnvoll, private Methoden zu testen? Falls ja, Zugriff über Java Reflection möglich Handout S. 7

0 0 ) ; f a i l ( " Should r a i s e I l l e g a l A r g u m e n t E x c e p t i o n " ) ; c a t c h ( I l l e g a l A r g u m e n t E x c e p t i o n e x p e c t e d )

Ähnliche Dokumente

Programmieren I. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011

Programmieren I. Martin Schultheiß. Hochschule Darmstadt Wintersemester 2010/2011 Programmieren I Martin Schultheiß Hochschule Darmstadt Wintersemester 2010/2011 1 Testen von Programmen 2 Übersicht Testen ist eine der wichtigsten, aber auch eine der Zeitaufwändigsten Arbeitsschritte