Test (informatique)


Test (informatique)
Page d'aide sur l'homonymie Pour les articles homonymes, voir Test.

En informatique, un test désigne une procédure de vérification partielle d'un système. Le but 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 le nombre d'erreurs trouvées est important, 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 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].

Sommaire

Définition

Cette définition est issue de la norme IEEE 829-1998[2] revue à l'aide du glossaire de l'ISTQB[3].

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[4] (version préliminaire disponible ici) ou le Software Testing Techniques[5] 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 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.

Défaut (Bogue)

L'ISTQB[3] 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.

La définition donnée dans la norme BS 7925-1[6] 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[7]), une « faute » de frappe ou une erreur de raisonnement par exemple. L'ISTQB semble se démarquer de cette position.

Qualité et Test

Les phases de test dans le cycle de développement d'un produit logiciel permettent d'assurer un niveau de qualité défini en accord avec le client. Une procédure de test peut donc être plus ou moins fine, et par conséquent l'effort de test plus ou moins important et coûteux selon le niveau de qualité requis. Aujourd'hui, les métiers dédiés au monde du test commencent à apparaître. C'est en grande partie grâce à une prise de conscience de la complexité ou de la criticité des produits. Il est alors important que ces différentes phases soient bien intégrées dans le cycle de développement sur la base de bonnes pratiques et de la rationalisation du processus[8].

Classification des tests

Il existe différentes façons de classer les tests informatiques. Nous proposons ici une classification selon trois perspectives : la nature de l'objet à tester (perspective étroitement liée au cycle de développement), le niveau de connaissance de la structure de l'objet et le type de caractéristique ou propriété (performance par exemple).

