Workflow-Integrationstests: Testfälle, Tools & Best Practices
Doppelte Abbuchungen und verlorene Bestellungen sind typische Integrationsfehler in verteilten Systemen. Sie treten auf, wenn Daten zwischen Services in der falschen Reihenfolge gesendet werden oder eine Bestätigung verloren geht. Für Ihr Team sind diese Bugs schwer zu finden, weil Unit Tests bestehen und API-Aufrufe immer noch 200 OK zurückgeben. Infolgedessen taucht der Fehler oft erst in der Produktion auf, wo das Nachverfolgen einer Bestellung über mehrere Service-Logs Stunden dauern kann. In diesem Leitfaden erfahren Sie, wie Workflow-Integrationstests funktionieren, und erhalten 44 Testfälle mit Referenzdaten und erwarteten Ergebnissen. Zusammen damit finden Sie Best Practices und Tools, die Ihr Team beim nächsten Release anwenden kann.
Workflow-Integrationstests decken Fehler auf, die nur auftreten, wenn verbundene Services einen vollständigen Geschäftsprozess gemeinsam ausführen.
Der Workflow für Integrationstests läuft vom initialen Trigger bis zur finalen Assertion in jedem teilnehmenden System.
Die 44 Testfälle decken den Hauptpfad sowie die Fehlerbehandlung ab, jeweils mit Referenzdaten und einem erwarteten Ergebnis.
Mehrdeutige Fehler an Integrationsgrenzen, wie eine verlorene Zahlungsbestätigung oder ein doppeltes Event, benötigen dedizierte Testfälle mit Fault Injection.
Prozesslogik-Tests gehören in jeden Commit, während vollständige End-to-End-Tests für umsatzrelevante Journeys vor dem Release reserviert sind.
Was sind Workflow-Integrationstests?
Bei Workflow-Integrationstests überprüfen Sie, dass verbundene Services und ihre Datenbanken gemeinsam einen vollständigen Geschäftsprozess abschließen, mit konsistenten Daten nach jedem Schritt. Ein Workflow bedeutet hier die Abfolge von Operationen hinter einem Geschäftsergebnis, wie das Aufgeben einer Bestellung oder die Genehmigung eines Kredits.
Jede Komponente in dieser Sequenz kann ihre eigenen Tests bestehen und dennoch den Prozess unterbrechen. Zum Beispiel könnte der Order Service einen Betrag in Cent senden, während der Payment Service einen Dezimalwert erwartet, was die Abbuchung mit 100 multipliziert.
Testtyp
Fokus
Typische Prüfung
Integrationstests
Datenaustausch zwischen zwei oder mehr Komponenten
Der Order Service sendet eine gültige Zahlungsanfrage an den Payment Service
Workflow-Integrationstests
Ein Geschäftsprozess über alle teilnehmenden Systeme hinweg
Die Bestellung endet als „bezahlt“ mit übereinstimmenden Einträgen in Payment und Inventory
End-to-End-Tests
Die vollständige User Journey in einer deployed Umgebung
Ein Kunde schließt einen Kauf im Browser ab und erhält eine Bestätigungs-E-Mail
In der Praxis kombinieren Workflow-Integrationstests Elemente der ersten beiden Stufen. Für eine breitere Sicht darauf, wie sich Teststufen unterscheiden, siehe unseren Leitfaden zu functional vs integration testing.
Wie Workflow-Integrationstests funktionieren
KI-generiertes Bild.
Workflow-Integrationstests beginnen mit einer Geschäftsprozessdefinition und ordnen zu, welches System welche Phase besitzt. Danach führen Sie den Prozess so aus, wie es ein echter Benutzer oder Event tun würde, und prüfen den Zustand in jeder Phase. Typischerweise durchläuft der Workflow für Integrationstests diese Phasen:
Workflow triggern mit derselben Aktion, die die Produktion nutzt, wie eine Bestellübermittlung oder ein veröffentlichtes Event.
Zwischenzustände beobachten, um sicherzustellen, dass die erwarteten Services die Anfrage im richtigen Format erhalten.
Integrationsgrenzen validieren, indem API-Antworten und Datenbanktransaktionen bei jeder Übergabe geprüft werden.
Entscheidungen und Ausnahmen bewerten, einschließlich bedingter Verzweigungen und Retry-Policies.
Finales Ergebnis assertieren in jedem teilnehmenden System, einschließlich Systemen, die die ursprüngliche Anfrage nie erhalten haben.
Die finale Assertion muss gespeicherte Geschäftsdaten abdecken, weil ein 200 OK nach Bestellübermittlung nicht beweist, dass Inventory reserviert wurde. Aus diesem Grund vergleicht Ihr Team den persistierten Bestellstatus mit dem Zahlungseintrag. Danach bestätigen Sie, dass die Fulfillment-Anfrage veröffentlicht wurde.
Workflow-Diagramm für Integrationstests
Ein Workflow-Diagramm für Integrationstests zeigt die Sequenz der Teststufen und die Daten, die bei jedem Schritt zwischen Systemen übertragen werden. Bevor Sie Tests schreiben, zeigt ein system integration testing Workflow-Diagramm Ihrem Team, welche Integrationspunkte Abdeckung benötigen.
Für verteilte Systeme markiert ein nützliches Workflow-Diagramm für Software-Integrationstests die folgenden Elemente, da jedes einer Gruppe von Testfällen entspricht:
Entry Points wie ein API-Call oder ein geplanter Job, weil jeder Trigger seinen eigenen Test benötigt
Service-Übergaben, wo Feldmappings brechen können
Message Broker wie Kafka oder RabbitMQ, wo Events zu spät oder zweimal ankommen können
Irreversible Schritte wie Payment Capture, die Fehlertests auf beiden Seiten benötigen
Der erwartete Endzustand in jedem System, den Ihr Team für die finale Assertion nutzt
Sobald das Diagramm fertig ist, halten Sie den Workflow für Software-Integrationstests an einem Ort dokumentiert und aktualisieren Sie das Diagramm, wann immer sich Ihre Architektur ändert. Als Ergebnis können neue Teammitglieder jeden Testfall zurück zur Grenze verfolgen, die er abdeckt.
Ein Order-to-Cash-Workflow benötigt bereits 44 Testfälle, und eine vollständige Anwendung fügt viele weitere hinzu. aqua cloud, eine KI-gestützte Test- und Anforderungsmanagement-Lösung, hält sie alle in einem Repository. Mit verschachtelten Testfällen definiert Ihr Team gemeinsame Schritte, wie das Order-Setup, einmalig. Wenn sich ein gemeinsamer Schritt ändert, erreicht das Update jeden Testfall, der ihn nutzt. Zusätzlich generiert aqua Intelligence, eine RAG-basierte KI, projektspezifische Testfälle aus Ihren Anforderungen in Sekunden. Da die KI aus Ihrer hochgeladenen Dokumentation arbeitet, nutzen die generierten Cases Ihre Service-Namen und API-Contracts. Währenddessen bleiben Ihre Projektdaten in einer sicheren Umgebung, und Benutzer sparen durchschnittlich 12,8+ Stunden pro Woche. Bidirektionales Jira-Sync und die Azure DevOps-Integration halten den Teststatus neben Ihren Tickets. Schließlich zeichnet Capture jeden Workflow-Lauf mit Video und Screenshots auf, sodass Ihr Team Nachweise an Fehlerberichte anhängen kann.
Generieren Sie projektspezifische Workflow-Integrationstestfälle 97% schneller mit aqua Intelligence
Workflow-Typen unterscheiden sich darin, wie ihre Schritte ablaufen, sodass jeder Typ zu einem anderen Zeitpunkt scheitern kann. Folglich benötigt Ihr Team für jeden einen anderen ersten Test:
Sequenzielle Workflows wie die Rechnungsverarbeitung führen Schritte in fester Reihenfolge aus. Hier ist das Hauptrisiko eine spätere Phase, die mit unvollständigen Daten aus einer früheren beginnt.
Bedingte Workflows leiten Anfragen nach Geschäftsregeln weiter. Bei der Spesenabrechnung benötigt beispielsweise der exakte Schwellenwert seinen eigenen Test, da ein Off-by-One-Vergleich Anträge über dem Limit ohne Review genehmigt.
Parallele Workflows führen Schritte gleichzeitig aus, z.B. Identitätsprüfung und Sanktions-Screening während des Financial Onboarding. In diesem Fall testen Sie, was passiert, wenn ein Zweig nach Abschluss der anderen ein Timeout hat.
Event-gesteuerte Workflows tauschen Nachrichten über Broker wie Kafka aus, was standardmäßig At-Least-Once-Delivery garantiert, laut der Confluent-Dokumentation. Infolgedessen benötigen doppelte Events ihre eigenen Testfälle.
Human-in-the-Loop-Workflows warten auf eine Person, wie einen Compliance-Officer, der einen Fall genehmigt. Da diese Schritte Tage dauern können, verwendet Ihr Team eine kontrollierte Test-Clock, um die Eskalation nach der Deadline zu prüfen.
Testfälle für Workflow-Integrationstests
KI-generiertes Bild.
Testfälle für Workflow-Integrationstests decken die Punkte ab, an denen Systeme Arbeit aneinander übergeben, sowohl unter normalen als auch unter Fehlerbedingungen. Alle Cases in diesem Abschnitt nutzen einen Referenz-Workflow, einen Order-to-Cash-Prozess mit fünf Services, die über Kafka verbunden sind:
Schritt
Service
Veröffentlichtes Event
Referenz-Testdaten
1
Order Service
OrderCreated
Bestellung ORD-1001: 2 × SKU-4471 zu €49,95, 1 × SKU-2210 zu €50,00, Gesamt €149,90
2
Payment Service (Stripe Test Mode)
PaymentCaptured
Betrag 14990 in Cent, Währung EUR
3
Inventory Service
StockReserved
SKU-4471 Bestand 10, SKU-2210 Bestand 1
4
Fulfillment Service
ShipmentCreated
Lieferadresse Königsallee 1, 40212 Düsseldorf
5
Notification Service
Keines
Eine Bestätigungs-E-Mail pro Bestellung
Die erwartete Bestellstatus-Sequenz ist CREATED → PAID → RESERVED → SHIPPED. Daher beziehen sich alle Testfälle auf diese Status, und das erwartete Ergebnis enthält das System, wo Ihr Team sie prüft.
Basis-Testfälle für Workflow-Integrationstests
Basis-Testfälle decken den Hauptpfad von Bestellübermittlung bis Versand ab. Führen Sie diese Gruppe zuerst aus, weil ein Fehler hier die Ergebnisse späterer Gruppen unzuverlässig macht:
TC-WF-01: Gültige Bestellung aufgeben. ORD-1001 mit den Referenzdaten übermitteln. Die Bestellung sollte als SHIPPED enden, und das Stripe-Test-Dashboard sollte eine Zahlung von €149,90 zeigen.
TC-WF-02: Statusverlauf prüfen. Den Statuslog der Bestellung nach TC-WF-01 lesen. Sie sollten genau vier Übergänge in der erwarteten Sequenz sehen, ohne übersprungenen oder wiederholten Status.
TC-WF-03: Bestandsänderungen verifizieren. Nach TC-WF-01 sollte SKU-4471 von 10 auf 8 Einheiten fallen und SKU-2210 von 1 auf 0. Ein Fall auf 6 bedeutet, dass die StockReserved-Logik zweimal lief.
TC-WF-04: Daten über Phasen hinweg transportieren. Die Lieferadresse im ShipmentCreated-Payload mit dem Checkout-Input vergleichen. „Königsallee“ muss intakt ankommen, weil ein UTF-8-Encoding-Fehler es als „Königsallee“ auf dem Versandetikett ausgibt.
TC-WF-05: Mittendrin abbrechen. ORD-1001 nach PAID und vor SHIPPED stornieren. Erwarten Sie eine Stripe-Rückerstattung von €149,90 und den Status CANCELLED, während der SKU-4471-Bestand auf 10 zurückkehrt.
TC-WF-06: Eine Bestätigung senden. Nach TC-WF-01 sollte der Kunde genau eine E-Mail erhalten, und die Summe darin sollte mit dem Zahlungseintrag übereinstimmen.
Einer meiner frühesten Fehler war der Versuch, E2E-Tests zu schreiben, die alles abdecken. Je mehr wir hatten, desto unzuverlässiger wurde die Pipeline. Kürzlich haben wir die Hälfte der Test-Suite eliminiert, alles, was möglich ist, früher in die Feedback-Schleife verschoben (Component/Unit-Tests mit Vitest) und nur die Hauptflows als wirklich E2E behalten. Schnelleres Feedback, stabilere Pipeline, gleiches Vertrauenslevel.
Datenfluss-Testfälle zeigen, ob Informationen ihre Bedeutung behalten, wenn sie eine Service-Grenze überschreiten. Leere und unerwartete Felder benötigen hier besondere Sorgfalt. Laut The Registers Bericht über den Google Cloud-Ausfall im Juni 2025 ließ eine Policy-Änderung mit unbeabsichtigten leeren Feldern Service Control abstürzen. Der fehlerhafte Code-Pfad war während des Rollouts nie durchlaufen worden.
TC-DF-01 · Betragsmapping
Input: Der Order Service sendet eine Summe von 149,90 EUR.
Erwartet: Stripe erhält 14990, da seine API Beträge in der kleinsten Währungseinheit nimmt, und der Finance-Export zeigt 149,90.
TC-DF-02 · Schema-Evolution
Input: Eine neue OrderCreated-Version fügt ein optionales Feld hinzu, giftWrap.
Erwartet: Consumer auf dem alten Schema verarbeiten weiter, und Confluent Schema Registry im BACKWARD-Mode lehnt eine Breaking Change wie eine entfernte customerId ab.
TC-DF-03 · Trace-Propagierung
Input: Die Checkout-Anfrage trägt einen W3C-Traceparent-Header.
Erwartet: Dieselbe Trace-ID erscheint in den Logs aller fünf Services und in den Kafka-Message-Headern.
TC-DF-04 · Konsistente Validierung
Input: Postleitzahl 4021, ein vierstelliger Wert, während deutsche Postleitzahlen fünf Stellen haben.
Erwartet: Checkout lehnt sie vor der Zahlung ab, weil die Carrier-API sie erst nach Zahlung des Kunden ablehnen würde.
TC-DF-05 · Eventual-Consistency-Fenster
Input: 2 Einheiten von SKU-4471 reservieren.
Erwartet: Das Inventory-Read-Model zeigt 8 Einheiten innerhalb von 5 Sekunden, sodass der Test in 500-ms-Intervallen pollt und nach dem Limit fehlschlägt.
API-Integrationstestfälle
API-Integrationstestfälle decken die Requests und Responses zwischen Services ab. Vor dem Lauf definiert Ihr Team den erwarteten Statuscode und Bestellstatus, sodass das Ergebnis automatisch verglichen werden kann:
TC-API-01 Zahlungsanfrage ohne das Currency-Feld senden → Erwartet: 400 Bad Request mit einem Fehler auf Feldebene, während die Bestellung CREATED bleibt und kein Retry feuert.
TC-API-02 Den Payment-Stub eine HTML-502-Seite ohne JSON-Body zurückgeben lassen → Erwartet: Der Order Service loggt einen Parse-Fehler mit der Trace-ID und markiert den Schritt als retryable ohne Crash.
TC-API-03 503 von der Payment-API zurückgeben, dann 422 bei einem zweiten Lauf → Erwartet: Die 503 triggert einen Retry, während die 422 den Schritt fehlschlagen lässt und die Bestellung auf PAYMENT_FAILED setzt.
TC-API-04 HTTP 429 mit dem Header Retry-After: 30 zurückgeben → Erwartet: Der nächste Call geht nicht früher als 30 Sekunden später raus.
TC-API-05 Payment-Response auf 12 Sekunden verzögern mit einem 10-Sekunden-Client-Timeout → Erwartet: Der Retry verwendet denselben Idempotency-Key, sodass Stripe eine Abbuchung verzeichnet.
TC-API-06 Drei aufeinanderfolgende 503-Fehler zurückgeben → Erwartet: Retries folgen Exponential Backoff ab 1 Sekunde, stoppen dann nach dem dritten Versuch und lösen einen Alert aus.
Testfälle für Workflow-Fehlerbehandlung
Fehlerbehandlungs-Testfälle zeigen, ob ein Fehler Ihre Daten konsistent und den Workflow wiederherstellbar hinterlässt. Die ersten beiden Cases betreffen mehrdeutige Ergebnisse, wo ein System Erfolg verzeichnet und ein anderes nicht. Aus diesem Grund benötigen sie schrittweises Setup:
TC-ERR-01: Verlorene Zahlungsbestätigung
Stripe Test Mode €149,90 für ORD-1001 capturen lassen.
Die Response auf dem Rückweg mit einem Fault-Proxy, z.B. Toxiproxy, droppen.
Dem Payment Service erlauben, mit dem ursprünglichen Idempotency-Key zu retrying.
Erwartet: Stripe zeigt eine Abbuchung, und die Bestellung wechselt einmal zu PAID.
TC-ERR-02: Inventory schlägt nach Payment fehl
Payment für ORD-1001 abschließen.
SKU-2210-Bestand auf 0 setzen, bevor der Reservierungsschritt läuft.
Erwartet: Der Kompensationsschritt erstattet €149,90 zurück und setzt die Bestellung auf CANCELLED. Danach erhält der Kunde eine Stornierungsmail.
Die verbleibenden Cases benötigen weniger Setup:
TC-ERR-03: Crash zwischen Commit und Publish. Den Order Service direkt nach dem Datenbank-Commit und vor Aussenden von OrderCreated stoppen. Mit einer Transactional Outbox wird das Event nach Neustart veröffentlicht. Ohne eine bleibt die Bestellung in CREATED, und der Test enthüllt die fehlende Outbox.
TC-ERR-04: Poison Message. Ein fehlerhaftes PaymentCaptured-Event veröffentlichen. Der Consumer sollte dreimal retrying und es dann in ein Dead-Letter-Topic wie payments.DLQ verschieben, während die nächsten Messages weiter fließen.
TC-ERR-05: Doppeltes Event. PaymentCaptured zweimal mit derselben Event-ID veröffentlichen. Bestand für SKU-4471 sollte einmal auf 8 fallen, und das zweite Event sollte als Duplikat geloggt werden.
TC-ERR-06: Secondary-Service-Ausfall. Den Notification Service für 10 Minuten herunterfahren. Bestellungen sollten trotzdem SHIPPED erreichen, und die gepufferten E-Mails sollten nach der Wiederherstellung rausgehen.
Authentifizierungs- und Autorisierungstestfälle
NISTʼs Guidelines vom Juni 2025 für API-Schutz in Cloud-Native-Systemen empfehlen Controls über den gesamten API-Lifecycle, sowohl vor als auch während der Runtime. Aus diesem Grund können Sicherheitsprüfungen in derselben Suite wie funktionale Workflow-Tests laufen. Auf den Referenz-Workflow angewendet, führen diese Controls zu folgenden Cases:
TC-SEC-01: Den Payment Service ohne Service-Token aufrufen. Er sollte 401 Unauthorized zurückgeben und keine Bestelldaten preisgeben.
TC-SEC-02: Ein JWT mit 5-Minuten-Ablauf für einen Approval-Schritt verwenden, der 10 Minuten später läuft. Der Service sollte das Token über den OAuth 2.0 Client Credentials Flow erneuern und fortfahren.
TC-SEC-03: Den Approve-Endpoint für ORD-1001 als User mit Viewer-Rolle aufrufen. Erwarten Sie 403 Forbidden und einen unveränderten Bestellstatus.
TC-SEC-04: Als Kunde A die Bestellung von Kunde B per ID anfordern. Die API sollte 403 oder 404 zurückgeben, weil gebrochene Object-Level-Authorization auf Platz eins der OWASP API Security Top 10 rangiert.
TC-SEC-05: Eine Rückerstattung als Support-Agent triggern. Das Audit-Log sollte die Agent-ID als Initiator verzeichnen, da eine Service-Account-ID verbirgt, wer die Rückerstattung genehmigte.
Testfälle für Drittanbieter-Integrationen
Drittanbieter-Integrationen benötigen eine separate Gruppe, weil Sie weder deren Uptime noch deren Release-Zeitplan kontrollieren. Laut Uptime Institutes 2025 Annual Outage Analysis machen Third-Party-IT- und Rechenzentrumsanbieter etwa zwei Drittel der öffentlich gemeldeten Ausfälle über neun Jahre aus. Die meisten dieser Cases laufen gegen Vendor-Sandboxen wie Stripe Test Mode:
TC-3P-01: Abgelehnte Karte. Mit Stripe-Testkarte 4000 0000 0000 0002 zahlen. Bestehen wenn: Die Bestellung endet als PAYMENT_FAILED und Bestand bleibt unberührt.
TC-3P-02: Unzureichende Deckung. Mit Testkarte 4000 0000 0000 9995 zahlen. Bestehen wenn: Der insufficient_funds-Decline-Code auf eine klare Kundennachricht mappt.
TC-3P-03: Manipulierter Webhook. Ein Feld in einem signierten Webhook-Payload ändern. Bestehen wenn: Ihr Endpoint ihn mit 400 ablehnt, und der Bestellstatus sich nicht ändert.
TC-3P-04: Wiederholter Webhook. Einen gültigen Webhook älter als 5 Minuten, die Default-Toleranz in Stripes Libraries, erneut senden. Bestehen wenn: Die Signaturprüfung ihn ablehnt.
TC-3P-05: Fehlender Callback. Den „delivered“-Webhook des Carriers blocken. Bestehen wenn: Die Bestellung wird nach dem vereinbarten Limit, z.B. 72 Stunden, für manuelle Nachverfolgung markiert.
TC-3P-06: API-Versions-Upgrade. Den aktuellen Stripe-Version-Header pinnen, dann die Suite gegen die nächste Version in der Sandbox laufen lassen. Bestehen wenn: Contract-Tests Breaking Changes vor dem Production-Upgrade markieren.
Negative Testfälle für Workflow-Integrationstests
In negativen Testfällen übermitteln Sie ungültigen Input oder ungewöhnliches Timing und prüfen, dass der Workflow ihn ablehnt, bevor Daten beschädigt werden. Race Conditions benötigen dedizierte Cases, da sie selten in sequenziellen Testläufen erscheinen. The Registers Analyse des AWS-Ausfalls im Oktober 2025 führt ihn auf eine latente Race Condition zwischen zwei Automatisierungskomponenten zurück. Diese Race ließ einen DynamoDB-Endpoint mit einem leeren DNS-Eintrag zurück.
TC-NEG-01 | Input: Menge 0, dann −1 | Erwartet: 422 Unprocessable Entity, und kein Bestelleintrag wird erstellt
TC-NEG-02 | Input: Menge 99 und 100 mit einem Limit von 99 | Erwartet: 99 besteht, während 100 mit einer klaren Limit-Nachricht fehlschlägt
TC-NEG-03 | Input: Der String '; DROP TABLE orders;-- in der Bestellnotiz | Erwartet: Der Text wird als Literalwert gespeichert, und die Orders-Tabelle bleibt intakt
TC-NEG-04 | Input: Zwei parallele Bestellungen für die letzte Einheit von SKU-2210 | Erwartet: Eine Bestellung gelingt, die andere erhält 409 Conflict, und Bestand geht nie unter 0
TC-NEG-05 | Input: Eine Versandanfrage für ORD-1001, während sie noch CREATED ist | Erwartet: 409 Conflict, und kein Versandetikett wird generiert
TC-NEG-06 | Input: 20 parallele Bestellungen mit dem Datenbank-Pool begrenzt auf 2 Verbindungen | Erwartet: Anfragen warten oder geben 503 mit Retry-After zurück, und keine halb erstellten Bestellungen bleiben übrig
End-to-End-Workflow-Integrationstests
End-to-End-Workflow-Integrationstests führen einen vollständigen Geschäftsprozess vom ersten Trigger bis zum finalen Ergebnis in einer produktionsähnlichen Umgebung aus. Weil sie gegen deployed Services laufen, enthüllen sie Fehler, die gemockte Komponententests verpassen. Jedoch ist jeder Lauf langsamer und teurer, halten Sie diese Suite also klein und beschränken Sie sie auf umsatzrelevante Journeys:
TC-E2E-01: Checkout bis Lieferung. Ein Kunde kauft ORD-1001 im Browser, und der Flow läuft durch Stripe Test Mode und das Warehouse zur Carrier-Sandbox. Am Ende sollten die Finance- und Warehouse-Systeme beide zur Bestellsumme von €149,90 passen.
TC-E2E-02: Dieselbe Rücksendung, zwei Kanäle. Eine Rücksendung in der Mobile App und eine identische in der Admin Console starten. Beide sollten denselben Rückerstattungsbetrag und dieselbe Bestandskorrektur produzieren.
TC-E2E-03: Broker-Neustart. Einen Kafka-Broker neustarten, während 50 Bestellungen in Bearbeitung sind. Alle 50 sollten SHIPPED erreichen ohne doppelte Zahlungen.
TC-E2E-04: Datenbank-Failover. Ein Primary-Datenbank-Failover während des Payment-Schritts triggern. Der Workflow sollte auf dem Replica mit einer Zahlung pro Bestellung fortsetzen.
Für Finanzinstitute in der EU haben Wiederherstellungsszenarien wie TC-E2E-04 auch eine regulatorische Seite. Artikel 25 des Digital Operational Resilience Act, anwendbar seit 17. Januar 2025, listet End-to-End-Tests und szenariobasierte Tests unter den angemessenen Tests für ein Resilience-Testing-Programm.
In ERP-Umgebungen kreuzen End-to-End-Flows wie Order-to-Cash mehrere SAP-Module, sodass Ihr Team modulspezifische Checks zu dieser Liste hinzufügt. Unser Leitfaden zu integration testing in SAP deckt diesen Fall im Detail ab.
Best Practices für Workflow-Integrationstests
InfoQs Coverage des 2025 DORA Report merkt an, dass KI-Adoption jetzt eine positive Beziehung zum Delivery-Durchsatz hat. Gleichzeitig steigt die Software-Delivery-Instabilität weiter. Mit mehr Releases läuft Ihre Workflow-Suite öfter, sodass jedes falsche Ergebnis oder jede langsame Debugging-Session Ihr Team mehr Zeit kostet.
Irreversible Schritte zuerst markieren. Eine Payment-Authorization kann retried werden, aber ein Payment Capture nicht, sodass die beiden unterschiedliche Fehlertests benötigen.
Prozesslogik ohne Infrastruktur testen. Mit Camunda Process Test oder der Step Functions TestState API prüft Ihr Team Verzweigungsregeln ohne deployed Services, sodass diese Tests in jeden Commit passen.
Eindeutige Daten pro Lauf generieren. Gemeinsame Order-IDs verursachen flaky Ergebnisse, wenn parallele Läufe dieselben Einträge modifizieren.
Business-State assertieren. Assertions auf internen Tabellenlayouts brechen nach einem Schema-Refactor, während eine Assertion auf Zahlungsstatus und reserviertem Bestand gültig bleibt.
Mit Deadlines pollen. Fixe Sleep-Calls verlangsamen die Suite und verbergen Performance-Probleme, also pollen Sie für den erwarteten Zustand bis zu einer Deadline, die an Ihr SLA gebunden ist.
Fehlgeschlagene Läufe tracen. Mit Correlation-IDs, die über OpenTelemetry gesammelt werden, kann Ihr Team sehen, welcher Service zuerst die erwartete Sequenz verlassen hat.
Echte und simulierte Dependencies labeln. Ein bestandener Test mit allen gemockten External Services beweist weniger, als es scheint, also verzeichnen Sie, welche Integrationen echt liefen.
Ich sehe durchaus den Wert von Integrationstests im Allgemeinen, da unsere App ziemlich datenbanklastig ist und die Logik nicht allein in der Anwendung ausgeführt werden kann. Zusätzlich dazu gibt es auch einen starken kartesischen Effekt durch die pure Anzahl an Konfigurationsoptionen, die wir haben.
Jedes Tool in der Tabelle deckt eine Schicht der Workflow-Ausführung ab, sodass Ihr Team üblicherweise mehrere davon kombiniert:
Tool
Testschicht
Wofür Ihr Team es nutzt
Camunda Process Test
Prozesslogik (BPMN)
BPMN-Prozesse isoliert mit simulierten Workern und kontrollierter Zeit ausführen, schnell genug für jeden Commit
AWS Step Functions TestState API
State-Machine-Logik
States mit gemockten Service-Responses testen, einschließlich Map- und Parallel-States seit dem November-2025-Update
Pact
Service Contracts
Bestätigen, dass ein Provider die Felder zurückgibt, die seine Consumer vor Deployment erwarten
Testcontainers
Infrastruktur-Dependencies
Disposable Docker-Instanzen von Datenbanken oder Brokern, z.B. PostgreSQL oder Kafka, für jeden Testlauf starten
Toxiproxy
Netzwerkfehler
Latenz und gedroppte Verbindungen zwischen Services für Fehlerbehandlungs-Cases wie TC-ERR-01 injizieren
Postman, REST Assured
API-Integration
Request-Konstruktion und Response-Handling für HTTP-Calls zwischen Services prüfen
Selenium, Cypress
UI End-to-End
Bestätigen, dass ein User den Workflow im Browser abschließen kann
Laut der AWS-Ankündigung funktioniert das TestState-Update mit Test-Frameworks wie Jest und pytest. Zusätzlich unterscheiden sich die Schichten in der Geschwindigkeit, sodass Ihr Team sie zu unterschiedlichen Pipeline-Phasen planen kann:
Prozesslogik-Tests bei jedem Commit, sodass Verzweigungsfehler im selben Pipeline-Lauf erscheinen.
Integrationstests mit echten Dependencies vor einem Merge in den Main-Branch.
End-to-End-Tests für umsatzrelevante Journeys vor jedem Production-Deployment.
Um jede TC-ID mit der Anforderung zu verknüpfen, die sie abdeckt, kann Ihr Team die Suite in einer Testmanagement-Plattform wie aqua cloud speichern. Dort teilen sich manuelle und automatisierte Ergebnisse einen Ort.
Fazit
Beginnen Sie mit einem Workflow, der Geld oder Bestand bewegt, und ordnen Sie seine Integrationspunkte in einem Diagramm zu. Danach passen Sie die oben genannten Testfall-Gruppen an Ihre eigenen Referenzdaten an und fügen die Wiederherstellungsszenarien vor Ihrem nächsten Release hinzu.
Von verlorenen Zahlungsbestätigungen bis zu wiederholten Webhooks benötigen Testfälle für Workflow-Integrationstests Updates, wann immer ein Service sich ändert. aqua Intelligence, eine KI in aqua cloud, der Test- und Anforderungsmanagement-Plattform, generiert kontextbewusste Szenarien aus Ihren hochgeladenen Anforderungen und Spezifikationen. Auf diese Weise passen Zustandsübergänge und Grenzwerte zu Ihrer Architektur. In der Praxis benötigen 42% der KI-generierten Testfälle null Bearbeitungen, was manuelle Nacharbeit für Ihr Team reduziert. Echtzeit-Dashboards zeigen, welche Anforderungen noch Abdeckung fehlt, und Traceability verknüpft jede Anforderung mit ihren Testfällen und Defekten. Als Ergebnis weist eine fehlgeschlagene TC-ID direkt auf die gefährdete Anforderung. Manuelle und automatisierte Tests teilen eine Plattform, und Jenkins bringt Ihre Pipeline-Ergebnisse hinein. Für Automatisierung bietet aqua 12+ native Integrationen, wie Ranorex und SoapUI. JMeter deckt Load Tests ab, während PowerShell- und UnixShell-Skripte aus demselben Workspace laufen. Datenbank-Integrationen mit MSSQL und Oracle vervollständigen das Setup.
Erreichen Sie 100% Workflow-Abdeckung und sparen Sie 12,8+ Stunden wöchentlich mit aqua Intelligence
Was sind Workflow-Integrationstests im Software-Testing?
Workflow-Integrationstests sind eine Software-Testing-Methode, die sich darauf konzentriert, wie verbundene Services gemeinsam einen Geschäftsprozess abschließen. Ihr Team führt den vollständigen Workflow aus, wie Order to Payment, und prüft Datenkonsistenz an jedem Integrationspunkt.
Was ist der Unterschied zwischen Workflow-Testing und Integrationstests?
Beim Workflow-Testing bestätigt Ihr Team, dass ein Geschäftsprozess den korrekten Schritten und Regeln folgt. Integrationstests fokussieren sich auf den Datenaustausch zwischen Komponenten. Workflow-Integrationstests kombinieren beides und decken den vollständigen Workflow für Integrationstests über Systeme hinweg ab.
Welche Testfälle sollten in Workflow-Integrationstests enthalten sein?
Beginnen Sie Workflow-Integrationstests mit Basis-Ausführungs- und Datenfluss-Testfällen. Danach fügen Sie API- und Fehlerbehandlungs-Cases hinzu, gefolgt von Sicherheits- und Drittanbieter-Cases. Negative Tests vervollständigen das Set mit ungültigem Input und Race Conditions.
Wie testet man den Datenfluss zwischen integrierten Systemen?
Sie verfolgen eine Bestellung durch jedes System im Workflow für System-Integrationstests und vergleichen ihre Werte bei jeder Übergabe. Ihr Team folgt diesem Eintrag über seine Correlation-ID, und Schema-Checks zeigen, ob Feldmappings korrekt bleiben.
Können Workflow-Integrationstests automatisiert werden?
Ja, die meisten Workflow-Integrationstests können automatisiert werden. Prozesslogik- und Contract-Tests laufen gut mit Camunda Process Test und Pact, während Testcontainers echte Datenbanken zu automatisierten Läufen hinzufügt. Für Human-Approval-Schritte kann Ihr Team simulierte Responses verwenden.
Pavel ist Quality-Assurance-Berater und Autor mit tiefem Fachwissen in der Lösung komplexer Testherausforderungen. Sein Hintergrund in der Softwareentwicklung hat Organisationen dabei geholfen, ihre QA-Praktiken von reaktiv zu proaktiv zu entwickeln. Neben der Beratung entwickelt Pavel Best-Practice-Leitfäden und Fallstudien für aqua cloud, die praxisnahe QA-Lösungen demonstrieren…
Nurlan, ein QA-Koordinator, ist stolz darauf, nahtlose QA-Operationen zu orchestrieren. Seine Expertise in der Koordination von QA-zentrierten Projekten und der Integration von QA-Lösungen hat konsequent höchste Kundenzufriedenheit erzielt. Neben seiner Vollzeittätigkeit als QA-Koordinator beinhaltet Nurlans Rolle das Erstellen von überzeugenden Inhalten, die Nutzer über die…
Robert hat mehrere Jahre Erfahrung in der Prozessoptimierung und im Testmanagement. Er ist Experte für die Definition und Implementierung von Arbeitsabläufen durch die Anpassung von aqua an die Prozesse der Kunden.
Beginnen Sie Ihre Arbeit nicht mit gewöhnlichen E-Mails: Fügen Sie eine gesunde Dosis an aufschlussreichen Softwaretest-Tipps von unseren QS-Experten hinzu.
Werden Sie Teil unserer Community von begeisterten Experten! Erhalten Sie neue Beiträge aus dem aqua-Blog direkt in Ihre Inbox. QS-Trends, Übersichten über Diskussionen in der Community, aufschlussreiche Tipps — Sie werden es lieben!
Wir sind dem Schutz Ihrer Privatsphäre verpflichtet. Aqua verwendet die von Ihnen zur Verfügung gestellten Informationen, um Sie über unsere relevanten Inhalte, Produkte und Dienstleistungen zu informieren. Diese Mitteilungen können Sie jederzeit wieder abbestellen. Weitere Informationen finden Sie in unserer Datenschutzrichtlinie.
X
🤖 Neue spannende Updates sind jetzt für die aqua-Intelligenz verfügbar! 🎉
