Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Projektplan: m : Anforderungsanalyse Dokument m : Projekthandbuch Sprint 2 m : An-/Abmeldefrist OKA (noch 3 Tage) m : Projekthandbuch Sprint 3 m : 1. Messe m : Projekthandbuch Integrationsaufgabe Sprint 1 m : Projekthandbuch Integrationsaufgabe Sprint 2 m : Projekthandbuch Integrationsaufgabe Sprint 3 m : 2. Messe

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Tätigkeiten bei der Softwareentwicklung

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Testen m (Whitebox) Glassbox-Test l anhand der Implementierung l Normal- und Grenzfälle aus Bedingungen l Überdeckungskriterien m Blackbox-Test l mit Hilfe der Spezifikation (ohne die Implementierung zu kennen) l Normalfälle aus der Spezifikation l Sonderfälle der Spezifikation l Unzulässige Eingaben der Spezifikation

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University White-Box-Testing m C0-Überdeckung (Anweisungs- und Bedingungsüberdeckung) l Beim Test muss jedes Statement und jeder Ausdruck mindestens einmal ausgewertet werden l Code Coverage Tools können das automatisch messen (Ergebnis gehört ins Testprotokoll) (Für Java z.B. EMMA) l manchmal schwer zu erfüllen z.B. try {... } catch (HeapOverflow e) { xxx () } l findet nicht alles: m (x, y) { int z = 0; if (x > 0) { z = 1; } y = x / z; // <== ERROR: Division by zero... l Der Aufruf m(1,0) erreicht C0-Überdeckung aber keine Fehlerfreiheit

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University White-Box-Testing m C1-Überdeckung: Zweigüberdeckung l auch leere if-then-else-Zweige müssen durchlaufen werden l (while) Schleifen müssen sowohl durchlaufen als auch übersprungen werden l findet aber immer noch nicht alles: m (x, y) { int z = 0; if (x > 0) { z = 1; } else { z = -1;} if (y > 0) { z ++; } else { z --; } y = x / z; // <== ERROR: Division by zero on x = 1 and y = -1

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University White-Box-Testing m C2-Überdeckung (Pfadüberdeckung) l Testfälle sollen alle möglichen Durchläufe durch eine Methode testen l Schleifen null und ein mal durchlaufen l Problem exponentieller Aufwand: m (x, y) { int z = 0; if (x > 0) { z = 1; } else { z = -1;} if (y > 0) { z ++; } else { z --; } if (...) {... } else {...} y = x / y; // <== ERROR: Division by zero on y = 0 l Bei jedem if-Statement 2 Fortsetzungsmöglichkeiten l bei n if Statements 2 hoch n Pfade (20 ifs 1 Millonen Testfälle) l in der Praxis nicht vertretbarer Zeitaufwand l findet immer noch nicht alle Fehler Bemerkung: sowas findet man gut mit Reviews

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University White-Box-Testing m Coverage Tools l cobertura ( l EMMA ( l EclEmma ( l Coverlipse ( l jCoverage ( l OptimzeIt ( l Clover (

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University

Black-Box-Testing m Funktionsorientierter Test l jede Funktion / Feature / Variable einzeln m Äquivalenzklassenbildung l Definitionsbereich der Variablen betrachten l Partitionierung, zwei Tests pro Partition l Randwerte m Regressionstests l Wiederhole Tests bei Programmänderungen l vgl. XP m Szenario-basierte Tests l vgl. FUP

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Random Testing

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University JUnit Tests – Test First Principle m im eXtreme Programming / agilen Methoden: JUnit Tests l Für jede Funktionalität (jedes Oval im Use-Case Diagramm) wird als erstes eine automatische Testroutine geschrieben l Testroutine ist einzeln aufrufbar und wird in Gesamttest eingehängt l Testroutine kommt in die gleichen Klassen, wie die Implementierung l Testroutinen verbleiben im Code und gehören zum Endprodukt l Aufgaben der Testroutine: l verschiedene Ausgangssituationen herstellen l Funktionalität aufrufen l Messpunkte im Code abfragen (Testanweisungen fügen Meldungen an Testreport an) l Testprotokoll ausgeben (Testreport mit erwartetem Output vergleichen) l expliziter Unit-Test kann entfallen m im Unified Process l Tester != Programmierer Defect-Removal-Rate ~ 1 per day

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Test Summary: m ein Fehler pro Tag m Test First m Funktionstests (anstatt Bausteintests) m Coverage m vollautomatisch m unglaublich wertvoll bei Änderungen / iterativem Vorgehen

Fachgebiet Software Engineering Übersicht © Albert Zündorf, Kassel University Reviews m Entwickler selbst plus Co-Entwickler oder externer Reviewer m Check-Liste mit typischen Fehlern m Code ist schon Unit getestet => suche nur nach typischen Fehlerquellen: l Division durch 0 l null-Pointer Dereferenzierung l Speicher-Lecks l Array-Grenzen bei for-Schleifen l deckt kompliziertes if alle Fälle richtig ab l Terminiert die Schleife / Rekursion sicher l Dead-Lock-Gefahren l Racing Conditions l... + Defect-Removal-Rate ~ 1 per hour + Reviewer lernt viele Kniffe + Viele Leute kennen viele Teile des Gesamtprogramms m bei XP pair-programming