THÈse présentée

télécharger 0.65 Mb.

titre	THÈse présentée
page	28/28
date de publication	09.06.2018
taille	0.65 Mb.
type	Thèse

ar.21-bal.com > droit > Thèse

1 ... 20 21 22 23 24 25 26 27 28

6.2Perspectives

6.2.1La génération de test pour le diagnostic

Le diagnostic est l’étape du test qui consiste à localiser et corriger une erreur lorsqu’un cas de test a échoué. L’impact de la stratégie de test choisie sur l’efficacité du diagnostic est largement reconnue. Cependant, très peu de travaux se sont intéressés à quantifier cet impact. Sur ce point, nous avons commencé une nouvelle étude qui, à partir de l’analyse des algorithmes de diagnostic, définit des critères de test pour une localisation efficace des erreurs dans un programme. Nous utilisons ensuite un algorithme bactériologique pour générer automatiquement des cas de test qui vérifient ces critères. Les expériences devraient nous permettre d’étudier l’efficacité des cas de test générés pour la localisation d’erreurs, ainsi que la validité du modèle de diagnosabilité proposé dans cette thèse.

6.2.2Les contrats comme oracle de test

Au cours de cette thèse, nous avons commencé, en collaboration avec une équipe de l’université de Carleton à Ottawa, à étudier certaines propriétés des contrats qui permettraient d’évaluer leur efficacité pour la détection d’erreur. L’idée initiale était de prioritiser les cas de test qui nécessitent un oracle explicite en présence de contrats. En effet, notre idée était d’observer les traces d’exécution des cas de test, et de classer ensuite les cas de test en fonction de la qualité des contrats le long du flot d’exécution de chacun. On obtiendrait alors un ensemble de cas de test qui exécutent des parties du système dans lesquelles les contrats sont faibles (détectent peu d’erreurs), et pour lesquels ils faudrait écrire un oracle explicite. La définition de l’oracle pour les cas de test exécutant des contrats efficaces pourrait être reportée à plus tard. Faute de temps, ces travaux n’ont pas pu aboutir, mais cela semble être une perspective intéressante pour la diminution de l’effort de test (en facilitant l’écriture de la fonction d’oracle).

6.2.3Transformation de modèles pour la testabilité

Globalement, et notre travail a tendu vers cela dans un but préventif, il doit être possible d’accompagner toutes les étapes de raffinement de l’analyse et de la conception en transformant les modèles de telle sorte qu’on évite ou limite une dégradation de la testabilité. Un cas particulier de transformation de modèle dont la testabilité peut être contrôlée concerne les design patterns évoqués ci-après. Dans la mesure où – dans le contexte du mde (Model Driven Enginnering) – on dispose d’un langage de transformation, défini au niveau méta, alors cette technique pourrait être appliquée de façon systématique à toute transformation identifiée et cataloguée. Ainsi, l’ajout de stéréotypes lors de l’application de design patterns serait vue comme une transformation de modèle, et pourrait être automatisée pour rendre les instances de design patterns testables dans un diagramme de classes.

6.2.4Design patterns et test

En forçant la distribution du contrôle à travers plusieurs classes, les design patterns rendent plus difficiles l’expression de contrats locaux à une classe. Un point intéressant pour la suite serait de reprendre l’étude da la rédaction de contrats efficaces dans le cadre d’une conception fondée sur les patterns, et d’explorer les points suivants :

existe-t-il des règles spécifiques pour la rédaction de contrats lors de l’application de design patterns ?
les contrats peuvent-ils être efficaces pour la détection d’erreur lors de l’application de design patterns ?

Annexes

Répartition des contrats dans un système OO

Cette annexe présente le détail de la mesure de la répartition des contrats sur cinq systèmes écrits en JAVA. Ces résultats justifient la validité de l’hypothèse de répartition uniforme des contrats nécessaire au modèle de diagnosabilité définit au chapitre 4.

