xonics/IHK-Projekt
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
24c0593f1571ad5bee8df442cd782c8172b98073
IHK-Projekt/04_Testing/Testcases.md

15 KiB
Raw Blame History

WCS-Refactoring IHK-Projekt — Strukturierte Testspezifikation & Testfälle

Dieses Dokument beschreibt die strukturierte Testphase des refaktorierten Warehouse Control Systems (WCS). Um Concurrency-Probleme (Race Conditions) und ungesteuerte Prozessstarts sicher auszuschließen, wurden alle Testfälle in einer realitätsnahen Simulationsumgebung verifiziert.

1. Test- und Simulationsumgebung (Der Digitale Zwilling)

Die Qualitätssicherung des Refactorings erfolgt über ein mehrstufiges Testverfahren unter Verwendung eines „Digitalen Zwillings“ der Fördertechnik. Da Concurrency-Probleme und physische Sensorfehler auf einer realen Anlage schwer zu reproduzieren sind, wird folgende Simulationsarchitektur genutzt:

  • Emulate3D: Bildet das physikalische Verhalten der Förderanlage (Rollenbahnen, Lichttaster, Weichen) in Echtzeit ab und visualisiert den Materialfluss.
  • EMC Runner (Equipment Management Controller Simulator): Ein in-house TCP/IP-Telegramm-Simulator, der SPS-Steuerungen simuliert. Er sendet standardisierte ASCII-Ereignistelegramme (z. B. DepartureNotification) an das WCS und validiert die zurückgesendeten Freigabetelegramme (Departure) auf logische Korrektheit und Latenz.
  • WCS-Knoten (GEBHARDT StoreWare®): Die modifizierten Prozesse HostBooking (speziell DepartureNotificationHandler) und ConveyorDispo (speziell StartInitialOrdersHost und OrderManager) laufen in einer lokalen Testinstanz.
  • Testdatenbank: Eine dedizierte Microsoft SQL Server-Instanz, die das relationale Schema inklusive der neuen DepartureFlag-Spalte abbildet.
  • WcsTestTool (WCS Test-Tool): Ein internes Windows-Desktop-Diagnosetool zur manuellen und automatisierten Steuerung von Testszenarien mit folgenden Modulen:
    • Test Orders: Erzeugung und Überwachung von Standard-Transportaufträgen.
    • Storage Test: Konfiguration und Durchführung automatisierter Ein- und Auslagerungstests.
    • Dummy OrdersMiniload: Generierung von Testaufträgen für das Kleinteilelager (Miniload).
    • Workplace Depature: Manuelle Simulation von Abmeldungen an den Kommissionierplätzen (PIC10 - PIC15 für Etra-Behälter und PIC20 - PIC27 für Karton-Behälter).
    • Workplace Simulation: Automatisierte Abwicklungs- und Routing-Simulation.
    • EtraBox Test / Carton test: Spezialisierte Testklassen zur Durchsatzmessung.

2. Strukturierte Testmatrix (Szenarien)

Die Testmatrix basiert auf den offiziellen Abnahmekriterien der Fachabteilung und stellt sicher, dass alle geschäftskritischen Betriebszustände und potenziellen Fehlerquellen abgedeckt sind.

