Annette Bieniusa Sommersemester 2015

Slides:



Advertisements
Ähnliche Präsentationen
Software Engeniering II
Advertisements

der Universität Oldenburg
Prüfung objektorientierter Programme -1
Integrations- und Funktionstests im Rahmen des V-Modelles
Präsentation PS: Klasse File von Janko Lange, Thomas Lung, Dennis Förster, Martin Hiller, Björn Schöbel.
DVG Dateien Dateien. DVG Dateien 2 Die Klasse File Die Klasse File stellt die Verbindung zwischen dem Filesystem des Rechners und dem.
Einführung in die Programmierung Ausführbare Klassen
Prof. Dr. Holger Schlingloff
Ausnahmen HS Merseburg (FH) WS 06/07.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Was ist Refactoring? Bevor man die Integration angeht, mag es angebracht sein, den.
Universität Stuttgart Institut für Kernenergetik und Energiesysteme Aufgaben des Testens Vergleich des Verhaltens einer Software mit den an sie gestellten.
FH-Hof Tools Richard Göbel. FH-Hof Tools für die Veranstaltung JUnit: Testen ANT: Build-Tool Eclipse: Entwicklungsumgebung.
Java: Dynamische Datentypen
Indirekte Adressierung
FH-Hof Verwaltung von Zeichenketten Richard Göbel.
Java: Referenzen und Zeichenketten
FH-Hof Fehlerbehandlung Richard Göbel. FH-Hof Konzept Fehler können mit dem Operator throw einer übergeordneten Funktion signalisiert werden. Parameter.
Klassenvariable. Da man für jede Kuh bzw. jede Henne auf dem Markt den gleichen Preis für ein Liter Milch, bzw. den gleichen Preis für ein Ei bekommt,
FOR Anweisung. Aufgabe : Ausgabe aller ganzen Zahlen von 0 bis 100 auf dem Bildschirm.
Das Test-Framework JUnit
Das Test-Framework JUnit
Automatisches Testen und Bewerten von Java-Klassen
PRJ 2007/1 Stefan Dissmann Motivation Problem: gleiche Datenstrukturen werden für verschiedene Objekte gebraucht: z.B. Listen von Studierenden, Kunden,
Projektplan: Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University.
1 WS 2012 Software-Engineering II Objektorientiertes Testen.
Modulare Programmierung
DVG Kommentare1 Kommentare. DVG Kommentare 2 Kommentare Es gibt zwei Arten von Kommentaren: einzeilige Kommentare // der Kommentar geht.
DVG Einführung in Java1 Einführung in JAVA.
DVG Klassen und Objekte
DVG Kommentare 1 Kommentare. 2 Kommentare Es gibt zwei Arten von Kommentaren: einzeilige Kommentare // der Kommentar geht bis zum Ende der Zeile.
© 2005 Pohlig - Taulien Datenströme GK Informatik 1 Datenströme.
Seite 1 Interface - Konzept Ein Interface führt einen neuen Datentyp ein: interface Frau {... } Das Interface enthält Deklarationen ( keine Definitionen.
Whitebox Testen mit JUnit
EPROG Tutorium Einheit 4 Klassen und Objekte. Wiederholung Schleifen do... while while for break/continue Strings String char Methoden für Strings Arrays.
Javakurs FSS 2012 Lehrstuhl Stuckenschmidt
Testtechniken-Praktikum WS 2005/06 1 Testen mit Mock- Objekten Andreas Höfer Dr. Matthias Müller.
Objektorientiertes Konstruieren
Variablenkonzept Klassisch, in Java Basistyp
Clean Code Software-Entwicklung als Handwerkskunst Thomas Nagel, November 2011.
EPROG Tutorium #4 Philipp Effenberger
EPROG Tutorium #6 Philipp Effenberger
Testtechniken-Praktikum WS 2005/06 1 Arbeiten mit JUnit Andreas Höfer Dr. Matthias Müller Mit Beiträgen von Johannes Link.
Programmiervorkurs WS 2014/15 Methoden
Voyager Eigenschaften/Vorzüge Universalität: –ROI-Modelle: CORBA, RMI, DCOM –verschiedene Namens-, Verzeichnisdienste Nachrichtentypen: synchron, oneway,
3. Beschreibung von Abläufen durch Algorithmen 3.4 Zufall
Robuste Programme durch Ausnahmebehandlung
Test-Driven Development
By Thorsten Zisler 1 SQL Datenbank Anbindung an den Supervisor.
Einführung. Ziel der Veranstaltung  Vermittlung von Grundkenntnissen in C++  Solide Basis für anschließende Weiterentwicklung  Fähigkeit, kleine Programme.
Atos, Atos and fish symbol, Atos Origin and fish symbol, Atos Consulting, and the fish itself are registered trademarks of Atos Origin SA. August 2006.
Webdeployment auf Cluster Seminarvortrag von Lukas Bonzelett.
Patrick Richterich Lattwein GmbH Web Services Softwareentwicklung mit SOAP.
Software-Delivery auf Knopfdruck IBM Cloud & DevOps.
Anforderungen an die neue Datenstruktur
Schnittstellen.
Hello World! Javakurs 2013 Arne Kappen
Zwei Denkansätze zur Klasse Schlange
Java-Kurs - 4. Übung weitere Kontrollstrukturen
Die Klasse Vielfrass in Java
Allgemeine Befehle für die allgemeine Liste
Create Table, Rechte und Rollen
PHP Testing.
Grundkurs Informatik 11-13
Raphael Fischer Informatik II - Übung 06 Raphael Fischer
SS 04 Christiane Rauh Christian Hellinger
«Delegierter» Methoden Schablone Funktionszeiger
Datenstrukturen und Softwareentwicklung
9. Vererbung und Polymorphie
Wissenschaftliches Projekt
1. Die rekursive Datenstruktur Liste 1.6 Die Datenstruktur Stapel
 Präsentation transkript:

Annette Bieniusa Sommersemester 2015 Programmierprojekt Annette Bieniusa Sommersemester 2015

Testen Kernfrage: Erfüllt die Software ihre Anforderungen / Spezifikation? Funktionale Anforderungen Korrekte Ergebnisse bei Berechnungen Nicht-funktionale Anforderungen Laufzeit von Algorithmen, Look-and-feel der GUI, Skalierbarkeit von Servern, Latenzzeiten ...

Testen „Ein Test [...] ist der überprüfbare und jederzeit wiederholbare Nachweis der Korrektheit eines Softwarebausteines relativ zu vorher festgelegten Anforderungen“ (Denert, 1991) Wichtiger Baustein der Qualitätssicherung in der Software-Entwicklung „Program testing can be used to show the presence of bugs, but never show their absence!“(Edsger W. Dijkstra)

Klassifizierung nach Umfang Unit-Tests (Komponententests) für einzelne Komponenten der Software Integrationstests für die Zusammenarbeit von Komponenten Systemtest für die Integration in die Anwendungsplattform Abnahmetests für die Interaktion mit dem Benutzer / Kunden

Klassifizierung von Informationsstand White-Box-Tests inspizieren auch den inneren Aufbau einer Komponente, häufig vom Entwickler durchgeführt Black-Box-Tests agieren mit einer wohldefinierten Schnittstelle, ohne Kenntnis über den tatsächlichen Aufbau einer Komponente, häufig von unabhängigen Instanzen auf Basis der Dokumentation durchgeführt

Methodik Ziel: Möglichst hohe Abdeckung des Java-Codes durch Testfälle Möglichst jede Methode einer Klasse sollte getestet werden Jede Methode sollte mit verschiedenen Parametern getestet werden Randfälle sind wichtig! [ Randomisierte Tests erzeugen zufällige Testfälle -> verringert die Chance, dass der Programmierer Randfälle übersehen hat ]

Junit4 Framework zum Unit-Testing von Java-Klassen Einfache Möglichkeit Tests zu spezifizieren und diese automatisiert auszuführen Reihenfolge der Ausführung ist nicht spezifiziert Testfälle müssen daher unabhängig von einander sein

Aufbau eines Tests Bei Hinzufügen eines neuen JUnit4- Tests wird folgender Stub erzeugt (und das Junit4 Package zum Build-Pfad hinzugefügt): import static org.junit.Assert.*; import org.junit.Test; public class ProjektTest { @Test public void test() { fail("Not yet implemented"); }

Assertions - Booleans Assertions testen, ob eine Bedingung erfüllt ist, andernfalls wird der Test nicht bestanden Um den Fehler zu beschreiben, kann man einen kurze Erklärung hinzufügen @Test public void testAssertFalse() { org.junit.Assert.assertFalse("failure - should be false", false); } public void testAssertTrue() { org.junit.Assert.assertTrue("failure - should be true", true);

Assertions - Objekte @Test public void testAssertNotNull() { org.junit.Assert.assertNotNull("should not be null", new Object()); } public void testAssertNull() { org.junit.Assert.assertNull("should be null", null); public void testAssertNotSame() { org.junit.Assert.assertNotSame("should not be same Object", new Object(), new Object()); public void testAssertSame() { Integer aNumber = Integer.valueOf(768); org.junit.Assert.assertSame("should be same", aNumber, aNumber);

Assertions - Equals @Test public void testAssertArrayEquals() { byte[] expected = "trial".getBytes(); byte[] actual = "trial".getBytes(); org.junit.Assert.assertArrayEquals("failure - byte arrays not same", expected, actual); } public void testAssertEquals() { org.junit.Assert.assertEquals("failure - strings are not equal", "text", "text");

Testen von Exceptions @Test(expected= IndexOutOfBoundsException.class) public void empty() { new ArrayList<Object>().get(0); }

Test fixtures import org.junit.*; public class TestFoobar { @BeforeClass public static void setUpClass() throws Exception { // wird zu Beginn einmal ausgeführt } @Before public void setUp() throws Exception { // wird vor jedem Test ausgeführt @Test public void test1() { // ein Test @After public void tearDown() throws Exception { // wird nach jedem Test ausgeführt @AfterClass public static void tearDownClass() throws Exception { // wird ganz am Schluss einmal ausgeführt Manchmal ist es sinnvoll, dass sich mehrere Testfälle eine Testumgebung teilen Um die Unabhängigkeit zu gewährleisten, muss vor/nach dem Test die Umgebung wiederhergestellt werden (setUp / tearDown)

Junit für den Budgetplaner Tests für das Lesen und Schreiben von Daten Sind nachdem Schreiben alle neuen und alten Einträge vorhanden? Sind gelöschte Einträge weg? Wichtig: Regressionstests, wenn Formate geändert werden! Tests für das Erstellen von Übersichten Summe aller Einnahmen / Ausgaben, pro Kategorie Tests für die Prognose !!!

Strategien zur Testbarkeit Modularisierung Testbare Einheiten identifizieren Interfaces nutzen Berechnung und Modell von GUI trennen!!! Einfache Tests mit guter Testabdeckung Randfälle! (leere Collections) Dokumentation von Verhalten in Übereinstimmung mit Tests