Sélectionner la technique d'implémentation appropriée
Objectif :
|
Déterminer la technique d'implémentation de test appropriée.
|
Sélectionnez la technique la plus appropriée pour l'implémentation du test. Pour chaque test, vous devez implémenter au
minimum un script de test. Dans certains cas, l'implémentation d'un test couvre plusieurs scripts de test. Inversement,
il arrive qu'un même script de test permette d'implémenter plusieurs tests.
Les méthodes généralement utilisées pour l'implémentation de tests incluent l'écriture d'une description textuelle sous
forme de script à exécuter (tests manuels) et la programmation, l'enregistrement ou la génération d'un langage de
programmation à base de scripts (tests automatiques). Chaque méthode fait l'objet d'une description dans les sections
suivantes.
Comme pour la plupart des approches, il est recommandé de croiser les techniques présentées afin d'optimiser les
résultats. Il n'est pas nécessaire de les utiliser toutes, mais il n'est pas non plus conseillé d'utiliser
exclusivement l'une d'entre elles.
Sous-rubriques :
De nombreux tests sont exécutés manuellement et vous ne devez pas tenter de les automatiser de façon inappropriée. Dans
de nombreux cas, il est recommandé d'exécuter les tests de convivialité de façon manuelle et non automatisée. De la
même façon, la validation de l'exactitude et de la qualité des résultats produits par un système logiciel (requise dans
le cadre d'un test) doit généralement s'effectuer manuellement. En règle générale, il est conseillé de commencer les
premiers tests des éléments de test cibles en procédant à une implémentation manuelle. Cette approche permet au testeur
de se familiariser avec l'élément cible, de réagir à tout comportement inadéquat et d'appliquer un jugement humain pour
déterminer l'action à entreprendre.
Il arrive parfois que des tests exécutés manuellement soient ensuite automatisés et réutilisés au sein d'une stratégie
de tests de régression. Toutefois, il est à noter qu'il n'est pas nécessaire ni même possible d'automatiser chacun des
tests que vous pouvez très bien exécuter manuellement. L'automatisation apporte certains avantages en termes de vitesse
et de précision d'exécution de test, de visibilité et d'assemblage des résultats de tests détaillés, ainsi qu'en termes
d'efficacité de création et de gestion pour les tests complexes. En revanche, comme pour tous les outils, elle
n'apporte pas la réponse à tous vos besoins.
L'automatisation présente certains inconvénients (en particulier l'absence de jugement humain et de raisonnement au
cours de l'exécution des tests). Les solutions d'automatisation disponibles actuellement n'ont pas les capacités
cognitives d'un être humain (et ne les auront sans doute jamais). Pendant l'implémentation d'un test manuel, le
raisonnement humain peut s'appliquer aux réponses aux stimuli fournies par le système. Les techniques de test
automatisés proposées actuellement et leurs outils associés ont une capacité limitée à détecter les implications de
certains comportements du système et à apporter des solutions aux éventuels incidents via un raisonnement déductif.
Il s'agit de la méthode pratiquée par la plupart des testeurs utilisant l'automatisation de tests. Elle s'exécute de la
même façon et suit les mêmes principes généraux que la programmation informatique. Ainsi, les méthodes et les outils
utilisés pour la programmation logicielle sont généralement applicables à la programmation automatisée de tests.
Que vous utilisiez un environnement de développement logiciel standard (tel que Microsoft Visual Studio ou IBM Visual
Age) ou un environnement de développement de tests automatisés (comme par exemple l'IDE fourni avec Rational Robot), le
testeur peut exploiter les caractéristiques et la puissance de l'environnement de développement pour en optimiser les
résultats.
Les aspects négatifs de la programmation de tests automatisés sont liés aux inconvénients de la technique de
programmation elle-même. Pour que la programmation soit efficace, certains points doivent être pris en considération,
faute de quoi l'implémentation risque d'échouer. Si le logiciel développé est modifié par différentes personnes
successivement (ce qui est souvent le cas), une forme et un style communs doivent être adoptés lors du développement et
de l'utilisation. Les deux problèmes les plus importants à signaler concernent la mauvaise utilisation de cette
technique.
En premier lieu, le testeur risque d'être absorbé par les fonctions de l'environnement de programmation et de passer
trop de temps à élaborer des solutions sophistiquées à des problèmes qui pourraient être résolus plus simplement. Le
testeur gaspille ainsi un temps précieux pour l'exécution de tâches de programmation, au détriment du temps qu'il
pourrait consacrer au test et à l'évaluation des éléments de test cibles. Pour éviter de tomber dans ce piège, beaucoup
de discipline et d'expérience sont requises.
Ensuite, le code programme utilisé pour l'implémentation du test risque de contenir des bogues introduits par erreur
humaine ou par omission. Pour certains de ces bogues, il est facile d'appliquer un débogage et une correction au cours
de l'implémentation du test automatisé ; pour d'autres, c'est impossible. Les erreurs peuvent être difficiles à
détecter, tant dans l'élément de test cible que dans le logiciel d'automatisation de tests. Des erreurs sont en outre
susceptibles d'être introduites lorsque des algorithmes utilisés pour l'implémentation de tests automatisés prennent
comme base les algorithmes erronés utilisés par l'implémentation logicielle elle-même. Ainsi, il arrive que certaines
erreurs ne soient pas détectées, masquées par la fausse sécurité des tests automatisés dont l'exécution s'exécute
apparemment avec succès. Pour minimiser ce risque, utilisez différents algorithmes dans les tests automatisés, lorsque
vous le pouvez.
Certains outils d'automatisation de tests permettent d'enregistrer l'interaction humaine à l'aide d'une application
logicielle et d'obtenir un script de test de base. Pour cela, différents outils existent. Ces outils élaborent, pour la
plupart, un script de test implémenté en langage de programmation performant et modifiable. Les plus connus
fonctionnent selon les modèles suivants :
-
En enregistrant l'interaction avec l'IU du client
d'une application chargée d'intercepter les entrées transmises par les périphériques matériels du client : souris,
clavier, etc. au système d'exploitation du client. Dans certaines solutions, cela s'effectue via l'interception de
messages échangés entre le système d'exploitation et le pilote de périphérique qui décrit les interactions. Dans
d'autres solutions, cela s'effectue via l'enregistrement de messages sur la base des mouvements de la souris ou de
la sélection de la flèche vers le haut ou de la flèche vers le bas.
-
En interceptant les messages échangés entre l'application client et une ou plusieurs applications serveur au sein
du réseau. L'interprétation réussie de ces messages repose généralement sur l'utilisation de protocoles de
messagerie reconnus standards, tels que HTTP, SQL , etc. Certains outils permettent également l'utilisation de protocoles
de communication "de base" tels que TCP/IP,
cependant ce dernier peut être plus complexe à utiliser avec les scripts de test de cette nature.
Ces techniques sont souvent utiles avec les tests automatisés, mais elles présentent quelques limitations. Par exemple,
certains outils se bornent à enregistrer l'interaction entre les applications. Sans l'insertion de points
d'observations qui enregistrent et comparent l'état du système au cours de l'exécution des scripts, le script de test
de base ne peut pas être considéré comme un test complet. Dans ce cas, un code programme personnalisé devra compléter
l'enregistrement initial en vue de l'implémentation de points d'observation au sein du script de test.
Plusieurs auteurs ont publié des documents et des essais sur ces thèmes liés à l'utilisation de l'enregistrement de
procédures de test comme technique d'automatisation de tests. Pour approfondir vos connaissances sur ces sujets, nous
vous recommandons de consulter sur Internet les documents rédigés par les auteurs suivants : James Bach, Cem Kaner, Brian Marick et Bret Pettichord, ainsi que le livre intitulé Lessons
Learned in Software Testing [KAN01]
Certains logiciels sophistiqués d'automatisation de tests permettent de générer différents aspects du test (liés à la
procédure ou aux données de test du script de test) sur la base d'algorithmes. Ce type d'automatisation peut jouer un
rôle utile dans votre effort de test, mais ne doit pas être considéré comme une approche suffisante en soi. L'outil
Rational TestFactory et la fonction de génération de pools de données Rational TestManager sont des exemples
d'implémentations de ce type de technologie.
|
Définir les préconditions applicables à l'environnement de test
Objectif :
|
Affecter à l'environnement l'état de démarrage correct.
|
Définissez l'environnement de test, y compris le matériel, les logiciels, les outils et les données. Assurez-vous que
tous les composants fonctionnent correctement. En général, ceci implique un rétablissement de l'environnement de base
(rétablissement du registre
Windows et d'autres fichiers de configuration), la restauration de bases de données sous-jacentes à un état
connu, etc. en plus des tâches comme le chargement de papier dans les imprimantes. Certaines tâches peuvent être
exécutées automatiquement, mais d'autres nécessitent une intervention humaine.
Sous-rubriques :
Les scripts de tests automatisés sont particulièrement adaptés à une révision initiale manuelle du test pour confirmer
que les conditions préalables sont réunies. Pendant cet examen, vous devez vérifier l'intégrité de l'environnement, du
logiciel et de la conception du test. Il est plus approprié si vous utilisez une technique d'enregistrement
interactive, et moins approprié si vous effectuez une programmation du script de test. L'objectif consiste à vérifier
que tous les éléments requis pour implémenter le test avec succès sont réunis.
Lorsque le logiciel est suffisamment stable, vous pouvez ignorer cette étape si vous estimez que le risque de
rencontrer des problèmes dans les zones concernées est relativement faible.
Confirmez que les oracles de
tests que vous envisagez d'utiliser sont appropriés. S'ils n'ont pas encore été identifiés, vous devez le
faire maintenant.
Vous devez confirmer par d'autres moyens que les oracles de test choisis permettront d'obtenir des résultats précis et
fiables. Par exemple, si vous envisagez de valider les résultats de test à l'aide d'une zone qui s'affiche via
l'interface utilisateur de l'application et qui indique qu'une mise à jour de base de données a eu lieu, interrogez la
base de données d'arrière-plan pour vérifier l'état des enregistrements correspondants dans la base de données. Vous
pouvez également ignorer les résultats présentés dans une boîte de dialogue de confirmation de mise à jour et confirmer
la mise à jour en interrogeant l'enregistrement via une autre fonction ou opération.
Vous devez ensuite rétablir l'état d'origine de l'environnement (y compris les outils de support). Comme mentionné dans
les étapes précédentes, cela implique notamment de rétablir l'environnement de base, de restaurer l'état connu des
bases de données, et d'exécuter des tâches telles que le chargement de papier dans les imprimantes. Certaines tâches
peuvent être exécutées automatiquement, mais d'autres nécessitent une intervention humaine.
Définissez les options d'implémentation du test (outils de support) qui varient selon la sophistication de l'outil.
Dans la mesure du possible, essayez de stocker les paramètres de chaque outil afin de pouvoir les recharger facilement
sous la forme de profils prédéterminés. Dans le cas de tests manuels, cela inclut des tâches telles que le
partitionnement d'une nouvelle entrée dans un système de consignation des résultats de test ou la consignation des
demandes de changement.
Dans le cas d'outils d'exécution de tests automatisés, les configurations requises peuvent être nombreuses. Si vous ne
configurez pas correctement ces options, cela risque de diminuer l'utilité et la valeur des actifs de test obtenus.
|
Implémenter le test
Objectif :
|
Implémenter un ou plusieurs actifs d'implémentation de test réutilisables.
|
A l'aide de la liste des idées de test ou d'artefacts de cas de test sélectionnés, commencez l'implémentation du test.
Commencez par attribuer au test un nom unique (s'il n'en porte pas déjà un) et préparez l'IDE, l'outil de capture, la
feuille de calcul ou le document permettant de commencer l'enregistrement des étapes spécifiques du test. Aidez-vous
autant que nécessaire des sous-sections suivantes pour implémenter le test.
Pour certains tests ou types de tests spécifiques, il n'est pas toujours utile de documenter les étapes explicites
requises pour conduire le test. Dans certains styles de tests
exploratoires , la répétition du test n'est pas un élément livrable. Pour les tests très simples, une brève
description de l'objectif des tests est suffisante pour permettre la reproduction.
Sous-rubriques :
Programmez, enregistrez ou générez les actions de navigation requises. Commencez par sélectionner la méthode de
navigation de votre choix. Pour la plupart des classes de systèmes, une "souris" ou un autre dispositif de pointage
constitue le moyen de navigation préféré et principal. Par exemple, le dispositif de pointage utilisé avec les
assistants électroniques de poche équivalent à une souris.
Le deuxième moyen de navigation est généralement l'interaction avec le clavier. Dans la plupart des cas, la navigation
se compose d'une combinaison d'actions de la souris et du clavier.
Il arrive parfois que vous ayez recours à d'autres formes de reconnaissance (visuelles ou vocales). Elles peuvent poser
problème dans le cas des tests automatisés, et peuvent nécessiter l'ajout d'extensions spécifiques à l'application pour
autoriser le chargement et le traitement d'éléments audio et visuels à partir d'un fichier et non via une capture
dynamique.
Dans certaines situations, vous pouvez souhaiter ou avoir besoin d'effectuer le même test à l'aide de plusieurs
méthodes de navigation. Plusieurs approches vous permettent d'y parvenir, comme par exemple l'automatisation de tous
les tests à l'aide d'une méthode et l'exécution manuelle de tous les tests ou d'une partie d'entre eux à l'aide d'une
autre méthode. Vous pouvez aussi séparer les aspects de navigation des tests des données de test qui caractérisent un
test spécifique, élaborant une interface de navigation logique via laquelle vous pouvez sélectionner une méthode de
conduite du test. Vous pouvez combiner les méthodes de navigation.
Pour chaque point du script de test correspondant à un point d'observation, utilisez l'oracle de test approprié pour
capturer les informations requises. Dans de nombreux cas, les informations rassemblées au niveau du point d'observation
doivent être enregistrées et conservées afin d'être référencées au cours de points de contrôle ultérieurs.
Pour les tests automatisés, déterminez la méthode de rapport des informations observées. Dans la plupart des cas, il
suffit d'enregistrer les observations dans un journal de test central à partir du début du script de test. Les
observations peuvent également être placées dans une feuille de calcul ou dans un fichier de données à des fins
d'utilisation plus sophistiquée.
Au niveau de chaque point du script de test impliquant une prise de décision de contrôle, rassemblez et évaluez les
informations appropriées afin de déterminer le flux de contrôle à suivre. Les données extraites de points d'observation
précédents sont généralement insérées dans les points de contrôle.
Pour effectuer les points de contrôle et les prises de décisions sur l'action suivante du flux de contrôle, enregistrez
les valeurs d'entrée et le flux sélectionné dans le journal de tests.
Pendant l'implémentation, vous introduirez sans doute des erreurs. Elles peuvent résulter d'omissions ou d'éléments que
vous avez oublié de prendre en compte dans l'environnement de test. Ces erreurs doivent être résolues pour que
l'implémentation puisse être considérée comme complète. Identifiez chaque erreur rencontrée et traitez-la.
Dans le cas d'une automatisation de tests avec utilisation d'un langage de programmation, des erreurs de compilation
peuvent se produire en raison de variables et de fonctions non déclarées, ou encore d'une utilisation incorrecte de ces
fonctions. Consultez les messages d'erreur affichés par le compilateur ou toute autre source de messages d'erreur,
jusqu'à ce que le script de test ne contienne plus aucune erreur d'implémentation syntaxique ou autre.
Pendant l'exécution ultérieure du test, d'autres erreurs peuvent être détectées. Ces erreurs peuvent apparaître comme
des échecs dans l'élément de test cible (lorsque vous analysez les échecs de test, vous devez veiller à confirmer que
les échecs se trouvent bien dans l'élément de test cible et non dans l'un des aspects de l'implémentation du test).
|
Etablir les ensembles de données externes
Objectif :
|
Créer et gérer les données stockées en externe dans le script de test et utilisées au cours de l'exécution
du test.
|
Dans de nombreux cas, il est plus approprié de gérer les données de test de façon externe. Cela permet de bénéficier de
souplesse, simplicité et sécurité pour le script de test et pour la gestion des données de test. Les ensembles de
données externes apportent les avantages suivants aux tests :
-
Les données de test sont externes au script de test, ce qui élimine les références figées dans le code
-
Les données de test externes peuvent être facilement modifiées, généralement sans impact important sur le script de
test
-
D'autres cas de test peuvent être facilement pris en charge par les données de test sans modification (ou très peu)
à apporter au script de test
-
Les données de test externes peuvent être partagées avec un grand nombre de scripts de test
-
Des scripts de test peuvent être développés en vue d'une utilisation de données de test externes, pour contrôler la
logique d'embranchement conditionnelle présente dans le script de test.
|
Vérifier l'implémentation du test
Objectif :
|
Vérifier le fonctionnement du script de test via son exécution.
|
Dans le cas des tests automatisés tout particulièrement, vous devrez probablement passer un certain temps à stabiliser
le fonctionnement du test lorsqu'il est en cours d'exécution. Une fois que vous avez terminé l'implémentation de base
du script de test, vous devez la tester pour vérifier que tous les tests sont correctement implémentés et qu'ils sont
exécutés avec succès.
De nouveau, vous devez restaurer l'état d'origine de l'environnement après l'implémentation du test. Comme mentionné
dans les étapes précédentes, cela implique notamment de rétablir l'environnement de base, de restaurer l'état connu des
bases de données, et d'exécuter des tâches telles que le chargement de papier dans les imprimante. Certaines tâches
peuvent être exécutées automatiquement, mais d'autres nécessitent une intervention humaine.
Dans le cas des tests automatisés tout particulièrement, les paramètres des outils doivent être modifiés. L'objectif
consiste à vérifier le fonctionnement correct du script de test via l'exécution de ce dernier.
Pour cette étape, il est conseillé d'utiliser la même version de logiciel que celle utilisée pour l'implémentation des
scripts de test. Cela permet d'éliminer tout problème éventuel dû à l'introduction d'erreurs dans des versions
ultérieures.
Il est fréquent de devoir ajuster certains éléments de l'implémentation pour que le test puisse être exécuté de façon
autonome, surtout lorsqu'il existe plusieurs configurations d'environnement de test.
Pour les tests automatisés, attendez-vous à devoir consacrer un certain temps à la vérification et que les tests
"fonctionnent dans les limites imparties" et à leur ajustement jusqu'à ce que leur fonctionnement soit fiable et que
vous les déclariez implémentés. Vous pouvez reporter cette étape à un moment ultérieur du cycle de vie (et attendre par
exemple le développement de séries de tests), mais nous vous recommandons de ne pas la reporter, car les échecs à
traiter risqueraient alors de s'accumuler.
|
Restaurer l'état connu de l'environnement de test
Objectif :
|
Laisser l'environnement dans l'état où vous l'avez trouvé ou dans l'état requis pour l'implémentation du
test suivant.
|
Cette étape peut sembler trop simple, mais c'est une bonne habitude à prendre pour travailler efficacement avec
d'autres testeurs de l'équipe (surtout si l'environnement d'implémentation est partagé). Il est également important
d'élaborer une routine permettant de restaurer l'état du système.
Lors de l'effort de test manuel initial, il est souvent simple d'identifier et de corriger les problèmes de
restauration, mais avec les tests automatisés, la capacité de tolérance de problèmes d'état de l'environnement est
beaucoup plus réduite.
|
Gérer les relations de traçabilité
Objectif :
|
Permettre la génération d'un rapport de l'analyse et de l'évaluation de l'impact sur les éléments
tracés.
|
Utilisez les exigences de traçabilité mentionnées dans le plan de test pour mettre à jour les relations de traçabilité.
|
Evaluer et vérifier vos résultats
Objectif :
|
Vérifier que la tâche a été correctement réalisée et que les produits en résultant sont
acceptables.
|
Maintenant que vous avez achevé le travail, il serait utile de vérifier que ce travail a suffisamment de valeur. Vous
devez évaluer si votre travail est d'une qualité correcte et qu'il est assez complet pour être utile aux membres de
l'équipe qui en feront un usage ultérieur comme entrée pour leur propre travail. Si possible, utilisez les listes de
contrôle fournies dans RUP pour vérifier que la qualité et l'exhaustivité sont "satisfaisantes".
Demandez aux personnes qui utiliseront votre travail de participer aux réunions de revue intermédiaires. Effectuez
cette revue pendant que vous avez encore du temps disponible pour prendre les mesures qui répondent à leurs
préoccupations. Vous devez également évaluer votre travail par rapport aux produits d'entrée clés pour vous assurer que
vous les avez précisément et suffisamment représentés. Il peut être utile que l'auteur du produit d'entrée revoie votre
travail sur cette base.
Essayez de vous rappeler que le RUP est un processus de livraison itératif et que dans de nombreux cas, les produits
évoluent au fil du temps. A ce titre, il n'est généralement pas nécessaire - et c'est même souvent contre-productif -
de développer complètement un produit qui ne sera que partiellement utilisé ou ne sera pas du tout utilisé dans
l'immédiat. Ceci parce qu'il y a une grande probabilité pour que la situation qui entoure le produit change - et que
les hypothèses émises lors de la création du produit s'avèrent incorrectes - avant même l'utilisation du produit,
occasionnant ainsi une perte d'efforts et un remaniement coûteux.
Evitez également le piège consistant à utiliser trop de cycles pour la présentation au détriment de la valeur du
contenu. Dans les environnements de projet où la présentation a une importance et une valeur économique comme livrable,
vous pouvez envisager d'utiliser une ressource d'administration ou junior pour réaliser les tâches d'amélioration de la
présentation.
|
|