Test (informatique) - Définition
La liste des auteurs de cet article est disponible ici.
Introduction
En informatique, un test (anglicisme) désigne une procédure de vérification partielle d'un système informatique. Le but en est de trouver un nombre maximum de comportements problématiques du logiciel, car il est impossible de prouver qu'un logiciel fonctionne bien dans tous les cas. Plus d'erreurs sont trouvées, plus il y a de chances qu'il y ait davantage d'erreurs dans le composant logiciel visé. Les tests de vérification ou de validation visent à s'assurer que ce système réagit de la façon prévue par ses concepteurs (spécifications) ou est conforme aux attentes du client l'ayant commandé (besoins), respectivement. Dans cet article nous ne traitons que du test de logiciel ; le test du matériel informatique n'est pas abordé.
Un test ressemble à une expérience scientifique. Il examine une « hypothèse » formulée par le triplet (données en entrée, objet à tester, 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é.
Définition
Cette définition est issue de la norme IEEE 829-1998 revue à l'aide du glossaire de l'ISTQB.
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 définition d'un test revient 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-2 (version préliminaire disponible ici) ou le Software Testing Techniques 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 objectif :
- de diagnostiquer la cause des erreurs,
- de les corriger,
- 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 plutô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 test 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 logiciel.
Défaut (Bug)
L'ISTQB 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 algorithmiquement 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.
La définition donnée dans la norme BS 7925-1 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-1990), une « faute » de frappe ou une erreur de raisonnement par exemple. L'ISTQB semble se démarquer de cette position.
