Testen allgemein: Unterschied zwischen den Versionen
| (9 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
'''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? == | |||
* 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 == | |||
* '''[[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 | ||
* ''' | |||
[[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 == | |||
* 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 == | |||
''' | '''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

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