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

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