Ambysoft logo

Le cycle de dÃveloppement de l'actività de tests orientÃs objet

by Scott W. Ambler

traduction en français par Guillaume Goarnisson, UNILOG Lyon, France, IngÃnieur Nouvelles Technologies de l'Information

Le cycle de dÃveloppement de l'actività de tests orientÃs objet (en anglais, "Full-Lifecycle Object-Oriented Testing" - FLOOT) est un ensemble de techniques de tests pour vÃrifier et valider le logiciel orientà objet. Le cycle de vie FLOOT qui est dÃcrit dans la Figure 1, indique qu'une large variÃtà de techniques de tests (voir le Tableau 1 ) couvrant tous les aspects du dÃveloppement logiciel sont à votre disposition. La liste proposÃe ne cherche pas à être exhaustive, mais au contraire à rendre explicite le fait que vous disposiez d'un large choix de techniques de tests. Il est important de comprendre que "la mÃthode" FLOOT est prÃsentÃe ici comme un ensemble de phases pÃriodiques (ou successives) mais que ce n'est pas forcÃment toujours le cas. Les techniques du FLOOT peuvent aussi bien être appliquÃes aux processus agiles. Je prÃsente le FLOOT de manière traditionnelle pour bien faire passer le message que les tests doivent être menÃs tout au long du dÃveloppement logiciel et non pas seulement lors des tâches de codage.

Figure 1. Le cycle de vie FLOOT.


Tableau 1. Les techniques de tests

Technique FLOOT

Description

Test boîte noire

Test qui permet de s'assurer que l'unità qui est testÃe fournit, à partir de paramètres d'entrÃes conforme, le rÃsultat attendu.

Test aux limites

Test sur des valeurs inhabituelles, particulières ou limites que le système doit pouvoir gÃrer.

Test de classe

Tâche qui permet de s'assurer qu'une classe et ses instances (objets) fonctionnent comme dÃfini.

Test d'intÃgration des classes

Tâche qui permet de s'assurer qu'une classe et ses instances (objets) issus de logiciels externes fonctionnent comme dÃfini.

Revue de code

Revue technique qui consiste en une rÃvision du code source : vÃrification de la conformità du code par rapport aux normes de programmation et aux spÃcifications.

Test de composant

Tâche de validation du bon fonctionnement d'un composant.

Couverture de test

La tâche qui consiste à s'assurer que chacune des lignes de code a Ãtà testÃe.

Revue de conception

Revue technique qui consiste à explorer le modèle de conception.

Test de non-rÃgression avec l'hÃritage

Tâche permettant de s'assurer que les cas de tests fonctionnent sur la classe "mère" et les classes "filles" ("mère" et "fille" : notions entre les classes introduites avec l'hÃritage).

Test d'intÃgration

Test pour vÃrifier que des lots fonctionnels fonctionnent correctement ensemble.

Test de mÃthode

Test pour vÃrifier que des mÃthodes (ou opÃrations) fonctionnent comme dÃfini.

Revue de modèle

La revue de modèle consiste à explorer complètement le modèle. La revue est d'autant plus pertinente qu'elle est rÃalisÃe par des personnes qui n'ont pas participà à la mise en oeuvre de ce modèle.

Test des chemins logiques

Tâche permettant de s'assurer que tous les chemins possibles ont Ãtà testÃs au moins une fois (Le composant est considÃrà comme un ensemble de branches constituant des chemins possibles qui doivent tous être vÃrifiÃs).

Revue de prototype (ou Test de prototype)

Pour cette revue, les futurs utilisateurs utilisent aux travers d'une collection de cas d'utilisation (c'est à dire diverse manière d'utiliser le système) le prototype comme ils utiliseraient la future application. L'objectif principal est de s'assurer que le prototype rÃpond bien aux attentes des utilisateurs.

Preuve par le code

Le meilleur moyen de s'assurer que le modèle correspond au besoin ou bien encore à ce qui doit être construit est de produire le logiciel basà sur ce modèle. Ceci permettra de valider l'exactitude du modèle.

Test de non-rÃgression

