Grundlagen und Methoden des Software-Testprozesses

Ziele des Software-Testprozesses

Der Testprozess von Software verfolgt zwei unterschiedliche Hauptziele:

1. Dem Entwickler und dem Kunden demonstrieren, dass die Software die Anforderungen erfüllt (Validierung).
2. Fehler oder Mängel in der Software, falsches oder unerwünschtes Verhalten, das nicht der Spezifikation entspricht, aufdecken (Verifikation).

Das erste Ziel führt zu Validierungstests, bei denen erwartet wird, dass das System bei einer gegebenen Menge von Testfällen, die die voraussichtliche Nutzung widerspiegeln, korrekt funktioniert. Das zweite Ziel führt zu Defekt- oder Fehlertests, bei denen Testfälle entworfen werden, um Schwachstellen aufzudecken.

Tests können nicht beweisen, dass Software frei von Mängeln ist oder dass sie sich in allen Fällen wie spezifiziert verhält. Es ist immer möglich, dass ein Test übersehene Probleme im System aufdeckt.

Erfahrungsbasierte Testrichtlinien

Alternative Testrichtlinien können auf Erfahrungen mit der Systemnutzung beruhen und sich auf die Prüfung der betriebsbereiten Eigenschaften des Systems konzentrieren. Zum Beispiel:

1. Alle Funktionen des Systems, die über Menüs zugänglich sind, sollten getestet werden.
2. Kombinationen von Funktionen (z. B. Textformatierung), auf die über dieselben Menüs zugegriffen wird, sollten getestet werden.
3. Alle Funktionen müssen sowohl mit korrekten als auch mit falschen Benutzereingaben geprüft werden.

Systemtests

Der Systemtest umfasst die Integration von zwei oder mehr Komponenten, Funktionen oder Eigenschaften zur Implementierung des Systems und das anschließende Testen dieses integrierten Systems. Bei den meisten komplexen Systemen gibt es zwei verschiedene Phasen des Systemtests:

Integrationstests

Hierbei muss das Testteam auf den Quellcode des Systems zugreifen. Wenn ein Problem entdeckt wird, versucht das Integrationsteam, die Ursache des Problems zu finden und die Komponenten zu identifizieren, die erneut getestet werden müssen.

Zweck der Systemintegration

Der Prozess der Systemintegration umfasst den Aufbau eines Systems aus seinen Komponenten und das Testen des Systems auf Probleme in der Interaktion zwischen diesen Komponenten.

Freigabetests (Release Testing)

Hier wird eine Version des Systems getestet, die für die Freigabe an Benutzer vorgesehen ist. Das Team konzentriert sich darauf, zu überprüfen, ob das System die Anforderungen erfüllt und zuverlässig ist.

Zweck der Freigabetests

Der Prozess der Freigabetests dient dazu, die Version des Systems zu testen, die an Kunden verteilt werden soll. Das Hauptziel ist es, das Vertrauen der Lieferanten zu stärken, dass das System die Anforderungen erfüllt.

Performancetests

Nachdem das System vollständig integriert wurde, kann es hinsichtlich emergenter Eigenschaften wie Leistung und Zuverlässigkeit getestet werden.

Komponententests (Unit Testing)

Der Komponententest (manchmal auch Unit-Test genannt) ist der Prozess der Prüfung einzelner Komponenten des Systems. Dies ist ein defektorientierter Testprozess, dessen Ziel es ist, Mängel in diesen Komponenten aufzudecken.

Arten von Komponenten, die getestet werden können:

1. Einzelne Funktionen oder Methoden eines Objekts.
2. Objektklassen mit verschiedenen Attributen und Methoden.
3. Zusammengesetzte Bauteile (Composite Components), die aus verschiedenen Objekten oder Funktionen bestehen. Diese Komponenten verfügen über eine definierte Schnittstelle, die für den Zugriff auf ihre Funktionalität verwendet wird.

Schnittstellentests

Der Schnittstellentest ist besonders wichtig für die objektorientierte und komponentenbasierten Entwicklung. Objekte und Komponenten werden durch ihre Schnittstellen definiert und können in Kombination mit anderen Komponenten in verschiedenen Systemen verwendet werden.

Verschiedene Arten von Schnittstellen:

• Parameter-Schnittstellen: Schnittstellen, die Daten oder, manchmal, Verweise auf Funktionen von einer Komponente zu einer anderen übergeben.
• Shared Memory Interfaces (Gemeinsamer Speicher): Schnittstellen, bei denen ein Speicherbereich zwischen den Komponenten geteilt wird.
• Prozedurale Schnittstellen: Schnittstellen, bei denen eine Komponente aus einer Reihe von Prozeduren besteht, die von anderen Komponenten aufgerufen werden können.
• Message Passing Interfaces (Nachrichtenübermittlung): Schnittstellen, bei denen eine Komponente einen Dienst von einer anderen Komponente anfordert, indem sie eine Nachricht an diese sendet.

Arten von Schnittstellenfehlern

Schnittstellenfehler gehören zu den häufigsten Fehlern in komplexen Systemen:

• Missbrauch von Schnittstellen: Eine Komponente ruft eine andere Komponente auf und macht dabei einen Fehler in der Verwendung ihrer Schnittstelle (z. B. falsche Parameterreihenfolge).
• Fehlendes Verständnis der Schnittstellenspezifikation: Die aufrufende Komponente ignoriert die Spezifikation der aufgerufenen Komponenten-Schnittstelle und trifft falsche Annahmen über deren Verhalten.
• Timing-Fehler: Diese Fehler treten in Echtzeitsystemen mit Shared-Memory- oder Message-Passing-Schnittstellen auf (z. B. Race Conditions).

