Relation entre métriques de code et effort de test

Relation entre métriques de code et effort de test

Les quelques travaux publiés sur le sujet dans la littérature démontrent le lien entre les métriques logicielles et le test logiciel [7, 29-32]. Les métriques logicielles existent depuis l’aube du génie logiciel. Les métriques sont utilisées comme instrument de contrôle dans le processus de développement et de maintenance du logiciel. Par exemple, les métriques ont été proposées pour identifier les emplacements problématiques dans le code source pour mieux effectuer la maintenance [13J. La qualité du produit dépend (en partie) du processus de développement, il est donc évident que les tests logiciels sont une étape importante dans la réalisation des logiciels de grande envergure. Plus le logiciel est grand, plus les efforts à consacrer pour les tests sont importants. De ce fait, la gestion d’allocation des ressources s’avère une tâche aussi lourde qu’importante. Comme mentionné dans les paragraphes précédents, plusieurs travaux ont été réalisés sur la prédiction des fautes logicielles et la prédiction des efforts de test. Mais, au mieux de nos connaissances, l’aspect des valeurs seuils des métriques et leur effet sur leurs capacités de prédiction de l’effort de test n’ont pas été explorés. L’effort à fournir pour tester un logiciel implique d’une manière ou d’une autre l’effort à fournir pour rendre les composants d’un logiciel de bonne qualité. Cette comparaison nous pousse à penser qu’il existe une relation entre les métriques logicielles et l’effort de test. Dans ce contexte, nous présentons certains travaux effectués dans ce sens, du moins dans le sens de la qualité logicielle.

• Satwinder Singh et K. S. Kahlon : Selon ces auteurs, les métriques logicielles jouent un rôle important dans la maintenance et les tests des logiciels. Plusieurs recherches ont démontré que les modèles basés sur les métriques logicielles sont efficaces pour l’analyse de la qualité des logiciels. Pour ces auteurs, la seule valeur d’une métrique n’est pas suffisante, il faut aussi tenir compte de sa valeur seuil [33J.

• Ruchika Malhotra et Ankita Jain Bansal : Pour ces auteurs, les métriques logicielles ont été utilisées pour construire des modèles de prédiction afin d’identifier les composants des logiciels ayant une forte probabilité d’occurrence de fautes. Ils ont considéré l’effet des valeurs seuils des métriques orientées objet sur la propagation des fautes et ont construit des modèles de prédiction basés sur les valeurs seuils des métriques utilisées [26J.

• Raed Shatnawi, WeiLi, James Swain et Tim Newman: Ils ont fait une étude empirique basée sur une relation entre les métriques orientées objet et les catégories de sévérité des erreurs. Ils se sont focalisés sur l’identification des valeurs seuils des métriques logicielles en utilisant les courbes ROC [16J.

• Tiago L. Alves, Chrsitian Ypma et Joost Visser: Ils ont souligné le fait que l’usage effectif des métriques orientées objet est entravé par le manque de seuils significatifs. Selon eux, les valeurs seuils ont été proposées en se basant sur l’opinion d’experts et un petit nombre d’observations. D’où la conception d’une méthode permettant de déterminer empiriquement les seuils de mesure à partir de données de mesure. Les données pour la mesure des différents systèmes logiciels sont regroupées et agrégées. Par la suite, des seuils sont sélectionnés qui (i) font apparaître la variabilité de la métrique entre les systèmes et (ii) permettent de se concentrer sur un pourcentage raisonnable du volume de code source. Leur méthode respecte les distributions et les échelles des métriques de code source et résiste aux valeurs aberrantes en ce qui concerne les métriques ou la taille du système [13, 19, 34J.

Pistes potentielles

Comme nous l’avons mentionné dans la section précédente, les limites relatives aux méthodes évoquées ressortent des études réalisées en utilisant les techniques supervisées (courbes ROC) et non supervisées (Alves Rankings). Dans ce contexte, notre approche consiste en une application des techniques supervisées et non supervisées ainsi que la combinaison de ces techniques avec plusieurs algorithmes d’apprentissage automatique. Raed Shatnawi a présenté un modèle basé sur l’analyse des courbes ROC pour la détermination des valeurs seuils [15]. Ce modèle est déterminé par l’utilisation de deux variables. Il s’agit d’une variable binaire qui consiste en l’existence d’une faute ou non. Dans notre cas, il s’agit de l’existence d ‘un effort important de test ou non. L’autre variable est continue, c’est celle des métriques CK. Cela consiste donc à déterminer l’aire sous la courbe (AUC) qui donne une valeur unique permettant ainsi d’évaluer le pouvoir de discrimination dans la courbe entre les classes contenant les fautes et celles qui n’en contiennent pas. Dans notre cas, il s’agit des classes qui demandent un effort important de test et celles qui n’en demandent pas. La valeur de l’AUC capable de déterminer la valeur seuil optimale des métriques doit être supérieure à 70%.

Mais dans nos expérimentations, nous avons situé la valeur seuil optimale à 60% afin d ‘étendre le nombre des métriques ayant des valeurs seuils valides. Shatnawi dans ses travaux a utilisé la distance euclidienne à partir du point optimal des courbes ROC pour trouver les valeurs seuil optimales. Le modèle de Shatnawi possède également un avantage intéressant qui consiste à utiliser des données débalancées. L’autre piste nous conduit à la méthode proposée par Alves et al. pour la dérivation des valeurs seuil [13]. Cette méthode a été utilisée et nommée Alves Rankings dans les travaux de A. Boucher et M. Badri [19]. Elle a été appliquée pour déterminer les seuils des métriques pour la prédiction des fautes logicielles [19] . En revanche, Alves et al. l’ont initialement utilisée pour la détermination des niveaux de seuil afin de décrire la qualité des classes et de les catégoriser comme bonnes ou moins bonnes. Cette méthode comporte six étapes dans son application init iale, comme l’indique la figure 2.2 [13]. Mais selon les études de cas, certaines étapes peuvent être écartées, c’est le cas de A. Boucher et M. Badri [19] qui ont utilisées l’étape 1,2,3 et 6. La méthode Alves Rankings donne le choix de plusieurs niveaux de pourcentage, notamment 70%, 80% et 90%. Dans notre étude, nous explorerons ces trois niveaux de pourcentage, et nous ajouterons la dérivation des seuils à 30%. Il est évident que cette méthode a été appliquée sur la prédiction des fautes, mais nous l’appliquerons sur la prédiction de l’effort de test.

Alves Rankings

La méthode d’Alves et al. pour calculer les seuils n’avait pas de nom dans le papier original [13, 19]. C’est A. Boucher et M. Badri qui l’ont intitulé Alves Rankings dans leurs travaux [19]. Alves et al. ont défini leur méthode pour trouver des seuils qui décrivent la qualité des classes et enfin les catégoriser. Pour ce faire, ils ont procédé en 6 étapes pour le calcul des seuils [13]. En ce qui nous concerne, nous n’utiliserons que les étapes 1, 2, 3 et 6, jugées pertinentes pour notre étude. La première étape, appelée extraction de métriques, consiste à extraire les métriques du système [13, 19]. Les métriques de code de chaque classe sont calculées à cette étape, mais également le poids de chaque classe [19]. Le poids d ‘une classe est défini par la métrique SLOC (Source Lines Of Code) dans le document d ‘Alves et al.. Pour notre étude, la première étape a consisté à rechercher les ensembles de données que nous avons décidé d’utiliser. La deuxième étape, appelée calcul du rapport de pondération ou ratio de poids, consiste à calculer le rapport de pondération de chaque classe [13]. Ce ratio est calculé simplement en divisant le poids d’une classe (LOC) par la somme des poids de toutes les classes. Le rapport pondéral représente simplement la taille relative de chaque classe du système. Par exemple, si une classe a un rapport de pondération de 0,01, cela signifie que le code de la classe représente 1% du code total du système [19]. La troisième étape, appelée agrégation d’entités, consiste à agréger le poids de toutes les entités (qui sont ici des classes) par des valeurs métriques [13] .

Le résultat de cette étape est semblable à un histogramme pondéré, donnant le pourcentage de code du système représenté par chaque valeur métrique. Par exemple, après cette étape, nous pourrions dire que 1% du LOC d’un système est représenté par une métrique CBO de 6 [19]. Les quatrième et cinquième étapes de la méthode ne sont pas utilisées dans notre étude. Cela est justifié par le fait que Alves et al. ont calculé les seuils utilisant une centaine de systèmes logiciels différents [13]. Dans notre cas, nous voulions calculer pour chaque système une valeur seuil pour chaque mesure de code. Les quatrième et cinquième étapes de la méthode Alves Rankings ont consisté à normaliser les poids de chaque système évalué [19]. Par la suite, ils ont agrégé les valeurs métriques pour ces systèmes, obtenant ainsi un résultat similaire à celui de la troisième étape. La différence est que le pourcentage de chaque métrique représente le pourcentage de code sur tous les systèmes, pas un seul comme dans la troisième étape [19]. La sixième étape de cette méthode, appelée dérivation de seuils, consiste à calculer les valeurs seuils pour chaque classe [19]. Pour ce faire, nous avons défini un pourcentage de code que nous représentons avec nos valeurs seuils. Par exemple, choisir 80% du code global pourrait générer une valeur seuil de 30 pour la métrique CBO [19]. Cela signifierait que 20% du code de mauvaise qualité selon la métrique CBO seraient ciblés par la valeur seuil de 30 [19]. Ces différentes étapes sont décrites à la figure 2.2. Nous avons utilisé des valeurs seuils définies à 30%, 70%, 80% et 90% des distributions de mesure pour nos modèles de prédiction. Toutefois, cette technique a été étudiée pour trouver les seuils des métriques pour la prédiction des fautes [19], mais ne l’a pas été pour la prédiction des efforts de test, moins encore dans une approche basée sur les seuils des métriques et les algorithmes d’apprentissage automatique.