THÈse présentée








télécharger 0.65 Mb.
titreTHÈse présentée
page8/28
date de publication09.06.2018
taille0.65 Mb.
typeThèse
ar.21-bal.com > droit > Thèse
1   ...   4   5   6   7   8   9   10   11   ...   28

2.6Testabilité et mesures pour les logiciels OO


La testabilité, que nous étudions pour un assemblage de composants au chapitre 5, est à la frontière de deux domaines. D'une part, elle est liée aux problèmes de test en évaluant l'effort requis pour examiner un logiciel. D'autre part, la testabilité est une mesure. Ainsi, cette section présente les travaux existants sur l’aspect mesure de la testabilité, et introduit certains travaux plus généraux sur la mesure des logiciels OO.

La mesure de testabilité est un critère de qualité qui évalue, à partir de caractéristiques structurelles d’un programme, l’effort nécessaire pour le tester. Cette mesure peut être définie ainsi :

Testabilité. La testabilité est un facteur de qualité, défini comme la facilité à tester un logiciel. Cette facilité est à la fois une propriété intrinsèque du schéma de conception (et donc une caractéristique propre au produit étudié) et une propriété relative à la stratégie de test adoptée pour vérifier un critère de test particulier. 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

De manière générale, la testabilité vise deux choses : un but technique pour un concepteur et un but de gestion de projet. Pour le concepteur du logiciel c’est un indicateur qui permet, dés les premières phases de la conception, d’identifier les systèmes qui peuvent devenir difficiles à tester. Pour le chef de projet, cette mesure permet de trouver un compromis en terme de coûts parmi différentes solutions fondées sur diverses conceptions et techniques de test.

Quel que soit le facteur de qualité observé, voici deux exemples d’informations que le concepteur peut espérer obtenir :

  • localisation des points délicats dans la conception où le facteur peut avoir une valeur faible, et où l’architecture doit être améliorée

  • détection des changements inadaptés (raffinements, évolutions) qui peuvent mener à une variation non désirée de ce facteur

L’objectif du test de logiciel n’est pas seulement de couvrir et exécuter chaque partie du logiciel mais aussi de révéler des fautes cachées. De ce point de vue, les notions de contrôlabilité et d’observabilité d’un composant logiciel, introduites par Freedman [Freedman''91], sont complémentaires du coût de test. Par exemple, la contrôlabilité est relative au rapport entre la taille du domaine des données de sortie et celle du domaine des données en entrée du logiciel. Cependant, son approche ne prend pas en compte la difficulté qu’il y a à exécuter un composant et à propager l’erreur jusqu’à la sortie du logiciel. Cette limite a été analysée en détails par Voas [Voas''92b; Voas''95] au niveau du code du composant. Plusieurs mesures ont été proposées pour évaluer la perte d’information dés la conception, telles que le Domain/Range Ratio de Voas [Voas''93] pour les programmes impératifs ou la mesure de contrôlabilité/observabilité pour les architectures flots de données [Le Traon''97; Le Traon''00b]. Weide et al. [Weide''96] ont défini l’observabilité et la contrôlabilité des types de données abstraits pour une meilleure réutilisation des composants logiciels. Quant à la mesure de la contrôlabilité et l’observabilité dans les programmes OO, aucune approche satisfaisante n’a été proposée.

En ce qui concerne l’étude de testabilité présentée au chapitre 5 de cette thèse, nous nous concentrons sur la mesure du coût global de test.

Coût global de test. Ce facteur évalue le coût nécessaire à la vérification d’un critère de test donné. Cette mesure est relative à la taille de l’ensemble de cas de test, à la difficulté de trouver des données de test pour vérifier le critère ainsi qu’à la difficulté d’évaluer la valeur d’oracle.

A propos des mesures du coût global de test, Bieman et Schultz [Bieman''89] ont compté combien de cas de test sont nécessaires pour vérifier le critère de couverture de tous les chemins définition-utilisation[Rapps''85]. Il existe de nombreuses mesures pour les architectures OO (e.g. [Chidamber''94; Shepperd''98]), mais la testabilité n’est jamais mesurée directement. Cependant, elle peut être évaluée à partir de la mesure de couplage sous l’hypothèse qu’un fort couplage dans une architecture OO entraîne une diminution de la testabilité. Le couplage mesure la force de la relation entre deux modules, i.e. des classes dans le cas des modèles orientés objet. Un grand nombre de mesures de couplage ont été proposées, chacune correspondant à un type de relations entre les classes. Dans [Briand''99], les auteurs proposent un classement des mesures de couplage pour des éléments de conception UML précis. La mesure de couplage entre objets (CBO) [Shyam''94; Briand''99] correspond à un ensemble de classes qui emploient chacune l'autre. Dans le diagramme de classes UML, on dit qu'une classe a emploie une autre classe b s'il existe une association ou une dépendance entre ces classes. La mesure CBO est discutée en termes de testabilité dans [Binder''94], et des critères de test pour ce type de relations parmi les classes sont proposés dans [Alexander''00]. Ces travaux se concentrent sur chaque chemin indépendamment et visent le comptage/couverture.

Dans le chapitre 5, nous nous concentrons sur des chemins particuliers dans le diagramme de classes, ainsi qu’à la complexité des interactions décrites par ces chemins (due au polymorphisme et à la liaison dynamique). À notre connaissance, la contribution précise à la testabilité de chaque dépendance participant au couplage n'a jamais été étudiée, particulièrement dans le cas de logiciels conçus en utilisant UML. Le but de l’analyse de testabilité proposée est donc plus d'indiquer les rôles des liens participants au couplage que de limiter le nombre de tels liens.
1   ...   4   5   6   7   8   9   10   11   ...   28

similaire:

THÈse présentée iconThèse Présentée à la Faculté de Pharmacie de Montpellier

THÈse présentée iconThèse présentée pour l’obtention du grade de Docteur

THÈse présentée iconThèse soutenue publiquement par Sang-Ha suh le 10 Juillet 2006
«avec projection», de cette thèse aux membres du Conseil scientifique et à leurs expliquer pourquoi cette thèse ne devait pas être...

THÈse présentée iconThèse soutenue publiquement par Sang-Ha S. le 10 Juillet 2006 Le...
«avec projection», de cette thèse aux membres du Conseil scientifique et à leurs expliquer pourquoi cette thèse ne méritait pas d’être...

THÈse présentée iconQuestionnaire sur les Cathédrales Quelle est le nom de la cathédrale...

THÈse présentée iconCommuniqué de presse
«L’homme et la matièRE» de Don Darby que l’année prenait son envol. L’exposition est présentée à la Salle Principale du cne jusqu’au...

THÈse présentée iconCatégorie de Grand Prix présentée (cocher la case correspondante)
«Les Grands Prix simi immobilier de Bureaux» du 17 juin au Vendredi 7 octobre 2016

THÈse présentée iconThèse

THÈse présentée iconCommuniqué de presse
«Komuna Fundamento» présentée lors de la xiiie exposition internationale d’architecture «Common Ground» qui se déroule dans le cadre...

THÈse présentée iconAutomne 2013 plan de cours
«Unified», combinée à l'apprentissage du langage uml, est présentée et mise en pratique dans un projet de conception et d'implantation...








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com