Meilleures pratiques d'automatisation de test SAP

Meilleures pratiques pour la structuration des projets d'automatisation de test SAP dans Test Manager et Studio : structure du projet, composants réutilisables et choix d'activités qui réduisent l'effort de maintenance.

La création de cas de test automatisés pour les applications SAP est rapide et fiable, mais la complexité de SAP peut affecter à la fois la stabilité de vos automatisations et l'effort nécessaire pour les maintenir au fil du temps. Ces directives permettent de garder les projets de test SAP simples à comprendre, faciles à étendre et peu coûteux à maintenir. Pour obtenir les étapes côté Studio qui connectent une automatisation à un cas de test, consultez la section Automatiser les cas de test.

Structure de projet recommandée

Un projet d'automatisation de test SAP bien structuré donne à chaque partie une responsabilité unique et claire :

• Modèle d'exécution : un modèle spécifique à WinGUI qui gère le nettoyage de l'environnement et démarre SAP avant l'exécution d'un cas de test.
• Aides : workflows réutilisables qui récupèrent les identifiants et se connectent à SAP.
• Composants réutilisables : blocs de construction d'automatisation, généralement un par transaction SAP, appelables à partir de plusieurs cas de test.
• Cas de test : les workflows de niveau supérieur qui assemblent les aides et les composants réutilisables dans un scénario de bout en bout.

Séparation des données de test de la logique d'automatisation

Les données dont un cas de test a besoin restent distinctes de la séquence d'étapes qui l'exécute :

• Préparation des données de test : affectation des données de test (type de commande, organisation de vente, canal de distribution et valeurs similaires) au début du cas de test.
• Séquençage des automatisations avec des vérifications entre les deux : invocation de chaque composant réutilisable dans l'ordre, avec une étape Vérifier l'expression après que chacune a confirmé le résultat attendu avant de continuer.

Une structure Given-When-Then n'est pas nécessaire pour les cas de test SAP - la séquence de préparation des données et d'automatisation affichée ci-dessous est suffisante.

Utilisation des transactions SAP comme composants réutilisables

Les transactions SAP sont les limites naturelles pour les séquences d'automatisation réutilisables :

• Démarrage de chaque composant à partir de la fenêtre SAP Easy Access.
• Utilisation d'activités spécifiques à SAP lorsqu'elles sont disponibles - elles enrichissent les activités UI Automation standard (Click, Get Text et autres) avec un comportement adapté à SAP.
• Quitter la transaction pour revenir à la fenêtre SAP Easy Access avant que le composant n'ait terminé, afin que la transaction suivante de la séquence puisse se poursuivre à partir d'un point de départ connu.

Remarque :

La Heatmap mesure la couverture par transaction SAP. Si votre automatisation n'est pas structurée avec un composant réutilisable par transaction, la couverture affichée dans la Heatmap peut paraître gonflée ou incomplète par rapport à ce que vous avez réellement vérifié.

Utilisation d'un modèle d'exécution WinGUI

Un modèle d'exécution spécifique à WinGUI s'exécutant avant chaque cas de test met l'environnement dans un état connu :

1. Fermeture de toute instance SAP qui est toujours en cours d'exécution, par exemple avec Kill Process sur saplogon.exe.
2. Connexion à SAP à l'aide d'un workflow d'aide réutilisable.

Privilégier Simuler plutôt que les événements matériels

Simuler est le mode d'entrée recommandé pour l'automatisation SAP, défini au niveau du projet sous Paramètres du projet > UI Automation Modern > Méthodes de ciblage - SAP. Il est plus rapide et plus fiable que les événements matériels pour la plupart des contrôles SAP.

Contrôles qui ne prennent pas en charge Simuler

Certains champs génèrent une erreur « L'écriture de texte avec Simuler n'est pas prise en charge ». La commutation du mode d'entrée de cette activité spécifique vers Événements matériels résout le problème, sans modifier la valeur par défaut au niveau du projet.

Choix des activités dédiées à SAP plutôt que les activités génériques

Les activités spécifiques à SAP sont généralement le meilleur choix par rapport aux activités UI Automation génériques ; elles sont conçues pour comprendre les contrôles SAP et sont plus résilientes au changement que les équivalents génériques.

Activités de navigation et d'écran :

• Call Transaction
• Click Picture on Screen
• Click Toolbar Button
• Select Menu Item
• SAP Login
• SAP Logon

Activités de la table et de l'arborescence :

• Développer la table hiérarchique ALV (visionneuse de liste ABAP)
• Expand ALV Tree
• Expand Tree
• Table Cell Scope

Activités de données et de statut :

• Read Status Bar
• Select Dates In Calendar

Exemple de cas de test de bout en bout

Un seul cas de test de bout en bout peut enchaîner les transactions SAP dans une session : journalisation avec SAP Logon, affecter les données de test avec Multiple Assign, puis exécuter le composant réutilisable pour chaque transaction de la séquence - par exemple, VA01, VKM1, VL10H, VT01N, VT02N, VL02N, VI01, VF01 et BF03 - revenant à SAP Easy Access avant que la transaction suivante ne démarre.

Résumé

Le fait de garder les projets d'automatisation de test SAP simples réduit l'effort nécessaire pour les maintenir au fil du temps :

• Une structure de projet facile à comprendre.
• La logique répétable est déplacée vers des composants réutilisables, chacun avec une seule responsabilité.
• Aucun temps passé à créer pour des exigences dont vous n'avez pas encore besoin.