Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Block beobachten
Der Observe-Block ist eine grundlegende Komponente des Test-Frameworks, das definiert, welche Systemereignisse Sie während der Testausführung überwachen möchten. Stellen Sie sich das so vor, als würden Sie in Ihrem Test Checkpoints einrichten, an denen Sie darauf warten, dass bestimmte Dinge passieren, bevor Sie Maßnahmen ergreifen.
Wenn Sie in Ihrem Test einen Observe-Block konfiguriert haben, sagen Sie dem System: „Achten Sie auf dieses bestimmte Ereignis, und wenn es eintritt, führen Sie diese spezifischen Aktionen aus.“ Dieser ereignisgesteuerte Ansatz spiegelt wider, wie reale Interaktionen in Kontaktzentren ablaufen: Es passiert etwas, und dann reagieren Sie darauf.
## Aktive Beobachtungen verstehen
Ein Observe-Block wird zu einer aktiven Beobachtung, wenn er während der Simulation aktiv auf das angegebene Ereignis achtet. Für die Vorhersage des Testverhaltens ist es entscheidend zu verstehen, wie Beobachtungen zwischen aktiven und inaktiven Zuständen übergehen.
**Wenn Beobachtungen aktiv werden:**
+ Alle Startinteraktionsgruppen, die nicht von einer anderen Interaktionsgruppe aus verbunden oder mit einem Startbanner gekennzeichnet sind, werden zu Beginn der Testausführung als aktiv markiert.
+ Wenn ein Ereignis gefunden wurde, werden alle Check-Blocks und Actions-Blöcke in derselben Interaktionsgruppe ausgeführt. Bei erfolgreicher Ausführung wird die Beobachtung jeder verbundenen Interaktionsgruppe als aktiv markiert.
+ Es können mehrere Beobachtungen gleichzeitig aktiv sein, wenn Ihr Test mehrere Startinteraktionsgruppen enthält.
**Wenn Beobachtungen inaktiv werden:**
+ Eine Beobachtung wird inaktiv, wenn ihr erwartetes Ereignis erfolgreich zugeordnet wurde.
**Auswirkungen auf die Testergebnisse:**
Wenn das erwartete Ereignis einer aktiven Beobachtung nicht eintritt, beobachtet die Beobachtung das Ereignis so lange, bis das Timeout für den Test nach 5 Minuten abläuft. Dieses Timeout weist darauf hin, dass die Überprüfung fehlgeschlagen ist, sodass Ihr Test fehlschlägt. Wenn eine Beobachtung aufgrund eines Timeouts fehlschlägt:
+ Die Beobachtung bleibt aktiv, wurde aber nicht erfüllt.
+ Alle Prüf- und Aktionsblöcke, die diesem Observe-Block in der Interaktionsgruppe zugeordnet sind, werden nicht ausgeführt, da das beobachtete Ereignis nicht erfüllt wurde.
+ Die Testausführung wird mit einem Fehlerstatus beendet.
Wenn eine Beobachtung erfolgreich ist, was bedeutet, dass das Ereignis übereinstimmt, wird die Beobachtung als inaktiv markiert, und alle Prüf- oder Aktionsblöcke in derselben Interaktionsgruppe werden ausgeführt, bevor sie zur nächsten verbundenen Interaktionsgruppe wechseln.
## Welche Ereignisse können Sie beobachten?
Der Observe-Block kann verschiedene Arten von Systemereignissen überwachen:
### Ereignis „Test hat gestartet“
Dieses Ereignis wird ganz zu Beginn Ihrer Testausführung ausgelöst. Es ist besonders nützlich, wenn Sie Anfangsbedingungen einrichten müssen, bevor Kundeninteraktionen beginnen. Beispielsweise möchten Sie möglicherweise gleich zu Beginn des Tests das Systemverhalten konfigurieren oder externe Abhängigkeiten simulieren.
Konfigurationsoptionen:
+ **Ereignistyp** — Wählen Sie „Test gestartet“ aus der Drop-down-Liste
Beispielaktionen: Definieren Sie, was passieren soll, wenn der Test beginnt (z. B. das Überschreiben von Systemverhalten).
### Ereignis „Test abgeschlossen“
Dieses Ereignis wird beobachtet, wenn Ihre Testausführung ihr Ende erreicht. Verwenden Sie dies, um Aktionen mit Informationen zum endgültigen Status zu erfassen, nachdem alle Testinteraktionen abgeschlossen sind.
Konfigurationsoptionen:
+ **Ereignistyp** — Wählen Sie „Test abgeschlossen“ aus der Dropdownliste
Beispielaktionen: Geben Sie alle abschließenden Validierungs- oder Protokollierungsaktionen an, die ausgeführt werden sollen.
### Ereignis „Nachricht empfangen“
Dieses Ereignis erkennt, wenn das System eine Aufforderung abspielt oder eine Sprachantwort an den simulierten Kunden sendet.
Das Ereignis „Nachricht empfangen“ bietet flexible Abgleichsoptionen, um die richtige Nachricht zu identifizieren:
Konfigurationsoptionen:
+ **Ereignistyp** — Wählen Sie „Nachricht erhalten“ aus dem Drop-down-Menü
+ **Nachrichteninhalt** — Geben Sie mit einer der folgenden Methoden an, nach welcher Nachricht gesucht werden soll:
+ **Text** — Geben Sie den erwarteten Textinhalt der Nachricht ein
+ **SSML** — Stellen Sie passende Inhalte im SSML-Format bereit
+ **Übereinstimmungskriterien** — Wählen Sie aus, wie die Nachricht abgeglichen werden soll:
+ **Ähnlich** — Verwendet intelligenten semantischen Abgleich, um Nachrichten mit ähnlicher Bedeutung zu finden (in den meisten Fällen empfohlen)
+ **Enthält** — Prüft, ob die beobachtete Nachricht Ihren angegebenen Text enthält
**Wichtig**
(Stimme) Die Testergebnisse können zwischen den Durchläufen leicht variieren. Das System unterteilt den Ton auf der Grundlage von Pausen und natürlichen Sprachmustern in Segmente. Diese können je nachdem, wie lange jemand pausiert oder wie er seine Sätze strukturiert, unterschiedlich sein. Das bedeutet, dass die Art und Weise, wie Eingabeaufforderungen in den einzelnen Testausführungen angezeigt werden, variieren kann.
### Die Flow-Aktion hat das Ereignis gestartet
Dieses Ereignis beobachtet, wann bestimmte Aktionen innerhalb Ihres Kontaktablaufs mit der Ausführung beginnen. Es ermöglicht Ihnen, Vorgänge in Ihrem Flow zu erkennen und darauf zu reagieren, z. B. Lambda-Funktionsaufrufen, Betriebsstundenprüfungen, Warteschlangenübertragungen oder Bot-Initialisierungen.
Konfigurationsoptionen:
+ **Ereignistyp** — Wählen Sie „Aktion ausgelöst“ aus der Dropdownliste
+ **Ressourcentyp** — Wählen Sie aus, welche Flow-Aktion beobachtet werden soll:
+ **Lambda-Funktion** — Erkennt, wenn eine Lambda-Funktion aufgerufen wird (wählen Sie aus der Dropdownliste oder geben Sie den Funktions-ARN an)
+ **Öffnungszeiten — Überwacht Betriebsstundenprüfungen** (wählen Sie aus der Drop-down-Liste oder geben Sie die Betriebsstunden an ARN)
+ **Warteschlange** — Beobachtet die Aktionen zur Übertragung von Warteschlangen (wählen Sie aus der Dropdownliste oder geben Sie den Warteschlangen-ARN an)
+ **Lex Bot** — Erkennt Lex-Bot-Verbindungen (wählen Sie aus der Drop-down-Liste oder geben Sie den Bot-ARN und den Alias an)
## Wie oft sollte das Ereignis auftreten?
Jeder Observe-Block erbt eine Standardverwendungseinstellung von der Interaktionsgruppe, die steuert, wie oft das Ereignis während der Testausführung abgeglichen werden soll. Die Standardeinstellung ist, dass das Ereignis genau einmal auftreten muss. Das Ändern dieser Einstellung wird nicht unterstützt.
## Interaktionsgruppen verbinden
Nachdem Sie definiert haben, was beobachtet werden soll, fügen Sie der Interaktionsgruppe einen Konnektor hinzu. Wählen Sie im Menü der Interaktionsgruppe () die Option **Konnektor hinzufügen** aus und ziehen Sie den Konnektor dann an den Anfang der Interaktionsgruppe, die die nächste Beobachtung enthält. Dadurch entsteht ein logischer Fluss durch den Test, der sich bei Eintreten von Ereignissen von einem Checkpoint zum anderen bewegt.
