Tâche: Implémentation du test
Cette tâche explique comment développer des tests autonomes ou en collaboration.
Objet

L'objectif de cette tâche est de :

  • Implémenter un ou plusieurs produits de test qui permettent la validation du produit logiciel par l'exécution physique
  • Développer des tests qui peuvent être exécutés conjointement avec d'autres tests dans le cadre d'une plus grande infrastructure de test
Relations
Etapes
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 :

Scripts de test manuels Sélectionner la technique d'implémentation

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.

Scripts de test programmés Sélectionner la technique d'implémentation

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.

Scripts de test enregistrés Sélectionner la technique d'implémentation

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]

Tests générés Sélectionner la technique d'implémentation

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 :

(Facultatif) Réviser le test manuellement Configuration

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.

Identifier et confirmer l'adéquation des oracles de test Configuration

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.

Rétablir l'environnement et les outils de test Configuration

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 :

Implémenter les actions de navigation Haut de la page

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.

Implémenter les points d'observation Haut de la page

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.

Implémenter les points de contrôle Haut de la page

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.

Résoudre les erreurs d'implémentation de test Haut de la page

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.

Restaurer l'état connu de l'environnement de test Vérifier l'implémentation de test

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.

Configurer les outils et commencer l'exécution du test Vérifier l'implémentation du test

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.

Résoudre les erreurs d'exécution Vérifier l'implémentation du test

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.



Propriétés
Plusieurs occurrences
Commandé par les événements
En cours
Facultatif
Planifié
Réitérable
Plus d'informations