Test (informatique) - Définition

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 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. 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 :

• le tests unitaires : est un niveau de test,
• le tests d'intégration : est également un niveau de test,

alors que ...

• le test de non-régression : n'est pas un niveau, mais un TYPE de test.

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-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 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 comme 2ⁿ où n est le nombre de bits dans la mémoire du calculateur ; le nombre de configurations accessibles, bien qu'inférieures, 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.