Zum Inhalt springen

Softwaretest

aus Wikipedia, der freien Enzyklopädie
Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 13. Juni 2006 um 14:58 Uhr durch 217.91.118.234 (Diskussion). Sie kann sich erheblich von der aktuellen Version unterscheiden.

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

Ein Software-Test dient der Qualitätssicherung 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.

Es handelt sich um eine Aktivität der Softwareentwicklung, in der das Computerprogramm auf seine Funktionalitäten hin getestet wird. Der 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.

In der Praxis werden Tests eingesetzt, um Programmfehler (Bugs) aufzufinden oder deren Wiederauftreten (Regression) zu vermeiden.

Allgemeines

Bei immer komplexeren Produkten spielt das Testen der Produktqualität während und nach der Produktion eine immer größere Rolle. Die Qualitätssicherung ist in vielen Betrieben deshalb oft direkt dem Management untergeordnet.

Bei elektronischen Bauelementen wird 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

  • Ziel des Testens ist es, ein Programm (einen Schaltkreis oder allgemein ein Werkstück) mit der Absicht auszuführen (zu belasten, ...), Fehler zu finden.
  • 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 seinen eigenen Programm als externe Personen.
  • Tests soll man unter der Annahme planen, dass Fehler gefunden werden können.
  • Ein Fehler in einem Modul weist oft auf weitere Fehler in diesem oder anderen Modulen hin.
  • Testziele in Bezug auf die Anforderungen:
    1. Jede Anforderung muss getestet werden, ansonsten ist das Testen unvollständig.
    2. Ungenügendes bzw. exzessives Testen soll vermieden werden. Es soll zwar jede Anforderung getestet werden, aber die Anzahl der Testfälle für einzelne Anforderungen sollte nicht zu groß sein.
    3. Geeignete Komplexität beim Testen. Die Anzahl der Testfälle, der Anforderungen und der Verbindungen zwischen Anforderungen und Testfällen sollte ausgewogen sein.

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 Vorlage:Lit 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.
  • 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 das automatisierte Software-Testing sind z. B.

Siehe auch

Literatur

[1]

Abgerufen von „https://de.wikipedia.org/w/index.php?title=Softwaretest&oldid=17811944“