Ces 3 perspectives ne permettent cependant pas de classer le test de non-régression (voir aussi l'article sur la non-régression). Le glossaire de l'ISTQB[3] le définit comme cherchant à mettre en évidence, dans la partie inchangée du logiciel, des défauts mis à jour ou introduits par un changement dans le logiciel (mise à niveau, correction, etc) ou son environnement d'exécution.

Le test de non-régression n'est donc pas restreint à une phase particulière du cycle de développement. Il n'est pas non plus restreint à un type de propriété à tester.

Classification selon le niveau

Le CFTL (Comité Français du Test Logiciel : ISTQB en anglais), identifie quatre niveaux de test :

  1. Composant (Unitaire)
  2. Intégration (anciennement test d'intégration technique...)
  3. Test Système (anciennement Homologation, ou test fonctionnel, ou même test d'intégration fonctionnel...)
  4. Test d'Acceptation ou UAT (User Acceptance Testing) (anciennement Recette, test usine...)


De plus, il est reconnu que d'autres niveaux de test soient requis afin de répondre à des besoins spécifiques formalisé dans les exigences : test de performance, de sécurité, d'ergonomie...

Ainsi :

alors que ...


Par ailleurs, on parle aussi de "niveaux de tests amont" et "aval" pour désigner respectivement Unitaire+Intégration = amont et Acceptation+Système = Aval. De même, en France, le terme "phase de test" est parfois utilisé à la place de "niveau de test" mais il ne respecte pas le vocabulaire du CFTL.

Définition des niveaux de test

  • Niveau de tests : un groupe d’activités de tests qui sont organisées et gérées ensemble. Un niveau de tests est lié aux responsabilités dans un projet. Les niveaux de tests sont les tests de composants, les tests d’intégration, les tests système et d’acceptation.

Cette définition (TMap) est citée celle du glossaire CFTL - cf liens externes en bas de cette page)

Classification selon le niveau d'accessibilité

  • Technique de conception de test de structure (boîte blanche, white box)  : technique de conception de test, en général fonctionnel, fondée sur l'analyse de la structure interne du composant ou du système.
  • Technique de conception de test de type boîte noire (black box) : technique de conception de test, fonctionnel ou non, qui n'est pas fondée sur l'analyse de la structure interne du composant ou du système.

Les tests résultants d'une technique de conception de test de structure (test structural) vérifient la structure interne de l'objet, par exemple l'exécution des branches des instructions conditionnelles. Les test unitaires sont souvent spécifiés à l'aide de telles techniques. Pour certains types de logiciel, des normes prescrivent les techniques de conception de test de structure à utiliser (par exemple, la norme américaine RTCA/DO-178B pour les logiciels d'avionique).

Dans les tests résultants d'une technique de conception de test de type boîte noire les données en entrée et le résultat attendu sont sélectionnés non pas en fonction de la structure interne mais de la définition de l'objet. Ces tests sont les plus fréquents parmi les tests fonctionnels d'intégration et de recette, mais rien n'empêche d'utiliser ces techniques de conception pour définir des tests unitaires.

Par extension, on appelle couramment les tests issus de ces types de techniques de conception tests boîte blanche (ou white box) et tests boîte noire (ou black box).

Pareillement, on appelle couramment test boîte blanche (ou structurel) une façon de tester utilisant des tests dits boîte blanche ; de même pour le test boîte noire. La référence à une telle façon de faire pourrait se trouver, par exemple, dans un plan de test.

Classification selon la caractéristique

On ne peut pas être exhaustif, on se contentera de quelques exemples :

  • tests de performance : validation que les performances annoncées dans la spécification sont bien atteintes,
  • test fonctionnel : vérification que les fonctions sont bien atteintes, par rapport aux attentes,
  • test de robustesse : validation de la stabilité et de la fiabilité du logiciel dans le temps.
  • test de vulnérabilité : vérification de sécurité du logiciel.

En dehors du cas très particulier de systèmes extrêmement simples, il est impossible de tester exhaustivement un logiciel, car le nombre de configurations possibles croît de façon exponentielle selon le nombre de mises en situation différentes que le logiciel pourra être appelé à traiter ; le nombre de configurations accessibles, bien qu'inférieur, reste tout de même prohibitif. La réussite des tests ne permet donc pas de conclure au bon fonctionnement du logiciel. On essaye cependant, heuristiquement, de faire en sorte que si un bug est présent, le test le mette en évidence, notamment en exigeant une bonne couverture des tests :

  • couverture en points de programme : chaque point de programme doit avoir été testé au moins une fois
  • couverture en chemins de programme : chaque séquence de points de programme possible dans une exécution doit avoir été testée au moins une fois (impossible en général).
  • couverture fonctionnelle : chaque fonctionnalité métier de l'application doit être vérifiée par au moins un cas de test.

Si l'on veut des assurances plus fortes de bon fonctionnement, on peut utiliser des méthodes formelles.

Les bibliothèques de tests telles JUnit en langage Java, permettent de faciliter l'écriture de tests unitaires par l'apport des méthodes "assert" permettant de vérifier le comportement du programme.

Selon la complexité du logiciel, des séquences de vérification globale peuvent s'avérer nécessaires. Celles-ci mettent en jeu la maîtrise d'ouvrage et toutes les composantes du projet, au-delà du logiciel lui-même (processus, organisation, formation, accompagnement du changement) : réception, qualification, certification, homologation, simulation, VABF (vérification d'aptitude au bon fonctionnement)... les termes varient selon les contextes.

Documents

  • Le plan de tests et d'évaluation est le document regroupant tous les tests et décrit la stratégie de test en décrivant les tests dans leur globalité : place dans le processus produit, environnement de test, types de tests, etc.
  • les fiches de test sont des documents rattachés au plan de test, chaque fiche correspondant à un ensemble cohérent des tests constitutifs du plan. Elles peuvent être basées sur un découpage fonctionnel (par ex par Use case), ou éventuellement sur d'autres critères. Une fiche de test décrit généralement, étape par étape, les démarches à suivre pour dérouler le test, et les résultats : comportement ou réaction attendu du système à chacune de ces étapes.
  • Le dossier de test désigne un ensemble de documents regroupant les différents plans de tests avec leurs fiches, mais aussi les résultats des tests passés sur la base de ces fiches.

Notes et références

  1. Claude Laporte et Alain April, Assurance qualité logicielle 2: processus de support, Chapitre 1, Lavoisier, 2011, (ISBN 9782746232228), page 372
  2. (en)IEEE Standard for Software Test Documentation, 1998 (ISBN 0-7381-1444-8)
  3. a, b et c (en)Standard glossary of terms used in Software Testing, ISTQB, version 2.0, décembre 2007
  4. (en)Software testing. Software component testing, 1998 (ISBN 0-580-29556-7)
  5. (en)Software Testing Techniques, Boris Beizer, 1990 (ISBN 0-442-20672-0)
  6. (en)Glossary of terms used in software testing
  7. (en)IEEE Standard Glossary of Software Engineering Terminology, 1990 (ISBN 0-7381-0391-8)
  8. (fr)Industrialiser le test fonctionnel : des exigences métier au référentiel de tests, 2009 (ISBN 978-2-100515-33-2)

Voir aussi

Sur les autres projets Wikimedia :

Articles connexes

Liens externes


Wikimedia Foundation. 2010.

Contenu soumis à la licence CC-BY-SA. Source : Article Test (informatique) de Wikipédia en français (auteurs)

Regardez d'autres dictionnaires:

  • Test logiciel — Test (informatique) 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… …   Wikipédia en Français

  • test — ● n. m. ►DEBUG Phase du développement d un logiciel lors de laquelle on se rend compte qu on aurait mieux fait de choisir un autre métier. D ailleurs, on utilise souvent des testeurs pour faire ce boulot. Verbe associé: tester. Voir aussi banc d… …   Dictionnaire d'informatique francophone

  • test de Turing — ● loc. m. ►INTART Test conçu par Turing, Alan Mathison, afin de déterminer si un ordinateur pense: on met un expérimentateur testeur d un côté, et une machine et un bonhomme de l autre. Si le testeur se fait avoir par la machine et ne sait pas… …   Dictionnaire d'informatique francophone

  • test de l'ascenseur — ● loc. m. ►DECI Une idée est considérée comme bonne si on peut en convaincre son chef dans la durée d un trajet d ascenseur. L idée de faire passer ce test à ses idées n est peut être pas une bonne idée. Enfin moi, je préfère prendre l escalier …   Dictionnaire d'informatique francophone

  • Test Management Approach — TMap Pour les articles homonymes, voir TMAP. TMap (Test Management Approach) est un modèle en matière de test et d assurance qualité des logiciels. TMap repose sur 4 grands thèmes : le Cycle de Vie (C) des activités de test, une forte… …   Wikipédia en Français

  • Test de la boîte noire — Pour les articles homonymes, voir Boîte noire (homonymie). Le test de la boîte noire est utilisé en programmation informatique et en génie logiciel, pour tester un programme en vérifiant que les sorties obtenues sont bien celles prévues pour des… …   Wikipédia en Français

  • Test de Charge — Test de performance Un test de performance ou benchmark est un test dont l objectif est de déterminer la performance d un système informatique. L acception la plus courante de ce terme est celle dans laquelle ces tests logiciels vont avoir pour… …   Wikipédia en Français

  • Test unit — Test unitaire Pour les articles homonymes, voir Test. En programmation informatique, le test unitaire est un procédé permettant de s assurer du fonctionnement correct d une partie déterminée d un logiciel ou d une portion d un programme (appelée… …   Wikipédia en Français

  • Test de recette — En informatique, la recette (le recettage) est une des phases de développement d un projet au cours de laquelle les différents acteurs se rencontrent afin de vérifier que le produit est conforme aux attentes formulées. Le test de recette permet… …   Wikipédia en Français

  • Test de turing — Pour les articles homonymes, voir Turing (homonymie). Le test de Turing est une proposition de test d’intelligence artificielle ayant la faculté d’imiter la conversation humaine. Décrit par Alan Turing en 1950 dans sa publication Computing… …   Wikipédia en Français


Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”

We are using cookies for the best presentation of our site. Continuing to use this site, you agree with this.