Test (informatique)

type de test

Pour les articles homonymes, voir Test.

En informatique, un test est une procédure de vérification partielle d'un système. Son objectif
principal est d'identifier un nombre maximal de comportements problématiques du logiciel. Il
permet ainsi, dès lors que les problèmes identifiés seront corrigés, d'en augmenter la qualité.

Une programmeuse écrivant du code

Java avec JUnit.

D'une manière plus générale, le test désigne toutes les activités qui consistent à rechercher des
informations quant à la qualité du système afin de permettre la prise de décisions.

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 et, dans
l'idéal, être reproduit[1].

Définition

La définition qui suit 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 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-2[4],[5] ou le Software Testing Techniques[6] 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é
de les corriger.

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. Cette contrainte est renforcée par certaines méthodes de
développement comme le Test-Driven Development [réf. souhaitée]. L'ISTQB souligne le rapport de
cette contrainte à la « maintenabilité » de l'objet [réf. souhaitée].

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 ou ses spécifications (vérification du produit) et
aux attentes du client (validation du produit). Elle est un des processus du développement de
logiciels.

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) si le système
est exécuté, c'est-à-dire une déviation par rapport au comportement ou résultat attendu[3].

Cette définition indique que l'exécution du système n'est pas la seule façon de détecter des
défauts. Elle laisse aussi entrevoir le fait qu'un code peut être syntaxiquement et
sémantiquement correct et pourtant présenter un défaut qui ne se manifestera 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 [réf. souhaitée].

La définition donnée dans la norme BS 7925-1[7] 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[8]), 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.
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 du test se développent considérablement. 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[9].

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), l'accessibilité de la structure de l'objet et la propriété de l'objet
(performance par exemple).

Ces trois 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 la nature de l'objet

Le glossaire de l'ISTQB[3] définit un niveau de tests comme 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.

Le Comité français du test logiciel (CFTL) identifie quatre niveaux de test :

1. Test unitaire (ou test de composants) ;

2. Test d'intégration (anciennement test technique ou test d'intégration technique) ;

3. Test système (anciennement test fonctionnel ou test d'intégration fonctionnel ou

homologation) ;

4. Test d'acceptation (anciennement test usine ou recette).

Par ailleurs, on parle aussi de niveau de test amont pour désigner les niveaux unitaire et
intégration, et de niveau de test aval pour désigner les niveaux système et acceptation.

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.

Classification selon l'accessibilité de la structure de l'objet

Technique de conception de test par 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 par 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 mais sur la définition du composant ou du système.

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

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

Les tests boîte noire vérifient la définition de l'objet. Les tests système et d'acceptation sont
souvent spécifiés à l'aide des techniques de conception de test par boîte noire, mais rien
n'empêche d'utiliser ces techniques pour définir des tests unitaires ou d'intégration.

Classification selon la propriété de l'objet

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

test fonctionnel ;

test de performance ;

test d'intrusion ;

test utilisateur.

Une liste de toutes les caractéristiques d'un logiciel a été établie par la norme ISO 9126.

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 que JUnit pour le 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.

Activités de test

Le test est souvent assimilé à son activité d'exécution. Cependant, cette activité d'exécution ne
saurait se passer des étapes nécessaires qui la précèdent et la suivent. L'ISTQB définit ainsi un
processus de test fondamental en cinq étapes. En pratique, ces étapes peuvent se chevaucher,
en particulier au sein des projets développés de manière itérative.

Planification. Cette activité est celle qui est pratiquée au tout début de la phase de test. Elle
permet de définir la stratégie qui sera mise en place tout au long de la phase de test.
Analyse et conception des tests. Cette activité consiste en la rédaction des scénarios de tests
qui seront joués. Elle définit pour chaque test à exécuter quels seront les prérequis à posséder
pour effectuer le test, les actions qu'il faudra mener et les résultats auxquels on s'attend.
Implémentation et exécution. Cette activité est le test à proprement parler du logiciel. Dans le
cas où une défaillance survient lors de cette phase, celle-ci est alors le plus souvent décrite
dans une fiche d'anomalie qui permet de conserver une trace du problème.
 Evaluation des critères de sortie et communication. Cette étape permet d'évaluer si les
