Testen allgemein: Unterschied zwischen den Versionen

Aus FI-Wiki
Zeile 15: Zeile 15:
* '''Strukturelle Tests''' – prüft interne Abläufe
* '''Strukturelle Tests''' – prüft interne Abläufe


[[Datei:Testen ueberblick.png|rahmenlos|links|alternativtext=Testen ueberblick|Testen ueberblick]]
[[Datei:Testen ueberblick.png|rahmenlos|links|upright=2|alternativtext=Testen ueberblick|Testen ueberblick]]
<br clear="all">
<br clear="all" />


== Testebenen ==
== Testebenen ==

Version vom 7. April 2026, 07:08 Uhr

Softwaretesten bezeichnet alle Maßnahmen, mit denen überprüft wird, ob ein Programm korrekt, zuverlässig und fehlerfrei funktioniert. Ziel ist es, Fehler früh zu finden, Risiken zu reduzieren und sicherzustellen, dass die Software die Anforderungen erfüllt.

Warum testen?

  • Fehler früh entdecken und beheben
  • Qualität und Zuverlässigkeit erhöhen
  • Anforderungen verifizieren
  • Risiken minimieren
  • Benutzerfreundlichkeit sicherstellen

Testarten

  • Statisches Testen – Prüfung ohne Ausführen des Codes (z. B. Code-Review)
  • Dynamisches Testen – Ausführen des Programms zur Fehlersuche
  • Funktionale Tests – prüft, ob Anforderungen erfüllt sind
  • Strukturelle Tests – prüft interne Abläufe
Testen ueberblick
Testen ueberblick


Testebenen

Beim Testen unterscheidet man verschiedene Ebenen, die aufeinander aufbauen:

Unit-Test (Modultest)

  • testet einzelne Methoden oder Klassen (kleinste Einheit)
  • isoliert von anderen Komponenten (z. B. mit Mocks/Stubs)
  • wird hauptsächlich von Entwicklern durchgeführt
  • meist automatisiert

Ziel: Fehler früh und lokal finden

Beispiel: Test einer Methode

FIRST-Prinzip für gute Unit-Tests

Gute Unit-Tests erfüllen häufig das FIRST-Prinzip:

  • F – Fast: Tests müssen schnell ausführbar sein
  • I – Independent: Tests dürfen sich nicht gegenseitig beeinflussen
  • R – Repeatable: Ergebnisse müssen reproduzierbar sein
  • S – Self-validating: Test bewertet sich selbst (z. B. assertEquals)
  • T – Timely: Tests werden früh (idealerweise vor dem Code) erstellt

Integrationstest

  • testet das Zusammenspiel mehrerer Module
  • Fokus auf Schnittstellen und Datenfluss
  • nutzt oft echte Komponenten (z. B. Datenbank)

Ziel: Fehler in der Zusammenarbeit erkennen

Beispiel: Service greift auf Datenbank zu und verarbeitet Daten korrekt

Systemtest

  • testet das gesamte System als Einheit
  • erfolgt in einer realitätsnahen Umgebung
  • umfasst funktionale und nicht-funktionale Tests

Ziel: Überprüfung der vollständigen Anforderungen

Beispiel: Test einer kompletten Webanwendung inkl. Login, Datenverarbeitung und Anzeige

Abnahmetest (Acceptance Test)

  • wird vom Kunden oder Auftraggeber durchgeführt
  • basiert auf Anforderungen (Lasten-/Pflichtenheft)
  • entscheidet über Freigabe der Software

Ziel: Nachweis, dass die Software den Anforderungen entspricht

Beispiel: Kunde prüft, ob alle vereinbarten Funktionen umgesetzt wurden

Zusammenhang der Testebenen

  • Unit-Test → einzelne Bausteine
  • Integrationstest → Zusammenspiel
  • Systemtest → Gesamtsystem
  • Abnahmetest → Kundensicht

Vom kleinen zum großen Test: Erst einzelne Funktionen, dann Zusammenspiel, dann das Gesamtsystem und zuletzt die Abnahme durch den Kunden.

Ziele des Testens

  • Fehler finden, bevor sie beim Nutzer auftreten
  • Vertrauen in die Software schaffen
  • Stabilität und Wartbarkeit erhöhen
  • reibungslose Weiterentwicklung ermöglichen

Kurzmerksatz

Testebenen bauen aufeinander auf: vom einzelnen Code (Unit-Test) bis zur Abnahme durch den Kunden (Abnahmetest).