Limitations connues des tests de performances

Contraintes connues pour les tests de performance dans Test Manager, y compris les limites de runtime du robot et le maximum de tâches simultanées.

Limites de durée d'exécution

Les robots Cloud, Serverless, peuvent s’exécuter pendant 60 minutes maximum par test. Les robots locaux peuvent dépasser cette limite.

Limites de simultanéité

• Nombre maximal de tâches simultanées: jusqu'à 500 tâches peuvent s'exécuter simultanément à l'aide de robots sans serveur.

• Impact sur les utilisateurs virtuels (VU) - sans serveur : le nombre d'utilisateurs virtuels réalisables dépend du multiplexage (plusieurs VU par tâche). Par exemple, avec un facteur de multiplexage de 4, un scénario peut atteindre 2 000 utilisateurs virtuels simultanés.

  • Ce facteur est automatiquement détecté pendant le test et rapporté dans les journaux de l'application. Il ne peut pas être modifié manuellement pour les robots sans serveur.

• Impact sur les utilisateurs virtuels (VU) - sur site : les robots sur site ne sont pas plafonnés à 2 000 VU. Avec une licence suffisante, le test peut calculer un nombre d'utilisateurs virtuels réalisable plus élevé, jusqu'à un maximum de 10 000 utilisateurs virtuels simultanés. Contrairement aux robots sans serveur, le facteur de multiplexage ici peut être outrepassé manuellement.

• Contraintes VPN: lorsque vous utilisez un VPN, la simultanéité efficace dépend de la capacité du VPN ou de la passerelle.

  • Limite par défaut: environ 250 tâches simultanées
  • La limite réelle peut varier en fonction de l' UGS de la passerelle et de la capacité de l'infrastructure.
  • Si une simultanéité plus élevée est requise, les clients doivent contacter l’assistance UiPath ou leur équipe de compte pour discuter des options de mise à l’échelle VPN.

• Durée d'exécution: les robots sans serveur sont limités à 60 minutes par exécution

Types d'automatisation pris en charge

Les tests de performances sont actuellement limités aux automatisations liées au navigateur, aux API (HTTP WebRequest et aux automatisations du bureau. Par exemple, Integration Service ou les automatisations codées ne sont pas encore prises en charge.

Dans ces types d'automatisation pris en charge, l'analyseur de workflow signale désormais les activités spécifiques non prises en charge automatiquement pendant le test - consultez la section Création de tests automatisés pour obtenir la liste actuelle.

Le mode Incognito/InPrivate n’est pas pris en charge pour les environnements locaux

Les exécutions de test de performances sur des machines locales ne prennent pas en charge l’automatisation du navigateur en mode Chrome Incognito ou en mode Edge InPrivate.

Cette limitation est due à des restrictions de sécurité du navigateur qui exigent que les extensions soient activées manuellement pour la navigation privée. Bien que l’extension du navigateur UiPath puisse être installée (par exemple, via la stratégie de groupe), elle ne peut pas être automatiquement activée en mode incognito, ce qui empêchera l’automatisation d’interagir avec le navigateur pendant l’exécution du test.

En outre, Performance Testing crée de nouveaux répertoires d'utilisateurs de navigateur pour chaque exécution. L’activation de l’extension pour le mode navigation privée nécessiterait une configuration manuelle pour chacun de ces répertoires, ce qui rend peu pratique pour les scénarios automatisés. Pour de plus amples informations, reportez-vous à la section Alternative pour activer le mode Incognito de la documentation de Studio.

Cette limitation s’applique uniquement aux environnements locaux.

Dans les environnements sans serveur, le mode Incognito est pris en charge car la configuration du navigateur est entièrement gérée par UiPath.

Solution: exécutez les tests en mode navigateur standard.

Performance Testing crée son propre profil de navigateur et répertoire dédiés, garantissant qu’il n’interfère pas avec le profil par défaut de l’utilisateur. Cette configuration permet aux tests de s’exécuter dans un environnement sandboxed, comme en mode navigation privée. Après l’exécution, tous les répertoires de navigateur créés pour les tests sont nettoyés, de façon à ne laisser aucune donnée résidus.

Limites supplémentaires

Performance Testing mesure uniquement les éléments suivants :

• Charger
• Délai de réponse
• Taux d’erreur
• Débit

Il ne collecte pas les métriques de surveillance au niveau de l'application ou du système (CPU, mémoire, base de données, infrastructure). Les outils APM/d'observabilité existants couvrent plutôt ces données.

L'accès programmatique aux données de tests de performances est disponible au niveau du scénario : l'API peut renvoyer des métriques d'exécution pour un ID de scénario spécifique, que vous pouvez utiliser pour créer votre propre suivi historique (par exemple, en exportant les résultats après chaque exécution pour une comparaison ultérieure).

Aucune API n'existe pour la comparaison des métriques d'exécution dans deux exécutions de scénario ou plus, ou pour la récupération d'un résumé historique agrégé entre les exécutions. Dans le produit lui-même, la vue Comparaison des résultats de performances prend en charge cela.