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