Test (Informatik)

Dies ist eine alte Version dieser Seite, zuletzt bearbeitet am 11. Juni 2004 um 03:14 Uhr durch Head (Diskussion | Beiträge) (Kategorie:Programmierung). Sie kann sich erheblich von der aktuellen Version unterscheiden.

Als Test oder Softwaretest bezeichnet man in der Informatik ein mögliches Verfahren zur teilweisen Verifikation eines Programms.

Es handelt sich um eine Phase 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, 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) oder deren Wiederauftreten zu vermeiden (Debugging).

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 übrigen 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 nicht nur mit den gleichen Bedingungen, sondern auch unterschiedlichen Bedingungen, den Test-Parametern, genau definiert wiederholbar sein muss.

Klassifikation

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, z.B. mit Hilfe eines Mocks.
  • Interoperabilitätstests testen die Funktionalität bei der Zusammenarbeit voneinander unabhängiger Komponenten unter Einsatz mehrer 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.
  • Stresstests 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 Stresstests, die das Systemverhalten unter besonders hohen Speicher- oder CPU-Anforderungen analysieren.
  • Performance Tests sind Tests, die ein korrektes Systemverhalten bei bestimmten Speicher- und CPU-Anforderungen sicherstellen sollen.
  • Sicherheitstests testen ein System gegen potentielle Sicherheitslücken.
  • Zufallstests sind Tests basierend auf Zufallsdaten.

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 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 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 Testgesteuerten Programmierung, d.h. 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 aufwendig und zum andern manchmal auch als sozial unverträglich wegen eventueller Spannungen zwischen den Test- und den Entwicklungsabteilungen.

Grey Box Tests (Testgesteuerte Programmierung) erweisen sich derzeit in der Praxis als besonders erfolgreich, da sie die Kostengünstigkeit von White Box Tests mit der Effizenz von Black Box Tests verbinden, sind allerdings außerhalb ihres üblichen Kontext des Extreme Programming oder zumindest der testgesteuerten Programmierung 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. ...

Siehe auch: Software-Life-Cycle