# Softwaretests: von Unit-Test bis Abnahme

> Softwaretests prüfen, ob ein Programm das tut, was es soll. Man unterscheidet Teststufen vom Modul- über den Integrations- und Systemtest bis zum Abnahmetest durch den Kunden. Beim Vorgehen trennt man Black-Box-Tests, die nur Eingabe und Ausgabe betrachten, von White-Box-Tests, die den inneren Code berücksichtigen. Je früher ein Fehler gefunden wird, desto billiger ist seine Behebung.

**Autor:** Mr. Benjamin · **Beruf:** IT-Grundlagen
**Veröffentlicht:** 2026-07-25 · **Aktualisiert:** 2026-07-25
**Quelle:** https://yellowbluetech.de/blog/softwaretests-grundlagen

---

„Läuft bei mir" ist kein Qualitätsnachweis. Software, die in Produktion Fehler zeigt, kostet Geld, Vertrauen und Nerven – und je später ein Fehler auffällt, desto teurer wird er. Deshalb ist Testen kein lästiger Anhang der Entwicklung, sondern ein eigener, planbarer Teil davon.

## Warum wird getestet?

Testen soll Fehler finden, **bevor der Kunde sie findet**. Ein wichtiger Grundsatz dahinter:

> **Merksatz**
>
> Testen kann die **Anwesenheit** von Fehlern zeigen, nie ihre **Abwesenheit** beweisen. Ein bestandener Test heißt „hier kein Fehler gefunden", nicht „fehlerfrei". Ziel ist deshalb, mit begrenztem Aufwand die **wichtigsten** Fehler zu finden.

Dazu kommt die **Zehnerregel**: Die Kosten, einen Fehler zu beheben, steigen mit jeder Phase, in der er unentdeckt bleibt, ungefähr um das Zehnfache. Ein Fehler im Konzept ist billig, derselbe Fehler beim Kunden ist teuer.

## Die Teststufen

Getestet wird von klein nach groß – das entspricht der rechten Seite des [V-Modells](/blog/lastenheft-pflichtenheft):

| Stufe | Was wird geprüft | Beispiel |
| --- | --- | --- |
| **Modultest** (Unit) | einzelne Funktion isoliert | Rechnet `berechneRabatt()` korrekt? |
| **Integrationstest** | Zusammenspiel der Module | Passen Warenkorb und Rabatt zusammen? |
| **Systemtest** | das Gesamtsystem | Funktioniert der ganze Bestellablauf? |
| **Abnahmetest** | Kunde prüft gegen Anforderung | Erfüllt es das Pflichtenheft? |

## Black-Box gegen White-Box

Zwei grundsätzliche Sichtweisen auf einen Test:

> **Merksatz**
>
> **Black-Box-Test**: Der Tester kennt den Code **nicht**, prüft nur, ob zu einer Eingabe die richtige Ausgabe kommt. **White-Box-Test**: Der Tester kennt den Code und legt die Testfälle so, dass **alle Zweige und Pfade** durchlaufen werden.

## Der wichtigste Trick: Grenzwerte

> **Prüfungstipp**
>
> Für Black-Box-Tests werden zwei Verfahren gern geprüft. Die **Äquivalenzklassenbildung** teilt alle Eingaben in Gruppen, die gleich behandelt werden – aus jeder Gruppe genügt ein Testfall. Die **Grenzwertanalyse** testet gezielt die **Ränder** dieser [Klassen](/blog/oop-grundlagen), weil dort die meisten Fehler stecken. Beispiel „Alter ab 18": Prüfe 17, 18 und 19 – nicht 5 und 40. Nenne bei Testaufgaben immer auch einen **ungültigen** Wert.

## Automatisieren, was sich wiederholt

> **Hinweis**
>
> Modultests schreibt man als Code, der bei jeder Änderung automatisch mitläuft – so bemerkt man sofort, wenn eine Anpassung anderswo etwas kaputt macht (eine **Regression**). Das ist die Grundlage moderner Entwicklung: Bei jedem Commit läuft die Testsuite. Manuelles Durchklicken bleibt für das nötig, was sich schwer automatisieren lässt, etwa das Aussehen der Oberfläche oder die Abnahme durch den Kunden. Wie solche automatischen Läufe in den Ablauf eingebettet werden, hängt eng mit der [Versionsverwaltung](/blog/git-versionsverwaltung) zusammen.

## Selbstkontrolle

**Frage:** Eine Eingabemaske akzeptiert ein Alter ab 18 Jahren. Welche Testwerte sind nach der Grenzwertanalyse am sinnvollsten?

- [ ] 5, 40 und 99
- [x] 17, 18 und 19
- [ ] Nur 18
- [ ] 0 und 100

**Erklärung:** Die Grenzwertanalyse prüft die Ränder der Äquivalenzklassen, weil dort die meisten Fehler auftreten. Bei der Grenze 18 sind das die Werte direkt an der Grenze: 17 (unzulässig), 18 (gerade zulässig) und 19 (zulässig). Weit entfernte Werte wie 5 oder 40 bringen kaum zusätzliche Sicherheit.

## Häufige Fragen

### Was ist der Unterschied zwischen Verifikation und Validierung?

Verifikation fragt: Haben wir das Produkt richtig gebaut, also entspricht es der Spezifikation? Validierung fragt: Haben wir das richtige Produkt gebaut, also erfüllt es den tatsächlichen Bedarf des Kunden? Ein Programm kann fehlerfrei die Spezifikation erfüllen und trotzdem am Bedarf vorbeigehen – dann ist es verifiziert, aber nicht validiert.

### Was ist eine Regression?

Ein Fehler, der in einer Funktion auftaucht, die vorher nachweislich lief, ausgelöst durch eine Änderung an anderer Stelle. Regressionstests sind Tests, die man nach jeder Änderung erneut laufen lässt, um genau das zu bemerken. Deshalb lohnt es sich, sie zu automatisieren.

### Wer führt den Abnahmetest durch?

Der Kunde oder Auftraggeber, nicht das Entwicklungsteam. Geprüft wird gegen die vereinbarten Anforderungen aus dem Pflichtenheft. Erst wenn der Abnahmetest bestanden ist, gilt die Leistung als erbracht – deshalb ist er auch rechtlich und für die Abrechnung bedeutsam.

### Muss man 100 Prozent des Codes testen?

Vollständige Testabdeckung ist bei realer Software weder erreichbar noch wirtschaftlich, weil die Zahl möglicher Eingabekombinationen praktisch unbegrenzt ist. Ziel ist eine sinnvolle Abdeckung der wichtigen und riskanten Teile. Kennzahlen wie die Zweigüberdeckung helfen einzuschätzen, wie gründlich getestet wurde, ohne Vollständigkeit vorzutäuschen.

**Weiterlesen:** [Fehlerbehandlung mit Exceptions](/blog/fehlerbehandlung-exceptions) · [UML-Grundlagen: Klassendiagramm und Use Cases](/blog/uml-diagramme-grundlagen) · [Wasserfall vs. Scrum: Unterschied erklärt](/blog/wasserfall-vs-scrum)

## Das Wichtigste in Kürze

- Testen zeigt die **Anwesenheit** von Fehlern, beweist nie Fehlerfreiheit.
- **Zehnerregel**: Je später ein Fehler gefunden wird, desto teurer.
- Teststufen: **Modul → Integration → System → Abnahme**.
- **Black-Box** prüft Ein-/Ausgabe, **White-Box** kennt den Code und dessen Pfade.
- **Grenzwertanalyse**: an den Rändern testen – dort stecken die meisten Fehler.