Approches d’analyse de la testabilité selon les techniques de test

Indéniablement, la testabilité est liée à l’objectif visé par le test d’un système. Lorsqu’elle est

évaluée à partir des critères externes du système, elle peut être considérée comme une approche

purement fonctionnelle comme le test. Par ailleurs, l’évaluation de la testabilité à partir des

critères internes du système ne peut pas forcement se réduire à une analyse purement

structurelle comme le test. En effet, elle peut prendre en compte les flots de données traversant

le système (qui sont étroitement liés avec les fonctionnalités du système) en plus de l’analyse de

la structure de contrôle du système.

Deux grandes techniques ou méthodes peuvent s’appliquer pour la génération de données

de test : le test structurel (boîte blanche) et le test fonctionnel (boîte noire). Pour chaque

technique de test, nous présentons les approches d’évaluation de testabilité appropriées qui ont

été proposées dans la littérature.

Test structurel et approches d’analyse de testabilité

Le test structurel consiste à se baser sur la connaissance de la structure interne du

programme sous test pour générer des données de test et définir des critères d’arrêt. Cette

technique de test présuppose que l’on dispose du code source du programme et non pas

seulement de son interface ou de sa spécification. La plupart des techniques de génération de

test structurelles se basent sur une abstraction du programme qui est ensuite couverte selon des

critères. Les modèles utilisés sont par exemple les graphes de flot de contrôle [Bei90] ou les

graphes de flot de données [Rap85] et sont couverts par des critères de couverture des arcs, des

1.4. Test et testabilité 31

nœuds, ou des chemins du graphe. Les outils de génération de données de test tels que GaTeL

[Mar00, Mar04] et AuGuSTe [Gou04] sont utilisés dans un contexte de test structurel.

Quelques approches d’analyse de testabilité basées sur la structure interne d’un programme

ont été proposées et sont brièvement exposées ci-dessous.

Nombre cyclomatique

Cette approche mathématique a été proposée par McCabe [McC76]. Elle permet d’identifier

les modules ou composants du logiciel qui sont difficiles à tester ou à maintenir. La complexité

d’un composant est évaluée en termes de chemins élémentaires qui, une fois combinés

permettent de générer tous les chemins possibles contenus dans le composant. Le nombre de

chemins élémentaires est en fait le nombre maximum de circuits linéairement indépendants, le

nombre cyclomatique. Myers [Mye77] et Sheppard [She88] ont notamment contribué à

l’amélioration de cette approche qui ne s’applique qu’aux programmes impératifs.

NPATH

Nejmeh [Nej88] pense qu’en dehors des facteurs (tels que la conception modulaire et la

taille du domaine d’entrée) qui affectent la testabilité du logiciel, un facteur important est le

nombre de chemins traversant les composants. En d’autres termes, les composants ayant plus de

chemins d’exécution sont plus difficiles à tester que les composants qui en ont moins. Dans ce

contexte McCabe et Nejmeh partagent le même point de vue qui est : la détermination du

nombre de chemins d’exécution dans un composant. Cependant, Nejmeh propose une autre

approche prenant en compte certains critiques liées à la méthode de calcul du nombre de

chemins de l’approche de McCabe et applicable à d’autres types de programmation.

PIE : Propagation – Infection – Execution

Voas a proposé une technique dynamique appelée PIE (Propagation – Infection – Execution)

[Voa91, Voa92, Voa95a, Voa96]. Cette technique permet d’estimer de manière probabiliste la

testabilité d’un programme en se basant sur la structure et la sémantique du programme. La

probabilité calculée correspond à celle qu’une faute contenue dans une instruction cause une

défaillance du programme sous une distribution des entrées spécifiées. Cette probabilité est

appelée la « sensibilité » d’une instruction dans le programme. La testabilité du programme est

donc mesurée au sens de la sensibilité dans toutes les instructions.

Approches de testabilité basées sur les flots de données

De nombreuses approches d’évaluation de la testabilité basées sur les flots de données,

telles que [Ovi80, Tai84, Mun93, Tan98], ont été proposées pour estimer la complexité, la

32 Chapitre 1. Etat de l’art

difficulté de compréhension et le test d’un logiciel. Les travaux d’Oviedo nous semblent aborder

la difficulté du test logiciel [Ovi80]. L’approche proposée se base sur les relations entre les

définitions et les utilisations des variables d’un programme. Cette approche, assez simple,