Test-ID Szenario / Name Testfokus / Ziel Eingabe / Vorbedingung Erwartetes Ergebnis (SOLL) Ist-Ergebnis (nach Refactoring) Status
TC-01 Normale Auslagerung (Kiste steht im Lager) Nachweis der korrekten Standard-Prozessabwicklung. Ladeeinheit (LE) befindet sich im statischen Lager. Ein neuer Transportauftrag (OrdersHost) wird mit Status Initial angelegt. ConveyorDispo identifiziert den neuen Initial-Eintrag zyklisch über StartInitialOrdersHost. Der Transport wird gestartet (InProgress), das Freigabetelegramm (Departure) an den EMC Runner gesendet und die LE physisch ausgelagert. Erfolgreich durchgeführt. LE wurde ohne Latenz oder Fehler ausgelernt und transportiert. Pass
TC-02 Mehrfach-Auftrag (Kiste fährt zu Arbeitsplatz) Nachweis der korrekten Zustandskoordination bei Folgeaufträgen während der Fahrt. LE befindet sich auf dem Weg zu Arbeitsplatz A (InProgress). WMS sendet über die Schnittstelle einen Folgeauftrag für dieselbe LE im Status Initial/Pending. HostBooking fängt den neuen Auftrag ab. Da bereits ein aktiver Transport für diese LE läuft, verbleibt der neue Auftrag kontrolliert im Status Initial/Pending. Es werden keine Concurrency-Ausnahmen oder Statuskonflikte erzeugt, was die Entstehung von Datenbankleichen verhindert. Erfolgreich. Der Folgeauftrag verbleibt im Ruhezustand, bis der aktive Transport beendet ist. Pass
TC-03 Sofortiger Folgeauftrag (Rückfahrt vom Arbeitsplatz) Nachweis der prozesssicheren Übergabe via DepartureFlag zur Verhinderung von Race Conditions bei Platzabmeldungen. LE fährt vom Arbeitsplatz zurück ins Lager. Bei der Abmeldung am Arbeitsplatz-Sensor (DepartureNotification) sendet das WMS zeitgleich einen neuen Transportauftrag. Der Handler in HostBooking erzwingt keinen ungesteuerten Sofortstart mehr. Er setzt stattdessen DepartureFlag = true. ConveyorDispo liest das Flag im nächsten Arbeitszyklus aus, führt alle Ressourcen- und Kapazitätsprüfungen zentral durch und startet den Transport kontrolliert. Erfolgreich. Keine Statuskonflikte im Log. Die Startlogik verbleibt exklusiv beim ConveyorDispo. Pass
TC-04 Leerbehälter-Wechsel (HuChange-Simulation) Nachweis der korrekten Daten- und Auftragsbereinigung am Arbeitsplatz. LE wird am Arbeitsplatz leer. Über die FromWms-Schnittstelle wird eine HuChange-Nachricht (Wechsel der HU-Nummer) simuliert. Das WCS verarbeitet die HuChange-Meldung, aktualisiert die Ladeeinheiten-Stammdaten in der Datenbank, schließt den alten Transportauftrag ordnungsgemäß ab (Finished) und bereitet den Transport des neuen Leerbehälters fehlerfrei vor. Erfolgreich. Alter Auftrag wurde beendet, neuer Leerbehälter-Auftrag wurde korrekt initialisiert. Pass
TC-05 Sequenzer-Einschleusung & Kapazitätsprüfung Nachweis der gesteuerten Freigabe und Kapazitätsprüfung beim Übergang von der Vorzone in den Sequenzer (Arbeitsplatz). LE befindet sich in der Vorzone vor PIC10 im Status InDestinationZone. Ein Abmeldesignal (DepartureNotification) von der Vorzone wird über das Testtool simuliert. HostBooking schreibt das physische Ziel auf SEQ10 um und setzt DepartureFlag = true. Der OrderManager im ConveyorDispo prüft die Sequenzer-Kapazität (< 50%). Bei freier Kapazität wird der Status auf InProgress gesetzt, das Freigabetelegramm gesendet und DepartureFlag = false gesetzt. Erfolgreich durchgeführt. Kiste wurde kontrolliert in den Sequenzer überführt, Kapazitätsprüfung griff fehlerfrei. Pass

3. Detaillierte Testspezifikation

TC-01: Normale Auslagerung (Kiste steht im Lager)

  • Ziel: Nachweis der korrekten Standard-Prozessabwicklung.
  • Vorbedingungen:
    • WCS-Knoten und Testdatenbank sind aktiv.
    • Ladeeinheit (z. B. LE 10000001) steht im physikalischen Lagerbereich (Aisle 1).
    • Es liegt kein aktiver Transportauftrag für diese LE vor.
  • Testschritte:
    1. Im WcsTestTool im Tab Test Orders oder direkt über die WMS-Schnittstelle einen neuen Transportauftrag (OrdersHost) für die LE 10000001 anlegen. Ziel: Arbeitsplatz PIC10. Status: Initial.
    2. Das Systemlog überwachen.
  • Erwartetes Verhalten (SOLL):
    • Der zyklische Prozess StartInitialOrdersHost im ConveyorDispo identifiziert den neuen Auftrag.
    • Da die LE im Lager verfügbar ist und die Kapazitäten ausreichen, ruft der Prozess _transportOrderService.ScheduleOrdersHost auf.
    • Der Status des Auftrags wechselt auf Pending und anschließend auf InProgress.
    • Das Freigabetelegramm (Departure) wird erfolgreich an den EMC Runner/Emulator übermittelt.
    • Die LE bewegt sich physisch im Emulator in Richtung PIC10.
  • Tatsächliches Verhalten (IST):
    • StartInitialOrdersHost erkennt den Auftrag sofort und startet ihn im nächsten Arbeitszyklus. Die LE wird fehlerfrei ausgelagert und zu PIC10 transportiert.
  • Status: Pass

