Test Structurel de programmes C

1
Test Structurel de programmes C à l'aide de la
programmation logique avec contraintes (PLC)
test dintégration

• Karim-Cyril Griche
• LSR/IMAG

2
Plan de la présentation

• Introduction
• Choix et objectifs
• Orientation prise modélisation de fonctions
• Comment modéliser?
• Analyse des fonctions appelantes
• Perspectives

3
Introduction

• Projet RNTL Inka en partenariat avec Thalès
  Systèmes Aéroportés, LIFC, I3S, Axlog
• Outil Inka
• Issu de la thèse de Arnaud Gotlieb
• Test structurel unitaire de programme C en
  utilisant la PLC
• Extension de Inka au test dintégration
• Extension aux flottants (I3S)
• Extension aux pointeurs (LIFC)

4
Outil Inka

• Fonctionnement
• Traduit un programme en un ensemble de clauses
  prolog (Sicstus)
• Réduit cet ensemble de clauses
• Génère des tests visant la couverture

Programme C
Équivalent Prolog
Ensemble réduit
Cas de test
Inka
5
Test unitaire

• Test unitaire on remplace les appels de
  fonctions par des bouchons

But couverture structurelle de f()
- On doit passer dans la branche THEN du
if...then...else
Condition résultat de g() négatif
- On crée un bouchon bg() qui rend une
valeur négative quelle que soit la valeur de y
6
Extension au test dintégration

• Intégration on remplace les bouchons par les
  véritables fonctions
• Problème Les véritables fonctions ne se
  comportent pas comme les bouchons

Lintégration de g() pour la couverture
structurelle de f() empêche le passage dans la
branche THEN du if...then...else

• Détecter les nouveaux chemins impossibles au plus
  tôt
• Mauvais bouchons ? erreurs dexécution
  potentielles ou
• masquage derreurs présentes

7
Étude bibliographique

• Rares publications
• Essentiellement des méthodologies dintégration
  portant sur lordre dintégration des fonctions
  dans le logiciel

8
Cadre de lintégration dans Inka

• Le test dintégration avec Inka seffectue sur un
  ensemble de fonctions complet formant un
  sous-système dun logiciel
• Pas de notion dordre dintégration
• Objectifs couverture structurelle

9
Problématique

• Ce sous-système est représenté sous forme de
  contraintes
• Inka traduit une fonction C en un ensemble de
  contraintes
• Un appel de fonction est traduit en un appel à la
  clause représentant la fonction
• Explosion du nombre de contraintes à traiter si
  le nombre dappel de fonctions est trop grand

10
Objectifs

• Trouver un moyen de  passer à léchelle 
• Modéliser les fonctions appelées de manière
  réduite
• Définir des modèles réalistes
• Moins complexes que les fonctions originales
• Équivalents vis à vis des besoins du test
  (génération de données)

11
Orientation Spécialisation de fonctions

• Modèles de fonctions optimisés fonctions
  originales spécialisées pour leur utilisation
  dans le test
• Techniques étudiées
• Interprétation abstraite
• Calcul dinvariants
• Slicing intra-procédural
• Découpe dune fonction
• Evaluation partielle
• Spécialisation de fonctions
• Approches heuristiques

12
Construction des modèles

• 2 critères Un modèle doit
• être plus simple que les fonctions originales
• Disposer dun modèle exact de chacune des
  fonctions
• 2ème critère nous a amené à une architecture où
  les approximations se superposent

13
Plan de la présentation

• Introduction
• Choix et objectifs
• Orientation prise modélisation de fonctions
• Comment modéliser?
• Analyse des fonctions appelantes
• Perspectives

14
Heuristiques

• Gestion des appels de fonctions
• Étude de simplification de fonctions basée sur
  lélimination de chemins compliqués

15
Gestion des appels de fonctions

• Un appel de fonction clause représentant la
  fonction
• les appels de fonctions sont traités
  naturellement
• - Mise à plat du système sous test lors de
  lintégration
• Idée Opérateur de gestion des appels de
  fonctions
• Limitation de la profondeur de mise à plat
• Développé et en cours dévaluation/calibrage

16
Gestion des appels de fonctions
f
g
h
k
i
j
17
Heuristique poids sur les branches

• Idée éliminer les branches définies comme
  complexes
• Définir un poids pour chaque opération/fonction
  et pondérer les branches/chemins dune fonction
• Introduire un mécanisme de préférence des
  branches à faible poids
• Quand cest possible, utiliser la branche avec le
  poids le plus faible

18
Poids sur les branches
Poids faible
Poids très fort
19
Plan de la présentation

• Introduction
• Choix et objectifs
• Orientation prise modélisation de fonctions
• Comment modéliser?
• Analyse des fonctions appelantes
• Perspectives

20
Analyse des fonctions appelantes

• 3 possibilités
• 1. Un modèle par fonction.
• 2. Un modèle par fonction et par fonction
  appelante.
• 3. Un modèle par fonction appelée et par appel
  dans la fonction appelante.

21
Un modèle par fonction

• On remplace tous les appels du sous-système par
  un appel au modèle
• rapidité de construction
• - modèles moins optimisés

22
Un modèle par fonction et par fonction appelante

• On remplace tous les appels à g() dans f() par
  des appels à mg()
• existe un contexte du modèle
• - modèle général

23
Un modèle par fonction appelée et par appel dans
la fonction appelante

• Chaque appel de fonction est remplacé par un
  appel au modèle de la fonction pour cet appel.
• modèles plus optimisés, contexte précis
• - nombre de modèles

24
Un modèle par fonction appelée et par appel dans
la fonction appelante
25
Contexte dutilisation

• Besoin dinformation Contexte dutilisation
• Contexte dun appel de fonction donné par la
  fonction appelante
• Contexte dutilisation défini en 2 parties
• Contexte dappel Information sur les domaines
  des variables dentrée de la fonction
• Objectifs de génération Information sur
  lutilisation faite des résultats de lappel à la
  fonction et notamment des branchements qui en
  dépendent

26
Un contexte dappel

• Un contexte dappel est formé par lensemble des
  
• chemins depuis le début de f() jusqu à lappel à
  g()
• Il peut être représenté par un ensemble de
  contraintes

27
Un objectif de génération
Obj. Gen. Notre modèle doit pouvoir produire
des sorties lt2 et dautres gt2 si cest possible
Int f(int x) ... If (g(y)gt2) ...
else ...
28
Perspectives

• Le contexte dappel
• Point de départ au calcul dun invariant sur
  domaines de sortie
• Utiliser une technique inspirée de lévaluation
  partielle pour éliminer certaines parties dune
  fonction
• Les objectifs de génération
• Envisager le  slice  dune fonction connaissant
  lutilisation qui doit en être faite

29
Travaux en cours et perspectives

• Premières expérimentations concluantes
• Définition des poids des heuristiques
  délimination de chemins compliqués et évaluation
• Prototype implémentant les différentes méthodes
  pour évaluer leurs résultats