Validations CPVV sur les versions du Système ANT

ÉTAT DE L’ART

La suggestion des composants candidats au test est un sujet qui a été exploré sous beaucoup d’angles et au cours de nombreuses études. Dans leur article, Toure et al. [11,12] ont étudié une approche basée sur l’historique des informations logicielles pour supporter la priorisation des classes à tester. Pour atteindre cet objectif, ils ont d’abord analysé différents attributs de dix systèmes logiciels open source, écrits en Java, pour lesquels des scénarios de tests unitaires JUnit ont été développés pour plusieurs classes. Premièrement, par une analyse de la moyenne et la régression logistique, ils ont identifié les classes pour lesquelles des classes de test JUnit ont été développées par les testeurs. Deuxièmement, ils ont utilisé deux classificateurs entraînés sur les valeurs de métriques et les informations de tests unitaires collectées à partir des systèmes sélectionnés. Ces classificateurs fournissent, pour chaque logiciel, un ensemble de classes sur lesquelles les efforts de tests unitaires doivent être concentrés. Les ensembles obtenus ont été comparés aux ensembles de classes pour lesquels des classes de test JUnit ont été développées par les testeurs. Les résultats montrent que: (1) les valeurs moyennes des métriques des classes testées identifiées sont très différentes des valeurs moyennes des métriques des autres classes, (2) les attributs d’une classe influencent la décision de développer ou non une classe de test JUnit dédiée à celle-ci, et (3) les ensembles de classes suggérées par les classificateurs reflètent assez correctement la sélection des testeurs. Yu et al. [32] ont proposé une technique de priorisation des cas de test basée sur les fautes. Cette technique qui utilise directement les connaissances théoriques sur leur capacité à détecter les fautes. La technique est basée sur les relations entre les cas de test et les fautes logicielles.

Lazié L. et al. [33] ont utilisé des algorithmes Naïve Bayes, et des algorithmes génétiques à différents niveaux de granularité pour mettre en oeuvre leurs approches de priorisation. Les résultats ont montré que l’utilisation de ces algorithmes permet une amélioration du taux de détection de fautes. Rothermel et al. [34] ont comparé neuf techniques de hiérarchisation des cas de test basées sur la hiérarchisation aléatoire, la hiérarchisation de la couverture et la détection des défaillances. Les résultats obtenus donnent un aperçu des compromis parmi diverses techniques de hiérarchisation des cas de test. Dans la comparaison des stratégies de priorisation, Rothermel et al. [34] ont utilisé plusieurs techniques de priorisation comme mentionnées plus haut. Parmi lesquelles, quatre techniques ciblent le taux de couverture à différents niveaux du programme: (l) la couverture totale des branches est une technique de priorisation qui consiste à trier les cas de test (après instrumentation du code) dans un ordre qui maximise le nombre total de branches couvertes, (2) la couverture incrémentale des branches qui consiste à chaque itération du tri, à sélectionner le cas de test qui couvre une nouvelle branche du flux, (3) la couverture totale des contrôles, et (4) la couverture incrémentale des contrôles. Les deux dernières techniques sont similaires aux deux précédentes stratégies à la différence qu’elles ciblent les contrôles et non les branches dans le programme. Après avoir été appliquées sur huit systèmes, les quatre techniques démontrent des performances similaires aux techniques ciblant directement l’optimisation du taux de fautes.

Dans les techniques basées sur la couverture, l’ obj ectif principal est d’exécuter des suites de test couvrant la plupart des artefacts logiciels modifiés lors des tests de régression. Cet objectif conduit à une amélioration du taux de détection des fautes. Des algorithmes plus complexes ont été proposés par Mirarab et al. [35]. Les auteurs ont utilisé les réseaux bayésiens pour créer un modèle unifié basé sur les informations fournies par les métriques de CK [13], les changements et les taux de couverture. L’approche ainsi définie, optimise la couverture et améliore le taux de détection des fautes par rapport à la planification aléatoire des scénarios de test. Pour optimiser les tests de régression, Wong et al. [36] suggèrent une des premières stratégies de priorisation dans la suite de tests de régression. Elle optimise le facteur « coût par taux de couverture (des branches ayant subi le changement) ». Les auteurs se focalisent sur la priorisation d’un sous-ensemble de cas de test d’une suite de tests par la technique du Safe Regression Selection. Les cas de test qui touchent les zones modifiées sont sélectionnés et placés en tête de file, les autres cas sont placés à la suite dans l’ordre d’exécution. L’objectif est d’optimiser le rapport entre le coût et le taux de couverture, mais aussi vise globalement à couvrir les zones ayant subi des changements en priorité. Cette technique est un simple algorithme gourmand et itératif qui cherche à couvrir le plus de branches de code ayant subi le plus de changements.

