Les tests dans un projet

Cycle de vie

Issu du monde de l'industrie, le Cycle en V présenté par l'illustration ci-dessous est devenu un standard de l'industrie logicielle depuis les années 1980. C'est un modèle de gestion de projet qui permet, en cas d'anomalie, de limiter un retour aux étapes précédentes.

La branche descendante contient les phases de conception du logiciel et la branche montante contient les étapes de tests du logiciel. La pointe du V quant à elle représente la phase de réalisation. Chaque phase de la branche descendante a un lien avec une phase de la branche montante.

Cycle en V

Les niveaux de test

• Tests unitaires : ils consistent à valider unitairement les fonctions ou modules de l'application ;
• Tests d'intégration : ils consitent à valider l'intégration des différents modules entre eux ;
• Tests fonctionnels : ils consistent à valider la conformité de l'application finale quant à ses spécifications (fonctionnelles et techniques) décrites dans le cahier des charges avant livraison ;
• Tests de recette : comme les tests fonctionnels, ils consistent à valider la conformité de l'application finale quant à ses spécifications mais après livraison, chez le client.

Les techniques de test

Technique statique

• Consiste à inspecter le code en le lisant
• Permet de détecter seulement la moitié des fautes
• Impose au développeur de coder proprement
• Le code inspecté est exécuté à la main, ce qui prend du temps

Technique "boîte blanche"

• Ces tests sont conçus par rapport à l'implémentation des modules
• Ils tiennent compte de la structure du code des composants testés
• Ils permettent de déceler les erreurs de développement

Technique "boîte noire"

• Ces tests sont conçus sans connaissance de l'implémentation des modules
• Ils consistent à analyser l'aspect fonctionnel des composants par le biais d'entrées/sorties
• Ils permettent de déceler les erreurs de conception au regard des spécifications

La gestion des tests

Planification

Pour chaque niveau de test présenté ci-dessus, la planification des tests commence au début du processus de test pour ce niveau et continue tout au long du projet jusqu'à l'achèvement des activités de clôture pour ce niveau.

La planification des tests consiste à définir les objectifs de tests et à spécifier les activités de tests à mettre en oeuvre pour atteindre ces objectifs.

Contrôle

Les activités de contrôle sont exécutées tout au long de la campagne de tests afin d'assurer que les tests qui ont été planifiés sont exécutés correctement et que les objectifs sont bien vérifiés.

Conception

La conception des tests est la phase durant laquelle les objectifs de tests sont traduits en conditions de tests (environnement de test défini) et en cas de tests (comportement attendu selon des données injectées en entrée).

Exécution

L'exécution des tests est l'étape où le système est testé suivant des procédures de tests et où le résultat obtenu est comparé avec le résultat attendu afin d'identifier ou non des anomalies.

Il s'agit ensuite d'établir leur cause et de répertorier le tout de manière détaillée afin de faciliter leur correction ultérieure.

Analyse des critères d'arrêt

Au cours de cette activité, l'exécution des tests est évaluée pour chaque niveau de test en fonction des objectifs définis au cours de la phase de planification.

Si un ou plusieurs critères de sortie ne sont pas atteints, il faut soit changer les critères de sortie, soit concevoir et exécuter des cas de tests supplémentaires.

Exemple

Cas de test

Prenons comme exemple un système dans lequel des messages arrivent et sont stockés dans une base de données avant d'être analysés.

Ces messages possèdent un ID et un statut, le statut doit avoir une valeur précise selon l'ID du message. Deux IDs sont possibles :

• KO : le statut du message doit être "Error"
• OK : le statut du message doit être "Validated"

Architecture logicielle

L'illustration ci-dessous a pour but de présenter une architecture logicielle de tests réalisée en Java :

• à droite du trait rouge se situe le code qui se connecte à la base de données pour en extraire les messages entrants dans le système ;
• à gauche du trait rouge se situe le code de test qui analyse le couple ID/statut de chaque message.

Architecture logicielle de tests

Récupération des messages en base

Une interface "IMessageDAO" fournissant une méthode publique getMessages(id) est conçue afin de récupérer les messages stockés en base. Pour réaliser cette fonctionnalité, une classe "MessageDAOImpl" qui implémente l'interface "IMessageDAO" et qui se connecte à la base de données est mise en place.

Vérification du contenu des messages

Une classe abstraite "AbstractTestCase" dont les différentes classes de test hériteront pour récupérer deux champs est conçue :

• le fameux ID qui est injecté automatiquement par le framework de construction du projet (Maven dans notre cas) ;
• et une variable du type de l'interface "IMessageDAO" pour faire appel au service d'extraction des messages en base.

Notre classe de test "Test", située dans le coin supérieur gauche, hérite de cette classe abstraite "AbstractTestCase" afin de récupérer les deux champs décrits ci-dessus. Cette classe de test va faire appel à la méthode getMessages(id) pour récupérer une liste des messages stockés en base et va vérifier la concordance entre l'ID et le statut de chaque message de cette liste.

Implémentation du test

Comme dit ci-dessus et illustré ci-dessous, la classe de test récupère donc une liste des messages stockés en base et, pour chacun d'entre eux, s'assure qu'à l'ID KO est bien associé le statut "Error" et qu'à l'ID OK est bien associé le statut "Validated".

Si le couple ID/statut du message courant est correct, alors l'assertion est vraie, sinon, elle est fausse et remonte un message d'erreur. Dans ce cas, le processus de construction du projet exécuté par le framework Maven va échouer et en avisera la personne responsable de son exécution.

Implémentation de la classe de tests

Validation du test

Afin d'assurer le suivi de la campagne de tests, il est essentiel de se munir d'outils afin d'automatiser certaines étapes et de centraliser l'état d'avancement global de la campagne.

Vous pouvez observer ci-dessous une illustration de l'interface web d'un outil propriétaire IBM nommé "Rational Quality Manager" (ou RQM) qui permet justement de centraliser l'ensemble des tests logiciels de chaque niveau du cycle en V. L'image décrit la procédure d'un test de type boîte noire (différent de celui concernant les messages entrants) ainsi que l'état de ce test.

Comme vous pouvez le remarquer, le test contient une description de la procédure de test à suivre dans le champ "Description", le comportement attendu du système dans le champ "Expected Results" et enfin le comportement obtenu en sortie de test dans le champ "Actual Results".

Grâce à cette interface web, n'importe quel collaborateur du projet est capable de savoir à tout instant l'état d'avancement de ce test et peut agir en conséquence, ce qui facilite l'évolution de la campagne de tests.

Rational Quality Manager