Ein Einkaufsagent meldet: „Ihre Bestellung wurde erfolgreich aufgegeben.“ Für eine Vorführung ist das ein guter Moment. Für eine Abnahme beginnt jetzt die eigentliche Arbeit: Welche Bestellung liegt im Shop? Welche Zahlung ist zugeordnet? Ist der Bestand korrekt? Und kann derselbe Auftrag nach einem Verbindungsabbruch nochmals ausgeführt werden?
Ein brauchbarer Test prüft diese Ergebnisse unabhängig von der Antwort des Agenten. Das folgende Verfahren ist ein vorgeschlagenes Prüfdesign für eine Testumgebung. Es beschreibt keine bereits durchgeführte Untersuchung und keine Zertifizierung.
Einen kleinen Auftrag vollständig festlegen
Nehmen wir einen fiktiven Fachhändler für Bürobedarf. Ein Testkunde möchte zwei Kartons einer genau bezeichneten Etikettenrolle kaufen. Der zulässige Gesamtbetrag beträgt 80 Euro inklusive Versand und Steuern. Geliefert werden soll an die freigegebene Geschäftsadresse. Ersatzprodukte benötigen eine neue Zustimmung.
Vor dem Test hält das Team Artikel, Variante, Menge, Angebotsfassung und Kundenzuordnung fest. Es definiert außerdem, wann eine Bestellung als angenommen gilt und welche Zahlungszustände dazu passen. Zahlungsautorisierung und tatsächlicher Einzug werden getrennt betrachtet.
Verwenden Sie synthetische Kundendaten, Testbestände und den Testmodus Ihres Zahlungswegs. Eine echte Belastung ist für diese Abnahme weder nötig noch durch diesen Leitfaden vorgesehen.
Drei unabhängige Prüfstellen einrichten
Die Oberfläche zeigt, was der Kunde versteht. Der Commerce-Kern zeigt, was bestellt und reserviert wurde. Der Zahlungsweg zeigt, was autorisiert oder eingezogen wurde. Diese drei Sichten müssen zusammenpassen.
Das Team liest die Zustände über administrative Testzugänge oder definierte Prüfendpunkte aus. Der Agent sollte seinen eigenen Erfolg nicht allein bewerten. Ein zweites Sprachmodell, das dieselbe freundliche Antwort liest, ersetzt ebenfalls keine Bestellprüfung.
Die Abnahmematrix
Jeder Test startet aus einem bekannten, wiederherstellbaren Zustand. Bei Paralleltests gehört die zeitliche Überschneidung ausdrücklich zum Aufbau.
| Fall | Gezielte Veränderung | Erwartetes Ergebnis im System |
|---|---|---|
| 1. Normalfall | Unverändertes Angebot wird bestätigt. | Eine passende Bestellung; Betrag, Kunde und Variante stimmen mit der Zustimmung überein. |
| 2. Verlorene Antwort | Verbindung nach Speicherung unterbrechen, denselben Auftrag erneut anfragen. | Vorhandenen Vorgang wiederfinden; keine zweite Bestellung und kein zusätzlicher Einzug. |
| 3. Veränderte Nutzlast | Dieselbe Wiederholungskennung mit anderer Menge senden. | Konflikt erkennbar behandeln; weder still überschreiben noch als genehmigten Neukauf ausführen. |
| 4. Abgelaufenes Angebot | Zustimmung erst nach Ablauf der Angebotsgültigkeit senden. | Alte Fassung wird nicht ausgeführt; neue Bedingungen werden zur Entscheidung vorgelegt. |
| 5. Letzter Bestand | Zwei berechtigte Kunden bestellen gleichzeitig den letzten Karton. | Bei ausgeschlossenem Überverkauf höchstens eine Annahme; der zweite Kunde erhält einen zutreffenden Status. |
| 6. Verspätetes Ereignis | Nach bestätigtem Zahlungserfolg eine ältere Meldung „in Bearbeitung“ zustellen. | Veraltete Nachricht darf den bestätigten Zahlungszustand nicht unbesehen zurücksetzen. |
| 7. Widerrufenes Mandat | Berechtigung vor dem ausführenden Schritt entziehen. | Keine neue Ausführung unter dem widerrufenen Mandat; bereits erfolgte Schritte bleiben nachvollziehbar. |
| 8. Wiederholte Erstattung | Dieselbe freigegebene Testerstattung mehrfach zustellen. | Eine Erstattungswirkung; Wiederholungen beziehen sich auf denselben Vorgang. |
Diese Erwartungen müssen zum vereinbarten Geschäftsmodell passen. Wer Rückstände oder Teillieferungen zulässt, braucht für Fall 5 eine andere Annahmeregel. Schreiben Sie diese vor dem Test auf. Eine nachträgliche Erklärung ist kein Ersatz für eine vorher festgelegte Erwartung.
Ein Timeout ist zunächst ein ungeklärtes Ergebnis
Besonders wichtig ist die Unterscheidung zwischen „abgelehnt“ und „Antwort fehlt“. Nach einem Timeout kann die Bestellung bereits existieren. Der nächste Schritt sollte deshalb den begonnenen Vorgang klären, bevor ein neuer Kauf gestartet wird.
Der HTTP-Standard beschreibt Idempotenz als gleiche beabsichtigte Wirkung wiederholter identischer Anfragen. Eine beliebige Bestellung über eine HTTP-Schnittstelle erhält diese Eigenschaft jedoch nicht automatisch. Für nicht idempotente Methoden ist automatisches Wiederholen nur unter zusätzlichen Voraussetzungen vorgesehen. Prüfen Sie das Verhalten Ihrer konkreten Integration. RFC 9110, Abschnitt 9.2.2
Legen Sie eine Frist für die technische Klärung fest. Bleibt das Ergebnis danach offen, erhält ein zuständiger Mensch den Fall mit den vorhandenen Referenzen. Die Kundenanzeige bleibt ehrlich: „Wir prüfen den Bestellstatus.“ Ein ungeklärter Vorgang gehört weder in die Erfolgsquote noch in den Topf sicher abgelehnter Käufe.
Einen Nachweis speichern, den jemand anderes lesen kann
Pro Lauf genügen Testfallkennung, Softwarestand, Ausgangsdaten, ausgelöste Störung, erwarteter Zustand, beobachteter Zustand und relevante Vorgangsreferenzen. Zugangsdaten und vollständige Zahlungsdetails gehören nicht hinein. Dokumentieren Sie auch, wer einen offenen Fall übernimmt.
Wiederholen Sie kritische Fälle mit unterschiedlichen Zeitabständen und Ereignisfolgen. Ein einzelner erfolgreicher Lauf belegt nur diesen Lauf. Besonders Parallelitätsfehler benötigen mehr als den üblichen Klick durch eine Demo.
Für die Freigabe werden Sicherheitsgrenzen und Qualitätsziele getrennt bewertet. Eine hübsche Antwort darf einen unberechtigten Einzug nicht ausgleichen. Wiederholen Sie die Matrix nach Änderungen an Angebotslogik, Berechtigungen und Zahlungsanbindung.
Der nächste praktische Schritt: Lassen Sie Fachteam und Entwicklung einen einzigen Testfall gemeinsam ausführen und den gespeicherten Zustand erklären. Die Grundlagen dazu stehen in Kapitel 8: Vom Angebot bis zum Service danach und Kapitel 13: Sicherheit für handelnde Agenten.
Quellen und Einordnung
- Belegter technischer Begriff: Die Aussage zu HTTP-Idempotenz und Wiederholungen folgt RFC 9110, Abschnitt 9.2.2. Daraus wird keine automatische Garantie für einen Kauf- oder Zahlungsprozess abgeleitet.
- Vorhandene Buchgrundlage: Kapitel 8 und 13 behandeln Angebotsbindung, Wiederholungsschutz und Kontrolle gespeicherter Wirkungen.
- Neuer redaktioneller Vorschlag: Szenario, Acht-Fälle-Matrix, Nachweisstruktur und Abnahmeverfahren dieses Artikels. Keine Messdaten, kein Sicherheitszertifikat und keine Behauptung über eine konkrete Produktimplementierung.