Beispiel: Adressänderung
Diese Seite demonstriert zwei verschiedene Strategien zum Testen desselben Adressänderungsablaufs. Sie repräsentieren unterschiedliche Kompromisse zwischen Kontrolle und Flexibilität:
-
Ansatz 1: Explizite Züge — Jede Benutzereingabe wird manuell, Zug um Zug, definiert. Dies gibt volle Kontrolle über den Gesprächsverlauf und eignet sich gut zur Überprüfung von Routing und Extraktion bei bestimmten Schritten.
-
Ansatz 2: Eingabegenerierung mit Wiederholungen — Ein einzelner Zug mit generierten Eingaben und Wiederholungen lässt den Bot das Gespräch bis zum Abschluss führen. Dieser Ansatz konzentriert sich auf den Endzustand anstatt auf den Weg und testet, ob der Bot das richtige Ergebnis in einem natürlichen, offenen Austausch erreichen kann.
Ansatz 1: Explizite Züge
Das Gespräch
Der Test basiert auf einem echten Gespräch, das im Entwicklungs-Chat erfasst wurde. Ein Benutzer möchte eine neue Adresse in Berlin registrieren:

Der Bot bearbeitet dies in drei Zügen: Er fragt nach der Stadt, dann nach der Postleitzahl und bestätigt dann die Registrierung. Dieser mehrstufige Ablauf ist genau die Art von Szenario, das sich zu automatisieren lohnt — es gibt mehrere Extraktionsschritte und eine spezifische Routing-Anforderung, die nach einer Änderung unbemerkt brechen könnte.
Der schnellste Weg, dies in einen Testfall zu verwandeln, besteht darin, das Gespräch direkt zu konvertieren — dies ist sowohl aus dem Entwicklungs-Chat als auch aus jedem Gespräch im Chat-Verlauf möglich. Das System generiert einen Testfall mit allen drei vorab ausgefüllten Zügen.

Der automatisch generierte Test enthält Äußerungsbedingungen in den ersten beiden Zügen und Slot-Bedingungen im dritten. Es ist eine nützliche Grundlage, aber nicht vollständig — es wird nicht überprüft, ob der Bot tatsächlich zum richtigen Ablauf geroutet wurde. Das ist es, was die unten stehenden Bedingungen hinzufügen.
Die Bedingungen
Zug 1 — Routing
Das Wichtigste, das in Zug 1 überprüft werden muss, ist, dass der Bot zum richtigen Ablauf routet. Wenn der Orchestrator die Absicht falsch identifiziert — zum Beispiel zu einem allgemeinen Anfragen-Ablauf anstatt zum Adressänderungs-Handler — wird die Adressänderung nie verarbeitet, selbst wenn das Gespräch von außen gut zu verlaufen scheint.
Dies ist etwas, das der automatisch generierte Test nicht abdeckt. Eine Tool Call Condition auf address_change_flow muss manuell hinzugefügt werden. Sie schlägt fehl, wenn dieses Tool während Zug 1 nicht aufgerufen wurde.

Zug 2 — Folgefrage
Zug 2 ist ein natürlicher Sprachenaustausch, bei dem der Benutzer die Stadt angibt. Eine Äußerungsbedingung kann überprüfen, ob der Bot korrekt nachfragt — zum Beispiel, indem überprüft wird, ob die Antwort nach einer Postleitzahl fragt.
Zug 3 — Extraktion und Bestätigung
Bis Zug 3 sollte der Bot beide Werte aus dem Gespräch extrahiert haben. Zwei Slot-Bedingungen überprüfen dies:
town == Berlinzip_code == 10155

Selbst wenn das Gespräch natürlich verläuft, bedeutet eine falsche Extraktion, dass die Adressänderung nicht korrekt weiterverarbeitet wird. Diese Bedingungen fangen diese Art von Fehler ab, bevor er in die Produktion gelangt.
Eine Äußerungsbedingung kann zusätzlich die Bestätigungsnachricht des Bots am Ende des Zuges überprüfen.
Die vollständige Validierungskette
Zusammen decken diese Bedingungen die kritischen Fehlermodi für diesen Ablauf ab:
- Falsches Routing — Tool Call Condition in Zug 1
- Falsche Extraktion — Slot-Bedingungen in Zug 3
- Fehlende Bestätigung — Äußerungsbedingung in Zug 3
Jede Regression im Verhalten des LLM, der Ablauf-Logik oder der Extraktionskonfiguration wird hier sichtbar, bevor ein echter Benutzer darauf stößt.
Ansatz 2: Eingabegenerierung mit Wiederholungen
Dieser Ansatz verwendet einen einzigen Zug mit einem Eingabegenerator und Wiederholungen, um denselben Ablauf zu testen. Anstatt jeden Austausch zu skripten, beschreiben Sie das Ziel des Benutzers und lassen den Bot das Gespräch bis zum Abschluss führen.
Die Einrichtung
Der Testfall hat einen einzigen Zug. Der Zug verwendet die Eingabegenerierung mit den folgenden Generierungsanweisungen:

"Sie sind ein freundlicher Benutzer, der seine Adresse ändern möchte. Ihre neue Adresse ist 10155, Berlin. Geben Sie diese Details nur nacheinander an, wenn Sie danach gefragt werden."
Der Zug ist so konfiguriert, dass bis zu 10 Wiederholungen erlaubt sind.
Zwei Slot-Bedingungen werden diesem Zug hinzugefügt:
town == Berlinzip_code == 10155
Wie es ausgeführt wird
Wenn der Test läuft, erzeugt der Eingabegenerator eine Eröffnungsnachricht — etwas wie "Ich möchte meine Adresse aktualisieren." Der Bot antwortet und fragt nach der Stadt. Die Bedingungen werden ausgewertet: Kein Slot ist bisher gesetzt, also schlägt der Zug fehl. Da Wiederholungen konfiguriert sind, wird der Zug erneut ausgeführt.
Beim nächsten Versuch hat der Eingabegenerator den Gesprächsverlauf als Kontext und gibt die Stadt an — "Berlin". Der Bot fragt nach der Postleitzahl. Die Bedingungen werden erneut ausgewertet: town ist jetzt gesetzt, aber zip_code nicht. Der Zug wird erneut wiederholt.
Beim folgenden Versuch gibt der Generator die Postleitzahl an. Der Bot bestätigt die Registrierung. Beide Slot-Bedingungen bestehen nun, und der Test besteht.

Wann dieser Ansatz verwendet werden sollte
Dieser Ansatz eignet sich gut, wenn Sie überprüfen möchten, dass der Bot einen Ablauf erfolgreich von Anfang bis Ende abschließen kann, ohne den Test an einen bestimmten Gesprächsverlauf zu binden. Er ist widerstandsfähiger gegenüber Änderungen in der Art und Weise, wie der Bot seine Fragen formuliert, und erfordert nicht, dass Sie die genaue Abfolge der Austausche im Voraus kennen.
Der Kompromiss besteht darin, dass er kein Routing oder Zwischenschritte überprüft. Wenn der Bot das richtige Ergebnis über den falschen Ablauf erreicht, wird dieser Test es nicht erkennen. Dafür ist Ansatz 1 mit einer expliziten Tool Call Condition die bessere Wahl.
Die beiden Ansätze ergänzen sich: Ansatz 1 bietet Präzision und Routing-Abdeckung; Ansatz 2 bietet Endzustandsabdeckung mit weniger Wartungsaufwand.