En informatique, un test désigne une procédure de vérification partielle d’un système. Son objectif principal est d’identifier un nombre maximum de comportements problématiques du logiciel afin d’en augmenter la qualité (si les problèmes identifiés lors des tests sont corrigés). Néanmoins, le test peut aussi avoir pour objectif d’apporter des informations quant à cette qualité afin de permettre la prise en décisions.

Les tests de vérification ou de validation visent ainsi à vérifier que ce système réagit de la façon prévue par ses développeurs (spécifications) ou est conforme aux besoins du client, respectivement. Dans cet article nous ne traitons que du test de logiciel, le test de matériel informatique (ou ‘hardware’) n’est pas abordé.

Un test ressemble à une expérience scientifique. Il examine une hypothèse exprimée en fonction de trois éléments : les données en entrée, l’objet à tester et les observations attendues. Cet examen est effectué sous conditions contrôlées pour pouvoir tirer des conclusions. Un bon test respecte également l’exigence de répétabilité 1.




La définition qui suit est issue de la norme IEEE 829-19982 revue à l’aide du glossaire de l’ISTQB3.

Un test est un ensemble de cas à tester (état de l’objet à tester avant exécution du test, actions ou données en entrée, valeurs ou observations attendues, et état de l’objet après exécution), éventuellement accompagné d’une procédure d’exécution (séquence d’actions à exécuter). Il est lié à un objectif.

La réalisation d’un test amène donc à définir cet ensemble. Différents types de test permettent de détecter différents types de défaut. Des méthodes de spécification de test ont été élaborées pour permettre une plus grande rigueur dans cette activité de définition. La norme britannique BS 7925-24 (version préliminaire disponible ici) ou le Software Testing Techniques5 de Boris Bezier en donnent des exemples.

Un test vise à mettre en évidence des défauts de l’objet testé. Cependant, il n’a pas pour finalité :

d’identifier la cause des erreurs,
de les rectifier,
de prouver la correction de l’objet testé.

La définition d’un cas à tester précise les exigences s’appliquant à une spécification. Un objet ne peut être testé que si on peut déterminer précisément le comportement attendu en fonction des conditions auxquelles il est soumis. Si la spécification ne permet pas cette détermination, la propriété du logiciel qu’elle définit ne peut être testée.

Soumettre la spécification à cette contrainte de « testabilité » permet d’en améliorer la précision puisqu’elle oblige à expliciter les caractéristiques de l’objet. Ceci permet, en retour, de trouver plus tôt les erreurs de spécification (incohérence, etc). Cette contrainte est renforcée par certaines méthodes de développement comme le Test-Driven Development. L’ISTQB souligne le rapport de cette contrainte à la « maintenabilité » de l’objet.

L’activité de test d’un logiciel utilise différents types et techniques de tests pour vérifier que le logiciel est conforme à son cahier des charges (vérification du produit) et aux attentes du client (validation du produit). Elle est un des processus du développement de logiciels.




L’ISTQB3 définit un défaut comme une imperfection dans un composant ou un système qui peut en perturber le fonctionnement. Ce défaut est révélé par une défaillance (failure) s’il est exécuté, c’est-à-dire une déviation par rapport au comportement ou résultat attendu.

Cette définition indique que l’exécution du produit n’est pas la seule façon de détecter des défauts. Elle laisse aussi entrevoir qu’un code peut être syntaxiquement et sémantiquement correct et pourtant présenter un défaut qui ne sera manifesté que lors d’un test de performance par exemple. Dans un tel cas, l’origine du défaut pourrait être une erreur d’architecture ou de configuration.

Le terme anomalie est aussi souvent utilisé. C’est un terme générique qui fait référence autant à un défaut qu’à une défaillance.




La définition donnée dans la norme BS 7925-16 pour l’entrée fault (il n’y a pas d’entrée defect) fait de cette imperfection la matérialisation d’une erreur, c’est-à-dire d’une action humaine produisant un résultat incorrect (voir cette norme et la norme IEEE 610.12-19907), une « faute » de frappe ou une erreur de raisonnement par exemple. L’ISTQB semble se démarquer de cette position car même s’il considère que les défauts sont le plus souvent provoqués par des erreurs humaines, ceux-ci peuvent aussi être la conséquence de phénomènes environnementaux (radiation, pollution, magnétisme,…) modifiant le support hardware des logiciels testés.