Cadre d'automatisation des tests : Archistructure et types

Qu’est-ce que le framework dans les tests d’automatisation ?

A Cadre d'automatisation des tests est un ensemble de lignes directrices telles que les normes de codage, la gestion des données de test, le traitement du référentiel d'objets, etc. qui, lorsqu'elles sont suivies lors des scripts d'automatisation, produisent des résultats bénéfiques tels qu'une réutilisation accrue du code, une portabilité plus élevée, une réduction des coûts de maintenance des scripts, etc. Ce ne sont que des lignes directrices et non règles; ils ne sont pas obligatoires et vous pouvez toujours rédiger un script sans suivre les directives. Mais vous passerez à côté des avantages d’avoir un Framework.

Pourquoi avez-vous besoin d'un framework ?

Prenons un exemple pour comprendre pourquoi vous avez besoin d'un Framework.

Je suis sûr que vous avez assisté à un séminaire/conférence/conférence où les participants ont été invités à respecter les directives suivantes :

• Les participants doivent occuper leur place 5 minutes avant le début d'une conférence.
• Apportez un cahier et un stylo pour prendre des notes.
• Lisez les abdostract, pour que vous ayez une idée du contenu de la présentation.
• Les téléphones mobiles doivent être réglés sur silencieux.
• Utilisez les portes de sortie à l’extrémité opposée de l’orateur si vous devez partir au milieu de la conférence.
• Les questions seront répondues à la fin de la séance.

Pensez-vous pouvoir animer un séminaire SANS respectant ces directives ?

La réponse est un grand OUI! Certes, vous pouvez organiser un séminaire/une conférence/une conférence/une démonstration sans les directives ci-dessus. En fait, certains d'entre nous ne les suivront pas même si elles sont présentées !

Mais si les directives sont respectées, cela se traduira par un résultat bénéfique comme une réduction de la désaffection du public.traction pendant les cours, augmentation de la rétention des participants et meilleure compréhension du sujet.

Sur la base de ce qui précède, un Le cadre peut être défini comme un ensemble de lignes directrices qui, lorsqu’elles sont suivies, produisent des résultats bénéfiques.

Cadre d'automatisation des tests Archistructure : Composants clés

Avant de comparer les types, il est utile de voir ce que contient chaque framework. ArchiLa structure décrit la manière dont ces parties sont agencées en couches, de sorte qu'une modification d'une couche n'affecte pas les autres.

• Couche de script de test : Contient les cas de test. Les scripts restent courts car ils font appel à des fonctions réutilisables au lieu de répéter les étapes de navigation.
• Bibliothèque de fonctions : Enregistre les actions partagées telles que la connexion, la recherche et la déconnexion, de sorte qu'une modification du flux de travail n'est effectuée qu'une seule fois.
• Référentiel d'objets : Associe des noms conviviaux à des localisateurs d'éléments d'interface graphique. Lorsque l'interface change, seule cette couche est modifiée.
• Couche de données de test : Conserve les valeurs d'entrée et les valeurs attendues dans des sources Excel, CSV ou de bases de données plutôt que dans le code.
• Couche de configuration : Contient l'environnement URLs, choix du navigateur, délais d'expiration et informations d'identification.
• Couche de reporting : Génère des rapports d'exécution, des captures d'écran des échecs et des journaux de diagnostic.
• Couche d'exécution : Déclenche des suites de tâches depuis un serveur de compilation, reliant l'automatisation à intégration continue.

Les types de cadres ci-dessous diffèrent principalement par la rigueur avec laquelle ils séparent ces couches.

Types de cadres d'automatisation des tests

Vous trouverez ci-dessous les différents types de frameworks de tests automatisés :

1. Script linéaire
2. La bibliothèque de tests ArchiCadre technologique.
3. Le axé sur les données Tests Cadre.
4. Le cadre de test piloté par mots-clés ou par tableaux.
5. Le cadre d'automatisation des tests hybrides.

Regardons-les en détail –

1) Script linéaire – Enregistrement et lecture

