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