Tâche permettant de s'assurer que les prÃcÃdents "modules" testÃs fonctionnent encore après des modifications apportÃes à l'application.

Test de stress (voir aussi Test de charge)

Tâche permettant de s'assurer que le système supporte les gros volumes de transactions, de charge, d'utilisateurs... (supporte dans le sens de fonctionner correctement).

Revue technique

Technique d'assurance qualità qui consiste à faire examiner et critiquer la conception de l'application par des pairs. La revue typique se concentre sur la qualitÃ, la facilità d'utilisation, la cohÃrence, la couverture. On peut Ãgalement parler de "Revue par ses pairs".

Test de scÃnarios d'usage (ou de scÃnarios de cas d'utilisation)

Technique de test dans laquelle un ou des membres de l'Ãquipe projet valide le modèle "en dÃroulant" des scÃnarios de cas d'utilisation du système.

Test de l'interface utilisateur (Test UI)

Les tests concernant l'interface utilisateur permettent de vÃrifier le respect des standards d'interface (standard UI) et de s'assurer que l'on rÃpond aux exigences dÃfinies au cours du projet concernant l'interface.

Test boîte blanche (ou Test boîte de cristal)

Test qui permet une validation technique du composant testÃ. (Remarque : Ces tests complètent les tests boîtes noires et permettent de dÃtecter les parties de code non accessibles et les comportements indÃsirables.).

J'aimerais un peu partager l'idÃe que je me fais de l'actività de tests :

  1. L'objectif est de trouver des dÃfauts (des anomalies). L'intÃrêt premier des tests est de valider le bon fonctionnement (l'exactitude) de tout ce que l'on peut tester. En d'autres termes, des tests concluant dÃcèlent des anomalies..
  2. Tous les artefacts peuvent être validÃs. Comme indiquà dans ce document, vous pouvez tester tous vos artefacts et non pas uniquement votre code source. Vous pouvez tout au moins rÃviser les modèles et documents et ainsi dÃtecter et corriger des anomalies bien avant qu'elles ne se retrouvent dans le code.
  3. Tester souvent et le plus tôt possible. Le coût lià aux changements qui croît de façon exponentielle en fonction de l'instant de dÃcouverte du dÃfaut (ou d'un changement nÃcessaire) devrait vous motiver à tester au plus tôt dans le projet. (Voir article concernant le coût lià au changement : cost of change)
  4. Tester procure de la confiance, de l'assurance. Dans Extreme Programming Explained Kent Beck propose une observation intÃressante : quand vous avez une suite complète de tests, suite de tests dans le sens collecion de tests, et que vous les exÃcutez aussi souvent que possible, cela vous donne du courage pour aller de l'avant. Beaucoup de personnes craignent de faire un cahngement dans leur code sous peine de casser ce code. Mais avec une suite complète de tests, si vous veniez à casser quelque chose, vous savez que vous le dÃtecteriez et que vous pourriez le rÃsoudre.
  5. Tester suivant la criticità de l'artefact. Plus un ÃlÃment est risquÃ, plus il a besoin d'être rÃvisà et testÃ. En d'autres termes, vous devez investir un effort certain pour examiner et tester un système de contrôle du trafic aÃrien et aucun effort pour une application du type "Hello World".
  6. Un test vaut plus que mille paroles. Vous aurez beau me dire que votre application fonctionne, tant que vous ne m'aurez pas montrà les rÃsultats des tests, je ne vous croirais pas.

Suggested Reading

Choose Your WoW! 2nd Edition This book, Choose Your WoW! A Disciplined Agile Approach to Optimizing Your Way of Working (WoW) Second Edition, is an indispensable guide for agile coaches and practitioners. It overviews key aspects of the Disciplined Agile (DA) tool kit. Hundreds of organizations around the world have already benefited from DA, which is the only comprehensive tool kit available for guidance on building high-performance agile teams and optimizing your WoW. As a hybrid of the leading agile, lean, and traditional approaches, DA provides hundreds of strategies to help you make better decisions within your agile teams, balancing self-organization with the realities and constraints of your unique enterprise context.

Traductions: