VO 6-7

Es ist oft unstrukturiert, oberflächlich und lückenhaft

– da lediglich „ausprobieren“

Lösung: automatisierte, feingranulare Funktionstests (Unit Tests)

TDD ist eine Entwicklungsmethode, bei der zuerst die Tests und erst danach der eigentliche Code geschrieben werden.

1. Schreiben eines fehlschlagenden Tests für eine neue Anforderung

2. Code schreiben, sodass Test erfolgreich durchläuf

3. Refactoring

• „You should write new business code only when an automated test

  has failed“

• “You should eliminate any duplication that you find“

Software testing is a formal process carried out by a specialized testing team in which a software unit, several integrated software units or an entire software package are examined by running the programs on a computer.

All the associated tests are performed according to approved test procedures on approved test cases.

1. Testen zeigt die Anwesenheit von Fehlern

2. Vollständiges Testen ist nicht möglich

3. Mit dem Testen frühzeitig beginnen

4. Häufung von Fehlern

5. Tests müssen laufend überarbeitet und erweitert werden

6. Testen ist abhängig vom Umfeld

7. Trugschluss: Keine Fehler bedeutet ein brauchbares System

• Verifikation: Prüfen des Systems gegen Spezifikation

  („Erstellen wir das Produkt richtig“)

• Validierung: Prüfen des Systems gegen (Kunden-)Anforderungen

  („Erstellen wir das richtige Produkt“)

Testfälle identifizieren, mit denen die höchste Wahrscheinlichkeit

gegeben ist, festzustellen, ob das Softwaresystem korrekt funktioniert

-> hohe funktionale/ nicht funktionale Abdeckung

• Klasse/Komponente: Unit-Test, Komponententest

• Modul (mehrere Komponenten): Integrationstest

• Komplette Applikation: Systemtest

• Robustheit

• Struktur (z.B. Zweigüberdeckung)

• Umgang mit Ressourcen

• Isolation der Komponenten vom Rest des Systems

Die Schnittstellen und Interaktion zwischen Komponenten

• Big-Bang-Integration

• Horizontale Integration (Schicht für Schicht)

  • Top-Down-Integration

  • Bottom-Up-Integration

• Vertikale Integration (Integrationsschritt pro Funktionalität/Use-Case)

• Nicht-iterative Integrationsform

• Gleichzeitige Kombination aller Komponenten zu einem

  Gesamtsystem

Vorteile

• Keine Mocks

• Keine Testtreiber

Nachteile

• Erst spät im Projekt möglich

• Fehleridentifizierung und –lokalisierung schwierig

Vorteil

Externe Schnittstellen früh verfügbar

Nachteil

Hoher Simulationsaufwand (Mocks)

Vorteil

keine Mocks notwendig (dafür mehr Testtreiber, geringerer Aufwand)

Nachteil

Externe Schnittstellen spät verfügbar

• anhand von Szenarien/Use-Cases

• mit den Komponenten, die für die zu testende Funktionalität notwendig sind

• über die Systemschichten hinweg

Vorteile

• früh verfügbar/abnehmbar

• lauffähiges, testbares Teilsystem (nach jeder Iteration von zB Scrum)

• geeignet für iterative Entwicklungsprozesse

Nachteile

• Alle Schichten müssen Funktionalität unterstützen

• Synchronisierung in der Entwicklung notwendig

• das spezifizierte Verhalten des Gesamtsystems

• Testumgebung äquivalent zu Produktivumgebung

• Abdeckung von funktionalen und nichtfunktionalen Anforderungen

• meist von Auftraggeber durchgeführt

• ob Auftragnehmer die vereinbarten Leistungen umgesetzt hat

• Anwender-AT: Prüft Benutzbarkeit für Anwender

• Betrieblicher AT: Backup-Mögl., Wiederherstellbarkeit, ...

• Regulatorischer/Vertraglicher AT: Gesetzes-, Standardkonformität

• Feldtest

Die funktionale Verifikation des Systems

• hohe Abdeckung (Coverage) des Systems

• die mit hoher Wahrscheinlichkeit Fehler findet

• mittels ausgewählter Testfälle

