JFPC11.ppt

CP-SST : approche basée sur la programmation
par contraintes pour le test structurel du logiciel

Abdelilah SAKTI, Yann-Gaël Guéhéneuc et Gilles Pesant
Département de Génie Informatique et Génie Logiciel
École Polytechnique de Montréal, Québec, Canada

Le 08 juin 2011,
Septièmes Journées Francophones de
Programmation par Contraintes (JFPC)

Plan

F Introduction
l Approches de test structurel basées PC
l Notre Approche
l Résultats
l Conclusions et travaux futurs

2
CP-SST : approche basée sur la programmation par contraintes pour le test structurel du logiciel A. SAKTI, Y.-G. Guéhéneuc et G. Pesant

Bogues historiques
Ø Le test est une phase très importante dans le cycle de vie
d’un logiciel
ü Coûte plus de 50% du budget d’un logiciel critique.
Ø Quelques catastrophes historiques liées au test logiciel
ü 2010 : La voiture hybride Toyota Prius a fait l’objet d’un rappel pour correction
de 160000 voitures suite à un problème informatique au niveau de l’ordinateur
de bord et du système de contrôle de vitesse.

ü 1996 : le vol 501 a causé la destruction du lanceur Arian 5 juste 40s après
le lancement. L’agence spatiale européenne (ASE) a déclaré un retard du
projet, une perte financière directe estimée de 500 million de dollars, et
indirectement une perte de la confiance des clients au profit de la
concurrence
ü Entre 1985 et 1987 : l’appareil de radiothérapie Therac-25 a causé au
moins cinq décès, et plusieurs autres patients ont été gravement atteints
de radiations. L'appareil envoyait au patient une dose de rayons X 100 fois
supérieure à celle prévue.

3
CP-SST : approche basée sur la programmation par contraintes pour le test structurel du logiciel. A. SAKTI, Y.-G. Guéhéneuc et G. Pesant

Test logiciel
Ø Deux grandes méthodes pour tester un logiciel

Ø Applications du test structurel
ü Analyse de la couverture d’un ensemble
de données de test;

ü Génération des données de test pour
assurer l’exécution d’un ensemble de
chemins
ü Critères de couverture: Tous-les-chemins
(Tous-les-k-chemins), Toutes-les-
branches, Toutes-les-instructions.

ü Atteindre un point donné dans un
programme (générer une exception).

ü Preuve de la post-condition ou
génération du contre-exemple.

4

Exemple d’utilisation du
test structurel
Ø La norme DO-178B
• Utilise différentes applications de test structurel;

• Le test structurel est utilisé pour analyser la couverture de test fonctionnel et
pour générer les cas de test manquants;

• Exige différents critères de couvertures d’analyse et de génération des données
de test;
• Un programme est testé selon sa criticité.

Couverture
Niveau Effet (Criticité)
requise
A Catastrophique MC/DC
B Dangereux branches
C Majeur instructions

5

Plan

l Introduction
F Approches de test structurel basées PC
l Notre Approche
l Résultats

6

Approches de test
structurel basés PC
Ø Approches Orientées Ø Approches Orientées Buts
Chemins
ü Traduisent un PST en un PSC en
ü La technique dominante, consiste à passant par un modèle SSA pour
éviter le coût de l'évaluation
extraire un chemin à partir de GFC ou
d'une version instrumentée du PST, symbolique. (INKA, Euclide, CPBPV)
puis de générer un prédicat de ce
chemin. La résolution de ce prédicat ü inconvénients
génère des données de test
correspondant au chemin choisi. ü Contrairement aux approches orientées
chemins, cette technique identifie
(PathCrawler, Osmose) difficilement des points du PST
nécessaires pour atteindre un critère de
ü inconvénients couverture donné.

ü Le processus de génération de prédicat a
un coût important lié à l'évaluation
symbolique.

ü En général, elle ne peut pas générer des
cas de test pour atteindre un point donné
dans un PST

7

Plan

l Introduction
F Notre Approche
l Résultats

8

Abstraction
1. Instrumentation

