LE PROJET INKA B.Botella Thalès Systèmes Aeroportés

Présentation au sujet: "LE PROJET INKA B.Botella Thalès Systèmes Aeroportés"— Transcription de la présentation:

1 LE PROJET INKA B.Botella Thalès Systèmes Aeroportés
Objectifs : Logiciel INKA générateur automatique de cas de test structurel pour C et C++ 5 partenaires : THALES SA AXLOG Ingénierie I3S - Université de Nice Sophia Antipolis LIFC - Université de Franche Comté LSR - Université de Grenoble Durée : 24 mois (01/ > 01/2003)

2 Cycle en V Validation en vol Validation sur banc Validation Globale
Conception Codage Test Unitaires (et d’Intégration) Tests du Logiciel / Fonction opérationnelle Exigences Modèle UML

3 Test fonctionnel : basé sur l’étude des spécifications
Stratégies de test Test fonctionnel : basé sur l’étude des spécifications Sorties Cas de test Test structurel : basé sur l ’analyse du programme Cas de test Sorties

4 (faire i fois l ’addition de j) return k ; } --> OK
Functional testing prod(int i,int j ) { int k ; if( i==2 ) k := i << 1 else (faire i fois l ’addition de j) return k ; } Specification : returns the product of i by j (i = 0, j = 0) --> 0 (i = 10, j = 100) -->1000 … --> OK

5 Structural testing is indispensable !
prod(int i,int j ) { int k ; if( i==2 ) k := i << 1 else (faire i fois l ’addition de j) return k ; } Specification : returns the product of i by j (i = 0, j = 0) --> 0 (i = 10, j = 100) --> 1000 Undetected fault by functional testing patch -> k := j << 1

6 Graphe de flot de contrôle
f( int i ) { j := ... if( Condition1 ) if( Condition2 ) return j }

7 Graphe de flot de contrôle
f( int i ) { j := ... if( Condition1 ) if( Condition2 ) return j } 1 v f

8 Graphe de flot de contrôle
f( int i ) { j := ... if( Condition1 ) if( Condition2 ) return j } 1 v f 2

9 Graphe de flot de contrôle
f( int i ) { j := ... if( Condition1 ) if( Condition2 ) return j } 1 v f 2 3 v f 4 5

10 Test Structurel Couvrir au moins toutes les branches (Modified Conditions Decision Criterium ) Tache difficile et pénible Automatisation => Gain de temps et d ’argent

11 Génération « manuelle » de cas de test : exemple
f( int i ) { j := 2 if( i  16 ) j := j * i if( j > 8) j := 0 return j } 1 t f 2 3 t valeur du paramètre i ? f 4 A test data for this program = a value for i Usually, we dispose of a first set of functional test data For example, here the value i = 0 and i = 100 which follow the paths 1235 and 135 in the program dessin de la couverture des 2 chemins Nevertheless, some points in the graph or statement in the program remain uncovered -- for example node 4 In order to obtain a complete coverage, we have to generate a test datum which go through node 4. This problem requires to analyse not only the structure but also the statements and the data Even manually, this problem requires a tricky analysis and doing so automatically is a well-known undecidable problem called the automatic test data genetaion problem 5

12 f( int i ) { j := 2 if( i  16 ) j := j * i if( j > 8) j := 0 return j } J > 8 supposons I > 16 I > 16 => J = 2 or J > 8 --> impossible soit I > 16 soit I 16 --> I  16 (I  16) => J = 2 * I or J > 8 et I  16 --> 4 < I  16 choix : I = 5 valeur de i ?

13 Principe Transformer le programme à tester en un système de contraintes. Utiliser la programmation par contraintes pour poser et résoudre des objectifs de test

14 Programme à contraintes
Principe Technique Entrees Sorties + Point sélectionné Programme à contraintes Entrées Requête 1 2

15 i := i + 1 i2 = i1 + 1 Modélisation d ’une affectation Inconnue : i0
j0 = 2 if( i0  16 ) j1 = j0 * i0 j2 = j1 else j2 = j0 if( j2 > 8) j3 = 0 j3 = j2 r = j3 Inconnue : r f( int i ) { j := 2 if( i  16 ) j := j * i if( j > 8) j := 0 return j }

16  Cond => j1 = j0* i0  j2 = j1  Cond => j2 = j0
Modélisation d ’une condition if( Cond ) 1 j1 = j0* i0 j2 = j1 j2 = j0 2 3  Cond => j1 = j0* i0  j2 = j  Cond => j2 = j0  (j1 = j0* i0  j2 = j1 ) => ( Cond  j2 = j0 )  (j2 = j0 ) => ( Cond  j1 = j0* i0  j2 = j1)

