Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Concepts de simulation
Les approches traditionnelles de simulation des centres d'appels reposent sur des identifiants d'étapes techniques et des transitions incompatibles avec les modèles naturels d'interaction humaine, ce qui crée un décalage dans les processus de validation. Les fonctionnalités de simulation de Connect Customer utilisent un modèle de réponse au déclenchement piloté par les événements qui reflète les modèles de raisonnement naturels de cause à effet utilisés par les ingénieurs d'assurance qualité et les testeurs commerciaux. Cette approche élimine le besoin de connaître toutes les interactions programmées pour tester et valider l'expérience. Chaque scénario de test est construit comme une séquence d'observations associées à des actions. Les dépendances entre les observations sont traitées comme des transitions, créant ainsi un flux logique qui correspond au raisonnement humain tout en préservant la précision technique. Les termes suivants sont utilisés dans la configuration du scénario de test :
- Observations
-
Les observations représentent chaque interaction complète qui comprend un événement observé attendu du système et de nombreuses actions visant à valider ou à simuler les comportements du système.
- Événements
-
Les événements représentent les comportements attendus qui proviendraient du système, tels qu'une invite, un message de bot ou un appel Lambda.
- Actions
-
Les actions représentent ce que le framework de test doit faire en réponse à un événement, tel que l'envoi de DTMF, la réponse par du texte, l'affirmation de valeurs d'attributs ou la fin du test.
- Acteurs
-
Les acteurs représentent les rôles à jouer dans le cadre de test. Lors de l'observation d'événements, les acteurs peuvent être le système ou l'agent, par exemple une invite de jeu provenant du système ou un agent acceptant le contact. Lors de la simulation d'actions, les acteurs peuvent être le client, le système ou l'agent, par exemple en simulant un DTMF ou un énoncé saisi par un client, ou en simulant une réponse système à partir d'une fonction Lambda.
Groupes d'interaction
Utilisez des groupes d'interaction pour créer des interactions simulées avec le centre d'appels. Chaque groupe d'interaction comporte trois étapes définies, décrites comme les blocs suivants :
- Observez
-
Pour chaque groupe d'interactions, vous devez configurer un bloc d'observation afin de valider l'interaction attendue du système. Vous pouvez observer quatre types d'événements : le test a été lancé, le message reçu, l'action déclenchée et le test terminé.
Note
Observe prend actuellement en charge les messages reçus en anglais uniquement. Les messages reçus dans d'autres langues ne sont pas pris en charge pour le moment et entraîneront l'échec du bloc d'observation lors de l'exécution du test.
- Check
-
Ce bloc est facultatif et permet de valider des métadonnées telles que les attributs définis par l'utilisateur, les attributs système et les attributs de segment. Vous pouvez valider plusieurs attributs dans le bloc à cocher.
- Actions
-
Ce bloc est facultatif et est utilisé pour annuler des actions, remplacer des ressources, envoyer des instructions ou tester des actions de contrôle. Vous pouvez utiliser des ressources de remplacement telles que Lambda, Lex, Queue ou Hours of Operation par d'autres ressources ou remplacer des actions par des valeurs de réponse issues d'actions associées. Vous pouvez valider l'expérience de contact sans faire appel à des ressources externes pour accélérer l'exécution des tests et empêcher toute véritable manipulation des données, par exemple en empêchant de rejouer un bloc Lambda qui débite une carte de crédit dans un environnement de production. Vous pouvez utiliser les instructions d'envoi pour simuler une entrée à envoyer à l'expérience du centre d'appels, telle qu'une text/utterance tonalité DTMF. En outre, vous pouvez utiliser des types d'actions de contrôle des tests pour enregistrer les données et mettre fin à l'exécution du scénario de test à tout moment.