2. Mise en forme
SSA

3. Génération du GFC
et PSC préliminaire

4. Génération du
PSC global

5. Résolution du
PSC global
9

Forme SSA

10

Génération du Graphe de
flot de contrôle
• Cinq classes de nœuds du GFC
ü Nœud de Paramètres et variables globales;
ü Nœud d’instruction;
ü Nœud de décision;
ü Nœud de condition;
ü Nœud de jointure.
• Les arrêtes sont étiquettées par 1 ou -1.

11

Relations entre les nœuds
Ø Nœud-Nœud

Ø Nœud de décision multi-
conditions (décomposition)

12

Les nœuds d’une boucle
• Toute boucle du PST doit être transformée en une boucle tant-
que (While).
• Limiter le nombre d'itérations d’une boucle par une constante k
(k-chemin).
ü Une boucle contient k +1 nœuds de décision.
ü Pour forcer le PST à quitter la boucle au maximum après k itérations, le dernier
nœud de décision Ndk+1 doit toujours être différent de la valeur 1.
• Les relations entre les nœuds d’une boucle sont les suivantes:
ü
ü
ü

13

Traduire un GFC en un PSC
(PSC-GFC)
ü Un nœud est traduit par une
variable.
ü Le domaine est l’ensemble
d’étiquettes des arêtes
sortantes et la valeur 0 pour
les non-racine.
ü Une relation nœud-nœud est
traduite par une contrainte
table.
ü Une variable Nfi prennent la
valeur et le domaine de la
décision correspondante.
ü Une relation décision-
conditions est traduite par une
contrainte table.

14

Génération du PSC global
(PSC-G)
ü Deux types de relations entre les Ø Déclaration de variable
nœuds et les instructions.
§ Scalaire ou tableau statique: traduction
§ (1) Nœud-Condition; directe;
§ (2) Nœud-Instruction.
§ Tableau dynamique: déclaration du
tableau et d’une variable qui représente sa
taille.

Ø PSC-G =
PSC-GFC ∧
Relations-Nœud-Condition ∧
Relations-Nœud-Instruction

15

Représentation formule d’un
besoin de test structurel
l Besoins du test structurel
ü Analyse, Génération de données ou preuve d’une post-condition.
l Ensemble objectif de test (EOT)
ü Un besoin du test peut être décomposé en un ensemble d'objectifs partiels
exprimables en termes de nœuds de décision, nœuds de condition ou nœuds
d'instruction.
ü Un objectif partiel est peut être représenté par un ensemble de paires
<variable,valeur>.
l EOT pour quelques mesures de couverture.
ü Couverture de toutes les instructions : chaque objectif partiel est un ensemble
qui contient une seule paire composée d'une variable nœud d'instruction et la
valeur 1.
ü Couverture de toutes les décisions : chaque objectif partiel est un ensemble
singleton qui contient une paire composée d'une variable nœud de décision et la
valeur 1 ou -1.

16

Analyse et génération des
données de test
• Génération des données de test
ü Résoudre PSC-G ∧ Un-objectif-partiel-de-l’EOT à la fois.
ü Si la solution pour un objectif satisfait d'autres objectifs partiels, supprimer ces
objectifs partiels de l'EOT.

• Analyse structurelle
ü Un jeu de données à analyser est représenté par un ensemble de données de test
(EDT) qui contient des vecteurs de test < val1; :::; valn >, où vali est la valeur du
paramètre d'entrée numéro i.
ü Résoudre PSC-G ∧ Un-vecteur-de-données-de-l’EDT à la fois.
ü Si la solution pour un vecteur de données satisfait des objectifs de l’EOT,
supprimer ces objectifs partiels de l'EOT.
ü Si l'EOT devient vide, alors une couverture de 100% est atteinte, sinon générer
des données de test et les chemins qui ne sont pas couverts.

17

