Cadres d'automatisation de données, de mots clés et hybrides dans QTP/UFT

Cadre basé sur les données

Data Driven Framework est un cadre qui s'appuie sur les différentes combinaisons de données d'entrée et de sortie.

Une façon de transmettre différentes combinaisons de données consiste à paramétrer. Dans cette méthode, nous utilisons différentes fonctionnalités de QTP. Pour en savoir plus sur le paramétrage, veuillez visiter ici.

Cependant, dans DDF, des scripts sont écrits pour effectuer le paramétrage. Ce type de cadre est utile lorsque la fonctionnalité de l'AUT doit être testée avec plusieurs entrées et capturer les sorties respectives. Ces entrées peuvent être lues à partir d'un fichier externe tel qu'une base de données, Excel, Outlook, fichier texte, etc. et les sorties respectives sont réécrites sur la source externe correspondante.

Cadre basé sur les données

Les étapes générales impliquées dans le cadre basé sur les données sont :

  1. Préparer la Cas de test pour l'application testée
  2. Ajouter les objets de AUT à OR
  3. Écrire les scripts basés sur le scénario de test

Dans ce nouvel article concernant notre nouveau projet Tutoriel UFT, nous développerons une conception de cadre basée sur les données pour un exemple de cas de test en utilisant Excel comme source externe pour les données de test.

Étape 1) Préparez le scénario de test pour l'application testée

Cas de test: Ouvrez le numéro de commande et obtenez le nom du client pour cette commande. Répétez le même processus pour différents numéros de commande

Source externe: Fichier Excel

Préparer le scénario de test pour l'application testée

La source externe de cet exemple est un fichier Excel. Le script VB dans Micro Focus UFT doit être écrit pour ouvrir un fichier Excel afin de lire les données de test. Ceci peut être réalisé de manière hiérarchique.

1. Un fichier Excel est d'abord ouvert en tant qu'application

2. Ensuite, le classeur doit être ouvert à partir de l'emplacement spécifié

3. La feuille où sont présentes les données de test.

4. Enfin, la cellule doit être lue.

Étape 2) Ajoutez les objets de AUT à OR

Une fois le scénario de test prêt, commencez à ajouter tous les objets requis au référentiel. Dans notre cas de test, les objets à ajouter sont les suivants

Ajouter les objets de AUT à OR

  • Case à cocher « N° de commande » qui peut être obtenue lorsque l'on clique sur l'icône « Ouvrir le dossier »

Ajouter les objets de AUT à OR

  • La case WinEdit du N° de commande (là où sont saisis les numéros)

Ajouter les objets de AUT à OR

  • Le bouton OK

Ajouter les objets de AUT à OR

  • Le champ « Nom » qui est une boîte WinEdit. Ce champ sera renseigné avec un nom une fois que vous aurez cliqué sur le bouton OK pour un numéro de commande particulier.

Ajouter les objets de AUT à OR

Une fois tous les objets requis ajoutés, le référentiel d'objets apparaîtra comme suit :

Ajouter les objets de AUT à OR

Étape 3) Écrivez les scripts basés sur le scénario de test

Avant d'exécuter le script, assurez-vous que le fichier Excel contenant les données de test a été enregistré et est fermé.

Le script ci-dessous consiste à lire le numéro de commande à partir d'Excel et à l'attribuer à l'application via la variable « vOrder » et à écrire le nom du client à partir de l'application via la variable « vName ».

Nom Excel: FlightDDF.xlsx

Nom de la feuille: Feuille1

Écrivez les scripts basés sur le cas de test

Sortie

Une fois le script ci-dessus exécuté, le résultat peut être obtenu à partir d'Excel comme suit :

Écrivez les scripts en fonction de la sortie du scénario de test

Le Data-Driven Framework peut également être développé en écrivant une programmation descriptive.

Utilisation de la base de données comme source externe pour DDF

Le même scénario de test peut être exécuté si la source externe est une base de données en suivant les étapes suivantes

  1. Écrivez VBScript pour établir la connexion à la base de données
  2. VBScript pour ouvrir un jeu d'enregistrements ou une table.
  3. VBScript pour ouvrir le champ souhaité
  4. La cellule particulière est lue à partir du champ.

Utilisation de la base de données comme source externe pour DDF

scénario

To Establish a Microsoft Database connection

