„Softwaretest“ – Versionsunterschied

Versionsgeschichte interaktiv durchsuchen
[ungesichtete Version][ungesichtete Version]
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
Inhalt gelöscht Inhalt hinzugefügt
VisuellWikitext
Zeile 146: Zeile 146:
* [[Software-Life-Cycle]], [[Bananaware]], [[Slicing]], [[Fehlerbereinigung]]
* [[Software-Life-Cycle]], [[Bananaware]], [[Slicing]], [[Fehlerbereinigung]]
* [[Testmethoden]]
* [[Testmethoden]]
* [[Modellbasiertes Testen]]
* [[Testautomation]]
* [[Testautomation]]
* [[Keyword driven testing]]
* [[Keyword driven testing]]

Version vom 4. Dezember 2006, 14:40 Uhr

Als Software-Test bezeichnet man in der Informatik ein mögliches Verfahren zur teilweisen Verifikation und Validierung eines Programms.

Ein Software-Test ist ein Werkzeug der Qualitätssicherung und die Beurteilung der Ergebnisse des Software-Tests dienen der Feststellung der Qualität einer neu erstellten oder geänderten Software. Dabei geht es prinzipiell darum, das tatsächliche Verhalten mittels Testfällen und gemäß eines Testplans zu untersuchen und die Ergebnisse mit den erwarteten Ergebnissen (Anforderungskatalog, Normen usw.) zu vergleichen und zu dokumentieren.

Die Bewertung dieser Ergebnisse führt dann im Rahmen des Softwareentwicklungsprozesses zu diversen Maßnahmen wie z.B.

Der Software-Test kann verschiedene Ausprägungen haben: So gibt es den Code and Unit-Test (Komponententest), der vom Entwickler durchgeführt wird und bei dem das Programm auf Syntax- und Logikfehler überprüft wird. Beim Integrationstest testet die Softwareproduktion in einer Testumgebung die Einbindung der Software in die bereits vorhandene Softwarearchitektur.

Im Allgemeinen sollte durch einen Softwareentwicklungsprozess festgelegt sein, dass es zu jedem Ergebnis eines Teilprozesses (Klassen, Module, Komponenten, aber auch Dokumentationen(!)) auch die zugehörige Überprüfung in Form eines irgendwie gearteten Tests gibt.


Allgemeines

Bei immer komplexeren Produkten spielt das Testen der Produktqualität während und nach der Produktion eine immer größere Rolle.

Bei elektronischen Bauelementen wird z.B. meist die komplette Funktionalität mit Hilfe von Testgeräten getestet. Bis zu 30% betragen die Testkosten bei sehr komplexen Microchips, da die Entwicklung von Testprogrammen sehr viel Zeit benötigt und das Testequipment sehr teuer ist. Aufgabe von Test-Ingenieuren ist es, den Testprozess zu optimieren, sodass Fehler mit geringstmöglichem Aufwand erkannt, aber funktionierende Bausteine unter Test nicht fälschlicherweise aussortiert werden.

Das Testen spielt besonders im Software-Engineering eine wichtige Rolle. Dort werden bis zu 40% der gesamten Projektdauer dem Testen gewidmet.

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 (der Test findet meist nur einen Effekt und nicht die eigentliche Ursache).

Kurz:
Wird (vor allem beim ersten Durchlauf) kein Fehler gefunden, heißt das nicht, dass die Software gut ist. Die Fehlersuche sollte eher verbessert werden ...

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 Seiteneffekte 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öglichst unabhängigen, Personen getestet werden, denn der Entwickler findet prinzipiell immer 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

Peter Liggesmeyer (Lit.: Liggesmeyer, S. 34) klassifiziert Testmethoden folgendermaßen (verkürzt):

Klassifikation nach der Systemstruktur

Testobjekt Testmethode
Modul bzw. Unit, Klasse Modultest, Klassentest
Klassenhierarchie Klassenhierarchietest
Komponente Komponententest (das Zusammenspiel mehrerer Module)
Schicht Subsystemtest
System Systemtest (Integrations- und Verbundtest)

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 .

  • Destruktionstests sollen das korrekte (ein definiertes) Verhalten bei unnormalem Gebrauch sicherstellen.
  • 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, wenn man sie dazu einsetzt, das Wiederauftreten bereits behobener Bugs zu entdecken.
  • Installationstests testen die Funktionalität unter verschiedenen Systemumgebungen.
  • Oberflächentests testen die Benutzerschnittstelle des Systems.
  • Stresstest sind Tests, die das Verhalten eines Systems unter Ausnahmesituationen analysieren. Im engeren Sinne handelt es sich bei Stresstests in der Praxis meist nicht um Tests, sondern um mit Hilfe von Testwerkzeugen erstellte Tries.
  • 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.

White-Box-Tests sind kurzfristig kostengünstiger, zeigen in der Praxis allerdings eine äußerst hohe Durchlässigkeit für Fehler.

Black-Box-Tests decken besonders viele Fehler auf, erweisen sich in der Praxis aber zum einen als organisatorisch aufwändig und zum anderen manchmal auch als sozial unverträglich wegen eventueller Spannungen zwischen den Test- und den Entwicklungsabteilungen.

Grey-Box-Tests (Testgetriebene Entwicklung) erweisen sich derzeit in der Praxis als besonders erfolgreich, da sie die Kostengünstigkeit von White-Box-Tests mit der Effizienz von Black-Box-Tests verbinden, sind allerdings außerhalb ihres üblichen Kontext des Extreme Programming oder zumindest der testgetriebenen Entwicklung nicht unkritisch zu betrachten, da Software-Entwickler sonst leicht zu White-Box-Tests abdriften und so die Black-Box-Test-artigen Vorteile der Grey-Box-Tests verlieren.

Automatisierte Tests

Für den Praxiseinsatz ist die Automatisierung von Tests 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.

Werkzeuge für Software-Tests

Werkzeuge für automatisiertes Software-Testing bzw. das automatisierte Testen von Webseiten sind z. B.

Siehe auch

Literatur

Quelle: https://de.wikipedia.org/w/index.php?title=Softwaretest&diff=prev&oldid=24658877