Le type d'un test définit son but, c'est à dire ce qu'on cherche à tester. Il est préférable de n'avoir qu'un seul et unique but pour un test: vérifier une caractéristique bien définie du logiciel à tester. Les tests avec un but similaire sont regroupés afin d'être exécuté en même temps car ils sont souvent complémentaires.
Le type de test le plus connue est le test fonctionnel qui contient tous les tests qui ont pour but de vérifier qu'une fonctionnalité est correctement implémentée. Par abus de langage, on confond parfois les tests systèmes (niveau de test) et les tests fonctionnels (type de test) car les tests systèmes ont pour but de vérifier ce qui est défini dans les spécifications et donc en particulier dans la partie souvent la plus importante des spécifications que sont les spécifications fonctionnelles.
Cet abus de langage ne doit donc pas faire oublier que les tests fonctionnels peuvent être exécuté à chacun des niveaux: par exemple, lors des tests unitaires afin de vérifier qu'une classe réalise bien la fonction qui lui a été assignée lors de la conception détaillée. Autre écueil possible du à cet abus de langage, les tests systèmes ne doivent pas occulter les autres aspects des spécifications.
On en vient donc aux autres types de tests, dits parfois non-fonctionnels, que sont entre autres les tests de performance, les tests de robustesse, les tests de vulnérabilité, les tests de défaillances. Ces notions sont voisines mais diffèrent: un test de performance a pour but de mesurer les performances en mode nominal alors qu'un test de robustesse vérifie le fonctionnement de l'application alors qu'elle est stressée. Un test de vulnérabilité vérifie que le code résiste à des attaques connues tandis qu'un test de défaillance regarde le comportement lorsqu'un défaut survient comme par exemple lors d'une perte de connexion avec une base de donnée ou un automate.
La liste des types de tests est longue et cet article n'a pas pour but de tous les détailler. Je voudrais toutefois citer encore les tests d'utilisabilité et de maintenance qui sont souvent oubliés alors que très importants. Un test d'utilisabilité a pour but de détecter des problèmes d'ergonomie de l'application en particulier en prenant en compte la résolution d'écran des différents appareils qui permettront d'y accéder (PDA, mini-PC...). La maintenance est aussi primordiale et il est impératif de de poser des questions sur le comportement en production comme "Est-on capable de restaurer rapidement un système en cas de crash d'une machine?". Parfois, un PC est un élément indispensable sur une ligne de production et sa défaillance entraîne l'arrêt de la production avec les conséquences économiques que l'on peut imaginer.
Pour finir, je voudrais aussi citer les tests de non-régression qui ont pour but de vérifier le plus rapidement possible que l'application n'est pas altérée suite à une mise à jour logicielle. Grâce à l'automatisation des tests, ces tests sont plus faciles à réaliser. Certains des tests de non-régression sont même souvent intégrés au process de génération du logiciel afin de détecter le plus en amont possible les défaillances. On parle alors de smoke-tests ou de tests de fumées en analogie avec le monde de l'électronique: ces tests se limitent à détecter des erreurs grossières qui rendraient inutiles d'aller plus loin dans les tests.
Voila, cette série sur la classification des tests est terminée. En résumé, classer les tests c'est répondre à 3 questions de base qui sont indépendantes: l'accessibilité définit le comment, le niveau définit le quand, le type définit le quoi.
J'espère que ces articles vous ont intéressé et qu'ils ont alimenté votre réflexion sur le test logiciel. N'hésitez pas à me faire parvenir vos commentaires par email à l'adresse [email protected].
Jeu de briques
Snake
Pacman
Bubble