TC-02: Mehrfach-Auftrag (Kiste fährt zu Arbeitsplatz)

  • Ziel: Nachweis der korrekten Zustandskoordination bei Folgeaufträgen während der Fahrt.
  • Vorbedingungen:
    • LE 10000002 befindet sich aktuell auf der Fördertechnik auf dem Weg zu Arbeitsplatz PIC11.
    • Der zugehörige Transportauftrag hat den Status InProgress.
  • Testschritte:
    1. Über die WMS-Schnittstelle einen neuen Folgeauftrag (OrdersHost) für dieselbe LE 10000002 mit Ziel PIC12 anlegen. Der Status des neuen Auftrags ist Initial.
    2. Das Systemlog und die Datenbanktabellen auf DbUpdateConcurrencyException oder fehlerhafte Statusänderungen prüfen.
  • Erwartetes Verhalten (SOLL):
    • Der neu angelegte Auftrag für LE 10000002 verbleibt kontrolliert im Status Initial.
    • HostBooking oder andere Prozesse dürfen den neuen Auftrag nicht ungesteuert aktivieren oder Status-Updates erzwingen, solange der aktive Transport läuft.
    • Es treten keine Datenbankkonflikte auf.
  • Tatsächliches Verhalten (IST):
    • Der Folgeauftrag bleibt im Ruhezustand (Initial) und wird mit der Info "Le has transports that are started first." versehen. Nach dem Abschluss des ersten Transports an PIC11 wird der Nachfolgeauftrag kontrolliert freigegeben.
  • Status: Pass

TC-03: Sofortiger Folgeauftrag (Rückfahrt vom Arbeitsplatz)

  • Ziel: Nachweis der prozesssicheren Übergabe via DepartureFlag zur Verhinderung von Race Conditions bei Platzabmeldungen.
  • Vorbedingungen:
    • LE 10000003 befindet sich an Arbeitsplatz PIC12.
    • Der aktive Transportauftrag zu PIC12 ist im Status InDestinationZone (oder InProgress).
    • Ein neuer Folgeauftrag für die Rückfahrt ins Lager (OrdersHost zu Ziel AISLE01) liegt im Status Initial vor.
  • Testschritte:
    1. Im WcsTestTool den Tab Workplace Depature öffnen.
    2. Unter PIC12 die Ladeeinheit 10000003 eintragen und den Button PIC12 klicken, um die physische Platzabmeldung zu simulieren.
    3. Die Telegrammkommunikation und den Status der Aufträge in der DB überwachen.
  • Erwartetes Verhalten (SOLL):
    • Der DepartureNotificationHandler in HostBooking fängt das Abmeldesignal ab.
    • Anstatt den Folgeauftrag direkt selbst zu starten und ein Telegramm abzusetzen, setzt der Handler lediglich das DepartureFlag = true auf dem Initial-Auftrag in der Datenbank.
    • Der ConveyorDispo (Prozess OrderManager) liest das Flag im nächsten Arbeitszyklus aus, validiert die Ressourcen und Kapazitäten zentral, sendet das Freigabetelegramm (Departure) und setzt das Flag zurück auf false.
    • Es entsteht keine Race Condition und kein paralleler Startversuch.
  • Tatsächliches Verhalten (IST):
    • Das Signal wird sauber an den ConveyorDispo übergeben. Es gibt keine Fehlermeldungen im Log. Die Startlogik verbleibt exklusiv und kontrolliert im Dispatcher.
  • Status: Pass

TC-04: Leerbehälter-Wechsel (HuChange-Simulation)

  • Ziel: Nachweis der korrekten Daten- und Auftragsbereinigung am Arbeitsplatz.
  • Vorbedingungen:
    • LE 10000004 befindet sich am Kommissionierarbeitsplatz PIC13 und wird dort komplett geleert.
  • Testschritte:
    1. Über die FromWms-Schnittstelle eine HuChange-Nachricht (Wechsel der Handling Unit) für den Platz PIC13 einspielen, um zu simulieren, dass der volle Behälter entnommen und ein neuer Leerbehälter mit einer neuen Nummer aufgesetzt wurde.
    2. Den Lebenszyklus der betroffenen Transportaufträge prüfen.
  • Erwartetes Verhalten (SOLL):
    • Das WCS verarbeitet die HuChange-Meldung und schließt den alten Transportauftrag für LE 10000004 ordnungsgemäß mit dem Status Finished ab.
    • Der neue Leerbehälter-Auftrag wird korrekt initialisiert, die LE-Stammdaten werden in der DB aktualisiert.
    • Der Abtransport des leeren Behälters wird fehlerfrei vorbereitet.
  • Tatsächliches Verhalten (IST):
    • Der alte Auftrag wird sofort auf Finished gesetzt, die neue HU-Nummer wird registriert, und der neue Transportauftrag wird sauber vorbereitet und im Dispo-Prozess eingeplant.
  • Status: Pass

