Was ist Thread-Test beim Softwaretest?

Was ist Thread-Testen?

Thread-Test ist eine Art Softwaretest, der die wichtigsten Funktionen einer bestimmten Aufgabe, eines sogenannten Threads, überprüft. Er wird üblicherweise in der frühen Phase der Softwareentwicklung durchgeführt. Integrationstests Threadbasiertes Testen ist eine der inkrementellen Strategien, die beim Systemintegrationstest angewendet werden. Aus diesem Grund wird ein Thread-Test genauer als … beschrieben. Thread-Interaktionstest.

Ein Thread ist hier nicht nur ein Betriebssystem-Thread. Softwareentwicklung Im Geschäftskontext bezeichnet ein Thread eine abgeschlossene Geschäftstransaktion – zum Beispiel „Kunde gibt eine Bestellung auf“ – tracEs durchläuft jedes Modul, mit dem es in Kontakt kommt. Thread-Tests prüfen, ob dieser einzelne Pfad sich nach der Verbindung der Module noch korrekt verhält.

Das untenstehende Diagramm zeigt, wie einzelne Threads als Subsystem integriert und ausgeführt werden, bevor das Gesamtsystem zusammengebaut wird.

Arten von Thread-Tests

Threadbasiertes Testen wird in zwei Kategorien eingeteilt, und diese Unterscheidung bestimmt sowohl die Testdaten als auch die Fehler, die Sie wahrscheinlich finden werden.

• Single-Thread-Test: Ein Single-Thread-Test umfasst jeweils nur eine Anwendungstransaktion. Es wird nur eine Anfrage bearbeitet, daher ist das Antwortverhalten vorhersehbar und der Test lässt sich leicht skripten und wiederholen.
• Multithread-Tests: Ein Multithread-Test umfasst mehrere gleichzeitig aktive Transaktionen. Für denselben Dienst werden separate Threads vorbereitet, um Reaktionsfähigkeit und die Verwaltung gemeinsam genutzter Zustände unter gleichzeitiger Last zu beobachten.

Eine Transaktion, die im Einzelthread-Test problemlos durchläuft, kann im Mehrthread-Test dennoch fehlschlagen, da im zweiten Durchlauf zusätzliche Konflikte um dieselben Datensätze, Verbindungen und denselben Speicher entstehen.

So führen Sie Thread-Tests durch

Der Thread-Prozess konzentriert sich auf die Integrationsaktivitäten und nicht auf den gesamten Entwicklungszyklus. In der Praxis funktioniert der Ansatz wie folgt.

• Thread-basiertes Testen ist eine verallgemeinerte Form des sitzungsbasierten Testens, bei dem Sitzungen eine Form von Threads sind, ein Thread jedoch nicht unbedingt eine Sitzung ist.
• Der Thread oder das Programm (eine kleine Funktionalität) wird als Subsystem inkrementell integriert und getestet und anschließend für das gesamte System ausgeführt.
• Auf der untersten Ebene verschafft es Integratoren ein besseres Verständnis dafür, was genau getestet werden soll.
• Anstatt Softwarekomponenten direkt zu testen, müssen sich Integratoren auf das Testen logischer Ausführungspfade im Kontext des gesamten Systems konzentrieren.

Da es sich bei der Arbeitseinheit um einen Geschäftsprozess und nicht um eine Komponente handelt, liegt das Thread-Testing naturgemäß zwischen Modultests und voll Systemtests.

Tipps für Multithread-Tests

Multithread-Fehler hängen vom Timing ab, daher beweist ein einzelner fehlerfreier Durchlauf nur wenig. Die folgenden Tipps erhöhen die Wahrscheinlichkeit, sie aufzudecken.

• Testen Sie Ihr Multithread-Programm, indem Sie es wiederholt mit unterschiedlichen gleichzeitig laufenden Anwendungen ausführen.
• Testen Sie Ihr Multithread-Programm, indem Sie mehrere Instanzen des Programms gleichzeitig aktiv haben.
• Führen Sie Ihr Multithread-Programm auf verschiedenen Hardwaremodellen mit unterschiedlichen Belastungsniveaus und Arbeitslasten aus.
• Nutzen Sie die Codeinspektion, da manche Synchronisationsfehler leichter zu lesen als zu reproduzieren sind.
• Es werden nur Fehler und Störungen erfasst, die in anderen Threads als dem Hauptthread aufgetreten sind.

Häufige Fehler bei der Gewindeprüfung

