Das Kefk Network Wiki befindet sich im Testbetrieb.

Softwaretest

Aus Kefk.

Wechseln zu: Navigation, Suche

Der Softwaretest ist eine analytische, dynamische Maßnahme zur Qualitätssicherung von Software, d.h. der Softwarequalität.

Inhaltsverzeichnis

Qualitätsmaßnahmen

Qualitätsmaßnahmen werden oft eingeteilt in

  • analytische Maßnahmen, die erst nach Erstellung des Prüfgegenstandes durchgeführt werden können, wobei 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) und
  • konstruktive Maßnahmen, die bereits bei der Erstellung vorliegen bzw. die Erstellung begleiten.

Definition Test

Die konkrete Abgrenzung von Tests zu anderen Qualitätsmaßnahmen fällt schwer. Aus diesem Grund gibt es mehrere - glücklicherweise ähnliche - Definitionen für Tests:

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

Schwierigkeit beim Test

Da sehr einfache Programme für einen vollständigen bzw. erschöpfenden Test bereits eine immens hohe Anzahl von Testfällen benötigen, ist ein angemessener Test immer nur eine Stichprobe. Aus diesem Grund kann man durch einen Test nur die Anwesenheit nicht aber die Abwesenheit von Fehler nachweisen (E. W. Dijkstra).

Beispiel: Ein Programm soll prüfen, ob eine Benutzereingabe durch 2 teilbar ist. Ein erschöpfender Test muss alle Eingaben und die erzeugten Ausgaben prüfen. Angenommen nur gültige numerische Werte sind zugelassen bzw. werden verlässlich zugesichert, so sind dennoch alle Zahlen zu prüfen. Wird weiter angenommen, daß nur natürliche Zahlen bis 65535 verlässlich als Eingabe zugesichert werden, so müssen mindestens diese Eingaben geprüft werden.

Aus diesem Grund beschäftigen sich verschiedene Teststrategien/-konzepte mit der Frage, wie mit einer sinnvollen Anzahl von Tests Fehlerarmut nachgewiesen werden kann.

Ziele

Man unterscheidet grundsätzlich zwischen den Zielen des Testprozesses und den Zielen eines einzelnen Tests.

  • Ziel des Testprozesses ist die Minimierung des Restrisikos verbleibender Fehler und somit eine Bewertung der realen Qualität des Testobjektes.
  • Ziel eines einzelnen Tests 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.

Beseitigt man die Fehlerursache, erreicht man damit eine Steigerung der Qualität und demzufolge die Reduktion der Fehlerfolgekosten.

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.

Planung

  • Tests soll man unter der Annahme planen, dass Fehler gefunden werden können. Deshalb ist ausreichend Zeit dafür einzuplanen.
  • Jede Anforderung muss getestet werden, ansonsten ist das Testen unvollständig.
  • Die Anzahl und Komplexität der Testfälle muss ausreichend sein. Die Details dazu werden in der Regel im Softwareentwicklungsprozess festgelegt.
  • 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.

Durchfü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.
  • Ein Fehler in einem Modul weist oft auf weitere Fehler in diesem oder anderen Modulen hin.

Abgrenzung

In ihrem Selbstverständnis sind Tests klar abzugrenzen von

  • der klassischen Verifikation, welche einen Korrektheitsbeweis verwendet,
  • dem einfachen Experiment oder Ausprobieren, in der Fachsprache des Software-Testens als "Try" (engl. für Versuch) bezeichnet. Während in den Naturwissenschaften an ein Experiment höhere Anforderungen gestellt werden als an die Tests, ist dies in der Informatik umgekehrt.

Als Naturwissenschaftler kann man sich einen Test dabei als Experiment vorstellen, das unter gleichen Bedingungen wiederholbar sein muss. (Dabei kann es innerhalb von Testfällen natürlich Variationen der Testbedingungen, definiert durch Test-Parameter, geben. Gleiche Testbedingungen müssen aber immer zu gleichen Ergebnissen führen.)

Klassifikation nach der Prüftechnik

Liggesmeyer([2] S. 34) klassifiziert Testmethoden folgendermaßen (verkürzt):

Klassifikation nach der Systemstruktur

