Introduction

Suite de Test Exemple

Création d'une Suite de Test

Utilisation du Débogueur

Ecriture d'une Procédure

Création d'une Procédure Générale

Modularisation

Bibliothèque Standard

Gestion de Composants d'IHM Complexes

Avant de démarrer votre propre Application

Lecture Avancée

Durée estimée : 30 à 45 minutes

7.1 Création de la Suite Pilote

7.2 Appartenance de la Suite d'Utilitaires

7.3 Création d'une Séquence de Test

7.4 Appel d'une Procédure dans la Suite Utilitaire

7.5 Ajout d'un Include

7.6 Modularisation pour Plusieurs SUT

Dans ce chapitre, nous allons approfondir les concepts étudiés dans les précédents chapitres. Notre objectif est de vous montrer comment vous pouvez modulariser les suites de test. Dans la mesure où les caractéristiques que nous allons présenter ici sont plus avancées que celles étudiées précédemment, il est important que vous ayez bien compris les concepts étudiés précédemment.

Alors que vous commencez à développer des suites de test spécifiques à vos besoins, vous vous trouverez souvent dans des situations dans lesquelles vous effectuez les mêmes étapes à plusieurs reprises, ou de façon redondante. La suite A, par exemple, peut souvent nécessiter l'utilisation d'opération de menu dans votre SUT dont la suite B a également besoin. Au lieu d'avoir la même procédure dans chacune des suites, il est beaucoup plus utile et fiable, d'avoir un source commun pour la procédure.

Cela nous amène à introduire le concept de la suite d'utilitaire (ou de bibliothèque) qui contient des procédures communes pour l'utilisation par n'importe quel nombre d'autres suites de test. Votre utils.qft, que vous avez sauvegardé dans la section précédente (Cf. section 6.10 du chapitre 6), va donc servir comme une sorte de bibliothèque à laquelle les autres suites de test peuvent accéder pour les procédures d'utilitaires communes. L'avantage d'une telle structure est que vous avez une bibliothèque de routines stables qui peut être utilisée pour effectuer leur fonction précisément par d'autres suites de test. Une telle modularisation de suites est facile à mettre en oeuvre dans QF-Test.

7.1 Création de la Suite Pilote

Ouvrez maintenant une nouvelle suite avec le menu File -> New Suite. Avec cette suite de test, vous allez créer un test réel pour le SUT.

Vous devez également ramener votre suite de test utils.qft, qui contient le paquetage checkbox que vous avez écrit dans le chapitre précédent.

Sauvegardez la nouvelle suite pilote dans le même répertoire que utils.qft. C'est nécessaire, ainsi vous pouvez utiliser des noms de chemin d'accès relatifs quand une suite de test se réfère à une autre. Le nom du fichier n'a pas d'incidence.

7.2 Appartenance de la Suite d'Utilitaires

Si l'application SUT n'est pas déjà en exécution, démarrez-la. Vous remarquerez que les nSuds de démarrage pour le SUT sont encore situés dans utils.qft. Une vraie suite d'utilitaires ne devrait avoir aucune connexion directe à un SUT, tout simplement parce que la suite d'utilitaires peut être utilisée par d'autres suites de test qui testent différents SUT.

Par exemple, disons que vous avez deux SUT complètement différents, A et B, que vous devez tester. Aussi vous voudriez créer deux suites de test pour chaque SUT. Mais, dans chacune des applications SUT, des cases à cocher sont présentes, qui peuvent être sélectionnées ou pas en utilisant votre suite d'utilitaires utils.qft. utils.qft doit donc être suffisamment polyvalente pour gérer ce genre de situation.

utils.qft contient des éléments qui les lient directement au SUT Options Demo, que nous avons créé en section 5.1, c'est-à-dire les nSuds Setup/Cleanup tout comme la section Windows and components. Cette information spécifique au SUT est maintenant sans rapport avec la suite d'utilitaires et doit être déplacée dans la suite de test qui testera directement le SUT.

Aussi, de la même manière qu'en section 5.1 du chapitre 5, vous pouvez maintenant déplacer les nSuds Setup/Cleanup et le contenu du nSud Windows and components dans votre nouvelle suite. Utilisez bien le menu Couper, et non pas Copier, pour que les nSuds soient bien enlevés de utils.qft. Une fois effectuée, votre nouvelle suite de test doit ressembler au squelette que nous avons vu sur la figure 5.1. Vous pouvez aussi nettoyer les nSuds de l'appel de procédure que vous avez créés dans utils.qft.

Figure 7.1 - Suite Utilitaire utils.qft

7.3 Création d'une Séquence de Test

Dans cette section, vous utiliserez votre nouvelle suite de test pour créer une séquence de test pour le SUT. La séquence de test sera simple : sélectionnez la fenêtre Miscellaneous du SUT et décochez la case Boolean option.

Après le nSud Setup dans votre suite de test, insérez un nSud séquence avec le menu Insert -> Sequence nodes -> Sequence. Donnez-lui un nom tel que Deselect checkbox. Ouvrez le nSud pour pouvoir y insérer de nouveaux nSuds.

Figure 7.2 - Désélection du NSud Séquence Checkbox

