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.
Von diesem, eine einzelne Testmaßnahme bezeichnenden Begriff ist die gleich lautende Bezeichnung 'Test' (auch 'Testen') zu unterscheiden, unter der die Gesamtheit der Maßnahmen zur Überprüfung der Softwarequalität (inkl. Planung, Vorbereitung, Steuerung, Durchführung, Dokumentation usw.; siehe auch Definitionen) verstanden wird.
Den Nachweis, dass keine Fehler (mehr) vorhanden sind, kann das Softwaretesten nicht erbringen. Es kann lediglich feststellen, dass bestimmte Testfälle erfolgreich waren. E. W. Dijkstra schrieb hierzu: Program testing can be used to show the presence of bugs, but never 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 Kombination 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 [1] erläutern zu Testen: "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."
Es gibt unterschiedliche Definitionen für den Softwaretest:
Nach ANSI/IEEE Std. 610.12-1990 ist Test „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 Denert[2], 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 Spillner[1]: 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.
Globales Ziel des Softwaretestens ist das Messen der Qualität des Softwaresystems. Dabei werden definierte Anforderungen überprüft und dabei ggf. vorhandene Fehler aufgedeckt. 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 [1].
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.
Die Einordnung der Teststufen (auch Testzyklen genannt) folgt häufig dem Entwicklungsstand des Systems. Ihr Inhalt orientiert sich dabei an den Entwicklungsstufen von Projekten nach dem V-Modell. 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 Spezifikationen. 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.
Der Modultest, auch Komponententest oder Unittest genannt, ist ein Test auf der Ebene der einzelnen Module der Software. Testgegenstand ist die Funktionalität innerhalb einzelner abgrenzbarer Teile der Software (Module, Programme oder Unterprogramme, Units oder Klassen). Testziel dieser häufig durch den Softwareentwickler selbst durchgeführten Tests ist der Nachweis der technischen Lauffähigkeit und korrekter fachlicher (Teil-) Ergebnisse.
Der Integrationstest bzw. Interaktionstests 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.
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. In der Regel wird der Systemtest durch die realisierende Organisation durchgeführt.
Ein Abnahmetest, Verfahrenstest, Akzeptanztest oder auch User Acceptance Test (UAT) ist ein Test der gelieferten Software durch den Kunden bzw. Auftraggeber. Oft sind Akzeptanztests Voraussetzung für die Rechnungsstellung. Dieser Test kann bereits auf der Produktivumgebung mit Kopien aus Echtdaten durchgeführt werden.
Die vorgenannten 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.
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 Handlungen (Eingaben des Benutzers, Grenzwerte bei der Datenerfassung, etc.).
Pol, Koomen und Spillner [1] empfehlen ein Vorgehen nach dem in der Grafik dargestellten Phasenmodell. Sie nennen dieses Vorgehen Testprozess, die Einzelschritte Testphasen und unterscheiden dabei: Testplanung, Testvorbereitung, Testspezifikation, Testdurchführung, Testauswertung, Testabschluss
Dieses Vorgehen ist generisch, d.h. es wird - jeweils nach Erfordernis - für unterschiedliche Ebenen angewendet, nämlich für das Gesamtprojekt, für jede Teststufe und letztlich auch je Testobjekt und Testfall. Die in diesen Ebenen i. d. R. anfallende Arbeitsintensität ist in der Grafik durch Punkte (= gering), Striche (= mittel) und durchgehende Linien (= Schwerpunkt) dargestellt.
Testaktivitäten werden (nach Pol, Koomen und Spillner [1]) 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.
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 "fundamentale Testprozess" mit folgenden Hauptaktivitäten definiert: Testplanung und Steuerung, Testanalyse und Testdesign, Testrealisierung und Testdurchführung, Testauswertung und Bericht, Abschluss der Testaktivitäten
Ergebnis dieser i. d. R. parallel zur Softwareentwicklung stattfindenden Phase ist i. W. der Testplan. Er wird für jedes Projekt erarbeitet und soll den gesamten Testprozess definieren. In TMap wird dazu ausgeführt: Sowohl die zunehmende Bedeutung von IT-Systemen für Betriebsprozesse als auch die hohen Kosten des Testens rechtfertigen einen optimal verwaltbaren und strukturierten Testprozess. Der Plan kann und soll je Teststufe aktualisiert und konkretisiert werden, sodass die Einzeltests im Umfang zweckmäßig und effizient ausgeführt werden können.
Inhalte im Testplan sollten z. B. folgende Aspekte sein: Teststrategie (Testumfang, Testabdeckung, Risikoabschätzung); Testziele und Kriterien für Testbeginn, Testende und Testabbruch - für alle Teststufen; Vorgehensweise (Testarten); Hilfsmittel und Werkzeuge; Dokumentation (Festlegen der Art, Struktur, Detaillierungsgrad); Testumgebung (Beschreibung); Testdaten (allgemeine Festlegungen); Testorganisation (Termine, Rollen), alle Ressourcen, Ausbildungsbedarf; Testmetriken; Problemmanagement
Aufbauend auf der Testplanung werden die dort festgelegten Sachverhalte zur operativen Nutzung vorbereitet und zur Verfügung gestellt.
Beispiele für einzelne Aufgaben (global und je Teststufe): Bereitstellen der Dokumente der Testbasis; Verfügbar machen (z.B. Customizing) von Werkzeugen für das Testfall- und Fehlermanagement; Aufbauen der Testumgebung(en) (Systeme, Daten); Übernehmen der Testobjekte als Grundlage für Testfälle aus der Entwicklungsumgebung in die Testumgebung; Benutzer und Benutzerrechte anlegen; ... Beispiele für Vorbereitungen (für Einzeltests): Transfer / Bereitstellung von Testdaten bzw. Eingabedaten in die Testumgebung(en).
Hier werden alle Festlegungen und Vorbereitungen getroffen, die erforderlich sind, um einen bestimmten Testfall ausführen zu können.
Beispiele für einzelne Aktivitäten: Testfallfindung und Testfalloptimierung; Beschreiben je Testfall (was genau ist zu testen); Vorbedingungen (incl. Festlegen von Abhängigkeiten zu anderen Testfällen); Festlegen und Erstellen der Eingabedaten; Festlegungen zum Testablauf und zur Testreihenfolge; Festlegen Soll-Ergebnis; Bedingung(en) für 'Test erfüllt'; ...
Bei dynamischen Tests wird dazu das zu testende Programm ausgeführt, in statischen Tests ist es Gegenstand analytischer Prüfungen.
Beispiele für einzelne Aktivitäten: Auswählen der zu testenden Testfälle; Starten des Prüflings - manuell oder automatisch; Bereitstellen der Testdaten und des Ist-Ergebnisses zur Auswertung; Umgebungsinformationen für den Testlauf archivieren, ...
Weitere Anmerkung: Ein Testobjekt sollte nicht vom Entwickler selbst, sondern von anderen, wenn möglich unabhängigen, Personen getestet werden.
Die Ergebnisse aus durchgeführten Tests (je Testfall) werden überprüft. Dabei wird das Ist-Ergebnis mit dem Soll-Ergebnis verglichen und anschließend eine Entscheidung über das Testergebnis (ok oder Fehler) herbeigeführt.
Abschluss-Aktivitäten finden auf allen Testebenen statt: Testfall, Testobjekt, Teststufe, Projekt. Der Status zum Abschluss von Teststufen wird (z. B. mit Hilfe von Teststatistiken) dokumentiert und kommuniziert, Entscheidungen sind herbeizuführen und Unterlagen zu archivieren. Grundsätzlich ist dabei zu unterscheiden nach:
In kaum einer Disziplin der Softwareentwicklung hat sich, der Komplexität der Aufgabe 'Testen' entsprechend, eine derart große Vielfalt an Begriffen für Verfahrensansätze gebildet wie beim Softwaretest. Dies beginnt bereits bei den Typ-Ausprägungen für Testvarianten, die mit Begriffen wie Teststufe, Testzyklus, Testphase, Testart, Testtyp, Testmethode, Testverfahren ... bezeichnet werden.
Die Bezeichnung konkreter Testarten leitet sich meistens aus ihren individuellen Zielen und Charaktermerkmalen ab - wodurch sich eine Vielzahl an Bezeichnungen ergibt. Dieser Vieldimensionalität entsprechend können für einen konkreten Test die Bezeichnungen mehrerer Testarten zutreffen. Beispiel: Entwicklertest, dynamischer Test, Blackbox-Test, Fehlertest, Integrationstest, Äquivalenzklassentest, Batchtest, Regressionstest. Durchaus im Sinn effizienter Testprozesse ist es, mehrere Testfälle mit nur einem konkreten Test abzudecken, z. B. eine technische Datenschnittstelle, die Prüfung korrekter Wertebereiche und eine Rechenformel.
Die nachfolgend beschriebenen Testart-Bezeichnungen sind Beispiele aus der Literatur. Im praktischen Einsatz werden aber viele dieser Bezeichnungen nicht verwendet, sondern (zum Beispiel) einfach als 'Funktionstest' bezeichnet und nicht als Fehlertest, Batchtest, High-Level-Test etc. Die Testeffizienz wird hierdurch nicht beeinträchtigt - wenn die Tests ansonsten angemessen geplant und ausgeführt werden. Die nachfolgenden Aufzählungen können auch eine Vorstellung davon vermitteln, was beim Testen, vor allem in der Testplanung berücksichtigt werden sollte oder könnte.
Ein Mittel zum Verständnis dieser Begriffsvielfalt ist die nachfolgend angewendete Klassifikation - bei der Testarten nach unterschiedlichen Kriterien gegliedert werden.
Softwaretests werden oft als analytische Maßnahmen, die erst nach Erstellung des Prüfgegenstandes durchgeführt werden können, definiert. Liggesmeyer [3] klassifiziert diese Testmethoden folgendermaßen (verkürzt und z. T. kommentiert):
Statischer Test (Test ohne Programmausführung)
Dynamischer Test (Test während Programmausführung)
Diesen analytischen Maßnahmen, bei denen Testobjekte "geprüft" werden, gehen die sog. konstruktiven Maßnahmen voraus, die bereits im Verlauf der Software-Erstellung zur Qualitätssicherung betrieben werden. Beispiele: Anforderungsmanagement, Prototyping, Review von Pflichtenheften.
Weiterhin sind von den Prüftechniken die Spezifikationstechniken zu unterscheiden: Sie bezeichnen keine Testarten, mit denen Testobjekte aktiv geprüft werden, sondern nur die Verfahren, nach denen die Tests vorbereitet und spezifiziert werden.
Beispiele Äquivalenzklassentest und Überdeckungstest: Testfälle werden nach diesen Verfahren identifiziert und spezifiziert, konkret überprüft jedoch (z. B.) im Integrationstest, Batchtest, Sicherheitstest etc.
Die Einordnung erfolgt hier je nachdem welche inhaltlichen Aspekte getestet werden sollen.
Aus den Qualitätsmerkmalen gem. ISO/IEC 9126 (die für die meisten Testanforderungen den Rahmen bilden können) leitet sich eine große Anzahl von Testarten ab. Auf Grund ihrer Vielfalt werden nachfolgend nur wenige Beispiele genannt: Sicherheitstest, Funktionstest, Wiederanlauftest, GUI-Test, Fehlertest, Installationstest, Lasttest.
Zum Testen ausgewählte methodische Ansätze spiegeln sich ebenfalls in Testart-Bezeichnungen wider. Das sind z. B.:
Testart-Bezeichnungen leiten sich u. a. auch vom Zeitpunkt der Testdurchführung ab:
Auch nach der Testintensität werden einige Testarten speziell benannt:
Testarten werden auch danach bezeichnet, welcher Informationsstand über die zu testenden Komponenten vorhanden ist (auf dessen Basis Testfälle spezifiziert werden könnten):
Aus der Art und dem Umfang des Testobjekts ergeben sich die folgenden Testart-Bezeichnungen:
Testarten können auch danach benannt sein, wer die Tests ausführt oder spezifiziert:
Von eher untergeordneter Bedeutung sind Testbegriffe, die sich an der Art der Softwaremaßnahme orientieren, aus der der Testbedarf resultiert:
Pol, Koomen und Spillner beschreiben in [1] die Teststrategie als umfassenden Ansatz: Eine Teststrategie ist notwendig, da ein vollständiger Test, d. h. ein Test, der alle Teile des Systems mit allen möglichen Eingabewerten unter allen Vorbedingungen überprüft, in der Praxis nicht durchführbar ist. Deswegen muss in der Test-Planung anhand einer Risikoabschätzung festgelegt werden, wie kritisch das Auftreten eines Fehlers in einem Systemteil einzuschätzen ist (z.B. nur finanzieller Verlust oder Gefahr für Menschenleben) und wie intensiv (unter Berücksichtigung der verfügbaren Ressourcen und des Budgets) ein Systemteil getestet werden muss oder kann.
Demnach ist in der Teststrategie festzulegen, welche Teile des Systems mit welcher Intensität unter Anwendung welcher Testmethoden und -Techniken unter Nutzung welcher Test-Infrastruktur und in welcher Reihenfolge (siehe auch Teststufen) zu testen sind.
Sie wird vom Testmanagement im Rahmen der Testplanung erarbeitet, im Testplan dokumentiert und festgelegt und als Handlungsrahmen für das Testen (durch die Testteams) zu Grunde gelegt.
Nach einer anderen Interpretation wird "Teststrategie" als methodischer Ansatz verstanden, nach dem das Testen angelegt wird.
So benennt z. B. ISTQB Ausprägungen für Teststrategien wie folgt:
Weitere Prinzipien und Techniken für Teststrategien sind:
Zur Testplanung gehört auch die Vorbereitung der Dokumentation. Eine normierte Vorgehensweise dazu empfiehlt der Standard IEEE 829.[4][5]. Laut diesem Standard gehören zu einer vollständigen Testdokumentation folgende Unterlagen:
Insbesondere bei Tests, die häufig wiederholt werden, ist deren Automatisierung angeraten. Dies ist vor allem bei Regressionstests und bei testgetriebener Entwicklung der Fall. Darüber hinaus kommt Testautomatisierung bei manuell nicht oder nur schwer durchführbaren Tests zum Einsatz (z.B. Lasttests).
Bei nicht automatisierten Tests ist in beiden Fällen der Aufwand so groß, dass häufig auf die Tests verzichtet wird.
Die nebenstehende Grafik zeigt Begriffe, die im Kontext 'Testen' auftreten - und wie sie mit anderen Begriffen in Verbindung stehen.
Zur Erläuterung: Die Grafik ist optisch ein ER-Diagramm, sie zeigt aber keine Datenobjekte, sondern nur Begriffe. Der den Zusammenhang beschreibende Text ist aus Sicht des 'ersten' Begriffs formuliert und steht links von der Linie, die (aus seiner Sicht) zum zweiten Begriff führt.
Die Grafik zeigt die wichtigsten Schnittstellen, die beim Testen auftreten. Zu den von Thaller [6] genannten 'Partnern' beim Testen wird nachfolgend beispielhaft angeführt, WAS jeweils kommuniziert / ausgetauscht wird.
Dieser Artikel basiert auf dem Artikel Softwaretest aus der freien Enzyklopädie Wikipedia und ist unter der Lizenz Creative Commons Attribution/Share Alike verfügbar. Zusätzliche Bedingungen können anwendbar sein. In der Wikipedia ist eine Liste der Autoren verfügbar. |
Wetter
