Ein Softwaretest prüft und bewertet Software auf Erfüllung der für ihren Einsatz definierten Anforderungen und misst ihre Qualität. Die gewonnenen Erkenntnisse werden zur Erkennung und Behebung von Softwarefehlern genutzt. Tests während der Softwareentwicklung dienen dazu, die Software möglichst fehlerfrei in Betrieb zu nehmen.
Diese für eine einzelne Testmaßnahme verwendete Bezeichnung wird auch – im Sinn von „Testprozess“ – für mehrere oder die Gesamtheit von Maßnahmen zur Überprüfung der Softwarequalität (inkl. Planung, Vorbereitung, Steuerung, Durchführung, Dokumentation usw.) verwendet; siehe auch Definitionen.
Den Nachweis, dass keine Fehler (mehr) vorhanden sind, kann das Softwaretesten nicht erbringen. Es kann lediglich fallibilistisch feststellen, dass bestimmte Testfälle erfolgreich waren. Edsger W. Dijkstra schrieb hierzu: „Program testing can be used to show the presence of bugs, but never to show their absence!“ (Das Testen von Programmen kann die Existenz von Fehlern zeigen, aber niemals deren Nichtvorhandensein). Der Grund ist, dass alle Programmfunktionen und auch alle möglichen Werte in den Eingabedaten in allen ihren Kombinationen getestet werden müssten – was (außer bei sehr einfachen Testobjekten) praktisch nicht möglich ist. Aus diesem Grund beschäftigen sich verschiedene Teststrategien und -konzepte mit der Frage, wie mit einer möglichst geringen Anzahl von Testfällen eine große Testabdeckung zu erreichen ist.
Pol, Koomen, Spillner erläutern 'Testen' wie folgt: „Tests sind nicht die einzige Maßnahme im Qualitätsmanagement der Softwareentwicklung, aber oft die letztmögliche. Je später Fehler entdeckt werden, desto aufwändiger ist ihre Behebung, woraus sich der Umkehrschluss ableitet: Qualität muss (im ganzen Projektverlauf) implementiert und kann nicht 'eingetestet' werden.“ Und: „Beim Testen in der Softwareentwicklung wird i. d. R. eine mehr oder minder große Fehleranzahl als 'normal' unterstellt oder akzeptiert. Hier herrscht ein erheblicher Unterschied zur Industrie: Dort werden im Prozessabschnitt 'Qualitätskontrolle' oft nur noch in Extremsituationen Fehler erwartet.“
Definition Es gibt unterschiedliche Definitionen für den Softwaretest:
Nach ANSI/IEEE Std. 610.12-1990 ist das Testen (engl. ‚Testing‘) „the process of operating a system or component under specified conditions, observing or recording the results and making an evaluation of some aspects of the system or component.“
Eine andere Definition liefert Ernst DenertErnst Denert: Software-Engineering. Methodische Projektabwicklung. Springer, Berlin u. a. 1991, ISBN 3-540-53404-0., wonach der „Test […] der überprüfbare und jederzeit wiederholbare Nachweis der Korrektheit eines Softwarebausteines relativ zu vorher festgelegten Anforderungen“ ist.
Eine weitergehende Definition verwenden Pol, Koomen und SpillnerMartin Pol, Tim Koomen, Andreas Spillner: Management und Optimierung des Testprozesses. Ein praktischer Leitfaden für erfolgreiches Testen von Software mit TPI und TMap. 2., aktualisierte Auflage. dpunkt.Verlag, Heidelberg 2002, ISBN 3-89864-156-2.: Unter Testen versteht man den Prozess des Planens, der Vorbereitung und der Messung, mit dem Ziel, die Eigenschaften eines IT-Systems festzustellen und den Unterschied zwischen dem tatsächlichen und dem erforderlichen Zustand aufzuzeigen. Bemerkenswert hierbei: Als Messgröße gilt 'der erforderliche Zustand', nicht nur die (möglicherweise fehlerhafte) Spezifikation.
'Testen' ist ein wesentlicher Teil im Qualitätsmanagement von Projekten der Softwareentwicklung.
Standardisierung Im September 2013 wurde die Norm ISO/IEC/IEEE 29119 Software Testing veröffentlicht, die international erstmals viele (ältere) nationale Normen des Softwaretestens, wie z. B. die IEEE 829, zusammenfasst und ersetzt. Die Normreihe ISO/IEC 25000 ergänzt die Seite des Software-Engineering als Leitfaden für (die gemeinsamen) Qualitätskriterien und ersetzt die Norm ISO/IEC 9126.
Motivation Jedes Softwaresystem von genügender Komplexität weist Fehler auf. Diesen können neben vielen anderen Fehlergründen zum Beispiel nicht bedachte Ausnahmesituationen oder nicht berücksichtigte Randbedingungen zugrunde liegen.
In der Softwareentwicklung wird der Test verwendet, um den Verlust von Geld, Zeit, Menschenleben oder anderen materiellen oder immateriellen Gütern, die durch mangelhafte Qualität eines Softwaresystems verursacht werden, zu minimieren. Durch das systematische Testen einer Software während der Entwicklung können Fehler früh festgestellt werden, was deren Fehlerkosten nach der Rule of ten minimiert.
Ziele Globales Ziel des Softwaretestens ist das Messen der Qualität des Softwaresystems. Dabei dienen definierte Anforderungen als Prüfreferenz, mittels derer ggf. vorhandene Fehler aufgedeckt werden. ISTQB: Der Wirkung von Fehlern (im produktiven Betrieb) wird damit vorgebeugt.
Ein Rahmen für diese Anforderungen können die Qualitätsparameter gem. ISO/IEC 9126 sein, denen jeweils konkrete Detailanforderungen z. B. zur Funktionalität, Bedienbarkeit, Sicherheit usw. zugeordnet werden können. Im Besonderen ist auch die Erfüllung gesetzlicher und/oder vertraglicher Vorgaben nachzuweisen.
Die Testergebnisse (die über verschiedene Testverfahren gewonnen werden) tragen zur Beurteilung der realen Qualität der Software bei – als Voraussetzung für deren Freigabe zum operativen Betrieb. Das Testen soll Vertrauen in die Qualität der Software schaffen.
Individuelle Testziele: Da das Softwaretesten aus zahlreichen Einzelmaßnahmen besteht, die i. d. R. über mehrere Teststufen hinweg und an vielen Testobjekten ausgeführt werden, ergeben sich individuelle Testziele für jeden einzelnen Testfall und für jede Teststufe – wie z. B. Rechenfunktion X in Programm Y getestet, Schnittstellentest erfolgreich, Wiederinbetriebnahme getestet, Lasttest erfolgreich, Programm XYZ getestet usw.
Teststufen miniatur|hochkant=2|Stufen des V-Modells Die Einordnung der Teststufen (zum Teil auch Testzyklen genannt) folgt gemäß V-Modell dem Entwicklungsstand des Systems. Ihr Inhalt orientiert sich dabei an den Entwicklungsstufen von Projekten. Dabei wird in jeder Teststufe (rechte Seite im 'V') gegen die Systementwürfe und Spezifikationen der zugehörigen Entwicklungsstufe (linke Seite) getestet, d. h., die Testziele und Testfälle basieren auf den jeweiligen Entwicklungsergebnissen. Dieses Vorgehensprinzip ist allerdings nur anwendbar, wenn evtl. in späteren Entwicklungsstufen vorgenommene Änderungen in den älteren Spezifikationen nachgeführt wurden.
In der Realität werden diese Ausprägungen, abhängig von der Größe und Komplexität des Software-Produkts, weiter untergliedert. So könnten beispielsweise die Tests für die Entwicklung von sicherheitsrelevanten Systemen in der Transportsicherungstechnik folgendermaßen untergliedert sein: Komponententest auf dem Entwicklungsrechner, Komponententest auf der Ziel-Hardware, Produkt-Integrationstests, Produkttest, Produkt-Validierungstests, System-Integrationstest, Systemtest, System-Validierungstests, Feldtests und Akzeptanztest.
Die nachfolgend beschriebenen Teststufen sind in der Praxis oft nicht scharf voneinander abgegrenzt, sondern können, abhängig von der Projektsituation, fließend oder über zusätzliche Zwischenstufen verlaufen. So könnte zum Beispiel die Abnahme des Systems auf der Grundlage von Testergebnissen (Reviews, Testprotokolle) von Systemtests erfolgen.
Komponententest Der Modultest, auch Komponententest oder Unittest genannt, ist ein Test auf der Ebene innerer, abgrenzbarer Einzelteile der Software wie beispielsweise Module, Unterprogramme, Units oder Klassen. Testziel dieser häufig durch den Softwareentwickler selbst durchgeführten Tests ist der Nachweis der technischen Lauffähigkeit und korrekter (Teil-)Ergebnisse. Mittels Unittests können im Schnitt 30 Prozent der Fehler erkannt werden; bei der Verwendung von testgetriebener Entwicklung 45 %. Auf Grund der Tatsache, dass Unittests die Fehler bereits während der Entwicklungsphase erkennen, sind die durch Unittests vermiedenen Fehlerkosten gemäß der Rule of 10 um ein Vielfaches höher als bei späteren Teststufen, was Unittests zur effizientesten Teststufe machen.
Integrationstest Der Integrationstest bzw. Interaktionstest testet die Zusammenarbeit voneinander abhängiger Komponenten. Der Testschwerpunkt liegt auf den Schnittstellen der beteiligten Komponenten und soll korrekte Ergebnisse über komplette Abläufe hinweg nachweisen. Mittels Integrationstests können im Schnitt 35 % der Fehler erkannt werden.
Systemtest Der Systemtest ist die Teststufe, bei der das gesamte System gegen die gesamten Anforderungen (funktionale und nicht-funktionale Anforderungen) getestet wird. Gewöhnlich findet der Test auf einer Testumgebung statt und wird mit Testdaten durchgeführt. Die Testumgebung soll die Produktivumgebung des Kunden simulieren, d. h. ihr möglichst ähnlich sein. In der Regel wird der Systemtest durch die realisierende Organisation durchgeführt. Mittels Systemtests können im Schnitt 40 % der Fehler erkannt werden.
Abnahmetest Ein Abnahmetest, Verfahrenstest, Akzeptanztest oder auch User Acceptance Test (UAT) ist das Testen der gelieferten Software durch den Kunden. Der erfolgreiche Abschluss dieser Teststufe ist meist Voraussetzung für die rechtswirksame Übernahme der Software und deren Bezahlung. Dieser Test kann unter Umständen (z. B. bei neuen Anwendungen) bereits auf der Produktionsumgebung mit Kopien aus Echtdaten durchgeführt werden.
Besonders für System- und Abnahmetests wird das Blackbox-Verfahren angewendet, d. h., der Test orientiert sich nicht am Code der Software, sondern nur am Verhalten der Software bei spezifizierten Vorgängen (Eingaben des Benutzers, Grenzwerte bei der Datenerfassung etc.).
Die Anzahl der Akzeptanztests sollte sich am Umfang der Software orientieren.
Testprozess / Testphasen Pol, Koomen und Spillner beschreiben im Kap. 8.1 ‚TMap‘ ein Vorgehen nach einem Phasenmodell. Sie nennen dieses Vorgehen Testprozess, bestehend aus den Testphasen Testvorbereitung, Testspezifikation, Testdurchführung und -Auswertung, Testabschluss. Parallel sieht der Testprozess die Rahmenfunktionen Planung & Verwaltung vor. Das Vorgehen sei generisch, d. h., es wird – jeweils nach Erfordernis – für unterschiedliche Ebenen angewendet, für das Gesamtprojekt, für jede Teststufe und letztlich je Testobjekt und Testfall.
Bei anderen Autoren oder Instituten finden sich zum Teil andere Gruppierungen und andere Bezeichnungen, die aber inhaltlich nahezu identisch sind. Z. B. wird bei ISTQB der Testprozess mit folgenden Hauptaktivitäten definiert:ISTQB , Deutschsprachige Ausgabe. Herausgegeben durch Austrian Testing Board, German Testing Board e. V. & Swiss Testing Board, Kap. 1.4 Testplanung und Steuerung, Testanalyse und Testentwurf, Testrealisierung und Testdurchführung, Bewertung von Endekriterien und Bericht, Abschluss der Testaktivitäten. Die einzelnen Aktivitäten und deren Reihenfolge, die (im Testprozess festgelegt) für die einzelnen Testobjekte auszuführen sind – ggf. mehrfach, z. B. bei Testwiederholung/Regressionstest – nennt ISTQB ‚Testzyklus‘.
Testaktivitäten werden (nach Pol, Koomen und Spillner) rollenspezifisch zu sog. Testfunktionen zusammengefasst: Testen, Testmanagement, Methodische Unterstützung, Technische Unterstützung, Funktionale Unterstützung, Verwaltung, Koordination und Beratung, Anwendungsintegrator, TAKT-Architekt und TAKT-Ingenieur (bei Einsatz von Testautomatisierung; TAKT = Testen, Automatisierung, Kenntnisse, Tools). Diese Funktionen (Rollen) haben Schwerpunkte in bestimmten Testphasen; sie können im Projekt selbst eingerichtet sein oder über spezialisierte Organisationseinheiten einbezogen werden.
Personenbezogen können u. a. die folgenden Rollen beim Testen unterschieden werden:
Testmanager (Führung)