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