Zum Inhalt springen

Softwaretest

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 8. Dezember 2010 um 12:21 Uhr durch VÖRBY (Diskussion | Beiträge) ('Testen' bezeichnet auch den Gesamtbegriff, nicht nur den Einzelfall). Sie kann sich erheblich von der aktuellen Version unterscheiden.
Eine gesichtete Version dieser Seite, die am 8. Dezember 2010 freigegeben wurde, basiert auf dieser Version.

Ein Softwaretest ist ein Test, der im Rahmen der Softwareentwicklung durchgeführt wird, um die Funktionalität einer Software an den Anforderungen und ihre Qualität zu messen, und Softwarefehler zu ermitteln.

Von diesem, einzelne Testdurchführungen bezeichnenden Begriff ist die gleich lautende Bezeichnung 'Test' (auch 'Testen') zu unterscheiden, unter der die Gesamtheit der Maßnahmen zur Überprüfung der Softwarequelität (inkl. Planung, Vorbereitung, Steuerung, Durchführung, Dokumentation usw.; siehe auch Definitionen) verstanden wird.

Definition

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 Denert[1], wonach der „Test […] der überprüfbare und jederzeit wiederholbare Nachweis der Korrektheit eines Softwarebausteines relativ zu vorher festgelegten Anforderungen“ ist.

Weitergehend definieren Pol, Koomen und Spillner 'Testen' in [2] mit: 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.


Der Softwaretest wird oft als analytische Maßnahme, die erst nach Erstellung des Prüfgegenstandes durchgeführt werden kann, definiert. Weiter unterteilt werden kann nach

Als Erweiterung zu den analytischen Maßnahmen sind konstruktive Maßnahmen zu sehen, die bereits bei der Software-Erstellung ausgeführt werden bzw. diese begleiten. Beispiele: Review, werkzeuggestützte Codeanalyse

Ziele

Globales Ziel des Softwaretestens ist das Messen der Qualität des Softwaresystems. Dabei werden definierte Anforderungen überprüft und dabei ggf. Fehler aufgedeckt.

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.

Die Testergebnisse (die über verschiedene Testverfahren gewonnen werden) tragen zur Beurteilung der realen Qualität der Software bei - als Voraussetzung für deren Freigabe für den operativen Betrieb.

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 hierzu: Program testing can be used to show the presence of bugs, but never show their absence! 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.

Individuelle Testziele: Da das Softwaretesten aus zahlreichen Einzelmaßnahmen besteht, die i.d.R. über mehrere Testphasen hinweg und an vielen Testobjekten ausgeführt werden, ergeben sich individuelle Testziele für jeden einzelnen Testfall und für jede Testphase - wie z. B. Rechenfunktion X in Programm Y getestet, Schnittstellentest erfolgreich, Wiederinbetriebnahme getestet, Lasttest erfolgreich, Programm XYZ getestet usw.

Testplanung

  • Welche Anforderungen und wie stark diese getestet werden, hängt von dem Testanspruch ab. Bei einem Softwaresystem mit sensiblen Daten wird man beispielsweise eine höhere Priorität auf die Datensicherheit legen als bei einem Computerspiel, bei dem die Benutzbarkeit eine größere Rolle spielt.
  • Die Anzahl und Komplexität der Testfälle muss ausreichend sein.
  • Werden iterative Softwareentwicklungsprozesse benutzt, sollten im Idealfall alle Funktionen der vorherigen Iteration wegen eventuell auftretender unerwünschter Nebeneffekte getestet werden. Das hat zur Folge, dass sich die Anzahl der zu testenden Funktionen bei jeder Iteration erhöht.

Die Testkonzeption findet parallel zur Softwareentwicklung statt.

Dokumentation

Zusammenhang der Dokumente und Verfahrensschritte laut IEEE 829

Zur Testplanung gehört auch die Vorbereitung der Dokumentation. Eine normierte Vorgehensweise dazu empfiehlt der Standard IEEE 829.[3][4]. Laut diesem Standard gehören zu einer vollständigen Testdokumentation folgende Unterlagen:

Testplan
Beschreibt Umfang, Vorgehensweise, Terminplan, Testgegenstände.
Testdesignspezifikation
Beschreibt die im Testplan genannten Vorgehensweisen im Detail.
Testfallspezifikationen
Beschreibt die Umgebungsbedingungen, Eingaben und Ausgaben eines jeden Testfalls.
Testablaufspezifikationen
Beschreibt in Einzelschritten, wie jeder Testfall durchzuführen ist.
Testobjektübertragungsbericht
Protokolliert, wann welche Testgegenstände an welche Tester übergeben wurden.
Testprotokoll
Listet chronologisch alle relevanten Vorgänge bei der Testdurchführung.
Testvorfallbericht
Listet alle Ereignisse, die eine weitere Untersuchung erforderlich machen.
Testergebnisbericht
Beschreibt und bewertet die Ergebnisse aller Tests.

Testdurchführung

  • Ein Testobjekt sollte nicht vom Entwickler selbst, sondern von anderen, wenn möglich unabhängigen, Personen getestet werden, denn der Entwickler findet meistens weniger Fehler in seinem eigenen Programm als externe Personen (Dies gilt nicht für den Ansatz der testgetriebenen Entwicklung).
  • Gefundene Fehler sollten nicht gleich korrigiert werden, sondern erst dokumentiert und der Test zu Ende geführt werden.
  • Ein Fehler in einem Modul weist oft auf weitere Fehler in diesem oder anderen Modulen hin.

Teststufen

Stufen des V-Modells

Die Einordnung der Teststufen folgt dem Entwicklungsstand des Systems. In der Regel werden die Teststufen bzw. Testphasen an das V-Modell mit den vier Stufen Komponententest, Integrationstest, Systemtest und Abnahmetest angelehnt. Dabei wird eine Entwicklungsstufe gegen die dazugehörige Spezifikation getestet.

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.

Komponententest

Der Komponententest, auch Modultest oder Unit Test genannt, ist ein Test auf der tiefsten Ebene. Dabei werden einzelne Komponenten auf korrekte Funktionalität getestet. Häufig wird der Modultest durch den Software-Entwickler durchgeführt. Die Testobjekte sind einzelne abgegrenzte Module, also Unterprogramme, Units oder Klassen.

Integrationstest

Integrationstest bzw. Interaktionstests testet die Zusammenarbeit voneinander abhängiger Komponenten.

Systemtest

Der Systemtest ist die Testphase, 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.

Abnahmetest

Ein Abnahmetest, Verfahrenstest, Akzeptanztest oder auch User Acceptance Test (UAT) ist ein Test der gelieferten Software durch den Kunden. Oft sind Akzeptanztests Voraussetzung für die Rechnungsstellung. Dieser Test kann bereits auf der Produktivumgebung mit Echtdaten durchgeführt werden.

Bei einem solchen Test wird das Blackbox-Verfahren angewendet, d. h. der Kunde betrachtet nicht den Code der Software, sondern nur das Verhalten der Software bei spezifizierten Handlungen (Eingaben des Benutzers, Grenzwerte bei der Datenerfassung, etc.). Das Blackbox-Verfahren kann auch auf allen anderen Teststufen angewandt werden.

Eine Abnahme kann aber auch aus einem Review der Testprotokolle des Systemtests bestehen.

Klassifikation nach der Prüftechnik

Liggesmeyer([5]) klassifiziert Testmethoden folgendermaßen (verkürzt):

Klassifikation nach dem Testkriterium

Die Einordnung erfolgt hier je nachdem welche inhaltlichen Aspekte getestet werden sollen.