Strukturelle Abdeckung (White-Box-Tests)

• Testfälle aus innerer Struktur des Systems ableiten

• Analyse des Kontrollflussgraphs (Quellcode)

Funktionale Abdeckung (Black-Box-Tests)

• Testfälle aus Spezifikation ableiten (Schnittstellen)

Äquivalenzklassen Analyse

• Einteilung der möglichen Eingabewerte in Äquivalenzklassen mit

  gleichem erwartbaren Systemverhalten

• Tests durchführen für einen Repräsentanten pro Klasse

Grenztwert Analyse

• Spezialfall von Äquivalenzklassenanalyse

• Fehler treten häufig an den Grenzen der Äquivalenzklassen auf

Äquivalenzklassen:

• Betrag kleiner 0 Cent

• Betrag von 0 bis 99 Cent

• Betrag größer 99 Cent

Testfälle:

• -1

• 0

• 1

• 99

• 100

• Äquivalenzklassen Analyse

• Zustandsbasierte Testmethoden

• Klassifikationsbaum Methode

• Informelle Testmethoden

• Testfälle aus Zustandsautomat (z.B. UML-Diagramm) abgeleitet

• Alle Zustände und alle Zustandsübergänge durchlaufen

• Alle Auslöser von Zustandsübergängen durchführen

• Einteilung der Testfälle in Klassifikationen (test-relevante Aspekte)

• Jede Klassifikation in Äquivalenzklassen zerlegen

• Testfall ist Kombination aus Klassen, eine Klasse pro Klassifikation

Keine oder nur teilweise systematische Ableitung von Testfällen

• Benutzbarkeit (Usability)

• Leistungsfähigkeit (Performance)

• Sicherheit (Security)

• Initialaufwand von Automatisierung wesentlich höher als bei manuellen Tests

• Testdurchführung von Automatisierung deutlich kürzer als bei manuellen Tests

• Hoher Wartungsaufwand bei Automatisierung

• Simulation des Benutzers

• Capture/Replay-Verfahren

• Wartung hoch

• Verfügbarkeit des Testobjekts

• Scripting

• Hybride Ansätze

Ob die Systemfunktionalität nach Änderungen noch gewährleistet ist

z.B.: Änderungen an Quellcode oder Konfiguration, Tausch einer Komponente, ...

• Anwendergerechte Dokumentation

  • Benutzerhandbuch

  • Online-Hilfe

• Schulungen

  • Meist mehrere Benutzergruppen

• Rollout

  • Parallelbetrieb

  • Testbetrieb mit kleinen Benutzergruppe bereits während Entwicklung

• Zusammenarbeit zwischen Entwicklern und Betrieb

• Verantwortlichkeiten festlegen

• Frühzeitiges Testrollout

• Manuelle Installation der Software

• Installation erst nach Abschluss der Entwicklung

• Manuelle Konfiguration

• Änderungen direkt in Betriebsumgebung („Hot Fixes“)

• Fehlerbehebung

• Verbesserung gewisser Eigenschaften der Software (z.B. Performance)

• Anpassung an eine geänderte Umgebung

• Gefundene Fehler

• Performance-Verbesserungen

• Updaten von verwendeten Frameworks und Bibliotheken

• Behebung von Sicherheitslücken

• Optimierung der Konfiguration

• Korrektive Wartung

  Ausbessern von aufgetretenem Fehler

• Präventive Wartung

  Ausbessern von Fehler, bevor dieser auftritt

• Adaptive Wartung

  • Anpassung an eine geänderte Umgebung

  • Investitionsschutz

• Perfektionierende Wartung

  Verbesserung des Systems, z.B. Performance, Usability,

  Speicherverbrauch, ...

• Reengineering

• Refaktorisierung

• Eliminieren von Anti Patterns

Eine Neuentwicklung eines (funktionierenden) Systemteils bei

gleichbleibender Funktionalität

Ziel:

Qualitätssteigerung, Vorbereitung für Weiterentwicklung

Eine Umstrukturierung bei gleichbleibender Funktionalität

Ziel:

Erhaltung/ Erhöhung der Wartbarkeit

Erkennen und Entfernen von schlechten Softwareteilen