MBT : Model Based Testing

Rhapsody est un logiciel conçu par Télélogic, filliale d'IBM depuis 2008. Telelogic s'est spécialisée dans le développement de solutions d'automatisation. Rhapsody est un logiciel de modélisation basé sur UML. Il propose une approche graphique pour les développeurs de logiciels et les ingénieurs systèmes qui travaillent sur des systèmes ou des applications temps réel ou embarqués. Rhapsody permet de générer un squelette d'une application modélisée dans des langages tels que le C, C++, Ada et Java.

QTronic est un logiciel développé par Conformiq, société finlandaise. QTronic est un outil basé sur Eclipse qui automatise le design des tests fonctionnels pour logiciels et systèmes. La conception d'un modèle est orientée développeur. Le modèle doit être défini en langage cqa (propriétaire). Ce langage est proche du Java. La génération de tests est ouverte sur plusieurs langages mais il faut pour cela, développer le plugin de convertion.

La force de QTronic réside dans sa facilité d'importation de modèles créés sous Rhapsody. Il est alors possible de réutiliser des modèles conçus précédemment.

Voici une application permettant de configurer un usager.

Ci-dessous, la modélisation de celle-ci, sous format graphic et sous format code.

On remarque que le modèle est construit sur les champs que comporte l'application. Associé au modèle, il faut maintenant définir un automate. Pourquoi définir un automate? Car il faut représenter les actions d'un utilisateur sur le système.

Mais un automate, c'est quoi? Il s'agit d'une machine à traiter des informations qui est caractérisée par des états reliés par des transitions. Les états représentent une position, une situation dans le logiciel. La position dans le logiciel va entrainer des vérifications sur celui-ci; chaque état renferme donc des tests. Pour arriver dans cet état, il faut effectuer des actions qui sont représentées par les transitions. Pour résumer, l'automate définit le fonctionnement du système, comment l'utilisateur va s'en servir.

Donc, comme vous l'aurez compris, les méthodes ou fonctions (suivant le langage utilisé), définies dans le modèle sont la base des actions et vérifications ajoutées dans l'automate.

Le parcours d'un automate est donc une étape obligatoire pour générer des tests, mais ce parcours a un coût. Lors de la modélisation, il arrive régulièrement qu'une personne fasse une erreur de conception. Cette erreur peut entrainer la sauvegarde d'un automate non-déterministe et donc un coût exponentiel. Heureusement les outils a disposition sont équipés de détecteur de cycle, ce qui élimine le risque d'attente infinie de résultats.

Les paramètres du modèle défini, l'automate terminé, il est possible de générer les tests. L'ensemble des logiciels de modélisation (du moins les 2 que j'ai utilisé) propose un générateur de tests. Le modèle va alors se substituer au système réel.

Le logiciel de modélisation va vérifier la conformité et la cohérence du modèle et de l'automate. Puis, il va démarrer un serveur. Ce serveur charge le modèle précédemment créé. Le logiciel va parcourir l'automate en envoyant des requêtes au serveur. Ces requêtes sont de type action ou demande d'informations, typiquement les actions programmées dans le modèle. On obtient alors une série d'actions ponctuées de vérification : entrer dans un menu entraine la vérification de cette action.

Cette tâche est de durée variable. Elle oscille entre quelques secondes et plusieurs heures. Cela dépend de la taille du modèle. Plus le modèle est grand plus longue sera la génération. Il n'est donc pas recommandé de créer un modèle trop grand et de bien définir les limites de la modélisation.

Il reste encore à générer les tests dans le langage voulu! Au choix : Java, C, C++, Ada, etc... Les logiciels en proposent souvent plusieurs. La génération est une étape aussi simple que la vérification du modèle.

Mais des problèmes peuvent survenir. Des applications comme QTronic ne fournissent pas de plugin pour convertir les tests en un langage. Il faut alors le créer. La documentation est plus ou moins bien écrite, mais on peut s'en sortir. D'autres logiciels vont créer des tests mais ceux-ci ne sont pas exécutables directement. Il faut effectuer quelques modifications. En effet, les tests générés ne contiennent pas de paramètres ou d'annotations de test tel qu'il est nécessaire en Java avec JUnit ou TestNG. Il convient de modifier le fichier à la main (pas pratique) ou modifier le script qui permet de générer les tests, ce qui est mieux.

Dans le cadre de cet exposé, j'ai créé un script pour transformer les tests générés en tests Java, exécutables avec le framework TestNG plus précisément.

Il faut donc bien faire attention à l'outil que l'on désire utiliser. Bien que les défauts de QTronic soient mis en avant dans les lignes ci-dessus, il est très pratique dès lors que l'on a plusieurs projets ou que l'on cherche à générer des tests dans un langage différent de ceux proposés par les autres outils, car le script est réutilisable.

Les tests générés correctement, il est possible de les exécuter, ou presque. En effet, si on regarde les méthodes (pour le langage Java) utilisées, on remarque que les appels de fonctions réalisés par l'objet correspondent aux noms de fonctions utilisées dans le modèle. De même, l'objet instancié n'est défini nul part. Pour exécuter ces tests, il faut un ensemble de classes appelées harnais.

Un harnais est une librairie qui permet de manipuler et de contrôler le système sous test. Il existe des harnais presque entièrement utilisable, mais en général, il faut modifier ou ajouter des fonctionnalités en utilisant des design pattern adapter ou proxy.

Le harnais est composé de 2 couches (c'est une architecture qui m'est propre et qui mériterait sans doute d'être discutée). Une couche fonctionnelle et une couche métier. La couche fonctionnelle est appelée par le test. Elle contient toutes les méthodes appelées par l'objet instancié, c'est à dire les fonctions qui vont être utilisable sur le modèle. Ce niveau utilise les assertations fournis par les frameworks de test pour vérifier les données reçues par rapport aux données attendues. Pour effectuer les actions, elle se sert de la couche métier. La couche métier est le proxy ou l'adapteur de la librairie. Cela permet de concevoir des manipulations à partir de plusieurs actions simples fournies par la librairie et d'en récupérer les informations nécessaires pour la couche supérieure.

L'exécution des tests va apporter beaucoup de renseignements sur le système sous test, mais aussi sur le modèle. Les résultats des tests vont indiquer la fiabilité du système et du modèle. Il est difficile de savoir si le modèle est conforme au système. Ainsi lors de l'exécution des tests il sera détectable dans les tests non exécutés ou échoués si le modèle respecte le comportement du système attendu. Les tests échoués et omis peuvent signifier que le système sous test est mal développé ou que le modèle est faux par rapport au comportement du logiciel. Le harnais peut également être mis en cause, car il peut aussi contenir des bugs.

Il est assez difficile de déceler une erreur si le suivi des premières phases d'exécution n'est pas effectué. L'automate présenté ci-dessus comporte une erreur qui n'a pu être décelée, et pour cause, c'est au développeur de connaitre le comportement du système final.