Softwaretest

Kern und Zweck

Ein Softwaretest prüft und bewertet Software darauf, ob sie die für ihren Einsatz definierten Anforderungen erfüllt, und misst ihre Qualität. Die Ergebnisse dienen dazu, Softwarefehler zu erkennen und zu beheben. In der Softwareentwicklung sollen Tests helfen, Software möglichst fehlerfrei in Betrieb zu nehmen. Der Begriff kann eine einzelne Testmaßnahme meinen oder den gesamten Testprozess mit Planung, Vorbereitung, Steuerung, Durchführung und Dokumentation.

Softwaretesten kann nicht beweisen, dass keine Fehler mehr vorhanden sind. Es kann nur zeigen, dass bestimmte Testfälle erfolgreich waren oder dass Fehler vorhanden sind. Edsger W. Dijkstra formulierte dazu: „Program testing can be used to show the presence of bugs, but never to show their absence!“ Ein vollständiger Test wäre nur möglich, wenn alle Funktionen und alle möglichen Eingabewerte in allen Kombinationen geprüft würden; das ist außer bei sehr einfachen Testobjekten praktisch nicht machbar. Deshalb versuchen Teststrategien, mit möglichst wenigen Testfällen eine möglichst große Testabdeckung zu erreichen.

Nach ANSI/IEEE Std. 610.12-1990 ist 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.“ Ernst Denert beschreibt den Test als „überprüfbare[n] und jederzeit wiederholbare[n] Nachweis der Korrektheit eines Softwarebausteines relativ zu vorher festgelegten Anforderungen“. Pol, Koomen und Spillner verstehen Testen als Prozess des Planens, der Vorbereitung und der Messung, um Eigenschaften eines IT-Systems festzustellen und den Unterschied zwischen tatsächlichem und erforderlichem Zustand aufzuzeigen.

Motivation und Ziele

Die Motivation für Softwaretests lautet: „Kein umfangreiches System ist fehlerfrei.“ Komplexe Softwaresysteme enthalten Fehler, etwa durch nicht bedachte Ausnahmesituationen oder Randbedingungen. Tests sollen Schäden durch mangelhafte Softwarequalität verringern, zum Beispiel Verlust von Geld, Zeit, Menschenleben oder anderen materiellen und immateriellen Gütern. Werden Fehler früh gefunden, sinken nach der Rule of ten die Fehlerkosten.

Das globale Ziel des Softwaretestens ist das Messen der Qualität eines Softwaresystems. Definierte Anforderungen bilden die Prüfreferenz, an der mögliche Fehler erkannt werden. Nach ISTQB wird damit der Wirkung von Fehlern im produktiven Betrieb vorgebeugt. Anforderungen können sich an Qualitätsparametern nach ISO/IEC 9126 orientieren, etwa Funktionalität, Bedienbarkeit und Sicherheit; auch gesetzliche oder vertragliche Vorgaben können nachzuweisen sein.

Testergebnisse tragen zur Beurteilung der realen Qualität bei und sind eine Voraussetzung für die Freigabe zum operativen Betrieb. Testen soll Vertrauen in die Qualität der Software schaffen. Zusätzlich gibt es individuelle Testziele für einzelne Testfälle und Teststufen, etwa eine bestimmte Rechenfunktion zu testen, einen Schnittstellentest erfolgreich abzuschließen oder einen Lasttest zu bestehen.

Wichtige Standards sind ISO/IEC/IEEE 29119 Software Testing, veröffentlicht im September 2013, sowie ISO/IEC 25000 als Leitfaden für Qualitätskriterien. ISO/IEC 25000 ersetzt ISO/IEC 9126 auf der Seite der Qualitätskriterien.

Teststufen

Die Teststufen folgen häufig dem V-Modell. Dabei wird auf jeder Teststufe gegen die Systementwürfe und Spezifikationen der passenden Entwicklungsstufe getestet. Testziele und Testfälle beruhen also auf den jeweiligen Entwicklungsergebnissen. In der Praxis sind die Stufen nicht immer scharf getrennt; je nach Projekt können sie fließend ineinander übergehen oder zusätzliche Zwischenstufen enthalten.

Der Komponententest, auch Modultest oder Unittest genannt, prüft innere, abgrenzbare Einzelteile der Software wie Module, Unterprogramme, Units oder Klassen. Ziel ist der Nachweis der technischen Lauffähigkeit und korrekter Teilergebnisse. Er wird häufig von Entwicklern selbst durchgeführt. Mittels Unittests können im Schnitt 30 Prozent der Fehler erkannt werden, bei testgetriebener Entwicklung 45 %. Weil Fehler dabei schon während der Entwicklung gefunden werden, können nach der Rule of 10 besonders hohe spätere Fehlerkosten vermieden werden.

