L’efficacité des modèles de test pour garantir leur capacité à révéler des erreurs, est essentielle pour la qualité d’une transformation. Dans ce chapitre, nous avons étudié l’analyse de mutation pour qualifier un ensemble de modèles de test.
L’utilisation de cette technique dans un nouveau contexte impose la définition de nouveaux modèles de fautes sous la forme d’opérateurs de mutation. Ainsi, nous avons proposé des opérateurs de mutation pour le test de transformations de modèles. Cependant, contrairement aux approches classiques, nous n’avons pas défini ces opérateurs en fonction de la syntaxe d’un langage de transformation, même si plusieurs nouveaux langages dédiés aux transformations de modèles ont été développés. La première raison vient justement de la nouveauté de ces langages : ils sont nombreux et aucun consensus n’a encore été trouvé dans la communauté IDM. La seule norme existante (QVT) définit elle-même non pas un mais trois langages dans différents paradigmes. La deuxième raison est le niveau auquel nous considérons les transformations : leurs spécificités sont essentiellement dues aux opérations qu’elles réalisent sur des modèles en se basant sur leurs méta-modèles. C’est ainsi que nous avons défini dix opérateurs de mutation au niveau sémantique des opérations abstraites réalisées par une transformation de modèles.
Dans un second temps, nous avons étudié la diminution de la part des activités manuelles du processus de l’analyse. En particulier, nous proposons de minimiser le nombre de modèles de test pour réduire l’effort dans la construction d’oracle (étudié dans le chapitre suivant).
Finalement, nous avons expérimenté ces opérateurs pour la qualification de modèles de test pour la transformation class2rdbms. Nous avons réalisé ces expériences avec le langage de transformations de modèles Kermeta. A l’avenir, si un langage de transformation était adopté dans la communauté, il serait envisageable de définir un mapping des opérateurs sémantiques vers la syntaxe de ce langage.
4
Oracles de transformations de modèles
L’oracle produit le verdict d’un cas de test. Contrairement à ce que suggère son nom, l’oracle n’est pas restreint à la prédiction du résultat attendu. Il vérifie si la « transformation d’un modèle de test » est correcte en analysant le modèle de sortie produit. Il analyse des modèles de sortie sur la base des modèles de test et d’informations extraites de la spécification de la transformation. Le verdict peut être partiel si les vérifications réalisées ne portent pas sur tous les éléments du modèle analysé ou si une seule partie de la spécification est considérée.La construction d’oracle est une tâche difficile pour le test de logiciel. Cette difficulté est particulièrement présente pour le test de transformations de modèles. D’une part, les modèles de sortie analysés sont des structures de données complexes pouvant être assimilées à des graphes d’objets. D’autre part, les paramètres considérés pour les vérifications sont aussi de nature complexe. Ils comprennent le domaine de sortie (défini dans nos études par un méta- modèle et des contraintes), le modèle de test utilisé, et des informations extraites de la spécification. Cette extraction d’informations est une étape critique dans la construction de l’oracle. Elle ne peut être réalisée automatiquement (en particulier quand la spécification est textuelle).
L’oracle utilisé pour le test de logiciel est généralement une fonction qui compare le résultat obtenu au résultat attendu en sortie. Nous retrouvons cette approche dans différentes études, dont certaines portent sur le test de transformations de modèles [Heckel'03]. Dans ce contexte, le résultat attendu est un modèle appartenant au domaine de sortie de la transformation. Certains travaux [Lin'07] transposent ainsi le problème de l’oracle en un problème de comparaison de modèles. Cependant, spécifier le résultat attendu est extrêmement complexe quand il s’agit d’un modèle. Même si cette approche doit être prise en compte, il est trop restrictif de considérer l’oracle sous ce seul angle. Plusieurs autres techniques peuvent être envisagées pour obtenir un verdict : nous étudions ces alternatives pour les qualifier et mettre en avant les plus appropriées pour le test de transformations de modèles.
Dans cette section, nous proposons six fonctions d’oracle différentes. Elles varient selon le nature de l’information qu’elles exploitent et que nous nommons « donnée d’oracle ». Le modèle attendu ne constitue qu’une seule sorte de donnée d’oracle parmi d’autres. En fournissant des transformations, des contraintes, des modèles, ou des patterns à différentes
fonctions d’oracle, nous définissons des oracles qui n’ont pas les mêmes propriétés et qui ne nécessitent pas le même travail d’extraction d’informations de la spécification.
Nous étudions les propriétés de ces fonctions pour les évaluer suivant deux critères qualitatifs. Le premier critère lié à la complexité, est le risque d’introduire des erreurs dans la fonction d’oracle. Ces fonctions d’oracles analysent des modèles complexes, ce qui implique un grand nombre de vérifications de propriétés et accroit le risque d’erreur (error-proneness) dans la définition de l’oracle. Le second critère est la réutilisabilité de l’oracle dans différents cas de test et lorsque la transformation de modèles évolue. Dans le but principal de qualifier chaque fonction d’oracle selon ces deux qualités, nous évaluons différentes propriétés caractérisant chacune des fonctions proposées dans ce chapitre.
Notre analyse va montrer que les oracles qui réalisent des vérifications partielles sont de meilleure qualité. En effet, l’utilisation d’un oracle dédié à une vérification particulière sur un modèle précis simplifie sa définition et permet sa réutilisation. En revanche, l’emploi d’un seul oracle pour vérifier la transformation de n’importe quel modèle de test entraîne une complexité importante et peu de réutilisabilité. Pour une intégration cohérente du test au développement dirigé par les modèles, nous montrons dans cette section que les oracles doivent pouvoir être modularisés, chaque module assurant des vérifications partielles.
Dans la section 4.1, nous présentons la problématique de l’oracle pour le test de transformation de modèles. Dans la section 4.2, nous proposons six fonctions d’oracle différentes qui exploitent différentes données d’oracle. Dans la section 4.3, nous traitons la construction de données d’oracle avec l’exemple class2rdbms. Dans la section 4.4, nous introduisons les qualités que nous voulons évaluer et les propriétés d’un oracle qui influencent sa qualification. Dans la section 4.5, nous comparons ces fonctions selon leur risque d’erreurs, ainsi que sur leur réutilisabilité.