Parallelitätsfehler kündigen sich selten durch einen sauberen Stack an. trace. Die folgenden Kategorien decken den größten Teil dessen ab, was bei einem Multithread-Lauf sichtbar wird, und jede Kategorie hat ein eigenes Symptom, das es wert ist, erkannt zu werden.

• Rennbedingungen: Zwei Threads lesen und schreiben denselben Wert ohne Berücksichtigung der Reihenfolge, sodass das Endergebnis davon abhängt, welcher Thread zuerst fertig war. Symptom: Summen, die bei manchen Durchläufen korrekt und bei anderen falsch sind.
• Deadlock: Zwei Threads halten jeweils eine Sperre, die der andere benötigt, und keiner von beiden wird ausgeführt. Symptom: Die Transaktion hängt sich auf, anstatt mit einem Fehler abzubrechen.
• Ressourcenkonflikte: Threads werden in eine Warteschlange gestellt, um dieselbe Verbindung, denselben Dateihandle oder denselben Datensatz zu verwenden, und der Durchsatz bricht ein, lange bevor die Hardwaregrenze erreicht ist.
• Datenkorruption: Teilweise geschriebene gemeinsam genutzte Strukturen hinterlassen Datensätze in einem Zustand, den keine gültige Transaktion erzeugen könnte.
• Hunger: Ein Thread mit niedriger Priorität erhält nie die benötigte Ressource, sodass ein Benutzerpfad einen Timeout verursacht, während der Rest des Systems in Ordnung zu sein scheint.

Jeder dieser Schritte erfordert die Protokollierung des fehlgeschlagenen Laufs, da ein Fehler, der nur einmal in fünfzig Versuchen auftritt, andernfalls nicht erkannt werden kann. Fehlermanagementprozess.

Thread-Testing vs. Concurrency-Testing vs. Integration-Testing

Die drei Begriffe überschneiden sich und werden in Testplänen häufig verwechselt. Die Tabelle trennt sie nach ihrer Bedeutung.

Zusamenfassend, Parallelitätstests Die erste Frage untersucht, welche Auswirkungen der gleichzeitige Zugriff auf das System hat, während die zweite Frage (Thread-Test) prüft, ob ein wichtiger Pfad die Integration überhaupt übersteht. Teams, die beides durchführen, planen in der Regel zuerst die Thread-Tests.

Vorteile des Thread-Tests

Die Technik verdient aus mehreren praktischen Gründen ihren Platz in einem Integrationsplan.

• Wichtige Geschäftsprozesse werden frühzeitig validiert, sodass fehlerhafte Übergaben erkannt werden, bevor das gesamte System zusammengestellt ist.
• Integratoren erhalten ein klares Bild des Umfangs, da die Testeinheit eine erkennbare Transaktion und keine absolute Einheit ist.tract-Komponentengrenze.
• Das Testen logischer Ausführungspfade im Systemkontext deckt Fehler auf, die isoliert wurden. Komponententests Ich kann nichts sehen.
• Durch die Ausführung mehrerer Threads werden Parallelitätsfehler – Deadlocks, Race Conditions und Ressourcenkonflikte – sichtbar, die andernfalls in die Produktion gelangen würden.
• Durch die inkrementelle Integration bleibt die Debugging-Oberfläche klein, da immer nur ein Thread hinzugefügt wird.
• Die Ergebnisse fließen direkt ein in Regressionstests, weil ein vorbeilaufender Thread ein offensichtlicher Kandidat für die Regressionssuite ist.

Nachteile des Thread-Tests

• Bei Multithreading-Tests besteht die größte Herausforderung darin, einen reproduzierbaren Test für einen Unit-Test programmieren zu können.
• Das Schreiben von Unit-Tests für Multithread-Code ist eine anspruchsvolle Aufgabe.
• Die Testkriterien für Multithread-Tests unterscheiden sich von denen für Singlethread-Tests. Bei Multithread-Tests variieren Faktoren wie Speichergröße, Speicherkapazität und Timing-Probleme, je nachdem, auf welcher Hardware der Code ausgeführt wird.
• Threads können erst getestet werden, wenn die Module, die sie durchlaufen, verfügbar sind; daher hängt die Planung von der Integrationsreihenfolge ab.
• Zeitweise auftretende Ausfälle werden leicht als Umgebungsrauschen abgetan, weshalb eine disziplinierte Protokollierung unerlässlich ist.

Häufig gestellte Fragen