Création d'une Procédure Générale
Gestion de Composants d'IHM Complexes
Avant de démarrer votre propre Application
2.1 Démarrage de qftestJUI et Chargement de la Suite de Test
2.2 Démarrage de l'Application
2.6 Contrôle d'un Bouton Radio
2.1 Démarrage de qftestJUI et Chargement de la Suite de Test
Après avoir démarré qftestJUI, vous pouvez immédiatement utiliser notre premier exemple de suite de test. Sélectionnez le menu File -> Open puis le répertoire qftestJUI-1.08.4/doc/tutorial depuis votre répertoire d'installation qftestJUI. Cliquez sur le fichier Options.qft. qftestJUI charge alors la suite de test, comme montré ci-dessous :
Figure 2.1 - Suite de Test Options.qft
La partie gauche de la fenêtre principale contient l'arborescence de la suite de test. La partie droite affiche les détails d'un nSud sélectionné. Si la vue Détails ne s'affiche pas, sélectionnez le menu View -> Details. Dans la zone inférieure de la fenêtre principale vous voyez la zone du Terminal, qui affiche les messages standards et les communications entre votre suite de test et l'application cliente que vous testez. Vous pouvez afficher ou non le Terminal en sélectionnant le menu View -> Terminal -> Show.
Avec la structure arborescente dans la fenêtre principale, vous pouvez naviguer et sélectionner des nSuds individuels de votre suite de test. Lorsqu'un nSud est sélectionné, ses propriétés s'affichent dans la zone Détails (partie droite de la fenêtre principale). Cliquez sur le nSud Test: Options pour ouvrir les nSuds du dessous. Vous verrez que ce nSud contient un nSud pour le Setup, trois nSuds test (un nSud test et deux nSuds séquences pour être précis), et un nSud pour le Cleanup.
Figure 2.2 - Contenu du NSud Test: Options
2.2 Démarrage de l'Application
La première étape consiste à examiner le nSud Setup. Ouvrez maintenant ce nSud afin de voir son contenu comme montré ci-dessous :
Figure 2.3 - NSud Setup
Dans le nSud Setup, vous voyez alors trois nSuds fils :
- Start Java SUT client - démarre l'application pour le client que vous allez tester, appelé le SUT (System Under Test).
- Wait for client to connect - attend que la nouvelle Machine Virtuelle Java (JVM), avec laquelle votre SUT s'exécutera, s'attache à qftestJUI.
- Wait for component - attend l'apparition d'un certain composant du SUT.
Pour cet exemple, nous attendons la fenêtre principale du SUT. Ne vous inquiétez pas si cette étape ne vous semble pas complètement claire, nous apporterons ultérieurement des explications sur les composants et leurs significations.
Maintenant cliquez sur le nSud Start Java SUT client de sorte qu'il soit sélectionné comme montré ci-dessous :
Figure 2.4 - Le NSud Start Java SUT Client
Regardons plus en détail les propriétés de ce nSud, telles q'elles sont affichées dans la fenêtre Détails (côté droit).
- Dans le premier champ l'étiquette Client est un nom sans équivoque pour l'application SUT. Vous pouvez donner au SUT le nom que vous souhaitez, mais ce même nom sera utilisé comme référence au SUT dans tous les autres nSuds. En d'autres termes, ce nom doit systématiquement être utilisé.
- Executable est le deuxième champ, dans lequel le nom de l'exécutable du programme est spécifié. Pour notre exemple, la variable ${qftestJUI:java} a été donnée. Cette variable correspond au programme Java que vous avez choisi à l'installation de qftestJUI. Sinon vous pouvez rentrer manuellement le chemin d'accès à votre JVM, avec l'exécutable Java. Avec le bouton Select executable file
vous pouvez entrer dans un exécutable avec un navigateur standard de fichiers. - Le champ Directory indique le répertoire de travail pour le SUT une fois démarré.
- Dans le quatrième champ, l'étiquette Class name spécifie la classe Java utilisée pour implémenter le SUT. La fonction main(), qui sera appelée par Java au démarrage du SUT, doit être dans cette classe.
- Dans la section Parameters vous voyez les arguments en ligne de commande pour le SUT. Dans cet exemple, nous spécifions les arguments pour paramétrer la langue de l'application à Anglais. De plus, le classpath est paramétré correctement, ce qui est nécessaire parce qu'une classe de qftestJUI est utilisée comme SUT.
- Les autres champs de propriétés peuvent être laissés vides et ils ne sont pas requis pour notre exemple. Toutefois vous remarquerez qu'un commentaire a été ajouté (dans le dernier champ). Tous les nSuds ont un champ commentaire facultatif, utile au développeur-testeur pour documenter l'objet d'un nSud.
Nous sommes maintenant prêts pour démarrer le SUT. Cliquez à nouveau sur le nSud Setup (pour qu'il soit sélectionné), mais encore ouvert (les nSuds fils doivent être visibles). Maintenant cliquez sur le bouton Replay (rejeu) 
. Ce bouton permet d'exécuter le nSud sélectionné, à savoir Setup dans notre cas.
Quand un nSud s'exécute, qftestJUI utilise la structure arborescente pour vous montrer ce qui se passe. Un nSud actif est marqué avec un pointeur en forme de flèche -> qui indique quel est le nSud est en exécution. Vous voyez également des messages provenant du SUT client dans la zone du Terminal.
Lorsque la séquence Setup est effectuée, notre application de démonstration Options Demo apparaît à l'écran. C'est le SUT, entièrement sous le contrôle de l'Sil vigilant de qftestJUI. Si vous ne voyez pas Options Demo à l'écran, vérifiez si cette fenêtre n'est pas cachée derrière la fenêtre principale de qftestJUI. Cela peut se produire quand la fenêtre de qftestJUI est maximisée.
Figure 2.5 - Options Demo
Ceci est un bref résumé de la séquence de démarrage dans le nSud Setup :
- Start Java SUT client démarre l'application.
- Wait for the client to connect attend que la Machine Virtuelle Java client se connecte à qftestJUI, ou que la temporisation soit atteinte.
- Wait for component attend que la fenêtre principale du SUT apparaisse. C'est la dernière étape de la séquence de démarrage et cela permet de s'assurer que le SUT est prêt à être testé.
Remarque : Si Options Demo n'est pas visible à votre écran ou apparaît pendant un court moment, c'est que cette fenêtre est probablement couverte (cachée) par la fenêtre principale de qftestJUI. La meilleure solution consiste à placer ces fenêtres côte à côte de manière à pouvoir toutes les voir en même temps.
La tâche suivante consiste à jeter un premier coup d'Sil sur la façon dont un test pour le SUT est structuré dans qftestJUI. Le nSud test Clickstream (Flux de Saisie) contient plusieurs séquences d'opérations qui exécutent des fonctions dans le SUT, telles que les clics souris et de la saisie de champs textes. Au travers de ce test, nous illustrons plusieurs fonctionnalités simples, mais très importantes de qftestJUI.
Lorsque vous ouvrez le nSud test Clickstream, vous voyez les deux séquences comme ci-dessous :
Figure 2.6 - NSud-Test Clickstream
Pour exécuter le test, sélectionnez le nSud Test: Clickstream et cliquez sur le bouton de rejeu . Les séquences de test seront alors exécutées directement dans le SUT, comme vous pouvez le voir pendant l'exécution.
Pour vous aider à comprendre ce que vous venez de voir, jetons un coup d'Sil à la séquence : Table.
Figure 2.7 - Séquence Test Table
Ici nous voyons que la séquence démarre avec plusieurs clics souris, indiqués par les étiquettes des nSuds avec l'acronyme MPRC. Moved-Pressed-Released-Clicked est un résumé des événements réels qui se produisent quand vous cliquez sur le bouton de la souris. A côté de l'étiquette MPRC vous voyez les coordonnées réelles utilisées pour implémenter le clic souris relatif au composant indiqué entre crochets après les coordonnées. Le premier nSud MPRC est, par exemple, un clic sur l'élément de la structure arborescente du SUT ayant pour étiquette Table.
Après les quelques premiers clics souris dans la séquence, l'exécution du nSud Wait for component provoque une attente jusqu'à l'apparition de la boîte de dialogue d'édition du SUT. Une fois que le dialogue apparaît, l'exécution de la séquence continue, dans laquelle le nSud Input est activé afin de saisir une chaîne de caractères dans un champ du dialogue. Les nSuds restants de la séquence ont des fonctions similaires à celles mentionnées ci-dessus et devraient vous sembler plus clairs à partir de leurs descriptions.
Si vous êtes curieux, ouvrez également l'autre séquence (Tab). Dans cette séquence, il y a des nSuds similaires à ceux que vous avez vu dans Table avec, en plus, un nSud utilisé pour le contrôle du clavier.
Nous faisons une courte pause ici pour vous donner quelques astuces qui s'avèreront utiles pour la suite du didacticiel.
Lorsque vous travaillez avec de nombreux nSuds dans qftestJUI vous pouvez, par exemple, avoir besoin d'aide pour vous rappeler la raison pour laquelle ils sont utilisés. Pour répondre à ce besoin, qftestJUI propose une aide contextuelle, accessible par un simple clic souris. Déplacez le pointeur de la souris sur un élément pour lequel vous voulez de l'aide, et faîtes un clic droit. Dans le menu contextuel qui s'affiche, vous voyez une entrée "What's this?" En sélectionnant cette option, la section appropriée du Manuel Utilisateur de qftestJUI s'affiche alors dans votre navigateur Web par défaut.
Nous vous précisons également qu'il existe une version du Manuel Utilisateur au format PDF, disponible dans le répertoire d'installation de qftestJUI.
Un des concepts les plus importants dans qftestJUI est celui du contrôle, c'est-à-dire une requête de certains éléments dans le SUT. Un Contrôle de Texte (Text Check) interroge sur l'existence ou l'absence de texte dans un composant du SUT, tel qu'un champ texte.
Par exemple, faisons un contrôle sur un champ dans le client SUT. Affichez la fenêtre Options Demo et cliquez sur le nSud Miscellaneous listé dans la structure arborescente pour que le nSud s'ouvre et affiche ses nSuds fils. Parmi les nSuds fils, vous voyez le nSud Numbers. Cliquez sur ce nSud pour afficher sur le côté une nouvelle fenêtre qui inclut le champ texte portant l'étiquette May be negative. Pour notre exemple, nous allons faire un contrôle sur ce champ.
Figure 2.8 - Champ Texte à Contrôler
Maintenant retournez à la suite de test et ouvrez le nSud Text check. A l'intérieur, vous voyez la séquence de test suivante :
Figure 2.9 - Séquence Text Check
Vous devez vous demander pourquoi il y a deux points d'exclamation placés devant le nom du nSud de la séquence Text check. Ces marques permettent de marquer les résultats, une fois exécutés, à des fins de documentation. Ces résultats finiront dans un rapport automatiquement créé au format HTML. Ce sujet sera couvert dans un autre chapitre.
Une fois le nSud séquence Check text sélectionné, cliquez sur le bouton de rejeu pour l'exécuter. Une fois la séquence terminée, une boîte de dialogue apparaît pour indiquer qu'une erreur s'est produite :
Figure 2.10 - Erreur dans le NSud Check text
Que s'est-il passé ? Quand de tels incidents se produisent, l'utilisation du run-log de qftestJUI peut s'avérer très utile pour le diagnostic. Sélectionnez le menu Run -> Run log pour afficher le run-log. Une nouvelle fenêtre apparaît alors affichant l'enregistrement du contenu de la séquence que vous venez d'exécuter :
Figure 2.11 - Run-Log pour la Séquence Text check
Le run-log est semblable en structure à l'arbre de la vue Suite de Test avec laquelle vous vous êtes familiarisé(e). L'arbre sur le côté gauche représente les événements journalisés pour l'exécution du test, avec le premier événement en haut et le dernier en bas. Quand vous cliquez sur l'un des nSuds événements sur le côté gauche, les propriétés de l'événement s'affichent sur la droite.
Alors que vous ouvrez les nSuds dans la structure arborescente sur la gauche, vous remarquez immédiatement que certains nSuds sont entourés par un cadre rouge. Comme vous vous en doutez, c'est une indication de qftestJUI concernant un problème s'étant produit dans un nSud fils. Si vous gardez ouverts les nSuds rouges, vous arriverez finalement au nSud qui pose problème. Un moyen plus facile pour trouver une erreur consiste à utiliser simplement le menu Edit -> Find next error à partir du menu run-log. Cela vous amènera à :
Figure 2.12 - Diagnostic de l'Erreur dans la Séquence Check text
Lorsque vous cliquez sur le nSud rouge, vous voyez dans les détails de ce nSud qu'il y a une différence entre le texte attendu dans notre champ SUT et celui trouvé. L'étape suivante consiste à aller au nSud correspondant dans la suite de test et à le corriger. Assurez-vous que le nSud approprié est sélectionné dans le run-log, et utilisez le menu Edit -> Find node in test-suite ou tapez le raccourci clavier Ctrl+T.
Un autre dispositif utile pour le diagnostic d'erreur est l'arbre de nSud screenshot dans le run-log. Ses détails incluent une capture d'écran complète prise au moment où l'erreur s'est produite. Etre en mesure de voir l'état du SUT à ce moment est d'une aide très précieuse pour déterminer la cause de l'erreur. La figure 2.13 montre une capture d'écran d'un nSud avec situation de l'erreur.
Remarque : Les informations réunies lors de l'exécution d'un test long peuvent être gourmandes en mémoire. Par conséquent qftestJUI est configuré pour créer un run-log compact. Seuls les 100 derniers nSuds de protocole sont conservés, le reste est jeté, excepté pour les informations pertinentes pour la génération de rapports et pour le diagnostic d'erreur qui sont toujours conservées. Cette fonctionnalité est configurable via l'option Create compact run-log accessible par le menu Edit -> Options -> Run-logs -> Content. Le type de run-log est également montré dans son nSud racine.
Exercice de base : retournez dans votre suite de test et modifiez le texte attendu dans le nSud Check text. Maintenant si vous exécutez la séquence, aucune erreur ne se produira.
2.6 Contrôle d'un Bouton Radio
La troisième séquence de test Selected test réalise des requêtes de l'état d'un bouton radio spécifique dans le SUT pour déterminer si ce bouton radio est sélectionné. Dans la section Choices de la zone Miscellaneous dans l'application Options Demo, vous pouvez sélectionner interactivement n'importe lequel des quatre boutons radio. Nous utiliserons ces boutons radio pour implémenter un test qui inclut un contrôle réussi, ainsi qu'un contrôle qui génère une erreur.
Figure 2.14 - NSud Selected test
Le nSud Selected test contient trois événements MPRC et deux contrôles. Les deux premiers MPRC permettent aux nSuds dans la structure arborescente du SUT de s'ouvrir jusqu'à ce que le nSud Choices soit visible et ses propriétés affichées sur la droite. Ensuite, vous voyez un nSud de contrôle Check selected state qui interroge l'état du quatrième bouton radio pour déterminer qu'il n'est pas sélectionné. Le troisième événement MPRC effectue un clic sur ce quatrième bouton radio qui est maintenant sélectionné. Finalement, un autre contrôle Check selected state est effectué. Cependant, maintenant que le bouton radio est sélectionné, vous voyez que ce dernier contrôle génère une erreur.
Figure 2.15 - Boutons Radio dans Options Demo
Essayez maintenant d'exécuter la séquence Selected test afin de voir l'exécution réelle de la description fournie. Après l'exécution de la séquence test, vous pouvez vouloir fermer les nSuds dans le SUT, de sorte qu'il soit de retour à son état original (nSud Miscellaneous plus visible).
La fonction de la séquence Cleanup (épuration / suppression) est importante à comprendre. Un nSud Cleanup sera exécuté après chaque test ou séquence localisé au même niveau de la structure arborescente, tout comme la séquence Setup sera exécutée avant chaque test ou séquence. Le nSud Cleanup permet de laisser le SUT dans un état spécifique ou "propre'" afin que des tests ultérieurs puissent être exécutés de manière déterministe.
Cependant veuillez noter que le nSud Cleanup, tout comme le nSud Setup, sera seulement exécuté lorsque le nSud de plus haut niveau est exécuté, ou lorsque vous l'exécutez explicitement. Dans les sections précédentes, vous avez sélectionné et effectué un test ou une séquence spécifique (comme par exemple Clickstream), qui n'entraîne pas l'exécution des nSuds Setup ou Cleanup. Dans la section qui suit, vous allez voir visuellement comment cela fonctionne quand vous exécutez le nSud de haut niveau Test: Options.
Ouvrez maintenant le nSud Cleanup pour voir ses nSuds fils. Pour ce nSud, nous essayons d'arrêter et de fermer l'application SUT d'une manière ordonnée en cliquant le bouton Cancel du SUT. Au cas où le résultat attendu n'est pas obtenu (le SUT ne se ferme pas), une tentative plus agressive est alors faîte.
Figure 2.16 - La Séquence Cleanup
Notre séquence Cleanup est organisée comme suit :
- Le premier nSud MPRC clique le bouton Cancel du SUT.
- Les nSuds restants sont construits autour d'une construction try/catch, qui est utilisée pour gérer les cas erronés du SUT en échec qui s'arrête quand Cancel est cliqué. Le premier nSud dans le bloc try/catch effectue un contrôle Wait for client to terminate.
- Dans le cas où le client SUT échoue pour terminer dans la période de temporisation donnée, une exception est générée - ClientNotTerminatedException, qui sera alors capturée dans le nSud Catch.
- Si l'exception est en effet générée, un nSud Stop client est alors exécuté sous le nSud Catch. Le nSud Stop client a pour effet de terminer le processus en cours exécutant l'application SUT.
Ce que nous avons mis en application est un nSud cleanup "défensif" qui essaie en premier de stopper l'application normalement, et seulement si cet échec arrête le processus.
Les sections précédentes ont eu pour objectif de vous amener étape par étape aux différents éléments de notre suite de test exemple. Désormais, vous êtes prêt(e) à exécuter le test entier d'un seul trait.
Premièrement, fermez Options Demo au cas où il serait toujours en exécution. Vous pouvez le faire en exécutant le nSud Cleanup décrit précédemment. Alors sélectionnez le nSud Test: Options et exécutez-le avec le bouton de rejeu. La suite de test complète durera quelques minutes, en raison des délais que nous avons construits dans certains nSuds de la suite de test, aussi vous pouvez mieux suivre ce qui se passe. Si vous regardez les détails du nSud Test: Options, vous verrez une variable delay définie dans la section Variables. Vous pouvez changer cette valeur si vous voulez réduire ou augmenter le temps total d'exécution.
Quand les tests sont achevés, vous devez finir avec deux échecs, les deux dont nous avons parlé dans les sections précédentes. Ouvrez à nouveau le run-log pour l'étudier :
Figure 2.17 - Run-Log pour les Tests Exécutés
Ici vous verrez le processus que nous avons essayé d'expliquer dans la section précédente concernant l'exécution des nSuds Setup et Cleanup avant et après chaque test et séquence de manière explicite.
Dans le domaine de l'Assurance Qualité, la documentation et l'archivage de tests sont d'une très grande importance. A cet effet, qftestJUI offre une fonctionnalité de génération automatique de rapports. Maintenant que vous avez effectué une exécution d'un test complet, c'est le moment de vous montrer ces possibilités.
Assurez-vous que le run-log de votre test est ouvert. Maintenant utilisez l'option File -> Create HTML/XML report du menu run-log pour afficher la fenêtre de dialogue utilisée pour spécifier la nature du rapport voulu.
Figure 2.18 - Propriétés de Génération de Rapport
Dans le premier champ, vous pouvez spécifier le nom du fichier du rapport. Ensuite, vous décidez du type de rapport que vous voulez. qftestJUI offre deux types de rapports : format HTML ou XML. Un rapport XML est utile si vous avez écrit vos propres feuilles de styles XSLT, pour mettre en forme le rapport dans le style que vous préférez.
Le champ Default depth spécifie la profondeur par défaut de la génération de rapports. C'est une nomenclature qui décrit simplement la profondeur de la structure arborescente de la suite de test que vous voulez dans votre rapport. Avec une profondeur par défaut à '1' votre rapport contiendra uniquement les séquences et les tests de la suite de test du niveau le plus élevé, et ne contiendra donc pas les nSuds fils sous-jacents, tels que les événements MPRC.
Nous devons nous référer aux points d'exclamation ("!") utilisés dans les sections précédentes. Ils sont utilisés pour marquer spécifiquement le nSud en question à des fins de documentations. Un nSud marqué avec un point d'exclamation de cette manière sera toujours inclus dans le rapport généré, indépendamment de la profondeur par défaut spécifié.
Essayez de générer un rapport HTML simple à partir des résultats du dernier test exécuté. Remplissez les champs que nous avons mentionné ci-dessus et confirmez la génération en cliquant sur le bouton OK. Le rapport sera alors généré et apparaîtra dans votre navigateur comme le montre la figure 2.19.
Le rapport commence avec une référence aux données du run-log associé, suivie d'une série d'informations sur votre système. Ensuite vous voyez les résultats du test, dont l'exécution totale, tout comme le comptage des erreurs et des exceptions qui se sont produites. Dans la figure 2.19, vous pouvez voir que deux erreurs se sont produites dans le test.
Après ce résumé, vous voyez les détails spécifiques aux nSuds de test et de séquence qui ont été exécutés. Cela vous aide à déterminer exactement où une erreur spécifique s'est produite. A la fin du rapport, vous voyez une courte description des erreurs rencontrées.
Remarque : Les icônes arbre-nSud au sein du rapport généré sont affichées pour une meilleure orientation et compréhension des relations entre le rapport et la suite de test. Mais elles n'ont aucune autre fonction, par exemple ouvrir/fermer les nSuds de l'arbre.
Le dispositif de génération de rapports s'avèrera très utile au fur et à mesure du développement de votre suite de test. Essayez d'ajuster certains des paramètres de la fenêtre de dialogue de génération de rapport pour obtenir le niveau et la profondeur des détails que vous souhaitez afficher.
qftestJUI est une marque de Quality First Software GmbH. KAPITEC SOFTWARE SAS est le Distributeur Français de qftestJUI. Ce didacticiciel a été traduit de l'anglais par KAPITEC SOFTWARE S.A.S. (Novembre 2005). Date de mise à jour : 27-Nov-2005