TC-05: Sequenzer-Einschleusung & Kapazitätsprüfung (Vorzonen-Szenario)

  • Ziel: Nachweis der gesteuerten Freigabe und Kapazitätsprüfung beim Übergang von der Vorzone in den Sequenzer (Arbeitsplatz).
  • Vorbedingungen:
    • WCS-Knoten und Testdatenbank sind aktiv.
    • LE 10000005 befindet sich in der Vorzone vor PIC10.
    • Der zugehörige Transportauftrag hat den Status InDestinationZone.
  • Testschritte:
    1. Im WcsTestTool im Tab Workplace Depature das Abmeldesignal (DepartureNotification) für den Pufferplatz simulieren, an dem die LE 10000005 steht.
    2. Die Datenbank-Einträge (Tabelle Wcs.OrdersHost) und die Telegrammkommunikation im Semic-Runner überwachen.
  • Erwartetes Verhalten (SOLL):
    • Der DepartureNotificationHandler in HostBooking fängt das Signal ab, ändert das physische Ziel (Destination) des Auftrags auf den Sequenzer (SEQ10), setzt DepartureFlag = true und speichert.
    • Der OrderManager im ConveyorDispo liest dieses Flag zyklisch aus.
    • Er prüft die Auslastung des Sequenzers SEQ10 (< 50%). Bei freier Kapazität setzt er den Status des Auftrags auf InProgress, setzt DepartureFlag = false und sendet das Freigabetelegramm (Departure) an den Emulator.
  • Tatsächliches Verhalten (IST):
    • Erfolgreich durchgeführt. Die Kiste wurde kontrolliert in den Sequenzer geschleust, sobald Kapazität vorhanden war. Keine ungesteuerten Sofortstarts und vollständige Einhaltung der Kapazitätsbegrenzung.
  • Status: Pass

4. Last- und Concurrency-Tests (Load Targets)

Um die absolute Zuverlässigkeit der geänderten Steuerungsprozesse unter realen Betriebsbedingungen nachzuweisen, wurde das System im Emulator drei definierten Belastungsstufen ausgesetzt:

1. Stufe 1: Nennlast (Baseline-Test)

  • Ziel: Nachweis der allgemeinen Systemstabilität im Normalbetrieb über einen längeren Zeitraum.
  • Lastprofil: 1.200 Behälterbewegungen pro Stunde (ca. 1 Telegramm alle 3 Sekunden).
  • Testergebnis: Das System lief über einen Testzeitraum von 2 Stunden absolut stabil. Alle Übergaben via DepartureFlag wurden latenzfrei abgearbeitet.

2. Stufe 2: Spitzenlast (Peak-Load-Test)

  • Ziel: Simulation von extremem Maximaldurchsatz (z. B. Saisongeschäft).
  • Lastprofil: 3.600 Behälterbewegungen pro Stunde (1 Telegramm pro Sekunde).
  • Testergebnis: Das Ressourcen-Throttling an den Sequenzern regelte die Materialflüsse fehlerfrei herunter. Es kam zu keinem physikalischen Stau auf den Rollenbahnen oder Systemstillständen. Die Kapazitätsbegrenzung (z. B. 50% max. Auslastung an den Sequenzern) funktionierte präzise.

3. Stufe 3: Burst-Last (Concurrency-Test)

  • Ziel: Gezieltes Erzeugen von Parallelzugriffen zur Verifizierung der Thread-Safety.
  • Lastprofil: Ein stetiger Burst von 10 identischen DepartureNotification-Telegrammen innerhalb von 100 Millisekunden für dieselbe LE an derselben Position unter gleichzeitiger Abwicklung von Standardtransporten.
  • Testergebnis: Während dieser Test im IST-Zustand zuverlässig zu DbUpdateConcurrencyExceptions im dezentralen HostBooking-Prozess und somit zu unvollständigen Datenbank-Auftragsleichen führte, blockierte die neue Flag-basierte Implementierung im SOLL-Zustand jegliche Concurrency-Konflikte. Es traten keinerlei Fehler auf.
Reference in New Issue View Git Blame Copy Permalink