Der Integrationstest, auch Interaktionstest, prüft das Zusammenspiel voneinander abhängiger Komponenten. Schwerpunkt sind die Schnittstellen, also die Übergänge und Aufrufe zwischen Komponenten. Er soll korrekte Ergebnisse über vollständige Abläufe hinweg nachweisen. Mittels Integrationstests können im Schnitt 35 % der Fehler erkannt werden.

Der Systemtest prüft das gesamte System gegen alle funktionalen und nicht-funktionalen Anforderungen. Er findet gewöhnlich in einer Testumgebung mit Testdaten statt, die die Produktivumgebung des Kunden möglichst gut simulieren soll. Meist führt ihn die realisierende Organisation durch. Mittels Systemtests können im Schnitt 40 % der Fehler erkannt werden.

Der Abnahmetest, Verfahrenstest, Akzeptanztest oder User Acceptance Test (UAT) ist das Testen der gelieferten Software durch den Kunden. Sein erfolgreicher Abschluss ist oft Voraussetzung für die rechtswirksame Übernahme und Bezahlung. Besonders bei System- und Abnahmetests wird häufig das Blackbox-Verfahren genutzt: Der Test betrachtet nicht den Code, sondern nur das Verhalten der Software bei spezifizierten Vorgängen.

Testprozess

Pol, Koomen und Spillner beschreiben einen Testprozess nach TMap mit den Phasen Testvorbereitung, Testspezifikation, Testdurchführung und Testauswertung sowie Testabschluss. Parallel dazu laufen Planung und Verwaltung. Das Vorgehen ist generisch und kann für das Gesamtprojekt, einzelne Teststufen, Testobjekte und Testfälle angewendet werden. ISTQB nennt ähnliche Hauptaktivitäten: Testplanung und Steuerung, Testanalyse und Testentwurf, Testrealisierung und Testdurchführung, Bewertung von Endekriterien und Bericht sowie Abschluss der Testaktivitäten.

In der Testplanung entsteht der Testplan. Er definiert den Testprozess für ein Projekt und kann je Teststufe konkretisiert werden. Inhalte sind zum Beispiel Teststrategie, Testumfang, Testabdeckung, Risikoabschätzung, Testziele, Kriterien für Beginn, Ende und Abbruch, Testarten, Werkzeuge, Dokumentation, Testumgebung, Testdaten, Rollen, Termine, Ressourcen, Testmetriken und Problemmanagement.

Die Testvorbereitung stellt die geplanten Grundlagen bereit: Testbasis-Dokumente, Werkzeuge für Testfall- und Fehlermanagement, Testumgebungen, Testdaten, Testobjekte, Benutzer und Rechte. In der Testspezifikation wird festgelegt, wie ein konkreter Testfall auszuführen ist. Dazu gehören Testfallfindung, Vorbedingungen, Eingabedaten, Testablauf, Testreihenfolge, Soll-Ergebnis und Bedingungen dafür, dass ein Test als erfüllt gilt.

In der Testdurchführung wird bei dynamischen Tests das Programm ausgeführt; bei statischen Tests wird es analytisch geprüft. Dazu gehören Auswahl der Testfälle, Start des Prüflings, Bereitstellen der Testdaten und Archivieren von Umgebungsinformationen. Ein Testobjekt sollte möglichst nicht vom Entwickler selbst, sondern von anderen, möglichst unabhängigen Personen getestet werden.

In der Testauswertung werden Ist-Ergebnis und Soll-Ergebnis verglichen. Bei Fehlern folgen Klassifizierung, Fehlerbeschreibung und Übergabe ins Fehlermanagement; der Testfall bleibt offen. Bei erfolgreichem Ergebnis gilt der Testfall als erledigt. Beim Testabschluss werden Status, Entscheidungen und Unterlagen auf Ebene von Testfall, Testobjekt, Teststufe oder Projekt dokumentiert und archiviert.

Testarten und Prüftechniken

Es gibt viele Bezeichnungen für Testarten, weil Tests nach Situation, Ziel, Methode, Zeitpunkt, Testobjekt, Informationsstand und beteiligten Personen unterschieden werden können. Ein konkreter Test kann zugleich mehreren Kategorien angehören, zum Beispiel dynamischer Test, Blackbox-Test, Integrationstest, Regressionstest und Äquivalenzklassentest.

