Software testing

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.

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.

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.