Maintenant cliquez sur le bouton d'enregistrement de votre suite de test afin d'enregistrer une séquence. Ramenez la fenêtre du SUT et cliquez sur l'élément Miscellaneous sous la liste Preferences. Vous voyez s'afficher la sous-fenêtre Miscellaneous Options dans le SUT. Retournez à votre suite de test et cliquez sur le bouton pour arrêter l'enregistrement.

Dans la séquence enregistrée qui apparaît dans le nSud Extras, vous voyez seulement un événement enregistré, à savoir le clic de l'élément Miscellaneous. Déplacez ce nSud dans votre nouveau nSud séquence, ce qui devrait vous donner ceci :

Figure 7.3 - NSud Séquence avec le Clic Enregistré

7.4 Appel d'une Procédure dans la Suite Utilitaire

L'étape suivante dans la séquence du test consiste à faire un appel à la suite utilitaire pour désélectionner la case à cocher. Comme vous l'avez fait en section 6.8 du chapitre 6, insérez un nSud appel de procédure à la procédure checkbox.setState. Cette fois, toutefois, nous avons besoin de procéder à une légère modification, dans la mesure où la procédure est dans une autre suite de test.

Les appels de procédure dans QF-Test peuvent être précédés du nom de la suite (suite#procedure) pour indiquer que la procédure cible est située dans la suite de test fournie. Pour notre exemple, l'appel de procédure est correctement déclaré utils.qft#checkbox.setState. N'oubliez pas de renseigner les variables comme cela a été fait en section 6.8 du chapitre 6, avec select positionné à false.

Figure 7.4 - Appel de Procédure à Utils.qft

7.5 Ajout d'un Include

Au lieu de faire des appels de procédure qui incluent une référence explicite à la suite de test comme avec utils.qft#setState, QF-Test fournit un mécanisme simple qui vous permet d'inclure certaines suites de test comme partie de votre structure globale de suite de test.

Un include est une référence implicite à une suite de test. Quand QF-Test voit un nSud appel de procédure sans une référence explicite à une suite de test (c'est-à-dire qu'il n'y a pas de nom de suite de test précédant le symbole # devant le nom de la procédure), alors il essaie de chercher dans la suite active la procédure appelée. Si la procédure n'est pas trouvée dans la suite, alors la recherche se fait dans la liste d'include de la suite de test.

Cliquez sur le nSud racine Test-suite de votre suite de test. Dans les propriétés de ce nSud, vous verrez une section pour les fichiers include. Dans cette liste, ajoutez maintenant le nom de votre suite utilitaire : utils.qft. Les entrées sont ajoutées et modifiées dans cette liste comme vous l'avez fait avec les variables en utilisant les petits boutons ajouter, éditer et supprimer. Vous devez obtenir ce résultat :

Figure 7.5 - Liste Include

Conseil : Pour des informations détaillées sur la manière dont QF-Test résoud des problèmes concernant les appels de procédure, merci de vous référer à la section Résolution de Fichier Include du Manuel Utilisateur.

7.6 Modularisation pour Plusieurs SUT

Si vous vous rappelez la discussion en section 7.2, une suite utilitaire telle que utils.qft ne doit pas contenir de références directes au client SUT. Si vous regardez bien utils.qft, vous verrez qu'il y a en effet encore de telles références à Options Demo. Jetez un coup d'Sil à l'un de vos nSuds Check selected state, par exemple, et vous verrez la référence au client :

Figure 7.6 - Référence Constante au Client SUT

Cette référence directe, bien sûr, vous empêche d'utiliser utils.qft avec d'autres suites de test, mais la solution est simple. Au lieu de référencer directement le SUT, vous remplacerez la référence avec une variable qui peut (et doit) être positionnée avec la suite de test qui utilise utils.qft.

Partout où vous voyez une référence au client Options, remplacez-la avec une référence variable, appelons-la $(client) comme montré ci-dessous :

Figure 7.7 - Référence Variable au Client SUT

Vous devez changer toutes les références au client dans utils.qft, mais QF-Test vous facilite cette tâche avec la fonctionnalité recherche/remplacement. Cliquez sur le nSud Test de haut niveau de la suite de test et sélectionnez le menu Edit -> Replace.

L'étape suivante consiste donc à modifier le pilote de la suite de test pour qu'une valeur de la variable client soit disponible quand des procédures à l'intérieur de utils.qft sont utilisées. Une façon de procéder est de passer la variable client comme un argument pour chaque appel de procédure dans utils.qft. Ce type de solution est parfaitement viable.

Une autre solution, plus élégante, consiste à positionner la variable une fois dans votre suite de test, aussi vous n'avez plus à vous en préoccuper. Ouvrez le nSud de haut niveau Test-suite. Dans la fenêtre de propriétés de la suite de test, vous verrez une section (au-dessous des includes et dépendances) dans laquelle vous pouvez définir les variables pour la suite de test. Dans cette zone, ajoutez la variable client et donnez-lui pour valeur Options :

Une fois que vous avez terminé cette étape, vous n'aurez plus à vous préoccuper de cette variable jusqu'à la création d'une nouvelle suite de test qui utilise utils.qft. Votre suite utilitaire est désormais complètement modulaire !