Exemple de référence et directives pour les tests de performance

Utilisez l’exemple de référence créé avec Apache JMeter disponible sur GitHub comme point de départ pour créer vos propres tests de performances.

L’exemple de référence démontre les principes suivants :

  • Communication avec Direct Line via WebSockets
  • Pilotage des requêtes multitour
  • Exécution de plusieurs groupes de fils de discussion, chacun pilotant un cas utilisateur conversationnel distinct

L’échantillon de référence est construit à l’aide de JMeter, un outil open source populaire. Vous pouvez aussi créer des scripts de test de performances pour les assistants Copilot Studio avec d’autres outils. Utilisez des critères de sélection tels que :

  • Soutien communautaire : choisissez un outil doté d’une communauté forte et active pour le dépannage et les ressources.
  • Disponibilité des plug-ins  : assurez-vous que l’outil prend en charge les plug-ins nécessaires, en particulier pour les protocoles WebSocket.
  • Reporting enrichi : recherchez des outils fournissant des rapports complets, intégrés ou extensibles avec des plug-ins.
  • Évolutivité : optez pour des outils qui peuvent facilement faire évoluer l’exécution des tests à grande échelle. JMeter et Locust sont tous deux compatibles avec Test de charge Azure.

Lorsque vous concevez des scripts de test de performance pour des assistants créés avec Copilot Studio, assurez-vous qu’ils simulent fidèlement l’utilisation réelle et qu’ils correspondent à votre configuration de production. Les directives clés suivantes vous aident à créer des scripts de test efficaces et réalistes :

  • Simulez des délais réalistes : après avoir capturé la dernière réponse de l’assistant, introduisez un délai réaliste (par exemple, de 30 secondes à 1 minute) avant d’envoyer le prochain message utilisateur. Ce délai reflète la façon dont les utilisateurs réels prennent le temps de lire, réfléchir et répondre lors des conversations.
  • Gestion des erreurs dans les requêtes multitour : incluez des vérifications d’erreur après chaque tour dans la conversation. Si une erreur survient (par exemple, une réponse manquante ou incorrecte), arrêtez la conversation simulée pour éviter des problèmes en cascade et pour refléter un comportement réaliste des utilisateurs.
  • Adaptez vos protocoles de communication en production : veillez à ce que votre script de test utilise les mêmes protocoles de communication que votre environnement de production, tels que WebSockets ou HTTP GET. Cette approche garantit que le test de performances reflète avec précision les conditions réelles.