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.
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 :