Post on 05-Apr-2015
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Wasserfallmodel
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Machbarkeitsstudie
Auswählen des Produktes
Voruntersuchung des Produkts
Durchführbarkeitsuntersuchung
Prüfen der ökonomischen Durchführbarkeit
Ergebnis: „Stop or go“ Entscheidung
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Anforderungsdefinition
Konzepterarbeitung mit Laien / Kunden
Verständliche Szenarios
Klärung der Funktionalität
Nichtfunktionale Anforderungen
Anforderungsdokumentation
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Analyse
Grob-Entwurf
in der „Problem-Domain“
Erfassen der Domain (Business-Model)
Konzeption neuer (komplexer) Funktionalität
Konzeption von (Architektur) Umbauten
Architekturkonzepte
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Design
Fein-Entwurf
in der „Solution-Domain“
Arbeitsvorlage für den Entwickler
Konzeption neuer (komplexer) Funktionalität
Konzeption von (Architektur) Umbauten
Architekturkonzepte
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Implementierung
hier wird „gehackt“
Entwickler orientieren sich am Design-Dokument
Tests
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Wartung
Auslieferung
Pflege vor Ort
Bugfixing
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Probleme mit dem Wasserfall
Alle Anforderungen zuerst ersten Phasen werden teuer Kunde bekommt nicht das, was er will
Probleme werden spät entdeckt
Phasen werden Arbeitsschritte iterativer Durchlauf prototypisch usecase / scenario – driven Test-first
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Kostenschätzung
Resultat aus Gruppendiskussion
Pi mal Daumen
Ergebnis: ca. ein Semester
Modul und Phasen-basiert
Schätzgrößen LOC, Seiten Zeit
Einzelschätzungen + Gesamtsumme
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Abgaben
Abgaben per CVS
setzen der Tags gemäß Aufgabenstellung v3
vor der Deadline
in eclipse: Rechtsklick Team Tag as Version
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Organisatorische Hinweise
Im OKA anmelden - bis Anfang Dezember, Veranstaltung „Softwaretechnik“
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Testen - Motivation
Testen ist Ausprobieren? GUI ‚durchklicken‘ System.out.println(…)
Wer hat das kaputt gemacht?
don't touch it if it works!
Je nach „Qualität“ geht bis zu 50% der Arbeitszeit Debugging und Fehlersuche
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Unit Tests
Testen eine ‚Einheit‘: Klasse Modul Komponente
Werden programmiert
Prüfen den Funktionsumfang
Rufen nur die öffentliche Schnittstelle auf
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Vorteile von Unit Testing
Tests sind: Reproduzierbar (von anderen) Automatisierbar und selbst auswertend Dokumentierend und Anwendungsbeispiel
Tests decken Designfehler frühzeitig auf
Der entstehende Code ist: Modular und einfach Änderungssicher Qualitativ hochwertiger
=> Weniger Fehler, Debugging und Fehlersuche
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Testen
Ziel: Fehler finden
IST-SOLL Vergleich
z.B. mit JUnit
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Vorgehen beim Testen
Test vor der Implementierung: Funktionalität abprüfen Alle möglichen Fehlerfälle prüfen aber keine Trivialitäten
So wenig wie möglich implementieren Genau soviel, dass der Test erfolgreich ist
Umfang vom Testcode: 15-50% Anteil am Gesamtcode
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Testgetriebene Entwicklung
Funktionale Anforderung
Test anlegen
Schnittstelle anlegen
Test implementieren
Funktion implementieren
Eine Iteration Zeit
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Tests für CoreWars
Verwenden Junit 3.8 (siehe Beispiele) möglichst früh Tests schreiben, (Test-first)
vor oder während der Implementierung Hinterher macht das keinen Spaß!
Achtung: gemeinsame Deadline für Tests und Implementierung! Szenarien-basiert:
Test „spielt“ ein Szenario durch Prüfen der Ergebnisse
Vorgehen siehe Vorlesung Programmiermethodik Debugger (Breakpoints, Variables View...) nutzen!
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Tests für die 8 neuen Befehle
Siehe existierende Tests in CUTest.java Selbes Schema:
Instruktion(en) erzeugen Queue mit Program Counter befüllen Aktuelle Instruktion ausführen Sind die richtigen Änderungen im Core? Stimmt der neue Program Counter?
Testet die Funktion der Opcodes Mindestens eine Test-Methode pro Opcode
Und auch die Fehlerfälle Division durch 0 ...
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
JUnit Framework (1)
Freies Open Source Framework http://www.junit.org/ Verwendet: 3.8.1, aktuell: 4.4
Autoren: Kent Beck & Erich Gamma
Grundeinstellung: Das Feature funktioniert erst … … wenn ein Test geschrieben wurde
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
JUnit Framework (2)
Tests in separaten Test-Klassen, aber im gleichen Paket
Test-Methoden Instanzieren von Objekten Prüfung des Objektzustandes vor und nach
Methodenaufrufen Assertion-Methoden Prüfung von Fehlerbehandlung (Exceptions)
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
JUnit Framework (3)
Basisklassen für Test-Klassen: junit.framework.TestCase Stellt Assert-Methoden bereit
TestRunner lassen Tests ablaufen: Eine Methode einer Test-Klasse Eine Test-Klasse komplett Mehrere Test-Klassen as TestSuite Grafisch oder Textmodus Oder direkt in Eclipse „Run As -> JUnit Test“
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Aufbau einer Test-Klasse
Tests werden thematisch in einer Klasse gesammelt: … extends TestCase …
Jeder Test ist eine Methode: public void test<Name> throws Exception { … }
Vor und nach jedem Test: public void setUp() { … }
Objektstruktur aufbauen
public void tearDown() { … } - aufräumen
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Assertion-Methoden
Ausdrücke, die wahr sein müssen, sonst Abbruch der aktuellen Test-Methode
assertEquals(soll, ist) Object, primitive Typen
assertTrue(boolean)
assert[Not]Null(Object), assert[Not]Same(obj1, obj2)
Bei Fehlschlag oder fail(): Wirft junit.framework.AssertionFailedError
Alle Methoden auch mit ‚String message‘ Parameter
Fachgebiet Software Engineering Übersicht © 11.04.23 Albert Zündorf, Kassel University
Testen - Vorgehen
Erster Hinweis: Fehlermeldung! Stacktrace
Debugging - Einkreisen eines Fehlers Breakpoints an „spannenden“ Stellen setzen Variablenbelegung / Objekstruktur überprüfen Methode schrittweise ausführen in interessante Methoden reinsteppen
Tip: Fehler gefunden => reproduzierenden Test schreiben