Ces répartitions ont été obtenues en utilisant l’outil JTracor.

Figure 83 – Répartition des contrats dans une classe List

Figure 84 – Répartition des contrats dans un serveur de réunion virtuelle

Figure 85 – Répartition des contrats dans la suite de tests de JUnit

Figure 86 – Répartition des contrats dans le JDK

Figure 87 – Répartition des contrats dans Jtree

Interactions d’objets pour le gestionnaire de livres

Nous présentons ici les traces d’exécution ainsi que les graphes de relations entre objets (obtenus avec Jtracor) pour les cas de test TC1 et TC3 da la section 5.3.4. JTracor est un framework pour tracer l’exécution de programmes Java, dont nous donnons ici les résultats sous forme textuelle et sous forme de diagrammes d’objets. Cet outil nous a permis d’exhiber deux interactions d’objets, qui rendent l’implantation de ce système peu testable d’après notre critère (section 5.3). Nous commençons par exhiber une interaction d’auto-utilisation effective, puis une interaction d’objets. Enfin, nous donnons les résultats de JTracor sur un autre cas de test qui couvre une interaction plus complexe que les deux premières

AU1

Cette section résume les traces d’exécution pour le cas de test TC1, qui teste l’interaction d’auto-utilisation AU1 de Book vers elle-même à travers BookEvent, dans le gestionnaire de livres.

Cas de test TC1 :

public void testManageEvent(){

Book b = new Book();

b.manageEvent(“setDamaged”);//the trace is produced from this call

}

Trace textuelle pour TC1 :

| | | | | |->SetDamaged@76.execute

| | | | | | |->Book@82.setDamaged

Diagramme d’objets pour TC1:

AU2

Cette section résume les traces d’exécution pour le cas de test TC3, qui teste l’interaction de classes AU1 entre BookEvent et Book par deux chemins différents (un direct et un autre passant à travers BookState), dans le gestionnaire de livres.

Cas de test :

public void testManageEvent(){

Book b = new Book(); //the book is in the ordered state

b.manageEvent(“deliver”); //puts the book in the available state

b.manageEvent(“borrow”); //the trace is produced from this call

}
Trace textuelle pour TC3:

| | | | | |->Borrow@72.execute

| | | | | | |->Book@82.getCurrent_state

| | | | | | |->Available@81.borrow

| | | | | | | |->Borrowed@86.

| | | | | | | | |->Book_State@86.

| | | | | | | |->Book@82.setCurrent_state
Diagrammes d’objets pour TC3:

IC(BookEvent, Book)

Nous détaillons ici un cas de test plus complexe qui couvre l’interaction de classes entre BookEvent et Book : un des chemins passe à travers Available, Reserved et BookState.

Cas de test :

public void testManageEvent(){

Book b = new Book(); //the book is in the ordered state

b.manageEvent(“reserve”); // the trace is produced from this call

}
Trace textuelle :

| | | | | |->Reserve@66.execute

| | | | | | |->Book@82.getCurrent_state

| | | | | | |->Available@81.reserve

| | | | | | | |->Reserved@87.

| | | | | | | | |->InLibrary@87.

| | | | | | | | | |->Book_State@87.

| | | | | | | |->Book@82.setCurrent_state

| | | | | | | |->Book_State@81.reserve

| | | | | | | | |->Book@82.inc_nb_res

Diagramme d’objets :

Glossaire

Algorithme évolutionniste : extension d’un algorithme génétique pour inclure les systèmes de classification et la programmation génétique où chaque solution est un programme.

Algorithme génétique : modèle computationnel de la résolution de problème fondé sur les principes de la génétique et les mécanismes de la génétique.

Assertion : prédicat ou combinaison de prédicats.

Cas de test : procédure qui permet d’exécuter le programme sous test avec une donnée de test.

Client : un composant C_i est client d’un composant C_j s’il utilise les services de C_j (i.e. si C_i a un attribut, une variable locale ou un paramètre de méthode de type C_j).