Il s'agit du plus simple de tous les frameworks d'automatisation des tests et également connu sous le nom de « Enregistrement et lecture ». Dans ce Tests d'automatisation Framework, le testeur enregistre manuellement chaque étape (navigation et entrées utilisateur), insère des points de contrôle (étapes de validation) au premier tour. Il lit ensuite le script enregistré lors des tours suivants.

Exemple : Pensez à vous connecter Demande de réservation de vol et vérifier si l'application s'est chargée lors d'une connexion réussie. Ici, le testeur enregistrera simplement les étapes et ajoutera des étapes de validation.

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
'Check Flight Reservation Window has loaded after successful log-on
Window("Flight Reservation").Check CheckPoint("Flight Reservation")

Avantages

• Le moyen le plus rapide de générer un script
• Expertise en automatisation non requise
• Le moyen le plus simple d'apprendre les fonctionnalités de l'outil de test

Désavantages

• Peu de réutilisation des scripts
• Les données de test sont codées en dur dans le script
• Cauchemar de maintenance

2) La bibliothèque de tests ArchiCadre technique

On l'appelle aussi « Scripts structurés » or « Décomposition fonctionnelle ».

Dans ce framework de tests d'automatisation, les scripts de test sont initialement enregistrés par «Enregistrement et lecture" méthode. Later, les tâches courantes à l'intérieur des scripts sont identifiées et regroupées en fonctions. Ces fonctions sont appelées par le script de test principal appelé Chauffeur de différentes manières pour créer des cas de test.

Exemple : En utilisant le même exemple que ci-dessus, la fonction de connexion à Flight Reservation ressemblera à .

Function Login()
  SystemUtil.Run "flight4a.exe","","","open"
  Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
  Dialog("Login").WinEdit("Password:").Set "Mercury"
  Dialog("Login").WinButton("OK").Click
End Function

Maintenant, vous appellerez cette fonction dans le script principal comme suit

Call Login()
---------------------------
'Other Function calls / Test Steps.
---------------------------

Avantages

• Un niveau plus élevé de réutilisation du code est atteint dans les scripts structurés par rapport à « enregistrement et lecture »
• Les scripts d'automatisation sont moins coûteux à développer en raison d'une plus grande réutilisation du code
• Maintenance des scripts plus facile

Désavantages

• Une expertise technique est nécessaire pour écrire des scripts à l'aide de Test Library Framework
• Il faut plus de temps pour planifier et préparer les scripts de test.
• Les données de test sont codées en dur dans les scripts

3) Le cadre de tests basés sur les données

Dans ce cadre, alors que Cas de test La logique réside dans les scripts de test, tandis que les données de test sont séparées et stockées en dehors de ces scripts. Ces données sont lues à partir de fichiers externes (fichiers Excel, texte, CSV, sources ODBC, objets DAO, objets ADO) et chargées dans les variables des scripts de test. Ces variables servent à la fois aux valeurs d'entrée et aux valeurs de vérification. Les scripts de test sont préparés soit par programmation linéaire, soit à l'aide d'une bibliothèque de tests. Cette technique est expliquée plus en détail dans la section suivante. test basé sur les données tutoriel.

Exemple : Développerping Le script de connexion à la réservation de vols utilisant cette méthode comprendra deux étapes.

Étape 1) Créez un fichier Test – Données qui peut être Excel, CSV ou toute autre source de base de données.

Étape 2) Développez un script de test et faites des références à votre source de données de test.

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set DataTable("AgentName", dtGlobalSheet)
Dialog("Login").WinEdit("Password:").Set DataTable("Password", dtGlobalSheet)
Dialog("Login").WinButton("OK").Click
'Check Flight Reservation Window has loaded
Window("Flight Reservation").Check CheckPoint("Flight Reservation")
'Note "dtGlobalSheet" is the default excel sheet provided by QTP.

Avantages

• Les modifications apportées aux scripts de test n'affectent pas les données de test
• Les cas de test peuvent être exécutés avec plusieurs ensembles de données
• Une variété de scénarios de test peuvent être exécutés en faisant simplement varier les données de test dans le fichier de données externe.

