Test (informatique)
78942
31755559
2008-07-21T11:47:03Z
212.35.103.35
/* Définition des niveaux de test */
En [[informatique]], un '''test''' (anglicisme) désigne une procédure de vérification partielle d'un [[système informatique]]. Le but en est de s'assurer que ce système réagit de la façon prévue par ses concepteurs ou est conforme aux attentes du client l'ayant commandé. 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 [[Institute of electrical and electronics engineers|IEEE]] 829-1998<ref name="ieee829-1998">{{en}}''IEEE Standard for Software Test Documentation'', 1998 {{ISBN|0-7381-1444-8}}</ref> revue à l'aide du glossaire de l'ISTQB<ref name="glossaireISTQB">{{en}}''Standard glossary of terms used in Software Testing'', ISTQB, version 2.0, décembre 2007</ref>.
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 differents 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<ref name="bs7925-2">{{en}}''Software testing. Software component testing'', 1998 {{ISBN|0-580-29556-7}}</ref> (version préliminaire disponible [http://www.testingstandards.co.uk/bs_7925-2.htm ici]) ou le ''Software Testing Techniques''<ref name="">{{en}}''Software Testing Techniques'', Boris Bezier, 1990 {{ISBN|0-442-20672-0}}</ref> 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<ref name="glossaireISTQB"/> 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<ref name="bs7925-1">{{en}}''Glossary of terms used in software testing''</ref> 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<ref name="ieee610-1990">{{en}}''IEEE Standard Glossary of
Software Engineering Terminology'', 1990 {{ISBN|0-7381-0391-8}}</ref>), 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 défini de qualité 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.
== 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<ref name="glossaireISTQB"/> 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 (et quatre seulement) :
# [[Test unitaire|Unitaire]]
# [[Test d'intégration|Intégration]]
# Système
# Acceptation
Cette classification a plusieurs mérites parmi lesquels :
* positionne un "état de l'art" de plus en plus reconnu par les plus grands intervenants sur le métier Test et Recette (SSII : Atos Origin, Sogeti, etc ... ; Grandes entreprises : EDF, ING.Bank, etc ...)
* correspond aux quatre sortes d'environnements de tests nécessaires : ceux-ci se doivent d'être d'autant plus réalistes qu'on est à un niveau élevé.
* .../...
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.
En France, le terme "phase de test" est parfois préféré au mot "niveau de test"
Ainsi ('''exemples''') :
* [[test unitaire|tests unitaires]] : est un niveau de test,
* [[test d'intégration|tests d'intégration]] : est également un niveau de test,
alors que ...
* [[Non-régression|tests de non-régression]] : n'est pas un niveau, mais un TYPE de test.
=== 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 [[boîte blanche|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 (informatique)|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-187B 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 le 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 technique 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 :
* [[test de performance|tests de performance]] : vérification 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 : vérification de la robustesse du logiciel.
* [[:Catégorie:audit logiciel|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 comme 2<sup>''n''</sup> où ''n'' est le nombre de [[Bit (informatique)|bits]] dans la mémoire du calculateur ; 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, [[heuristique]]ment, de faire en sorte que si un [[bogue (informatique)|bogue]] 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éthode formelle (informatique)|méthodes formelles]].
Les bibliothèques de tests telles [[JUnit]] en [[Java (langage)|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 (gestion de la qualité)|processus]], organisation, formation, [[accompagnateur du changement|accompagnement du changement]]) : réception, qualification, certification, [[homologation]], simulation, VABF (vérification d'aptitude au bon fonctionnement)... les termes varient selon les contextes.
== Notes et références ==
<references /> <!-- aide : http://fr.wikipedia.org/wiki/Aide:Notes et références -->
== Voir aussi ==
=== Articles connexes ===
* [[Cycle en V]]
* [[Gestion de projet]]
* [[TMap]] (Test Management Approach)
=== Liens externes ===
* [http://www.istqb.org/download.htm Glossaire de l'ISTQB] (''International Software Testing Qualifications Board'') qui s'inspire de diverses normes dont IEEE 829-1998 (''IEEE Standard for Software Test Documentation'').
* [http://www.cftl.net/cms/files/Dokumente/frGlossaire%20des%20tests%20de%20logiciel%20-%20ISTQB.pdf Glossaire des termes relatifs au test logiciel] (''version française du glossaire de l'ISTQB '' : traduit par le CFTL (Comité Français du Test Logiciel)- ''ajouté le 20 Avril 2008 par JPG.''
* [http://www.testingstandards.co.uk/bs_7925-1.htm Norme BS 7925-1] (''Glossary of Software Testing Terms'').
* [http://www.testingstandards.co.uk/bs_7925-2.htm Norme (version préliminaire) BS 7925-2] (''Software component testing'')
{{Audit de sécurité informatique}}
{{Portail|programmation informatique}}
[[Catégorie:Test logiciel|*]]
[[ar:فحص البرمجيات]]
[[be-x-old:Тэставаньне праграмнага забеспячэньня]]
[[cs:Testování softwaru]]
[[de:Softwaretest]]
[[en:Software testing]]
[[es:Pruebas de software]]
[[et:Tarkvara testimine]]
[[he:בדיקות תוכנה]]
[[hu:Szoftvertesztelés]]
[[it:Collaudo del software]]
[[ja:ソフトウェアテスト]]
[[ko:소프트웨어 테스트]]
[[nl:Testen (software)]]
[[no:Programvaretesting]]
[[pl:Testowanie oprogramowania]]
[[pt:Teste de software]]
[[ro:Testarea software]]
[[ru:Тестирование программного обеспечения]]
[[sk:Testovanie softvéru]]
[[sv:Programvarutestning]]
[[ta:மென்பொருட் சோதனை]]
[[te:సాఫ్టువేరు టెస్టింగ్]]
[[th:Software testing]]
[[uk:Тестування програмного забезпечення]]
[[zh:软件测试]]