Composant autotestable : composant logiciel dans lequel sont regroupés son implantation, une spécification sous forme de contrats exécutables, et un ensemble de cas de test.

Conception par contrat : méthodologie de conception pour des systèmes orientés objet qui consiste à définir qui consiste à définir les devoirs et obligations des éléments du système. Trois types principaux d’assertions peuvent être définis : des pré et post conditions sont pour les méthodes, et un invariant pour les classes. La précondition définit la condition légale pour utiliser une méthode. La postcondition définit les propriétés du résultat fourni par la méthode. Un invariant définit des propriétés qui doivent vérifiées l’état de l’objet avant et après chaque appel de méthode.

Couplage : mesure la force de la relation entre deux modules, i.e. des classes dans le cas des modèles orientés objet.

Critère de test : critère qui doit être vérifié par des cas de test sur un programme sous test. Par exemple, couverture des chemins, couverture des prédicats, score de mutation…

Défaillance: événement survenant lorsque le service délivré dévie de l’accomplissement de la fonction du système.

Design Pattern : un design pattern représente une solution aux problèmes qui surgissent quand un logiciel est développé dans un contexte particulier. Les design patterns peuvent être considérés en tant que microarchitectures réutilisables qui contribuent à une architecture du système globale; ils saisissent les structures dynamiques et statiques et les collaborations entre les principaux participants du modèle de conception.

Délégation : mécanisme de programmation objet qui consiste, pour un objet, à déléguer tout ou partie du traitement d’une méthode à un autre objet.

Diagnosabilité : mesure de l’effort pour le diagnostic d’un programme.

Diagnostic : localisation et correction d’une faute lorsqu’un cas de test a échoué.

Donnée de test : donnée en entrée pour exécuter un programme sous test.

Double renvoi : double mécanisme de délégation.

Driver de test : programme qui exécute les cas de test sur le programme à tester, et qui sauvegarde les verdicts pour chaque cas de test.

Erreur: partie de l’état d’un système qui est susceptible d’entraîner une défaillance.

Faute: cause adjugée ou supposée d’une erreur.

Framework : Un framework est un ensemble de classes et de collaborations entre les instances de ces classes

.

OCL : Object Constraint Language. Langage d’assertions pour l’expression de contraintes sur un modèle UML.

Oracle : une fonction d’oracle calcule la valeur attendue comme résultat d’un programme en fonction des données en entrée.

Orienté objets (conception) : la conception objet a pour but de préparer l’implantation d’un programme dans un langage orienté objet.

Polymorphisme : le fait qu’une référence puisse pointer sur des objets de types différents au cours de l’exécution.

Robustesse : La robustesse d’un composant est définie comme la capacité de ce composant à fonctionner même dans des conditions anormales. La robustesse peut aussi être vue comme la probabilité qu’une erreur soit détectée et traitée par un mécanisme d’exception sachant qu’une défaillance se produit certainement sinon.

Testabilité : La testabilité est un facteur de qualité, défini comme la facilité à tester un logiciel. La testabilité se dérive en trois attributs :

le coût global de test : le coût global pour obtenir des cas de test vérifiant un critère de test donné
la contrôlabilité : la facilité pour générer des données de test efficaces (propriété intrinsèque au logiciel sous test)
l’observabilité : la facilité avec laquelle il est possible de vérifier la pertinence des résultats obtenus après l’exécution des cas de test

Test de logiciel : il existe deux grandes catégories de test logiciel :

le test dynamique qui consiste à exécuter des cas de test sur un programme et vérifier si la valeur obtenue est conforme à la valeur attendue.

le test statique qui observe les propriétés statiques d’un programme pour détecter des fautes.

UML : Unified Modelling Language. Langage graphique pour la conception de logiciels, en particulier des logiciels orientés objet.

Verdict de test : un cas de test passe si la valeur obtenue après exécution du cas de test est conforme à l’oracle, sinon il échoue.

Bibliographie