Planifiez et créez un test de performance d’agent conversationnel

Les agents conversationnels construits avec Copilot Studio fonctionnent sur une plateforme qui s’adapte automatiquement à l’augmentation de la demande et de la charge. Cependant, les agents conversationnels utilisent souvent une logique personnalisée ou des appels vers des API backend, ce qui introduit de la latence car la logique personnalisée est inefficace ou les API sous-jacentes et les systèmes backend ne s’adaptent pas bien.

Les tests de performance évaluent la performance et la stabilité d’un agent sous différents schémas de charge. Il identifie les problèmes potentiels à mesure que la base d’utilisateurs grandit, garantissant que l’agent reste fonctionnel et réactif. Si vous ne testez pas votre agent conversationnel sous charge, il peut bien fonctionner pendant le développement et les tests mais échouer sous le trafic utilisateur réel.

Avant d’aborder les aspects techniques des tests de performance, définissez des critères d’acceptation qui capturent l’expérience utilisateur souhaitée et identifiez les cas d’utilisation conversationnels générant des schémas de charge distincts. Cet article traite brièvement de la phase de planification des tests de performance et fournit des conseils sur les spécificités techniques de la génération de charge pour vos agents conversationnels.

Planifiez votre test de performance

Un plan de test de performance doit avoir un objectif défini et des critères d’acceptation spécifiques. Par exemple, certains tests mesurent la performance d’un système sous charge standard, tandis que d’autres tests génèrent un stress plus extrême qui provoque volontairement une non-réactivité du système. Lors de la mesure des performances des agents conversationnels construits avec Copilot Studio, il faut concevoir des tests pour mesurer soit la performance de base de l’agent, soit la charge lourde anticipée, mais ne configurez pas les tests pour générer un stress excessif.

Comprendre le comportement des utilisateurs

Commencez votre plan de test en analysant comment les utilisateurs sont censés se comporter dans différents cas d’usage conversationnels. D’un point de vue test de charge, le comportement des utilisateurs peut varier selon les cas d’usage, en termes de ce que les utilisateurs disent ou demandent (par exemple, « Je veux réserver un vol » ou « Quelle est votre politique de retour ? »), le nombre d’utilisateurs qui motive un cas d’usage particulier, et les habitudes d’engagement des utilisateurs (par exemple, des utilisateurs se connectant tous en même temps à midi plutôt qu’une augmentation progressive tout au long de la journée).

Le tableau suivant décrit le comportement attendu des utilisateurs pour un agent conversationnel bancaire.

Créer un plan de test

Après avoir défini le comportement de l’utilisateur en termes de cas d’usage et de schémas d’engagement, réfléchissez aux spécificités de votre plan de test de performance. Au minimum, un plan de test de performance pour un agent conversationnel doit spécifier un objectif, des scénarios de test, des indicateurs clés de performance, des données de test détaillées et des critères de réussite.

Si votre équipe a déjà défini des scénarios conversationnels pour les évaluations, soit en créant des cas de test en produit, soit en utilisant le kit Copilot Studio, vous pouvez réutiliser ces scénarios pour commencer à élaborer votre plan de test.

Le type de plan de test suivant est destiné à un agent de conversation bancaire. Le plan utilise les cas d’usage conversationnels précédemment identifiés pour définir un scénario de test de référence et un scénario de test de charge. Tester la base évalue les performances normales, identifiant les problèmes lors d’une utilisation régulière, tandis qu’une charge plus élevée peut révéler comment le système gère l’activité maximale des utilisateurs.

Travaillez avec les parties prenantes techniques et commerciales pour élaborer un plan de test adapté aux besoins de votre organisation. Soyez d’accord sur les paramètres clés décrits dans l’exemple. Apprenez à utiliser des outils comme Apache JMeter pour créer des scripts de test dans des exemples de références et des directives de test de performance.

Simuler des conversations à plusieurs tours

Les données de test spécifiées dans le plan impliquent que les performances prévues de test conduisent des conversations sur plusieurs tours. Les conversations à plusieurs tours sont une série de messages échangés entre les utilisateurs simulés et l’agent conversationnel. Les tests de performance doivent entraîner des conversations à plusieurs tours afin que la charge générée ressemble au comportement réel de l’utilisateur. De plus, certaines actions ou appels API de longue durée ne s’activent que lorsque les utilisateurs effectuent une série spécifique de choix ou envoient un schéma spécifique de messages au sein d’une conversation.

Dans l’exemple suivant, l’API backend de la banque ne s’invoque qu’après que l’utilisateur ait sélectionné un compte d’épargne. Le temps de réponse pour le premier message est inférieur à un second car seul le moteur de reconnaissance d’intention de l’agent est impliqué. Le dernier message attend une réponse d’une API backend, ce qui introduit une latence supplémentaire. Sans simuler une conversation sur plusieurs tours, les problèmes de performance n’auraient pas survécu.

Simuler des conversations sur plusieurs tours nécessite de planifier à la fois la préparation des données de test et la construction des scripts de test. Incluez une série d’énoncés utilisateurs dans vos données de test qui invoquent des flux conversationnels complets, comme montré dans l’exemple. Assurez-vous que vos scripts de test envoient plusieurs énoncés dans une même conversation.