Désavantages

• Plus de temps est nécessaire pour planifier et préparer à la fois les scripts de test et les données de test.

4) Le cadre de test piloté par mots-clés ou piloté par table

Le Axé sur les mots clés ou le développement d'un framework d'automatisation piloté par les tables nécessite des tables de données et des mots-clés, indépendant du outil d'automatisation de test utilisé pour les exécuter. Les tests peuvent être conçus avec ou sans l'application. Dans un test basé sur des mots clés, la fonctionnalité de l'application testée est documentée dans un tableau ainsi que dans des instructions étape par étape pour chaque test.

Il existe 3 composants de base d'un framework basé sur les mots clés, à savoir. Mot-clé, carte d'application, fonction du composant.

Le mot clé est une action qui peut être effectuée sur un composant GUI. Ex. Pour la zone de texte du composant GUI, certains mots-clés (action) seraient InputText, VerifyValue, VerifyProperty, etc.

Qu'est-ce que la carte des candidatures ?

Une carte d'application fournit des références nommées pour les composants de l'interface graphique. Les cartes d'application ne sont rien d'autre que «Référentiel d'objets"

Qu'est-ce que la fonction des composants ?

Les fonctions de composant sont les fonctions qui manipulent ou interrogent activement le composant GUI. Un exemple de fonction serait de cliquer sur le bouton Web avec toute la gestion des erreurs, de saisir des données dans une édition Web avec toute la gestion des erreurs. Les fonctions des composants peuvent dépendre de l'application ou être indépendantes.

Exemple: Pour comprendre la vue par mot-clé, prenons le même exemple. Cela implique 2 étapes

Étape 1: Création d'une table de données (différente de la table de données de test créée dans Data Driven Framework). Cette table de données contient l'action à effectuer sur les objets GUI et les arguments correspondants, le cas échéant. Chaque ligne représente une étape de test.

Étape 2: En écrivant Code sous la forme de fonctions composantes.

Une fois que vous avez créé votre ou vos tables de données, il vous suffit d'écrire un programme ou un ensemble de scripts qui lit chaque étape, exécute l'étape en fonction du mot-clé contenu dans le champ Action, effectue une vérification des erreurs et enregistre toutes les informations pertinentes. Ce programme ou ensemble de scripts ressemblerait au pseudo-code ci-dessous :

Function main()
{
  Call ConnectTable(Name of the Table) { //Calling Function for connecting to the table.
  while (Call TableParser() != -1) //Calling function for Parsing and extracting values from the table.
  {
    Pass values to appropriate COMPONENT functions. Like Set(Object Name, Argument) ex. Set(Agent Name, Guru99).
  }
}
  Call CloseConnection() //Function for Closing connection after all the operation has been performed.
} //End of main

C’est tout pour Keyword Driven Framework.

L’avantage du Keyword Driven Framework est que les mots-clés sont réutilisables. Pour comprendre cela, considérez que vous souhaitez vérifier l'opération de connexion à un site Web, par exemple YAHOO MAIL. Le tableau ressemblera à ceci –

Dans ce cas, vous constaterez que les mots clés « Définir », « Cliquer » et « Vérifier » restent inchangés, car les fonctions correspondantes sont déjà développées. Il vous suffit de modifier la carte d'application.ping (Référentiel d'objets) de la réservation de vol précédente vers Yahoo Mail , avec un changement dans les valeurs des arguments et le même script fonctionnera !

Avantages

• Fournit une réutilisation élevée du code
• Outil de test indépendant
• Indépendamment de l'application testée, le même script fonctionne pour AUT (avec quelques limitations)
• Les tests peuvent être conçus avec ou sans AUT

Désavantages

• L'investissement initial étant assez élevé, les avantages ne peuvent être réalisés que si l'application est considérablement volumineuse et si les scripts de test doivent être maintenus pendant plusieurs années.
• Une expertise élevée en automatisation est requise pour créer le cadre axé sur les mots clés.

