refactor: migrate project structure by reorganizing realization code snippets into documentation and analysis categories.
This commit is contained in:
154
04_Testing/Testcases.md
Normal file
154
04_Testing/Testcases.md
Normal file
@@ -0,0 +1,154 @@
|
||||
# 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
Block a user