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 Links zwischen Anforderungen und Testfällen sollte ausgewogen sein.

Werkzeuge für Software-Tests

 B.Werkzeuge für das automatisierte Software-Testing sind z.

• JUnit und Cactus für Java
• NUnit für alle .NET Sprachen
• CppUnit und CTA++ für C++
• PHPUnit für PHP
• Hyades
• Tessy
• Open Source Tools

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.
• 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.
• 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.