17 j2 > 8 => j3 = 0 Système de contraintes Inconnue : i0 j0 = 2
if( i0  16 ) j1 = j0 * i0 j2 = j1 else j2 = j0 if( j2 > 8) j3 = 0 j3 = j2 r = j3 Inconnue : r Inconnue : i0 j0 = 2 i0  16 => (j1 = j0 * i0  j2 = j1) i0 > 16 => j2 = j0 (j1 = j0* i0  j2 = j1 ) => (i0 > 16  j2 = j0) (j2 = j0 ) => (i0  16  j1 = j0* i0  j2 = j1) j2 > 8 => j3 = 0 j2  8 => j3 = j2  (j3 = 0) => (j2  8  j3 = j2)  (j3 = j2) => (j2 > 8  j3 = 0) r = j3 Inconnue : r

18 i0 = 18 r = 2 i0 = 4 r = 8 impossible r = 12 2  r  8 1  i0  4
Exploitation du système de contraintes Inconnue : i0 j0 = 2 i0  16 => (j1 = j0 * i0  j2 = j1) i0 > 16 => j2 = j0 (j1 = j0* i0  j2 = j1 ) => (i0 > 16  j2 = j0) (j2 = j0 ) => (i0  16  j1 = j0* i0  j2 = j1) j2 > 8 => j3 = 0 j2  8 => j3 = j2  (j3 = 0) => (j2  8  j3 = j2)  (j3 = j2) => (j2 > 8  j3 = 0) r = j3 Inconnue : r i0 = 18 r = 2 i0 = 4 r = 8 impossible r = 12 2  r  8 1  i0  4

19 Utilisation des dépendances de contrôle [Ferrante et al. TOPLAS’87]
Sélection d’un point Utilisation des dépendances de contrôle [Ferrante et al. TOPLAS’87] = ensemble de conditions à vérifier Condition4  Condition2  Condition1  Contraintes issues du Programme CLP Condition1 2 v Condition2 3 v Condition3 4 v f 5 6 7 Condition4 v f 8

