Konzepte zur Anrufsimulation

Die traditionellen Test- und Simulationsansätze in Kontaktzentren basieren auf technischen Schritten IDs und Übergängen, die nicht mit den natürlichen menschlichen Interaktionsmustern vereinbar sind, was zu einer Diskrepanz bei den Validierungsprozessen führt. Die Funktionen zur Anrufsimulation von Connect verwenden ein ereignisgesteuertes Trigger-Response-Modell, das die natürlichen cause-and-effect Denkmuster widerspiegelt, die von QA-Technikern und Geschäftstestern verwendet werden. Dieser Ansatz macht es überflüssig, jede programmierte Interaktion zu kennen, um das Erlebnis zu testen und zu validieren. Jeder Testfall besteht aus einer Abfolge von Beobachtungen gepaart mit Aktionen. Abhängigkeiten zwischen Beobachtungen werden als Übergänge behandelt, wodurch ein logischer Ablauf entsteht, der dem menschlichen Denken entspricht und gleichzeitig die technische Präzision gewahrt bleibt. Die folgenden Begriffe werden in der Testfallkonfiguration verwendet:

Beobachtungen

Beobachtungen stellen jede vollständige Interaktion dar, die ein beobachtetes Ereignis, das vom System erwartet wird, und viele Aktionen zur Validierung oder Simulation des Systemverhaltens umfasst.

Ereignisse

Ereignisse stellen erwartete Verhaltensweisen dar, die vom System ausgehen würden, z. B. eine Aufforderung, eine Bot-Nachricht oder ein Lambda-Aufruf.

Aktionen

Aktionen stellen dar, was das Test-Framework als Reaktion auf ein Ereignis tun sollte, z. B. das Senden von DTMF, das Antworten mit Text, das Bestätigen von Attributwerten oder das Beenden des Tests.

Akteure

Akteure stehen für Rollen, die innerhalb des Test-Frameworks zu spielen sind. Bei der Beobachtung von Ereignissen können Akteure das System oder der Agent sein, z. B. eine vom System ausgehende Aufforderung zur Wiedergabe oder ein Agent, der den Anruf annimmt. Bei der Simulation von Aktionen kann es sich bei den Akteuren um den Kunden, das System oder den Agenten handeln, z. B. bei der Simulation einer DTMF oder Äußerung einer Kundeneingabe oder bei der Simulation einer Systemreaktion durch eine Lambda-Funktion.

Interaktionsgruppen

Verwenden Sie Interaktionsgruppen, um simulierte Interaktionen mit dem Call Center zu erstellen. Jede Interaktionsgruppe besteht aus drei definierten Schritten, die als die folgenden Blöcke beschrieben werden:

Beobachten

For each interaction group, you must configure an observe block to validate the expected interaction from the system. There are four types of event you can observe from, which are test started, message received, action triggered, and test completed.

Anmerkung

Observe unterstützt derzeit nur Nachrichten, die auf Englisch empfangen wurden. In anderen Sprachen empfangene Nachrichten werden derzeit nicht unterstützt und führen dazu, dass der Observe-Block während der Testausführung fehlschlägt.

Check

Dieser Block ist optional und wird zur Validierung von Metadaten wie benutzerdefinierten Attributen, Systemattributen und Segmentattributen verwendet. Sie können mehr als ein Attribut im Prüfblock validieren.

Aktionen

Dieser Block ist optional und wird verwendet, um Aktionen zu überschreiben, Ressourcen zu überschreiben, Anweisungen zu senden oder Kontrollaktionen zu testen. Sie können Ressourcen wie Lambda, Lex, Queue oder Betriebsstunden mit alternativen Ressourcen überschreiben oder Aktionen mit Antwortwerten aus verwandten Aktionen überschreiben. Sie können das Kontakterlebnis überprüfen, ohne externe Ressourcen aufrufen zu müssen, um die Testausführung zu beschleunigen und echte Datenmanipulationen zu verhindern, z. B. die Verhinderung der Wiederholung eines Lambda-Blocks, der eine Kreditkarte belastet, in der Produktionsumgebung. Mithilfe von Sendeanweisungen können Sie Eingaben simulieren, die an das Kontaktzentrum gesendet werden sollen, z. B. Text/Äußerung, DTMF-Ton oder WAV-Datei für vorab aufgezeichnetes Audio. Darüber hinaus können Sie Aktionstypen für die Teststeuerung verwenden, um Daten zu protokollieren und die Testfallausführung jederzeit zu beenden.