Allgemeine Richtlinien für Schnittstellentests

• Untersuchen Sie den zu testenden Code und listen Sie jeden Aufruf externer Komponenten explizit auf.
• Testen Sie die Schnittstelle immer auf die Zusammenarbeit mit Zeigern, insbesondere wenn Null-Zeiger über die Schnittstelle übergeben werden.
• Entwerfen Sie Tests, die zum Fehlschlagen der Komponente führen, wenn diese über eine prozedurale Schnittstelle aufgerufen wird.
• Verwenden Sie Stresstests in Message-Passing-Systemen.
• Wenn mehrere Komponenten über gemeinsamen Speicher interagieren, entwerfen Sie Tests, die die Reihenfolge der Aktivierung dieser Komponenten variieren.

Testfallentwurf (Test Case Design)

Der Entwurf von Testfällen ist ein zentraler Bestandteil des Testprozesses. Dabei werden die erwarteten Ein- und Ausgaben des zu testenden Systems festgelegt. Es gibt verschiedene Ansätze zur Erstellung von Testfällen:

• Anforderungsbasierte Tests (Requirements-Based Testing): Testfälle werden entworfen, um zu überprüfen, ob das System die spezifizierten Anforderungen erfüllt.
• Äquivalenzklassenbildung (Prüfung von Partitionen): Es werden Partitionen identifiziert, die die Eingaben und Ausgaben des Systems abdecken. Das System wird mit Eingaben aus allen Partitionen getestet, um die entsprechenden Ausgaben zu erzeugen.
• Strukturtests (Prüfung der Struktur): Wissen über die interne Struktur des Programms wird genutzt, um Tests zu entwerfen, die alle Teile des Programms ausführen.

Pfadtests (Path Testing)

Pfadtests sind eine Strategie für strukturelle Tests, deren Ziel es ist, jeden möglichen Pfad (Ausführungsweg) einer Komponente oder eines Programms unabhängig voneinander auszuführen. Wenn jeder Pfad unabhängig ausgeführt wird, werden alle Anweisungen in den Komponenten mindestens einmal ausgeführt.

Testautomatisierung und Test-Tools

Das Testen ist eine teure und arbeitsintensive Phase des Softwareprozesses. Daher gehörten Test-Tools zu den ersten entwickelten Software-Tools. Eine Software-Test-Workbench ist ein integriertes Set von Werkzeugen zur Unterstützung des Testprozesses.

Beispiele für Test-Tools in einer Test-Workbench:

1. Test-Manager: Verwaltet die Ausführung des Testprogramms, verfolgt Testdaten, erwartete Ergebnisse und die Ressourcen der getesteten Programme.
2. Testdatengenerator: Erzeugt Testdaten für das zu testende Programm.
3. Test-Orakel (Oracle): Erzeugt Vorhersagen der erwarteten Testergebnisse.
4. Dateivergleicher (File Comparator): Vergleicht die Ergebnisse des Testprogramms mit früheren Testergebnissen und meldet die Unterschiede.
5. Berichtsgenerator (Report Generator): Stellt Funktionen zur Erfassung und Meldung der Testergebnisse bereit.
6. Dynamische Analyse: Fügt dem Programm Code hinzu, um zu zählen, wie oft jede Anweisung ausgeführt wurde. Nach dem Test wird ein Ausführungsprofil erstellt, das zeigt, wie oft jede Programmanweisung ausgeführt wurde.
7. Simulator: Verschiedene Arten von Simulatoren können bereitgestellt werden, um den Zielcomputer, auf dem das Programm ausgeführt wird, zu simulieren.

Zusammenfassung: Wichtige Punkte zum Software-Test

• Tests können nur zeigen, dass ein Programm Fehler enthält. Sie können nicht beweisen, dass keine verbleibenden Fehler existieren.
• Komponententests liegen in der Verantwortung des Komponentenentwicklers. Ein separates Testteam führt in der Regel die Systemtests durch.
• Integrationstests sind die erste Aktivität des Systemtests, bei der integrierte Komponenten auf Mängel geprüft werden. Freigabetests konzentrieren sich auf die Versionen, die an den Kunden freigegeben werden sollen, und überprüfen, ob das System die Anforderungen erfüllt.
• Beim Testen von Systemen sollte man versuchen, das System zu "brechen", indem man Erfahrungen und Richtlinien nutzt, um Testfälle auszuwählen, die bei der Fehlersuche in anderen Systemen effektiv waren.
• Schnittstellentests versuchen, Mängel in den Schnittstellen von Verbundkomponenten aufzudecken. Schnittstellendefekte können aufgrund von Fehlern beim Lesen oder Fehlinterpretationen der Spezifikation oder aufgrund ungültiger Timing-Annahmen auftreten.
• Die Äquivalenzklassenbildung ist eine Methode zur Ableitung von Testfällen. Sie basiert auf der Identifizierung von Partitionen in den Mengen von Eingaben und Ausgaben und der Ausführung des Programms mit Werten aus diesen Partitionen. Oft ist der wahrscheinlichste Wert für einen erfolgreichen Test ein Schwellenwert innerhalb der Partition.
• Strukturtests basieren auf einer Programmanalyse, um die möglichen Pfade zu bestimmen, und nutzen diese Analyse zur Unterstützung der Auswahl von Testfällen.
• Die Testautomatisierung reduziert die Testkosten durch die Unterstützung des Prozesses mit einer Vielzahl von Software-Tools.