Testen allgemein: Unterschied zwischen den Versionen

Aus FI-Wiki
 
(9 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== Testen allgemein ==
'''Softwaretesten''' bezeichnet alle Maßnahmen, mit denen überprüft wird, ob ein Programm korrekt, zuverlässig und fehlerfrei funktioniert.   
'''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.
Ziel ist es, Fehler früh zu finden, Risiken zu reduzieren und sicherzustellen, dass die Software die Anforderungen erfüllt.


=== Warum testen? ===
== Warum testen? ==
* Fehler früh entdecken und beheben   
* Fehler früh entdecken und beheben   
* Qualität und Zuverlässigkeit erhöhen   
* Qualität und Zuverlässigkeit erhöhen   
Zeile 11: Zeile 9:
* Benutzerfreundlichkeit sicherstellen   
* Benutzerfreundlichkeit sicherstellen   


=== Testarten ===
== Testarten ==
* '''[[Statisches Testen]]''' – Prüfung ohne Ausführen des Codes (z. B. Code-Review)   
* '''[[Statisches Testen]]''' – Prüfung ohne Ausführen des Codes (z. B. Code-Review)   
* '''[[Dynamisches Testen]]''' – Ausführen des Programms zur Fehlersuche   
* '''[[Dynamisches Testen]]''' – Ausführen des Programms zur Fehlersuche   
* '''Funktionale Tests''' – prüft, ob Anforderungen erfüllt sind   
* '''Funktionale Tests''' – prüft, ob Anforderungen erfüllt sind   
* '''Strukturelle Tests''' – prüft interne Abläufe  
* '''Strukturelle Tests''' – prüft interne Abläufe
* '''Testen auf verschiedenen Ebenen''' – Unit-, Integrations-, System- und Abnahmetest
 
 
[[Datei:Testen ueberblick.png|rahmenlos|links|upright=2|alternativtext=Testen ueberblick|Testen ueberblick]]
<br clear="all" />
 
== 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 ===
== Ziele des Testens ==
* Fehler finden, bevor sie beim Nutzer auftreten   
* Fehler finden, bevor sie beim Nutzer auftreten   
* Vertrauen in die Software schaffen   
* Vertrauen in die Software schaffen   
Zeile 24: Zeile 86:
* reibungslose Weiterentwicklung ermöglichen   
* reibungslose Weiterentwicklung ermöglichen   


=== Kurzmerksatz ===
== Kurzmerksatz ==
'''Testen stellt sicher, dass Software korrekt funktioniert, zuverlässig, sicher und wie gefordert.'''
'''Testebenen bauen aufeinander auf: vom einzelnen Code (Unit-Test) bis zur Abnahme durch den Kunden (Abnahmetest).'''

Aktuelle 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).