Testobjekt Testmethode
Komponente wie z.B. Modul, Unit oder Klasse Modultest, Unit-Test, Klassentest
mehrere abhängige Komponenten Integrationstest (das Zusammenspiel mehrerer Komponenten)
Teilsystem Subsystemtest
System Systemtest

Klassifikation nach Ablauf, Umfang

Es gibt unter anderem folgende Bezeichnungen für spezielle Arten von Tests:

  • Funktionale Tests, Abnahmetests, Akzeptanztests und Systemtests dienen dazu, die vom Abnehmer des Programms erwartete Funktionalität des Systems im normalen Gebrauch und somit die Akzeptanz beim Abnehmer sicherzustellen.
    • Beim Abnahmetest testet der Auftraggeber, ob das Programm den vereinbarten Anforderungen entspricht.

Auch bekannt als UAT (User Acceptance Test). Beim UAT kommen die Enduser zum Einsatz die das entwickelte Programm auf Herz und Nieren prüfen ob es wirklich den Bedürfnissen und Anforderungen des Business entspricht .

  • Modultests, Unit-Tests und Component Tests testen die Funktionalität einzelner kleiner Programmelemente.
  • 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
  • Interoperabilitätstests testen die Funktionalität bei der Zusammenarbeit voneinander unabhängiger Komponenten unter Einsatz mehrerer Komponenten.
  • Integrationstests bzw. Interaktionstests testen die Zusammenarbeit voneinander abhängiger Komponenten.
  • Regressionstests nennt man Tests, die man dazu einsetzt, nach einer Änderung der Software die Unversehrtheit bereits getesteter Bereiche zu überprüfen
  • Installationstests testen der Softwareinstallationsroutinen ggfs. in verschiedenen Systemumgebungen (z.B. verschiedene Hardware oder unterschiedliche Betriebssystemversionen)
  • Oberflächentests testen die Benutzerschnittstelle des Systems.
  • Stresstest sind Tests, die das Verhalten eines Systems unter Ausnahmesituationen analysieren.
  • Crashtests sind Stresstests, die versuchen, das System zum Absturz zu bringen.
  • 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.
  • WAN-Tests sind Tests, die das Systemverhalten im WAN analysieren (z. B. bez. Latency-Aspekten). WAN-Tests werden häufig mit WAN-Simulatoren durchgeführt.
  • Sicherheitstests testen ein System gegen potentielle Sicherheitslücken.
  • Zufallstests sind Tests basierend auf Zufallsdaten.
  • Als Trivialtests werden Tests bezeichnet, die trivial erscheinende Funktionalität testen. Sie erscheinen häufig überflüssig und bedeuten einen im Vergleich zum Testobjekt hohen Aufwand, was in einem vergleichsweise schlechten Kosten-Nutzen-Verhältnis resultiert.

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, allerdings nach der testgetriebenen Entwicklung, das heißt vor dem und damit ohne Kenntnisse über das zu testende System.

Testautomation

Für den Praxiseinsatz ist die Testautomation besonders wichtig. Tests werden im Idealfall nach jeder Änderung ausgeführt. Bei nicht automatisierten Tests wäre dabei der für das Durchführen der Tests notwendige Aufwand zu groß, sodass man häufig auf die Tests verzichten würde, was wiederum den Nutzen der Tests stark verringert.

Siehe auch


Literatur

  • Andreas Spillner und Tilo Linz: Basiswissen Softwaretest dpunkt.verlag, Heidelberg, 2005, ISBN 3-89864-358-1

Verweise

  1. ↑ E.Denert, Software-Engineering, Springer, 1991
  2. ↑ Peter Liggesmeyer: Software-Qualität: Testen, Analysieren und Verifizieren von Software. Spektrum, Akademischer Verlag, Heidelberg, Berlin, 2002, ISBN 3-8274-1118-1
Wikipedia
 Dieses Dokument entstammt in seiner ersten oder einer späteren Version der deutschsprachigen Wikipedia. Es ist dort zu finden unter dem Stichwort Softwaretest, die Liste der bisherigen Autoren befindet sich in der Versionsliste; die Originalfassung kann dort auch bearbeitet werden. Alle Texte der Wikipedia und ihre Derivate stehen unter der GNU-Lizenz für freie Dokumentation.
Von „http://www.kefk.org/wiki/Softwaretest“
Persönliche Werkzeuge