Funktionale Tests bzw. Funktionstests
überprüfen ein System in Bezug auf funktionale Anforderungsmerkmale wie Korrektheit und Vollständigkeit.
Nicht-funktionale Tests
überprüfen die nicht funktionalen Anforderungen, wie z. B. die Sicherheit, die Gebrauchstauglichkeit oder die Zuverlässigkeit eines Systems. Dabei steht nicht die Funktion der Software (Was tut die Software?) im Vordergrund, sondern ihre Funktionsweise (Wie arbeitet die Software?).
Schnittstellentests
testen die Funktionalität bei der Zusammenarbeit voneinander unabhängiger Komponenten unter Einsatz einer einzelnen Komponente und einer Spezifikation, beispielsweise mit Hilfe von Mock-Objekten
Wiederinbetriebnahmetest
testet ob ein System nach einem Abschalten oder Zusammenbruch (z. B. ausgelöst durch Stresstest) wieder in Betrieb genommen werden kann.
Interoperabilitätstests
testen die Funktionalität bei der Zusammenarbeit voneinander unabhängiger Komponenten unter Einsatz mehrerer Komponenten.
Installationstests
testen der Softwareinstallationsroutinen ggfs. in verschiedenen Systemumgebungen (z. B. verschiedene Hardware oder unterschiedliche Betriebssystemversionen)
Oberflächentests
testen die Benutzerschnittstelle des Systems.
Stresstests
sind Tests, die das Verhalten eines Systems unter Ausnahmesituationen analysieren.
Crashtests
sind Stresstests, die versuchen, das System zum Absturz zu bringen.
Smoketest
bezeichnet den ersten Probelauf nach der Implementierung einer neuen Funktionalität, um sicherzugehen, dass die Programmfunktion nicht schon ansatzweise fehlschlägt.
Lasttests
sind Tests, die das Systemverhalten unter besonders hohen Speicher-, CPU-, o. ä. -Anforderungen analysieren. Besondere Arten von Last-Tests können Multi-User-Tests (viele Anwender greifen auf ein System zu, simuliert oder real) und Stresstests (dabei wird das System an die Grenzen der Leistungsfähigkeit geführt) sein.
Performance Tests
sind Tests, die ein korrektes Systemverhalten bei bestimmten Speicher- und CPU-Anforderungen sicherstellen sollen.
Rechnernetz-Tests
testen das Systemverhalten in Rechnernetzen (z. B. Verzögerungen der Datenübertragung, Verhalten bei Problemen in der Datenübertragung).
Sicherheitstests
testen ein System gegen potentielle Sicherheitslücken.

Klassifikation nach Informationsstand

Neben dieser Einordnung anhand des Ablaufs und Umfangs des Tests lassen sich Tests auch nach Wissen über die zu testende Komponente einordnen:

Black-Box-Tests,
auch Funktionstests genannt, werden von Programmierern und Testern entwickelt, die keine Kenntnisse über den inneren Aufbau des zu testenden Systems haben. In der Praxis werden Black-Box-Tests meist von speziellen Test-Abteilungen oder Test-Teams entwickelt.
White-Box-Tests,
auch Strukturtests genannt, werden von den gleichen Programmierern entwickelt wie das zu testende System selbst. Der den Test entwickelnde Programmierer hat also Kenntnisse über das zu testende System.
Grey-Box-Tests
werden von den gleichen Programmierern entwickelt wie das zu testende System selbst, gemäß den Regeln der testgetriebenen Entwicklung, also vor der Implementierung des Systems, und damit (noch) ohne Kenntnisse über das zu testende System.

Testautomatisierung

Insbesondere bei Tests, die häufig wiederholt werden, ist deren Automatisierung (siehe Testautomatisierung) 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.

Einzelnachweise

  1. ↑ Ernst Denert: Software-Engineering. Springer, Berlin 1991, 1992. ISBN 3-540-53404-0
  2. ↑ Management und Optimierung des Testprozesses. dpunkt.Verlag, ISBN 978-3-89864-951-3
  3. ↑ IEEE Standard for Software Test Documentation (IEEE Std. 829-1998)
  4. ↑ IEEE Standard for Software and System Test Documentation (IEEE Std. 829-2008)
  5. ↑ Peter Liggesmeyer: Software-Qualität - Testen, Analysieren und Verifizieren von Software. Spektrum Akademischer Verlag, Heidelberg/Berlin 2002, S.34. ISBN 3-8274-1118-1

Siehe auch

Literatur

  • Andreas Spillner, Tilo Linz: Basiswissen Softwaretest. dpunkt.verlag, Heidelberg 2005. ISBN 3-89864-358-1
  • Harry Sneed, Manfred Baumgartner, Richard Seidl: Der Systemtest - Anforderungsbasiertes Testen von Software-Systemen. Carl Hanser, München/Wien 2006. ISBN 3-446-40793-6
  • Georg Erwin Thaller: Software-Test. Verifikation und Validation. Heise, Hannover 2002. ISBN 3-88229-198-2
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Softwaretest&oldid=82410907“