System-Test

Ein Softwaretest ist ein Test während der Softwareentwicklung, um die Funktionalität einer Software an den Anforderungen und ihre Qualität zu messen, und Softwarefehler zu ermitteln.

Definition

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

• dynamischen Maßnahmen, die eine Ausführung der Software erfordern (Bsp. Überdeckungstest) und
• statischen Maßnahmen, die auf eine Ausführung der Software verzichten können (Bsp. Verifikation, Code-Reviews)

Als Abgrenzung zu den analytische Maßnahmen sind konstruktive Maßnahmen zu sehen, die bereits bei der Erstellung vorliegen bzw. die Erstellung begleiten.

Es gibt mehrere 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.

Ziele

Ziel des Softwaretests ist das Aufdecken von Fehlern, nicht der Beweis der Abwesenheit von Fehlern. Der Test findet meist nur einen Effekt und nicht die eigentliche Ursache. Ein erfolgloser Test (d. h. ein Test ohne gefundene Fehler) ist niemals ein Beweis für ein korrektes Programm. Es wurden lediglich keine Fehler gefunden.

Die Korrektheit eines Programms kann durch Testen (außer in trivialen Fällen) nicht bewiesen werden. Der Grund liegt in der Komplexität der Programme. Alle Kombinationen aller möglichen Werte der Eingabedaten müssten getestet werden. Dadurch ergeben sich vielfältige Kombinationsmöglichkeiten, so dass ein Test aller Möglichkeiten realistisch nicht durchführbar ist.

Aus diesem Grund beschäftigen sich verschiedene Teststrategien/-konzepte mit der Frage, wie mit einer möglichst geringen Anzahl von Testfällen eine große Testabdeckung zu erreichen ist.

Die Ergebnisse des Softwaretests tragen zur Beurteilung der realen Qualität der Software bei.

Testplanung

• Welche und wie stark die Anforderungen getestet werden, hängt von dem Testanspruch ab. Bei einem Softwaresystem mit sensiblen Daten wird man z. B. eine höhere Priorität auf die Datensicherheit legen als bei einem Computerspiel, bei dem man eine höhere Priorität z. B. auf die Benutzbarkeit legen wird.

• 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 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.^[2][3]. 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 z. B. für die Software-Entwicklung von sicherheitsrelevanten Systemen in der Transportsicherungstechnik zusätzliche Untergliederungen sein der 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, Modultest oder Unit Test 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 Module, 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öhnlicherweise findet der Test auf einer Testumgebung statt und wird mit Testdaten durchgeführt. 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.).

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

Klassifikation nach der Prüftechnik

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

• Statischer Test (Test ohne Programmausführung)
  • Review
  • Statische Code-Analyse
• Dynamischer Test (Test während Programmausführung)
  • Strukturorientierter Test
    • Kontrollflussorientiert (Maß für die Überdeckung des Kontrollflusses)
      • Anweisungs-, Zweig-, Bedingungs- und Pfadüberdeckungstests
    • Datenflussorientiert (Maß für die Überdeckung des Datenflusses)
      • Defs-/Uses Kriterien, Required k-Tupels-Test, Datenkontext-Überdeckung
  • Funktionsorientierter Test (Test gegen eine Spezifikation)
    • Funktionale Äquivalenzklassenbildung, Zustandsbasierter Test, Ursache-Wirkung-Analyse z. B. mittels Ursache-Wirkungs-Diagramm, Syntaxtest, Transaktionsflussbasierter Test, Test auf Basis von Entscheidungstabellen
  • Diversifizierender Test (Vergleich der Testergebnisse mehrerer Versionen)
    • Regressionstest, Back-To-Back-Test, Mutationen-Test
  • Sonstige (nicht eindeutig zuzuordnen, bzw. Mischformen)
    • Bereichstest bzw. Domain Testing (Verallgemeinerung der Äquivalenzklassenbildung), Error guessing, Grenzwertanalyse, Zusicherungstechniken

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 Benutzbarkeit 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).

• Durch Regressionstests wird nach Softwareänderungen meist im Zuge des System- oder Abnahmetests der fehlerfreie Erhalt der bisherigen Funktionalität überprüft.
• Bei der testgetriebener Entwicklung werden die Tests im Zuge der Softwareentwicklung im Idealfall nach jeder Änderung ausgeführt.

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. ↑ IEEE Standard for Software Test Documentation (IEEE Std. 829-1998)
3. ↑ IEEE Standard for Software and System Test Documentation (IEEE Std. 829-2008)
4. ↑ 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

• Software-Life-Cycle, Bananaware, Slicing, Fehlerbereinigung
• Testmethoden
• Modellbasiertes Testen
• Keyword driven testing
• Klassifikationsbaummethode
• Kontrollflussorientierte Testverfahren
• ISTQB Certified Tester

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