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

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

Baustein- vs. Funktionsorientierte Organisation


Features / User Stories

Baustein übergreifende Funktionalität

realisiert (Teil-) Anforderung

Use Case + GUI Entwurf + textuelle Szenarien + Objektdiagramme (Story Boards)

automatischer JUnit Test

Implementierung


Scrum


Scrum

Product Backlog: priorisierte Features / User Stories

Release Backlog: Unterteilung des ProductBacklog

Sprint Backlog: Features des Sprints mit Status geschätzter Aufwand Bearbeiter Restaufwand

Kunagi Example


Scrum Roles:

Product Owner: lebende Anforderungsdoku Onsite Customer Priorisierung der Features Reviews der Entwürfe Abnahme der Implementierung Alpha Tester


Scrum Roles:

Scrum Master: Project Manager Scrum Meetings Burndown Charts provide Tools, Computers, Room, Coffee, … manage Risks manage Failures Parties …

The Team:


Scrum Roles:

The Team: do the work story boards / user stories tests implementation bug tracking bug killing reviews testing debugging documentation


Was Scrum verschweigt:

Story Boards müssen harmonisiert werden

Klassendiagramme / Architektur

Metaphern / gemeinsame Vision

Bug Sqash Weeks

Libraries / Frameworks


Kunagi


Features / User Stories

Baustein übergreifende Funktionalität

realisiert (Teil-) Anforderung

User Story + GUI Entwurf + textuelle Szenarien (+ Objektdiagramme (Story Boards) )

automatische JUnit Test

Implementierung


Testen

(Whitebox) Glassbox-Test anhand der Implementierung Normal- und Grenzfälle aus Bedingungen Überdeckungskriterien

Blackbox-Test mit Hilfe der Spezifikation (ohne die Implementierung zu

kennen) Normalfälle aus der Spezifikation Sonderfälle der Spezifikation Unzulässige Eingaben der Spezifikation


White-Box-Testing

C0-Überdeckung (Anweisungs- und Bedingungsüberdeckung) Beim Test muss jedes Statement und jeder Ausdruck mindestens einmal

ausgewertet werden Code Coverage Tools können das automatisch messen

(Ergebnis gehört ins Testprotokoll) (Für Java z.B. EMMA) manchmal schwer zu erfüllen z.B.

try { ... } catch (HeapOverflow e) { xxx () } findet nicht alles:

m (x, y) { int z = 0; if (x > 0) { z = 1; } y = x / z; // <== ERROR: Division by zero ...

Der Aufruf m(1,0) erreicht C0-Überdeckung aber keine Fehlerfreiheit


White-Box-Testing

C1-Überdeckung: Zweigüberdeckung auch leere if-then-else-Zweige müssen durchlaufen werden (while) Schleifen müssen sowohl durchlaufen als auch übersprungen

werden 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


White-Box-Testing

C2-Überdeckung (Pfadüberdeckung) Testfälle sollen alle möglichen Durchläufe durch eine Methode

testen Schleifen null und ein mal durchlaufen 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

Bei jedem if-Statement 2 Fortsetzungsmöglichkeiten bei n if Statements 2 hoch n Pfade (20 ifs 1 Millonen Testfälle) in der Praxis nicht vertretbarer Zeitaufwand findet immer noch nicht alle Fehler

Bemerkung: sowas findet man gut mit Reviews


White-Box-Testing

Coverage Tools cobertura (http://cobertura.sourceforge.net) EMMA (http://emma.sourceforge.net) EclEmma (http://www.eclemma.org) Coverlipse (http://coverlipse.sourceforge.net) jCoverage (http://www.jcoverage.com) OptimzeIt

(http://www.borland.com/us/products/optimizeit) Clover (http://www.cenqua.com/clover)


Black-Box-Testing

Funktionsorientierter Test jede Funktion / Feature / Variable einzeln

Äquivalenzklassenbildung Definitionsbereich der Variablen betrachten Partitionierung, zwei Tests pro Partition Randwerte

Regressionstests Wiederhole Tests bei Programmänderungen vgl. XP

Szenario-basierte Tests vgl. FUP


Random Testing


JUnit Tests – Test First Principle

im eXtreme Programming / agilen Methoden: JUnit Tests Für jede Funktionalität (jedes Oval im Use-Case Diagramm) wird als erstes

eine automatische Testroutine geschrieben Testroutine ist einzeln aufrufbar und wird in Gesamttest eingehängt Testroutine kommt in die gleichen Klassen, wie die Implementierung Testroutinen verbleiben im Code und gehören zum Endprodukt Aufgaben der Testroutine:

verschiedene Ausgangssituationen herstellen Funktionalität aufrufen Messpunkte im Code abfragen (Testanweisungen fügen Meldungen an Testreport

an) Testprotokoll ausgeben (Testreport mit erwartetem Output vergleichen)

expliziter Unit-Test kann entfallen im Unified Process

Tester != Programmierer

Defect-Removal-Rate ~ 1 per day


Test Summary:

ein Fehler pro Tag

Test First

Funktionstests (anstatt Bausteintests)

Ein Assert pro (typischer) Fehler(quelle)

Coverage

vollautomatisch

unglaublich wertvoll bei Änderungen / iterativem Vorgehen


Reviews

Entwickler selbst plus Co-Entwickler oder externer Reviewer Check-Liste mit typischen Fehlern Code ist schon Unit getestet => suche nur nach typischen Fehlerquellen:

Division durch 0 null-Pointer Dereferenzierung Speicher-Lecks Array-Grenzen bei for-Schleifen deckt kompliziertes if alle Fälle richtig ab Terminiert die Schleife / Rekursion sicher Dead-Lock-Gefahren Racing Conditions . . .

+ Defect-Removal-Rate ~ 1 per hour

+ Reviewer lernt viele Kniffe

+ Viele Leute kennen viele Teile des Gesamtprogramms bei XP pair-programming

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

Documents

Transcript of Fachgebiet Software Engineering Übersicht © 23.01.2014 Albert Zündorf, Kassel University...