Ce billet décrit les différentes type de tests.

Qu’est ce qu’un test ?

Un test est l’exécution du programme contre une spécification. C’est une opération destinée à contrôler le bon fonctionnement ou la bonne exécution d'un programme dans son ensemble. Les objectifs des tests sont de :

• Trouver des anomalies qui n’ont pas été détectées
• Vérifier la conformité d’un logiciel avec ses spécifications

De ce fait, il existe de nombreux types de test. On peut les regrouper en 2 familles:

• Test en boite blanche
• Test en boite noir

Les tests en boite blanche

Ils consistent à faire un test en regardant ce qui se passe dans le programme (un peu comme un garagiste qui soulève le capos pour regarder comment le moteur d'une voiture tourne).  Ce sont ces tests qui permettent de valider la structure de chaque module composant le logiciel. Ils permettent d'avoir l'assurance que toutes les parties d'un programme ont été essayées. On teste ici ce que le programme fait (comment il le fait) et non pas ce qu'il est censé faire. On distingue les :

• Tests de chemin: Ce test consiste à analyser la structure interne du programme en déterminant les chemins minimaux. Ainsi, toutes les branches d’une instruction conditionnelle sont testées de même, les structures de données internes sont vérifiées. L'ensemble des lignes testées pas ces chemins permettent de mesurer le taux de couverture du test.
• Tests de boucles : Est une sous partie du test de chemin, il s’agit de vérifier que toutes les boucles se terminent grâce au condition d’arrêt. Dans le cas contraire on risque une boucle infinie donc le plantage du logiciel.
• Tests aux limites : On génère des cas de tests aux limites pour vérifier le comportement du programme sur les cas aux bornes. L'un des exemple célèbre est celui du bug affectant le logiciel de l'avion de chasse f-16 qui provoquait le retournement de l'horizon artificielle au passage de l'équateur (inversion du signe de coordonnées géographique).

Les Tests en boite noir

On fait abstraction du fonctionnement du programme. Ce sont ces tests qui permettent de vérifier l'adéquation du logiciel aux contraintes définies dans les spécifications. Les tests de fonctionnalités évaluent la réaction du logiciel par rapport à des données d'entrées représentatives. On teste ici ce que le programme est censé faire et non pas ce qu'il fait réellement. Ces Tests sont réalisés pour assurer qu’une fonction métier est exécutée correctement. On distingue :

• Tests unitaires ou de modules : Tests pratiqués sur une méthode, une classe ou un composant pour vérifier un comportement individuel correct. Cela permet de valider la qualité du code et les performances des différents modules.  Il est couramment admis que ces tests sont pratiqués lors de la phase de réalisation/codage.
• Tests d’intégration: Consiste à tester le logiciel complet. Une fois que chaque module à subit les tests nécessaires à sa validation, viennent les tests d’intégrations. Utiliser pour révéler les problèmes d'interface entre les différents programmes, ils permettent de valider l’intégration des modules entre eux et dans leur environnement d’exploitation définitif. Les tests d’intégrations s’attachent aux réactions du produit dans un contexte ensembliste. Il teste à la fois les interactions entre les modules, et les réactions des modules seules, dans le contexte de l’application globale. Ce type de tests est directement lié aux tests unitaires, ils sont complémentaires.
• Tests Fonctionnels ou de fonctionnement : Dans ce type de test, on vérifie qu’il n’y a pas d’anomalies dans les fonctions réalisées par l’application. Le but est de valider les spécifications techniques et les exigences fonctionnelles.
• tests de non-régression: Ils sont utilisé pour vérifier que l’application modifiée continue de fonctionner comme spécifiée même si les fonctionnalités testées n’ont pas fait l’objet de modification. Cela permet de vérifier qu'une correction de bug a un endroit n'a pas une conséquence inattendue ailleurs.
• Les tests d’installation : Comme le nom l’indique, il s’agit de tester les procédures d’installations, vérifier la documentation et vérifier que la plate-forme convient aux tests.
• Tests grandeur nature :  Leur objectif est de vérifier le fonctionnement du produit sur des systèmes correspondant à ceux pour lesquels il est destiné. On reproduit généralement la plateforme cible le plus strictement possible.
• Les tests de performances : les tests de performances ne s’attardent plus sur le fonctionnement du logiciel. Ce dernier étant déjà validé, ces tests tendent à vérifier les temps de réaction du système dans différentes situations, et des les comparer aux performances attendues.
• Tests de Charge :  Les tests de charge servent à évaluer les limites de rupture à l’utilisation (nombre de requêtes simultanées…), et de connaître les réactions du produit en cas de dépassement de ces limites. Le test de performance mesure isolément les temps de réponse pour chaque type de sollicitation. Le test de charge mesure la capacité de répondre simultanément à de nombreuse requête et à vérifier les capacités de répondre à un nombre données de requêtes simultanées et à y répondre dans un temps limité.

Cet ensemble de tests théoriques semble avoir été pensé pour des logiciels type mainframe. Il est évident que des architectures temps réel ou web ont des problématiques de test différentes de celles décrites ici. Que pourraient être un test de charge dans une application temps réelle ? Comment faire un test unitaire dans un développement MVC ?

La semaine prochaine : les tests pour le web (en PHP).