Couverture tous les
chemins
• Génération des données de test pour une couverture k-chemins
ü Orienter la rechercher de solution par les variables nœuds de décision (Ndi).
ü Résoudre PSC-G ∧ Heuristique-de-recherche.
ü Une stratégie de recherche a deux niveaux:
§ Niveau 1, l'énumération est faite sur les variables de type nœud de décision ( Ndi),
§ Niveau 2, l’énumération est faite sur les variables qui représentent les paramètres
d'entrée.
§ Une fois qu'une solution est trouvée, le solveur doit faire un retour-arrière vers le premier
niveau.

Niveau 1

Niveau 2

18

Preuve de la postcondition
• Prouver une post-condition
ü Résoudre PSC-G ∧ ⅂ Post-condition
§ Si le problème a une solution, alors il existe un chemin qui viole cette post-condition. La
solution donne le chemin concerné et les données de test pour violer la post-condition.
§ Si non, alors le post-condition est toujours satisfaite.

19

Plan

l Introduction
l Notre Approche
F Résultats

20

Comparaison avec une
approche orientée buts
üComparaison avec une approche orientée buts (Gotlieb et al. 2000)
§ Le programme sous test est trytype;
§ PSC1 est généré manuellement selon l’approche de Gotlieb et al. 2000;
§ PSC2 est généré manuellement selon notre approche.

üSur les douze branches, après cinq minutes d'attente pour
chaque branche, PSC1 n'a pas pu générer des données de test
pour couvrir cinq branches qui représentent 40 % du PST

21

Comparaison avec une
approche orientée chemins
üComparaison avec une approche orientée chemins (PathCrawler)
§ Les programmes sous test sont Merge, Trytype et Sample;

üEn termes de temps d'exécution, notre approche a prouvé son
efficacité en particulier pour les deux derniers programmes (Merge
et Sample) où il est presque cinq fois plus rapide que PathCrawler

22

Comparaison avec
l’algorithme génétique
üComparaison avec AG pour générer des exceptions de type division
par zéro
§ Les programmes sous test sont l’exemple de Tracy et al. , Bogue d’Eclipse et
Bogue d’Android;

üEn termes de temps d'exécution, notre approche est nettement
meilleure que l’algorithme génétique pour ce genre d’exceptions.

23

Preuve d’une post condition
üComparaison avec CPBPV Collavizza et al. pour la preuve d’une post-
condition
§ Le programme sous test est Bsearch.

Taille du tableau 8 16 32 64 128

Bsearch une erreur Notre Approche 0 0 0 0 0
est injectée
CPBPV 2010 0,027 0,037 0,064 0,115 0,241

Notre Approche >300 >300 >300 >300 >300
Bsearch sans erreur
CPBPV 2010 1,08 1,69 4,04 17,01 136,8

üNotre approche peut générer un contre exemple dans un temps
meilleur que celui de la proche de CPBPV, mais elle est incapable
de prouver que le programme ne viole pas la post-condition.

24

Plan

l Introduction
l Notre Approche
l Résultats
F Conclusions et travaux futurs

25

Conclusions
• Une nouvelle approche de test structurel. Il s'agit d'une approche
qui combine les applications de test structurel les plus utilisées;
• La première approche qui regroupe quatre applications de test
structurel et toutes les mesures de couverture structurelle;
• La modélisation d'un PST combiné à son GFC par un PSC
conserve sa sémantique structurelle et peut donc répondre aux
différents besoins de test structurel;
• Notre approche peut être utilisée pour
• Automatiser le processus de test structurel;
• Réduire la taille d'un ensemble de données de test;
• Réduire le temps nécessaire pour tester un système critique.
• Les résultats obtenus prouvent l’efficacité de l’approche proposée.

26

Travaux futurs
• L'implantation d'un outil complet qui mettra en œuvre cette
approche.
• Extension pour dépasser ses limites actuelles
• Les pointeurs;
• Les nombres à virgule flottante;
• Les appels aux fonctions
• Les instructions non structurelles (goto).
• L’application de l’approche sur des programmes de grande
taille.
• Combinaison avec les approches méta-heuristiques.

27

Merci pour votre attention
Questions ?

28

JFPC11.ppt

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Mehr von Ptidej Team

Mehr von Ptidej Team (20)

JFPC11.ppt