Nach der Prüftechnik unterscheidet man analytische Maßnahmen und konstruktive Maßnahmen. Analytische Maßnahmen prüfen ein bereits erstelltes Testobjekt. Dazu gehören statische Tests ohne Programmausführung, etwa Reviews und statische Code-Analyse, sowie dynamische Tests mit Programmausführung. Dynamische Tests können strukturorientiert sein, zum Beispiel Anweisungs-, Zweig-, Bedingungs- und Pfadüberdeckungstests, oder funktionsorientiert, also Tests gegen eine Spezifikation, etwa Äquivalenzklassenbildung, zustandsbasierte Tests, Ursache-Wirkung-Analyse und Entscheidungstabellentests. Konstruktive Maßnahmen sichern Qualität schon während der Erstellung, zum Beispiel Anforderungsmanagement, Prototyping und Review von Pflichtenheften.

Nach Art und Umfang der Testobjekte unterscheidet man unter anderem Debugging einzelner Codeteile, Komponenten- oder Unittests, Integrationstests, Systemtests, Schnittstellentests, Batch- und Dialogtests, Web-Tests und Hardwaretests. Nach Benutzersicht gibt es zum Beispiel Geschäftsprozesstests, End-to-End-Tests, Verhaltenstests, Featuretests, Fähigkeitstests, Akzeptanztests und Oberflächentests.

Nach softwaretechnischen Zusammenhängen werden unter anderem Datenkonsistenztests, Wiederinbetriebnahmetests, Installationstests, Stresstests, Crashtests, Lasttests, Performance Tests, Rechnernetz-Tests und Sicherheitstests unterschieden. Aus Software-Qualitätsmerkmalen ergeben sich funktionale Tests und nicht-funktionale Tests. Funktionale Tests prüfen, was die Software tut; nicht-funktionale Tests prüfen, wie sie arbeitet, etwa in Bezug auf Sicherheit, Gebrauchstauglichkeit oder Zuverlässigkeit.

Weitere wichtige Einteilungen betreffen den Zeitpunkt: Alpha-Test, Vorbereitungstest, Betatest, Produktionstest, Regressionstest und Retest. Nach Informationsstand unterscheidet man Black-Box-Tests ohne Wissen über den inneren Aufbau, White-Box-Tests mit Wissen über die interne Struktur und Grey-Box-Tests als Mischform oder mit partiellem Codewissen.

Strategie, Grundsätze und Automatisierung

Eine Teststrategie ist nötig, weil vollständiges Testen in der Praxis nicht durchführbar ist. In der Testplanung wird anhand einer Risikoabschätzung entschieden, welche Systemteile wie kritisch sind und wie intensiv sie mit den verfügbaren Ressourcen getestet werden. Festgelegt wird, welche Teile mit welcher Intensität, mit welchen Methoden, mit welcher Infrastruktur und in welcher Reihenfolge geprüft werden.

ISTQB nennt unter anderem top-down, bottom-up, hardest first und big-bang als Ausprägungen von Teststrategien. Weitere Prinzipien sind Risk based Testing, Data driven Testing, testgetriebene Entwicklung, SMART, Keyword driven testing, framework based Testing und Testing nach ISO/IEC 25000. Bei risikobasiertem Testen nach der RPI-Methode werden Anforderungen gruppiert und nach Kriterien wie Businessrelevanz, Auffindbarkeit und Komplexität bewertet. Die Anforderungen erhalten Werte von 1 bis 3, wobei 3 den höchsten Wert darstellt; aus dem Produkt der Kriterien ergibt sich die Wichtigkeit.

ISO 25000 definiert 8 Dimensionen für Software-Qualitätsmerkmale: Funktionale Eignung, Zuverlässigkeit, Benutzbarkeit, Leistungseffizienz, Wartbarkeit, Anpassbarkeit, Sicherheit und Kompatibilität. Eine Teststrategie kann auf diese Merkmale ausgerichtet werden und durch passende Testfälle prüfen, ob die Software die relevanten Kriterien einhält oder unterstützt.

Die Sieben Grundsätze des Testens nach ISTQB CTFL Syllabus lauten sinngemäß: Testen zeigt die Anwesenheit von Fehlerzuständen, nicht deren Abwesenheit; vollständiges Testen ist nicht möglich; frühes Testen, auch Shift left, spart Zeit und Geld; Fehlerzustände treten gehäuft auf; Tests nutzen sich ab und müssen überprüft und ergänzt werden; Testen ist kontextabhängig; und „Keine Fehler bedeutet ein brauchbares System“ ist ein Trugschluss, weil auch ein fehlerarm getestetes System schwer nutzbar sein oder Nutzerbedürfnisse verfehlen kann.

Zur Dokumentation empfiehlt IEEE 829 unter anderem Testplan, Testdesignspezifikation, Testfallspezifikationen, Testablaufspezifikationen, Testobjektübertragungsbericht, Testprotokoll, Testvorfallbericht und Testergebnisbericht. Testautomatisierung ist besonders bei häufig wiederholten Tests sinnvoll, vor allem bei Regressionstests und testgetriebener Entwicklung, außerdem bei manuell schwer durchführbaren Tests wie Lasttests.