20 f( int i ) { j := 2 if( i  16 ) j := j * i if( j > 8) j := 0
Génération de cas de test f( int i ) { j := 2 if( i  16 ) j := j * i if( j > 8) j := 0 return j } Inconnue : i0 j0 = 2 i0  16 => (j1 = j0 * i0  j2 = j1) i0 > 16 => j2 = j0 (j1 = j0* i0  j2 = j1 ) => (i0 > 16  j2 = j0) (j2 = j0 ) => (i0  16  j1 = j0* i0  j2 = j1) j2 > 8 => j3 = 0 j2  8 => j3 = j2  (j3 = 0) => (j2  8  j3 = j2)  (j3 = j2) => (j2 > 8  j3 = 0) r = j3 Inconnue : r J2 > 8 4 < i0  16

21 Projet INKA : Historique
1995 : Début de la Recherche sur les extensions du produit d’exécution de test DEVISOR ( Dassault Electronique) 1996 : Génération automatique de cas de test, basée sur l’utilisation de la Programmation par Contraintes [GL96] 1998 : Premier prototype pour C-, publications [ISSTA98, CL00] 2000 : Soutenance Thèse Arnaud Gotlieb 2000 : Labelisation RNTL pour industrialiser ces résultats

22 sp5 : Management (Thalès)
InKa : sous-projets sp5 : Management (Thalès) sp1 : Industrialisation (Axlog, Thalès) sp3 : extension aux structures dynamiques (LIFC, Thalès) sp4 : extension au test d ’integration (LSR, Thalès) sp2 : extension aux flottants (I3S, Thalès)

23 Industrialisation : Version V1
traite le langage C les types « entiers » les pointeurs sans allocation dynamique les structures, les tableaux visualisation de la couverture génération pour toutes_les_instructions , toutes_les_branches expression de contraintes sur les données de tests gestion des bouchons interface : import/export de jeux de tests au format XML …. UNE DEMO ! The main expected result of the project is to dispose of a product for the language C and C++. The devlopment and validation of the product will be made in 2 stages : First the devlopment of a version called V0 which will consist to industrialize the prototype as it is. This version will be devoted to Unit testing and will handle a restricted subset of the C++ language only. A validation period will then arose. It will consist to use the product to test an Airborne system software provided by Detexis. Available in 12/2001 Second the devlopment of a version V1 of the product designed to unit but also integration testing. This version will benefit from the results of the Research works done by our academic partners and will not be restricted. This version will be validated by an application provided by Axlog, our industrial partner. Available in 12/2002

24 Extension aux flottants (problématique)
Extension aux flottants (problématique) I3S (Michel Rueher, Claude Michel), TSA x := a + b < > X = A + B calcul approximé < > résolution exacte X in [Xi,Xs], A in [Ai,As], B in [Bi,Bs] X <- A + B A <- X - B (fausse) B<- X - A (fausse) on ne peut pas utiliser directement un solveur sur les réels

25 Extension aux flottants (résultats)
FP-Box-consistance : utilisation heuristique des algos de consistance sur les réels FP-2B-consistance : adaptation spécifique de la consistance de bornes aux cas des flottants (étude des fonctions de projections directes et inverses pour les opérations arithmétiques et de conversion)

26 1 variable du programme <-------> 1 var log pour chaque modif.
Extension aux structures dynamiques (problématique) LIFC (Legeard, Bouquet, Ambert, Gaspari, Parreaux) TSA 1 variable du programme < > 1 var log pour chaque modif. Si modif via pointeur < > var logique ? i:=i+1; > I2=I1 +1 *p := 3; > (*p)1=3 (impact sur i ?) j:= i + 2; > J1 = I? + 2 Ajout de contraintes gardées reposant sur l ’analyse statique des relations de pointage : p pointe_vers i -> I3=3 ; I3=I2 p pointe_vers k -> K1=3; K1=K0 …

27 Extension aux structures dynamiques (résultats)
Introduction d ’inconnues représentant un état de la mémoire = (ensemble de couples Adresse-Valeur) Définition d ’une couche de contrainte intermédiaire (ajout, accès, maj) sur ces états i:=i > acces(ad(i),M1,I1) I2 = I1 + 1 maj(M2,M1,ad(i),I2) *p:= > acces(ad(p),M2,P1) EP1 = 3 maj(M3,M2,P1,EP1), j:=i > acces(ad(i),M3,I3), J4 = I3 + 2 maj(M4,M3,ad(j),J4)

28 comment éviter l ’explosion d ’INKA?
Extension au test d’intégration (problématique) LSR (Ioannis Parissis, Karim-Cyril Griche) TSA Test unitaire des fonctions de haut niveau en utilisant le code des fonctions de niveau inférieur comment éviter l ’explosion d ’INKA?

29 Extension au test d’intégration (résultats)
1/ Utilisation du contexte d ’appel pour simplifier la fonction appelée 2/ Création automatique de modèles partiels d ’une fonction, Affectation de poids caractéristiques du coût à ces modèles, Utilisation successive de ces modèles (à partir du moins coûteux) 3/Paramètrage du solveur d ’INKA pour limiter l ’utilisation du modèle d ’une fonction appelée lors de l ’évaluation des contraintes if et while

30 Poursuite du développement d ’INKA
Développement de la version V2 en cours intégration des extensions flottants et pointeurs prise en compte de C++ (sauf aspects dynamiques, templates,..) critère MC/DC ...

31 Autres applications de la modélisation du programme en contraintes
Projet DANOCOPS (label RNTL 2002) : Détection automatique de Non-Conformités Programme-Spécification Automatic Metamorphic Testing, Gotlieb & Botella COMPSAC ’03

32 Système de contraintes
Le projet DANOCOPS Programme Système de contraintes InKa Spécifications Λ Confrontation

33 S(Invavant) Λ S(F) Λ ¬S(Invaprès)
Danocops : Exemple Non-conformité d ’une méthode vis à vis d’un invariant Soit un invariant Inv sur la classe C, Soit une méthode F de la classe C, On recherche : S(Invavant) Λ S(F) Λ ¬S(Invaprès) Trois possibilités : Échoue  pas de défaut Réussit  cas de défaut Time Out  ne sait pas S(Invavant) Λ S(F) Λ S(Invaprès) Trois possibilités : Échoue  que des défauts Réussit  cas normal Time Out  ne sait pas ET

34 Exemple commutativité des entrées : min(X,Y) = min(Y,X)
Automatic Metamorphic Testing Pas d ’oracle Connaissance de propriétés du programme vis à vis de ses entrées Exemple commutativité des entrées : min(X,Y) = min(Y,X) Metamorphic Testing : choisir X et Y et vérifier la propriété. Automatic Metamorphic Testing Chercher X et Y tels que {R=min(X,Y) , R1=min(Y,X), R<>R1} Echoue -> la propriété est vérifiée Reussit -> cas de test provoquant une erreur dans le programme

35 INKA : A comparison function trityp
Jtest / C++test Parasoft : 63 % in 30s Inka prototype : 100% in 3s (random generation : 86% in 30s)

36 Succès sur les sommets difficiles à atteindre
Temps requis pour générer un cas de test Temps CPU (sec) +5h 15 Programme Trityp.c Aléatoire 10 5 InKa Numéro sommet Succès sur les sommets difficiles à atteindre