montre l’effort du test basé sur le flot de données. Par ailleurs, elle n’est qu’une mesure

complémentaire avec d’autres mesures, comme celles basées sur le flot de contrôle.

Le Traon [LeT95a, LeT95b, LeT97] et Do [Do06] proposent d’analyser la testabilité de

spécification flot de données de systèmes réactifs. L’approche se base sur l’analyse du transfert

d’information travers le logiciel. Elle propose des mesures calculées à partir de l’évaluation de la

perte d’information dans le système.

Test fonctionnel et approches d’analyse de la testabilité

Le test fonctionnel consiste à considérer le système comme une boîte noire dont on ne

connaît que les spécifications. Pour la génération de données de test, ces spécifications sont la

plupart du temps exprimées de manière la plus formelle possible. Le test fonctionnel ne prend

pas en compte la structure du programme, et les tests générés sont ainsi indépendants de

l’implantation du programme sous test, ce qui n’est pas le cas pour le test structurel. Il est ainsi

possible de réappliquer les mêmes données de test à la suite d’une modification du système qui

ne remet pas en cause sa spécification. Dans ce contexte, les tests de non régression peuvent être

effectués afin de vérifier que les modifications n’ont pas introduit d’erreurs. Lutess [Par96] et

Lurette/Lucky [Ray98] sont par exemple des outils de générations de données utilisés dans un

contexte de test fonctionnels.

Des approches d’analyse de testabilité basées sur les spécifications du système ont été

proposées et sont exposées ci-dessous.

Testabilité de domaine

Freedman a introduit la notion de domaine de testabilité d’un composant en termes de

propriété d’observabilité et de contrôlabilité [Fre91]. Un composant devient observable lorsqu’il

produit des sorties distinctes depuis des entrées distinctes. De la même manière, un composant

est contrôlable si le domaine de sortie spécifié est égal au domaine de sortie produit par le

composant. Enfin, un composant est domaine-testable lorsqu’il est observable et contrôlable.

Cette approche ne peut pas être appliquée aux systèmes réactifs pour deux principales raisons.

La première raison est que les composants des systèmes réactifs contiennent souvent des états,

ils ne sont donc pas souvent observables. Et la modification d’un composant avec états afin qu’il

devienne observable est difficile et parfois impossible. La seconde raison est la complexité des

systèmes réactifs qui rend l’étude de domaines contrôlables très difficile.

1.4. Test et testabilité 33

DRR : Domain/Range Ratio

Partant de l’observation que les fautes logicielles affectant rarement des sorties causent des

problèmes dans la mise au point des logiciels, Voas et Miller proposent d’étudier les fautes

cachées du logiciel pour mettre en évidence les parties (ou composants) les plus douteuses

[Voa93a]. Notamment lors de la phase de conception des logiciels critiques, les auteurs pensent

qu’ont peut isoler les composants susceptibles de cacher des fautes. Cela peut d’une part réduire

l’effort de test et d’autre part renforcer la sûreté de fonctionnement du logiciel. Cette approche

propose une métrique qui exhibe les composants ayant une tendance à cacher des fautes.

Le « rapport domaine/image » (DRR – domain/range ratio), dérivable depuis la spécification

du composant, est un rapport entre la cardinalité du domaine d’entrée et la cardinalité du

domaine de sortie (image des entrées). Cette métrique ne dépend que du nombre de valeurs du

domaine d’entrée et du domaine de sortie d’un composant. Pour les auteurs, l’approche du DRR

se place parmi les facteurs qui déterminent si un composant semble cacher des fautes dans le

sens où : lorsque le DRR d’un composant est très élevé, alors il cache très probablement des

fautes.

Cependant, dans le domaine logiciel, les domaines des entrées et des sorties peuvent ne pas

être dénombrables. Il devient alors difficile d’appliquer l’approche du DRR. De plus, cette

métrique est assez simpliste, puisqu’elle ne procède pas à l’analyse de chaque paramètre

d’entrée et de sortie du composant. A titre d’exemple, pour un composant avec une entrée de

type entier et une sortie de type entier, le DRR est (∞ : ∞) ; pour un autre composant avec dix

entrées de type entier et une sortie de type entier, le DRR est aussi (∞ : ∞). On peut regretter

que ces deux composants soient qualifiés dans la même testabilité.

Dans le document Contribution à l'analyse de testabilité des systèmes réactifs temps-réel : Aide à la validation et à la vérification de systèmes (Page 31-34)