Fachgebiet Software Engineering Übersicht © 22.01.2014 Albert Zündorf, Kassel University Projektplan: m 12.11.08: Anforderungsanalyse Dokument m 26.11.08:

Präsentation zum Thema: "Fachgebiet Software Engineering Übersicht © 22.01.2014 Albert Zündorf, Kassel University Projektplan: m 12.11.08: Anforderungsanalyse Dokument m 26.11.08:"—  Präsentation transkript:

1 Fachgebiet Software Engineering Übersicht © 22.01.2014 Albert Zündorf, Kassel University Projektplan: m 12.11.08: Anforderungsanalyse Dokument m 26.11.08: Projekthandbuch Sprint 2 m 16.12.08: An-/Abmeldefrist OKA (noch 3 Tage) m 17.12.08: Projekthandbuch Sprint 3 m 14.01.09: 1. Messe m 21.01.09: Projekthandbuch Integrationsaufgabe Sprint 1 m 28.01.09: Projekthandbuch Integrationsaufgabe Sprint 2 m 04.02.09: Projekthandbuch Integrationsaufgabe Sprint 3 m 11.02.09: 2. Messe

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

3 Fachgebiet Software Engineering Übersicht © 22.01.2014 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

4 Fachgebiet Software Engineering Übersicht © 22.01.2014 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

5 Fachgebiet Software Engineering Übersicht © 22.01.2014 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

6 Fachgebiet Software Engineering Übersicht © 22.01.2014 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

7 Fachgebiet Software Engineering Übersicht © 22.01.2014 Albert Zündorf, Kassel University White-Box-Testing m Coverage Tools l cobertura (http://cobertura.sourceforge.net) l EMMA (http://emma.sourceforge.net) l EclEmma (http://www.eclemma.org) l Coverlipse (http://coverlipse.sourceforge.net) l jCoverage (http://www.jcoverage.com) l OptimzeIt (http://www.borland.com/us/products/optimizeit) l Clover (http://www.cenqua.com/clover)

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

9

10

11 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

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

13 Fachgebiet Software Engineering Übersicht © 22.01.2014 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

14 Fachgebiet Software Engineering Übersicht © 22.01.2014 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

15 Fachgebiet Software Engineering Übersicht © 22.01.2014 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