NOTE: Même si OpenText UFT One (anciennement Micro Focus) UFTBien que ce framework se présente comme un framework piloté par mots-clés, son utilisation ne permet pas d'atteindre une indépendance totale entre les outils de test et les applications.

5) Le cadre d'automatisation des tests hybrides

Comme son nom l'indique, ce cadre est la combinaison d'un ou plusieurs cadres d'automatisation évoqués ci-dessus tirant parti de leurs points forts et essayant d'atténuer leurs faiblesses. Le cadre d'automatisation de l'assurance qualité des tests hybrides est ce vers quoi la plupart des cadres d'automatisation des tests évoluent au fil du temps et de plusieurs projets. L'industrie maximale utilise Keyword Framework dans une combinaison de méthodes de décomposition de fonctions.

PS: D'autres cadres d'automatisation qui méritent d'être mentionnés sont

Cadre de modularité des tests

Dans ce cadre, une tâche courante dans le script de test est regroupée en modules.

Exemple: Utilisation des actions dans QTP L'utilisateur peut créer des scripts modulaires

Exemple de script pour la connexion

SystemUtil.Run "flight4a.exe","","","open"
Dialog("Login").WinEdit("Agent Name:").Set "Guru99"
Dialog("Login").WinEdit("Password:").Set "Mercury"
Dialog("Login").WinButton("OK").Click
'End of Script

Vous pouvez maintenant appeler cette action dans le script principal comme suit :

RunAction ("Login[Argument]", oneIteration)

Tests de processus métier (BPT)

Ces cadres d'automatisation divisent les grands processus métier en composants qui peuvent être réutilisés plusieurs fois dans le même ou dans des scripts de test différents. Par exemple, le processus métier de réservation d'un vol est divisé en composants tels que la connexion, la recherche de vols, la réservation, le paiement et la déconnexion qui peuvent être réutilisés dans le même processus métier ou dans différents processus. En outre, BPT facilite une coordination plus étroite entre les PME et les ingénieurs en automatisation.

Comment choisir le bon framework d'automatisation des tests

Aucun type de solution n'est systématiquement gagnant. Le choix optimal dépend des compétences de l'équipe, de la taille de l'application et de la durée de vie requise. Le tableau ci-dessous compare les cinq types de solutions selon les facteurs déterminants.

Réfléchissez à ces questions avant de vous engager :

1. Combien de temps durera la suite ? Des années de maintenance justifient l'investissement initial élevé d'une conception basée sur des mots-clés ou hybride. Ce n'est pas le cas pour un projet de courte durée.
2. Qui rédige les tests ? Si des testeurs manuels contribuent aux cas d'utilisation, un tableau de mots-clés leur permet de travailler sans avoir à apprendre le langage de script.
3. À quel point l'interface est-elle volatile ? Les changements fréquents d'écran rendent indispensable un référentiel d'objets séparé, sinon chaque script devra être modifié.
4. Quel degré de variation des données est nécessaire ? De nombreuses combinaisons de données d'entrée indiquent clairement une conception axée sur les données.
5. Quel outil est déjà utilisé ? Le cadre doit correspondre au choix outil d'automatisation et une langue que l'équipe connaît, comme Selenium au Java or Cucumber.

La plupart des équipes commencent par une approche basée sur une bibliothèque ou sur les données, puis évoluent vers un modèle hybride. régression La suite s'agrandit.

Avantages du cadre d'automatisation des tests Architecture

Voici les avantages de l’architecture du cadre d’automatisation des tests :

• Un cadre d'automatisation des tests permet de réduire les risques et les coûts
• Il améliore l’efficacité des tests
• Cela aide à réduire les coûts de maintenance
• Permet la réutilisation du code
• Il permet d'obtenir une couverture de test maximale
• Il maximise la fonctionnalité de l'application
• Aide à réduire la duplication des scénarios de test
• Il contribue à améliorer l'efficacité et les performances des tests grâce à l'automatisation des tests.

FAQ