LIRE AUSSI :  Analyse et conception d’une application informatique de gestion

Métriques d ‘héritage DIT : (Depth of Inheritance Tree)

Calcule la profondeur de l’héritage. Cette métrique de la suite CK [13] compte le nombre de classes qu’il y a entre la classe mesurée et la racine de sa hiérarchie d’héritage. Elle évalue la complexité de la classe mesurée, mais aussi la complexité de la conception de la classe. En effet, le comportement d’une classe étant plus difficile à comprendre quand le nombre de méthodes héritées augmente. Avec plus de classes héritées, la conception et la redéfinition des comportements deviennent plus délicates. Par ailleurs, cette métrique mesure aussi le niveau de réutilisation du code des classes dans la hiérarchie d’héritage. Plus une classe est profonde dans la hiérarchie, moins elle est générique.

NOC: (Number of Children) Le nombre d’enfants ou de descendants d’une classe. Calcule le nombre de sous-classes qui héritent de la classe mesurée. Cette métrique appartient à la suite CK [13]. Elle compte le nombre de classes immédiatement dérivées de la classe concernée. NOC reflète (théoriquement) l’impact potentiel d’une classe sur ses descendants. NOC évalue aussi le niveau de réutilisabilité de la classe dans la mesure où une classe ayant plusieurs enfants (classes dérivées) est souvent très générique. Cependant, un très grand nombre de dérivations directes est signe de mauvaise conception et d’une abstraction impropre [13]. Théoriquement, le nombre de dérivations directes impacte fortement la hiérarchie des classes et peut nécessiter un effort de test particulier pour la classe en question.

Table des matières

REMERCIEMENTS
RESUME
ABSTRACT
TABLE DES MATIERES
LISTE DES TABLEAUX
LISTE DES FIGURES
Chapitre 1 INTRODUCTION
1.1 Introduction
1.2 Contexte
1.3 Problématique
1.4 Objectif
Chapitre2 ETAT DE L’ART
Chapitre 3 COLLECTE DE DONNÉES ET MÉTHODES D’ANALySE
3.1 Les Systèmes logiciels
3.1.1 Apache ANT
3.2 Les métriques
3.2.1 Métriques de couplage
3.2.2 Métriques d’héritage
3.2.3 Métrique de cohésion
3.2.4 Métriques de complexité
3.2.5 Métriques de taille
3.3 Outils de collecte de données
3.3.1 Granularité méthodes
3.3.2 Granularité lignes de codes
3.3.3 Couverture selon le profil opérationnel
3.4 Méthode de collecte des données
3.5 Statistiques descriptives
3.5.1 Système POl
3.5.2 Système ANT
Chapitre 4 MÉTHODE EXPÉRIMENTALE
4.1 Le modèle d’apprentissage profond
4.1.1 Apprentissage supervisé
4.1 2 L,’ apprentIssage non supervIse . ,
4.1.3 L’apprentissage automatique par renforcement
4.2 Le Réseau de Neurones artificiels
4.2.1 Présentation générale
4.2.2 Les couches du perceptron
4.2.3 Le neurone
4.2.4 La règle delta
4.2.5 Le minimum global
4.3 Construction du Réseau de neurones
4.3.1 La fonction d’activation
4.3.2 L’optimiseur
4.3.3 La fonction perte
4.4 Évaluation et Validation du classificateuf
4.4.1 Évaluation
4.4.2 Validation du classificateuf
Chapitre 5 RÉSULTATS ET INTERPRÉTATIONS
5.1 CVV Validation
5.1.1 Validation sur le système POI
5.1.2 Validations CVV sur les versions du Système ANT
5.1.3 Conclusion partielle
5.2 CPVV Validation
5.2.1 Validations sur le système POl
5.2.2 Validations CPVV sur les versions du Système ANT
5.2.3 Conclusion partielle
5.3 Validation CSPVV Validation
5.3.1 Validation sur les versions du système POI
5.3.2 Validations sur les versions du Système ANT
5.3.3 Conclusion partielle
5.4 LOSOV Validation
5.4.1 Résultats obtenus après validation sur le système ANT
5.4.2 Résultats obtenus après validation sur le système POI
5.4.3 Conclusion partielle
5.5 Limitations
Chapitre 6 CONCLUSION GÉNÉRALE
Chapitre 7 RÉFÉRENCES BIBLIOGRAPHIQUES.

Cours gratuitTélécharger le document complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *