Skip to main content
In der Softwareentwicklung werden Testaktivitäten in verschiedene Teststufen unterteilt, die jeweils unterschiedliche Ziele verfolgen und auf verschiedenen Ebenen der Systemarchitektur ansetzen.

​
Komponententests

Dies ist die niedrigste Teststufe, in der die elementaren Bausteine der Software (Module, Units, Klassen) isoliert geprüft werden. Ziel ist es, die Funktionalität gemäss der Komponentenspezifikation sicherzustellen und Fehlerzustände im Code frühzeitig aufzudecken.
Es muss der Quellcode vorliegen. Da Komponenten meist nicht allein lauffähig sind, ist ein Testrahmen mit Treibern und Platzhaltern (Stubs) erforderlich. Oft kommen hier Frameworks wie JUnit zum Einsatz.
Er wird meist von den Entwicklern selbst durchgeführt (Entwicklertest) und konzentriert sich auf interne Aspekte, nicht auf das Zusammenspiel mit anderen Teilen.

​
Integrationstests

Hier wird das Zusammenspiel zwischen zwei oder mehreren bereits getesteten Komponenten oder (Teil-)Systemen geprüft. Der Fokus liegt auf der Aufdeckung von Fehlern in den Schnittstellen und der Kommunikation zwischen den Bausteinen.
Die zu integrierenden Teile sollten den Komponententest erfolgreich durchlaufen haben. Es wird eine Integrationsstrategie (z. B. Top-down oder Bottom-up) benötigt, um die Reihenfolge des Zusammenbaus festzulegen.
Man unterscheidet den Komponentenintegrationstest (interne Schnittstellen) vom Systemintegrationstest (Schnittstellen zu externen Systemen). Im Gegensatz zum Komponententest wird nicht die isolierte Logik, sondern die Wechselwirkung geprüft.

​
Strategien

Für die Durchführung von Integrationstests gibt es verschiedene Strategien, die festlegen, in welcher Reihenfolge Komponenten zusammengeführt und geprüft werden. Man unterscheidet grundlegend zwischen nicht-inkrementellen und inkrementellen Ansätzen.

​
„Big Bang“-Integration

Bei dieser Strategie werden alle oder eine grosse Anzahl von Komponenten gleichzeitig integriert und als Ganzes getestet.
Man wartet, bis alle Bauteile entwickelt sind, und wirft sie dann „auf einmal“ zusammen.
Es werden theoretisch keine Testtreiber oder Platzhalter benötigt.
Fehler sind extrem schwer zu lokalisieren, da viele Komponenten gleichzeitig interagieren. Die Wartezeit bis zum Testbeginn ist verlorene Zeit, und Fehler treten geballt auf, was das System oft kaum lauffähig macht.

​
Top-Down-Integration

Der Test beginnt bei den obersten Komponenten (z.B. der Benutzeroberfläche), die andere aufrufen.
Es entsteht früh ein Simulationsmodell, das dem Benutzer bereits Teile der Funktionen zeigt.
Untergeordnete Komponenten müssen durch aufwendige Platzhalter (Stubs) simuliert werden.

​
Bottom-Up-Integration

Man beginnt mit den elementaren Basiskomponenten der untersten Schicht.
Keine Platzhalter erforderlich; das Zusammenwirken mit der Hardware wird früh geprüft.
Erfordert Testtreiber für die oberen Schichten; ein lauffähiges Gesamtsystem ist erst am Ende verfügbar.

​
Backbone-Integration

Es wird ein Programmskelett („Backbone“) erstellt, in das die Komponenten schrittweise eingehängt werden. Eine moderne Form hiervon ist die Continuous Integration (CI), bei der Codeänderungen mindestens täglich in einen vorhandenen Build integriert werden.

​
Ad-hoc-Integration

Die Komponenten werden einfach in der Reihenfolge ihrer Fertigstellung integriert. Dies spart Zeit, erfordert aber sowohl Platzhalter als auch Testtreiber.

​
Geschäftsprozessorientiert

Es werden gezielt die Komponenten zusammengeführt, die einen spezifischen Geschäftsprozess (z.B. eine Bestellung von der Eingabe bis zur Bezahlung) abbilden.

​
Funktionsorientiert

Integration basierend auf funktionalen Testfällen, wobei die dafür benötigten Komponenten schrittweise „zusammenmontiert“ werden.

​
Hardest First

Diese Strategie priorisiert die Integration der kritischsten oder komplexesten Komponenten zuerst.

​
Systemtests

Diese Stufe prüft das integrierte Gesamtsystem gegen die ursprünglichen Spezifikationen und Anforderungen. Das Ziel ist die Validierung, ob das Produkt aus Sicht des Kunden und Anwenders die funktionalen und nicht funktionalen Anforderungen (wie Performanz oder Sicherheit) erfüllt.
Das System muss vollständig integriert sein. Erforderlich ist eine separate Testumgebung, die der späteren Produktivumgebung so nahe wie möglich kommt, um Verfälschungen und Risiken für echte Daten zu vermeiden.
Während die unteren Stufen eher die technische Korrektheit prüfen (Verifizierung), steht beim Systemtest die Eignung für den Geschäftszweck im Vordergrund (Validierung).

​
Abnahmetests

Dies ist die letzte Validierungsstufe vor der Inbetriebnahme. Hier entscheidet der Kunde oder Anwender auf Basis von Abnahmekriterien, ob das System vertraglich als mangelfrei gilt und für den Betrieb übernommen wird.
Ein weitgehend stabiler Stand aus dem Systemtest ist die Regel. Der Test findet oft in der Umgebung des Kunden statt.
Im Fokus steht nicht das Finden neuer Fehlerzustände, sondern der Aufbau von Vertrauen in das System und die formale Bestätigung der Gebrauchstauglichkeit.

​
Strategien

Es gibt verschiedene Strategien und Formen des Abnahmetest, die darauf abzielen, das Vertrauen in das System zu stärken und eine fundierte Entscheidung über dessen Übernahme zu ermöglichen. Dabei wird geprüft, ob das System die Benutzeranforderungen, Geschäftsprozesse und vertraglich vereinbarten Kriterien erfüllt.

​
Benutzerabnahmetest

Diese Form konzentriert sich darauf, ob das System für die vorgesehenen Benutzer in deren Arbeitsumfeld geeignet ist.
Überprüfung der funktionalen Eignung, der Geschäftsprozesse sowie der Gebrauchstauglichkeit (Usability)
Sicherstellen, dass die Benutzer ihre Aufgaben effektiv, effizient und zufriedenstellend erledigen können.

​
Betrieblicher Abnahmetest

Hierbei stehen die administrativen und betrieblichen Aspekte des Systems im Vordergrund, die meist durch Systemadministratoren oder Betreiber geprüft werden.
Tests zur Datensicherung und Wiederherstellung, Installation, Konfiguration, Benutzerverwaltung sowie Überprüfung der Sicherheitsmassnahmen.
Sicherstellung, dass das System stabil in die vorhandene IT-Infrastruktur integriert werden kann und betriebsbereit bleibt.

​
Vertraglicher Abnahmetest

Prüft die Erfüllung der im Entwicklungsvertrag festgeschriebenen Abnahmekriterien bei Individualsoftware.

​
Regulatorischer Abnahmetest

Verifiziert, ob das System zu relevanten Gesetzen, Normen oder Sicherheitsvorschriften konform ist (z. B. Datenschutz oder branchenspezifische Standards).

​
Feldtests

Diese Strategien werden vor allem für Software auf dem breiten Markt (Standardsoftware) eingesetzt, um Feedback aus realen Nutzungsszenarien zu erhalten.
Findet in einer Simulations- oder Nutzungsumgebung direkt beim Hersteller statt, wird jedoch oft von Personen ausserhalb der Entwicklung durchgeführt.
Das System wird ausgewählten „Pilot“-Kunden in deren eigener realer Umgebung zur Verfügung gestellt, um unvorhergesehene Probleme vor der endgültigen Markteinführung aufzudecken.
Die Teststufen bauen logisch aufeinander auf: Fehler sollen idealerweise auf der Stufe gefunden werden, auf der sie entstanden sind. Ein wesentlicher Zusammenhang wird durch die Testpyramide verdeutlicht: Sie empfiehlt eine grosse Anzahl schneller, automatisierter Komponententests an der Basis und eine geringere Anzahl komplexer System- und Abnahmetests an der Spitze. In agilen Projekten verschwimmen die zeitlichen Grenzen oft, da alle Teststufen innerhalb einer Iteration (Sprint) parallel oder in enger Folge durchlaufen werden, um kontinuierlich ein potenziell auslieferbares Produktinkrement zu erzeugen.