activités de test sont conformes aux objectifs définis. Il s'agit également de communiquer les
résultats des tests aux autres parties prenantes.
Clôture. Cette activité permet de synthétiser la phase de test quand elle est terminée. Elle
décrit tous les éléments survenus lors du test et peut s'accompagner de recommandations
pour l'utilisation ou l'évolution du logiciel testé[10].

Exemples de logiciels de test

Outre les librairies utilisées lors des tests unitaires et d'intégration, les activités de test
nécessitent l'utilisation de logiciels de différentes natures.

Gestionnaires des tests

Ces outils permettent entre autres de constituer des référentiels de tests fonctionnels et
d'exécuter des campagnes de test.

Testlink (en)

HP Quality Center (en)

Squash TM

Refertest

Gestionnaire des anomalies

Ces outils permettent entre autres de déclarer des anomalies et de les assigner pour correction.

Bugzilla

Mantis

Jira (avec son module Xray)

Génération de référentiel de test

MaTeLo

Yest

Outils d'automatisation des tests fonctionnels

Une liste détaillée peut être trouvée sur l'article en anglais Comparison of GUI testing tools.
Outils de tests non-fonctionnels
Cette section est vide, insuffisamment détaillée ou incomplète. Votre aide est la bienvenue pour
mentionner des outils de test non-fonctionnel (sécurité, performance, accessibilité,
utilisabilité...) !

Tests de sécurité
ZAP (Zed Attack Proxy) (en)

Tests de performance et de charge

JMeter

Gatling

NeoLoad (en)

Dynatrace
Qualité de code

SonarQube

CodeSonar

LDRA TestBed

Notes et références

1. Claude Laporte et Alain April, Assurance qualité logicielle 2 : processus de support, Chapitre
1, Lavoisier, 2011, (ISBN 9782746232228), p. 372.

2. (en)IEEE Standard for Software Test Documentation, 1998 (ISBN 0-7381-1444-8).

3. (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. version préliminaire disponible ici (http://www.testingstandards.co.uk/bs_7925-2.ht

m) [archive]

6. (en) Software Testing Techniques, Boris Beizer, 1990 (ISBN 0-442-20672-0).

7. (en) Glossary of terms used in software testing.

8. (en) IEEE Standard Glossary of Software Engineering Terminology, 1990 (ISBN 0-7381-0391-8).

9. (fr) Industrialiser le test fonctionnel : des exigences métier au référentiel de tests, 2009
(ISBN 978-2-100515-33-2).
 10. International Software Testing Qualifications Board, Comité Français des Tests Logiciels,
Testeur Certifié - Syllabus Niveau Fondation, 82 p. (lire en ligne (http://www.cftl.fr/wp-content/upload
s/2015/03/ISTQB-FL-Syll-2011-Released_FR.pdf) [archive]), p. 15-17

Voir aussi

Articles connexes
Cycle en V

Gestion de projet

TMap

Test de performance

Test A/B

Ingénierie des systèmes - IVVQ

Test unitaire

Test d'intégration

Tests système

Test d'acceptation

Liens externes

Notice dans un dictionnaire ou une encyclopédie généraliste : Britannica (https://www.britan

nica.com/technology/testing-technology) [archive]

Notices d'autorité : Tchéquie (http://aut.nkp.cz/ph173828)

Glossaire de l'ISTQB (http://www.istqb.org/downloads.html) [archive] (International Software

Testing Qualifications Board) qui s'inspire de diverses normes dont IEEE 829-1998 (IEEE
Standard for Software Test Documentation).

Glossaire des termes relatifs au test logiciel (http://www.cftl.fr/wp-content/uploads/2015/03/

Glossaire-des-tests-de-logiciel-2-2-F-P1.pdf) [archive] (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)

Norme BS 7925-1 (http://www.testingstandards.co.uk/bs_7925-1.htm) [archive] (Glossary of

Software Testing Terms).
Norme (version préliminaire) BS 7925-2 (http://www.testingstandards.co.uk/bs_7925-2.ht
m) [archive] (Software component testing).

Comment construire les tests d'un logiciel - INRS - Cahiers de notes documentaires No 181, 4e
trimestre 2000 (http://www.inrs.fr/dms/inrs/CataloguePapier/ND/TI-ND-2140/nd2140.pd
f) [archive]

Portail de la programmation informatique