Meilleures pratiques en matière de tests de performances

Concevez des automatisations de tests fiables

Assurez-vous que les cas de test sont robustes, stables et ne présentent aucune faille avant la mise à l’échelle.

Choisir les stratégies de montée en puissance et de durée

Utilisez une méthode de montée en puissance pour simuler un trafic réaliste et éviter les phases de pic imprévues.

Gérer les données de test à grande échelle

Préparez des ensembles de données paramétrés (sur Data Fabric) pour éviter les entrées en double qui pourraient fausser les résultats.

Évitez les erreurs courantes

• Assurez-vous que les ressources d’infrastructure sont suffisantes.
• Validez les tests localement avant de les publier.
• Utilisez les dernières versions du package.

Automatisation du navigateur

Les recommandations suivantes détaillent les bonnes pratiques générales en matière de tests de performances, en particulier pour les scénarios d’automatisation des navigateurs. Les tests de performances nécessitent l’exécution simultanée de plusieurs utilisateurs virtuels (VU) sur la même machine, ce qui introduit des contraintes qui n’existent pas dans l’exécution avec un seul utilisateur.

1. Évitez les opérations du système de fichiers locaux.

   Toute étape qui lit ou écrit dans un fichier local s'appuie sur des handles de fichiers Windows. Windows verrouille un gestionnaire de fichier lorsqu'il est ouvert par un processus, empêchant tous les autres processus d'accéder au même fichier. Cela provoque des échecs lorsque plusieurs VU s’exécutent simultanément.

   Exemples courants :

   • Lecture des données de test d’Excel ou de CSV — Plusieurs VU ne peuvent pas ouvrir le même fichier simultanément. Utilisez Data Fabric à la place pour gérer les données de test simultanément sans conflit de traitement de fichier.
   • Écriture de captures d'écran dans des documents Word : la capture de preuves n'est généralement pertinente que pour les tests fonctionnels et ne doit pas faire partie d'un test de performances. Dans un test de charge, des centaines de VU s’exécutent en boucle : chaque itération génère ses propres documents, produisant rapidement un volume d’artefacts ingérable.
   • Toute autre interaction avec les fichiers locaux , c’est-à-dire les fichiers de configuration, les fichiers journaux, les magasins de données intermédiaires, sont tous soumis à un verrouillage de la gestion des fichiers.
2. Préférer l'API Chromium - Évitez les événements matériels et Computer Vision.

   Approche	Description	Compatibilité multi-vU
   API Chromium (événements DOM simulés)	Déclenche les événements directement sur les éléments DOM dans l’instance de navigateur via des sélecteurs. Aucune entrée réelle ne se produit au niveau du système d’exploitation : le navigateur gère l’interaction en interne.	Parfait — indépendant par instance ; fonctionne sur les fenêtres en arrière-plan.
   Événements matériels	Génère une entrée souris/clavier réelle au niveau du système d’exploitation. Le système d'exploitation le renvoie à la fenêtre actuellement active (au premier plan).	Faible — l'entrée va à la fenêtre qui se trouve au premier plan, pas nécessairement l'instance de navigateur prévue.
   Computer Vision	Localise les éléments par correspondance de modèle visuelle à l'écran.	Non viable : les instances du navigateur en arrière-plan sont invisibles pour la reconnaissance des images.

3. Utilisez toujours l'API Chromium par défaut.

   ChromiumAPI fonctionne directement sur le DOM et fonctionne, que la fenêtre du navigateur soit au premier plan, réduite ou masquée.

4. Évitez les événements matériels.

   Les événements matériels sont transmis par le système d'exploitation à la fenêtre active. Avec plusieurs VU, un événement matériel destiné à une instance de navigateur sera envoyé à la fenêtre qui se trouve actuellement au premier plan. Les événements matériels ne sont pas adaptés lorsque plusieurs automatisations s'exécutent en parallèle sur une même machine.

5. Évitez Computer Vision.

   Computer Vision ne peut pas interagir avec les fenêtres en arrière-plan et est donc incompatible avec l'exécution multi-VCPU. Les sélecteurs incorrects ou ambigus sont la raison la plus courante pour laquelle une infrastructure est abandonnée à Computer Vision. Assurez-vous que les sélecteurs sont corrects et validés lors du développement. Les sélecteurs stricts (ID, attributs de test de données, rôles ARI) fonctionnent bien, en particulier pour des applications comme SAP Fiori. Les sélecteurs de correspondances approximatives sont également compatibles avec les tests de performances tant qu’ils correspondent de façon fiable à l’élément prévu sans déclencher de solution de secours Computer Vision.

6. Recommandation d’exécution d’essai

   Lorsque vous ajoutez un cas de test à un scénario de performances pour la première fois, l’outil vous invite à effectuer une exécution d’essai. Une exécution d'essai exécute plusieurs instances sur la même machine pour confirmer qu'il n'y a pas de verrouillages de fichiers, de conflits d'entrée ou de problèmes de sélecteur avant de passer à la charge complète.