ankn
a5f8fb49ab
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)
Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
2.9 KiB
Systemintegrationstests für BS â IFP-SST
Confluence Page ID: 206667964 Version: 11 Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/QA Themen/Systemintegrationstests für BS â IFP-SST Labels: meeting-notes
Teilnehmer: Â
Was soll genau mit SITs getestet werden? das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-1614   Relevante Aktionen zwischen BS und realen externen Partner zu testen. Pro Schnittstelle mind. ein Positiv und ein Negativfall testen.   Die Tests werden möglichst einen kleinen Teil des Ablauf im BS testen. In diesem Fall SV<->IFP
Akzeptanzkriterien von https://nvi.jaas.service.deutschebahn.com/browse/O2CCIB-1614 :
- Die Definition /Umfang von SIT ist für die IFP-SSTs geklärt
- Die bereits definierten Systemintegrationstestfälle wurden ggf. überarbeitet bzw. Aktualisiert
Die Tests müssen minimal die Kommunikation zwischen SV und IFP testen(Aufgrund Kosten der höheren Teststufen) Stand der Testfälle aus TK: Die vorhandene Regressionstestfälle im Testkonzept sind sehr umfangreich für Systemintegrationstest.
Testfall: Ein konstruierbarer/nicht konstruierbarer Produktionsauftrag/Ãnderungsanmeldung(in TDM Format) wird von Steuerungsvertrieb an IFP geschickt. Beispiel für den Negativfall: Pflichtangaben fehlen. AnschlieÃend wird die Anfrage abgelehnt. Vorerst kein negativer Testfall.
Anforderungen an Testfall:
- Der erste Testfall soll SQS testen und der zweite Testfall S3
- Die Nachrichten von SV(mit Trassenanmeldung API)Â an IFP schicken
Bzgl. beteiligten Prozesse: Ãberlegung: Die BEP und AC für SIT werden wir nicht aufnehmen( Das kann gemockt werden) Idee: Sub-Prozesse direkt im Test starten und dadurch die Nachricht an IFP über Camunda API versenden. Ziel: Wir testen mit echtem Schnittstellen-Code auf SIT Umgebung. Ohne Code Ãnderung den Test durchführen. Z.B Prozess kopieren und den BEP-Aufruf weglassen. Die Datenbank auf SIT wird nicht migriert.
Damit keine manuelle Aktion benötigt wird:Â
- IFP erstellt statisch Angebote und SV Schickt Annahme für die von uns bekannten Aufträge
- Wir schicken eine Trassenanmeldung, die nicht konstruierbar ist.
Zusätzliche HealthChecks (Springboot, Kub Healthchecks)-> Ãberprüfen, ob die Nachricht verschickt und Response zurück kommt. Queue stellt sicher, dass die Nachrichten nicht verloren gehen. Daher verzichten wir von dieser doppelter Ãberprüfung. Bessere Alternative: Queuegrosse überprüfen (Gelegenheitsverkehr) -> vorerst nicht geplant Generieren von pathID für periodische Tests Durchführung (mit IFP abstimmen z.B für die Erstanmeldungen -> An Christian Meins )
TODOs:
- Der Testfall ist mit IFP zu klären(Jahan hält Absprache mit , um den Testfall mit IFP abzusimmen)Â
- Alexander kümmert sich um die Prozesse für den Testfall