Pilote = {Microsoft Pilote d'accès (*.mdb)} ; DBQ =

Nom du jeu d'enregistrements : OpenOrder

Nom des champs : Numéro de commande, nom du client

PS: Microsoft Access 2010 ne peut pas être connecté à l'aide du script ci-dessous.

Utilisation de la base de données comme source externe pour DDF

Sortie

Utilisation de la base de données comme source externe pour la sortie DDF

Avantages du DDF

  • Un grand nombre de données de test peuvent être lues et écrites dans le fichier externe en un seul test
  • L'instruction de boucle est utilisée pour répéter les mêmes étapes pendant plusieurs itérations. L’effort de codage est donc réduit
  • Puisque les données sont lues et écrites directement dans le fichier externe, il n'est pas nécessaire de copier, coller ou exporter les données pour les utiliser.
  • Les données de test peuvent être lues à partir d'un fichier externe et les sorties peuvent être écrites dans n'importe quel autre fichier externe

Inconvénients du DDF

  • Des connaissances en scripting sont nécessaires pour développer ce framework
  • Parfois, un certain nombre ou des combinaisons de données provenant d'une source externe telle qu'une base de données peuvent ralentir ou même faire planter QTP.

Cadre axé sur les mots clés

Keyword Driven Framework est un cadre dans lequel les mots-clés pilotent le test. Ici le mot-clé fait référence aux fonctions définies par l'utilisateur. Dans ce cadre, des mots-clés sont créés afin d'effectuer une étape de test particulière ou un scénario de test. Ces mots-clés sont ensuite appelés dans le test du pilote pour exécuter plusieurs scénarios de test dans le même test.

Pour en savoir plus sur les fonctions définies par l'utilisateur dans QTP, veuillez visiter ici

Cadre axé sur les mots clés

En général, les frameworks peuvent être développés de trois manières afin d’être testés.

  1. Enregistrez et exécutez le test
  2. Ajoutez des objets au référentiel local et écrivez les scripts pour toutes les étapes de test
  3. Rédiger une programmation descriptive pour toutes les étapes de test

Dans ce didacticiel, le KDF est développé en enregistrant et en exécutant le test.

Notre objectif est d'exécuter un seul test pour cinq cas de test différents, tels que la connexion à l'application, l'insertion d'une commande, l'ouverture d'une commande, la suppression d'une commande et la fermeture de l'application. Par conséquent, nous enregistrerons les étapes de test pour ces cas de test et créerons les fonctions avec les mots-clés Login, InsertOrder, OpenOrder, DeleteOrder et CloseApp respectivement.

Cas de test 1 : Connectez-vous à l'application

Mot-clé: Se connecter ()

Script enregistré :

Cadre axé sur les mots clés

Cas de test 2 : insérer la commande

Mot-clé:InsérerOrdre()

Script enregistré :

Cadre axé sur les mots clés

Cas de test 3 : ouvrir la commande

Mot-clé:OuvrirCommande()

Script enregistré :

Cadre axé sur les mots clés

Cas de test 4 : supprimer la commande

Mot-clé:Supprimer la commande()

Script enregistré :

Cadre axé sur les mots clés

Cas de test 5 : Fermez l'application

Mot-clé:FermerApp()

Script enregistré :

Cadre axé sur les mots clés

Les fonctions créées pour différents scénarios de test sont enregistrées dans une bibliothèque de fonctions et sont associées au test principal. Il suffit d'appeler les mots-clés pour les cas de test nécessaires dans le test principal, réduisant ainsi la taille du script du pilote dans le test principal.

Le script du pilote pour ce framework simple ressemble à :

Cadre axé sur les mots clés

En exécutant le script ci-dessus, le résultat réel des cinq cas de test peut être obtenu à partir d'un seul test.

Avantages

  • N'importe quel nombre de cas de test peut être exécuté sur un seul test simplement en appelant leurs mots-clés respectifs
  • Écrire une programmation descriptive générale pour tous les objets Web/Windows et les appeler comme mots-clés aidera à exécuter le même test pour différentes applications dynamiques
  • Réduit la taille du script du pilote

Désavantages

  • Le temps nécessaire au développement de ces frameworks est très long s'il y a très peu de cas de test à exécuter
  • L'enregistrement des étapes n'est pas toujours utilisé lors de la conception de KDF pour de nombreuses applications sur le même test.

Cadre hybride

Un framework hybride est une combinaison de Data Driven Framework (DDF) et de Keyword Driven Framework (KDF) où plusieurs cas de test avec plusieurs entrées peuvent être exécutés dans le même test.

Dans cet article, les mêmes scénarios de test utilisés dans KDF seront exécutés en un seul test. Les mots-clés et les scripts de tous les cas de test sont les mêmes que dans KDF. Cependant TC3 : Ouvrir la commande a été paramétré. Par conséquent, le script de ce scénario de test est écrit pour recevoir le numéro de commande à partir d'un fichier Excel et pour écrire le nom du client dans le fichier Excel.

Cadre hybride

Cas de test 1 : Connectez-vous à l'application

Mot-clé: Se connecter ()

Cas de test 2 : insérer la commande

Mot-clé:InsérerOrdre()

Cas de test 3 : ouvrir la commande pour plusieurs numéros de commande

Mot-clé:OuvrirCommande()

Description: Ici, le même script que celui utilisé pour développer un DDF est utilisé, réalisant ainsi le cas de test sur plusieurs itérations.

Scénario:

Cadre hybride

Cas de test 4 : supprimer la commande

Mot-clé:Supprimer la commande()

Cas de test 5 : Fermez l'application

Mot-clé:FermerApp()

En suivant cette méthode simple, le paramétrage de TC3 est réalisé. Le cas échéant, tous les autres cas de test peuvent également être paramétrés dans le même test.

Par exemple, c'est un moyen très simple de concevoir un framework hybride. Le même cadre peut également être obtenu avec une programmation descriptive.

Avantages

  • Le temps nécessaire pour exécuter le test conçu avec un framework hybride est relativement inférieur à celui d'autres frameworks
  • Cela peut être utilisé lorsque nous avons besoin de tous les scénarios de test et entrées associés à un scénario de test particulier, dans la même suite de tests.

Désavantage

  • Une connaissance claire de la combinaison de différents cadres est requise.