Test fonctionnel - Exercice 1

 Supposons que nous élaborions un compilateur pour

le langage BASIC. Un extrait des spécifications
précise :
« L ’instruction FOR n ’accepte qu ’un seul paramètre en
tant que variable auxiliaire. Son nom ne doit pas
dépasser deux caractères non blancs; Après le signe =
est précisée aussi une borne supérieure et une borne
inférieure. Les bornes sont des entiers positifs et on place
entre eux le mot-clé TO. »

 Déterminer par analyse partitionnelle des domaines

des données d ’entrée les cas de test à produire pour
l ’instruction FOR.
Méthodes de test fonctionnel - Correction
Exercice 1
 DT obtenues par analyse partitionnelle pour l ’instruction
FOR :
– FOR A=1 TO 10 cas nominal
– FOR A=10 TO 10 égalité des bornes
– FOR AA=2 TO 7 deux caractères pour la variable
– FOR A, B=1 TO 8 Erreur - deux variables
– FOR ABC=1 TO 10 Erreur - trois caractères pour la variable
– FOR I=10 TO 5 Erreur - Borne sup < Borne inf
– FOR =1 TO 5 Erreur - variable manquante
– FOR I=0.5 TO 2 Erreur - Borne inf décimale
– FOR I=1 TO 10.5 Erreur - Borne sup décimale
– FOR I=7 10 Erreur - TO manquant
 Méthodes de test fonctionnel- Exercice 2
 Considérons les spécifications suivantes :

« Ecrire un programme statistique analysant un fichier comprenant les noms et les

notes des étudiants d ’une année universitaire. Ce fichier se compose au
maximum de 100 champs. Chaque champ comprend le nom de chaque étudiant
(20 caractères), son sexe (1 caractère) et ses notes dans 5 matières (entiers
compris entre 0 et 20). Le but du programme est de :
– calculer la moyenne pour chaque étudiant,
– calculer la moyenne générale (par sexe et par matière),
– calculer le nombre d ’étudiants qui ont réussi (moyenne supérieure à 10) »

 Déterminer par une approche aux limites les cas de test

à produire pour cette spécification
Méthodes de test fonctionnel - Correction
Exercice 2
 DT obtenues par test aux limites pour l ’exemple Etudiants :
– passage d ’un fichier vide, puis comprenant 1 champ, 99, 100 et 101 (
5 tests différents, la valeur -1 n ’ayant pas de sens dans ce cas);
– inclure un nom d ’étudiant vide, un nom avec des caractères de
contrôle, un nom avec 19, puis 20, puis 21 caractères;
– inclure un code sexe vide, puis avec un caractère faux (C par exemple);
– avoir un étudiant sans aucune note et un avec plus de 5 notes;
– pour certains champs, les notes ne doivent pas être des nombres
entiers, mais des caractères, des réels avec plusieurs décimales, des
nombres négatifs ou des nombres entiers supérieurs à 20.
 Les DT aux limites doivent être passées indépendamment :
les erreurs peuvent se compenser.
 1.1 Méthode pour le test combinatoire
 Les combinaisons de valeurs de domaines d’entrée
donne lieu a explosion combinatoire
 Exemple : Options d’une boite de dialogue MS Word

 212 * 3 (nombre d’item dans le menu déroulant) = 12 288

 Test combinatoire : approche Pairwise
 Tester un fragment des combinaisons de valeurs qui
garantissent que chaque combinaison de 2 variables
est testé
 Exemple : 4 variables avec 3 valeurs possibles chacune

OS Réseau Imprimante Application

Toutes les combinaisons : 81
XP IP HP35 Word
Toutes les paires : 9
Linux Wifi Canon900 Excel

Mac X Bluetooth Canon-EX Pwpoint

Pairwise testing
 9 cas de test : chaque combinaison de 2 valeurs est testée
OS Réseau Imprimante Application
Case 1 XP ATM Canon-EX Pwpoint
Case 2 Mac X IP HP35 Pwpoint
Case 3 Mac X Wifi Canon-EX Word
Case 4 XP IP Canon900 Word
Case 5 XP Wifi HP35 Excel
Case 6 Linux ATM HP35 Word
Case 7 Linux IP Canon-EX Excel
Case 8 Mac X ATM Canon900 Excel
Case 9 Linux Wifi Canon900 Pwpoint

L’idée sous-jacente : la majorité des fautes sont

détectées par des combinaisons de 2 valeurs de variables
Test combinatoire
 L’approche Pairwise se décline avec des triplets, des
quadruplets, …. mais le nombre de tests augmente très
vite
 Une dizaine d’outils permette de calculer les
combinaisons en Pairwise (ou n-valeurs) :
– http://www.pairwise.org/default.html
– Prise en charge des exclusions entre valeurs des domaines et
des combinaison déjà testée
– Exemple : outil Pro Test
 Problème du Pairwise :
– le choix de la combinaison de valeurs n’est peut-être pas celle
qui détecte le bug …
– Le résultat attendu de chaque test doit être fournis manuellement
1.2 Test aléatoire ou statistique
 Principe : utilisation d ’une fonction de calcul
pour sélectionner les DT :
– fonction aléatoire : choix aléatoire dans le domaine de la
donnée d ’entrée,
– utilisation d ’une loi statistique sur le domaine.
 Exemples :
– Echantillonnage de 5 en 5 pour une donnée d ’entrée
représentant une distance,
– Utilisation d ’une loi de Gauss pour une donnée représentant
la taille des individus,
– ...
Evaluation du test aléatoire

 Intérêts de l ’approche statistique :

– facilement automatisable pour la sélection des cas de test,
(plus difficile pour le résultat attendu)
– objectivité des DT.

 Inconvénients :
– fonctionnement en aveugle,
– difficultés de produire des comportements très spécifiques.
Productivité du test aléatoire ou statistique

% de Test déterministe
satisfaction
d ’un
objectif
Test aléatoire

Effort

Les études montrent que le test statistique permet d ’atteindre

rapidement 50 % de l ’objectif de test mais qu ’il a tendance
à plafonner ensuite.
2-4– Génération automatique de tests à
partir de spécifications

 Test à partir de modèles (Model-Based Testing)

 Modéliser pour tester

 Stratégies de génération

 Sélection des tests – Critères de couverture

 Exemple d’outils : LEIRIOS Test Generator

 Etudes de cas
odel-Based Testing

Test à partir de modèle dans le cycle de vie

 Test boîte noire

Analyse de besoins
Déploiement
-
Génération
Spécifications automatique
de tests Test Fonctionnel
Modèle

fonctionnel
Modélisation Test Système
Architecture

Conception Test d’Intégration

Implementati Modules
on test
Model-Based Testing

Application du test boite-noire

Unitaire Intégration Système Conformité

 Le test boite-noire peut s’appliquer au différent niveau

de remontée du cycle en V
 le modèle utilisé pour la génération sera adapté au niveau testé
(module, sous-système ou système) et aux objectifs de test
Model-Based Testing

Process du test à partir de modèles

Modélisation Spécifications
Techniques
de Besoins
Modèle formel
StateCharts,B,UML,
…
Génération de Développement
Test

Cas de test
générés
Génération de
scripts
Scripts de Validatio
Implémentation
tests n
exécutables
Model-Based Testing

Model Based Test Generation

Modèle formel

Ensemble de
Générate Cas de tests
ur de
Directives
tests • séquence de stimuli
de
• résultats attendus
génératio
n

 Directives de génération (définition d’un scénario de tests) :

– Critères de couverture du modèle
– Critères de sélection sur le modèle
odel-Based Testing

Composition d’un cas de test

 Un cas de test généré se décompose en quatre parties:

– Préambule : séquence des stimuli depuis l’état initial jusqu’à
un état recherché pour réalisé le test,
– Corps : appel des stimuli testé
– Identification : appel d’opérations d’observation pour
consolider l’oracle (facultatif)
– Postambule : chemin de retour vers l’état initial ou un état
connu permettant d’enchaîner automatiquement les tests

Préambule Corps Identification Postambule

Model-Based Testing

Model-Based Testing : Technologie émergente

 De nombreux travaux de recherche depuis 10 ans :
– Comment simuler l’exécution des spécifications ?
– Quels critères de couverture du modèle ?
– Comment maîtriser l’explosion combinatoire ?
– Comment assurer la liaison en les tests générés à partir du
modèle et l’environnement d’exécution des tests ?
– Quelle modélisation des spécifications fonctionnelles dans
le contexte de la génération de tests ?
 De nombreux centres actifs
LIFC Microsoft Research CEA
IBM Haifa LSR
Univ. Twente/Nijmegen Ac. Sc. St Petersbourg
IRISA
Univ. Munich Verimag MIT
2-4- Génération automatique de tests à partir
de spécifications
 Test à partir de modèles (Model-Based Testing)
 Modéliser pour tester
 Modéliser les spécifications fonctionnelles
 Besoins en modélisation dans le contexte de la génération de tests
 Choix de notation
 Stratégies de génération
 Sélection des tests – Critères de couverture
 LEIRIOS Test Generator
 Etudes de cas
odéliser pour tester

Modéliser les spécifications fonctionnelles

 Modéliser les objets et les comportements attendus du système

Modélisation
Diagramme
d’activités

Diagramme
Spécifications d’états
fonctionnelles

Modèle fonctionnel
Modéliser pour tester

La modélisation des spécifications est une tendance

lourde du développement de logiciels

 Modéliser les spécifications :

– Valider l’expression de besoins
» Inspecter le modèle
» Vérifier le modèle
» Animer / simuler le modèle
– Documenter
– Générer les tests
Besoins ≠
– Générer le code

Model-Driven Development
Modéliser pour tester

Modéliser pour tester : le besoin (1)

 Modèle abstrait
– modèle fonctionnel (et non modèle d’architecture
et/ou d’implémentation)
 Modèle détaillé et précis
– Le modèle doit permettre de calculer les cas de test et les
résultats attendus
 établir automatiquement le verdict de test
 Modèle validé et vérifié
– Si le verdict de test « Fail » : l’erreur est-elle dans
l’implantation ou dans le modèle ?
Le test à partir de modèle confronte deux points de vue
Modéliser pour tester

Modéliser pour tester : le besoin (2)

 Modèle adapté aux objectifs de test
– Plus le modèle intègre d’informations inutiles par rapport aux objectifs de
tests, plus cela génère de « bruit » en génération de tests
 Modèle tenant compte des points de contrôle
et d’observation du système sous test

Génération
des tests

Génération
des scripts
Modèle fonctionnel Banc de test
Modéliser pour tester

Notations de modélisation
 De nombreux paradigmes
– Systèmes de transitions (Etats / Transitions / Evénements)
» Flow Charts
» Data Flow Diagrams
» Diagramme d’état
– Diagrammes objet & association (Entité-Relation, héritage, …)
» Diagramme de classe (UML)
» Entité-Relation
– Représentation Pré-Post conditions
» OCL (UML)
» Machine Abstraite B
 Représentation :
» Graphique (plus « intuitive » )
» Textuelle (plus précise)
Modéliser pour tester

Quelles notations de modélisation en génération de tests

à partir de modèles ?

1. Pouvoir calculer les cas de test

Invariant
et les résultats attendus x  -1000 .. 1000
2. Pouvoir se situer à un Preop
x  100
niveau abstrait Postop
IF x  0 THEN y := default
3. Pouvoir capter le modèle
ELSE IF x  40
de données THEN y := low
(variables/valeur) ELSE y:= high
END
4. Pouvoir capter les END
caractéristiques spécifiques de
l’application (ex.
Temps réel, …)
Exemple en notation B
Modéliser pour tester

Choix de notations
 Evalutation pour quelques notations

Notation Présentation +++ ---

UML 2.0 Unified . Grande diffusion . Peu précise

(Diag. Classe + Modeling . Variété de . Pas de
OCL + Diag. Language diagrammes sémantique
État)
Statecharts Diag. Etat . Bien adapté . Faible sur les
contrôleur système données
embarqué
Notation B Méthode . Sémantique claire . Apprentissage
formelle . Précision
Modéliser pour tester

Exemple 1 – Le régulateur de vitesse

 Le régulateur de vitesse permet de régler la vitesse du
véhicule suivant la vitesse demandée par le
conducteur du véhicule.
 Un bouton “on/off” permet d’activer le système. Si le
conducteur accélère, le système de régulation est
désactivé pendant le temps de l’accélération. Si le
conducteur freine, le système est mis à off. Ce système
est modélisé en Statecharts Statemate (I-Logix) au
travers d’un diagramme d’activités et d’un diagramme
d’états.
Diagramme d’activités du contrôleur de vitesse
Diagramme d’états du contrôleur de vitesse
Modéliser pour tester

Exemple 2 – La norme carte à puces GSM 11-11

 La norme GSM 11-11 défini l’interface entre le
Mobile (téléphone GSM) et la puce SIM –
Subscriber Identifier Module
 La puce SIM est une carte à puces qui contient toutes
les données utilisateurs et gére la protection de
l’accès
 Le standard GSM 11-11 propose 21 API incluant la
gestion du PIN – Personal Identifier Number – et du
PUK – Personal Unblocking Key – et la lecture et
mise à jour de données.
odéliser pour tester

Noyau de la norme GSM 11.11

 Commandes :  Arborescence de fichiers
– Verify_Chv(chv,code),
– Change_Chv(chv,code1,code2),
– Disable_Chv(code),
MF
– Enable_Chv(code),
– Unblock_Chv(chv,code_unblock DF_GSM ed_iccid
1, code_unblock2),
– Select_File(ff),
– Read_Binary, ed_lp ed_imsi ed_ad
– Update_Binary(data),
– Reset,
Modèle en B de la norme GSM 11-11 (fragment) – 1/4
MACHINE GSM_11-11

SETS
FILES = {mf,df_gsm,ef_iccid,ef_lp,ef_imsi,ef_ad};
PERMISSION = {always,chv,never,adm};
VALUE = {true, false};
BLOCKED_STATUS = {blocked, unblocked};
CODE = {a_1,a_2,a_3,a_4};
DATA = {d_1,d_2,d_3,d_4}

CONSTANTS
FILES_CHILDREN,
PERMISSION_READ,
MAX_CHV,
MAX_UNBLOCK,
PUK

DEFINITIONS
MF == {mf};
DF == {df_gsm};
EF == {ef_iccid,ef_lp,ef_imsi,ef_ad};
COUNTER_CHV == 0..MAX_CHV;
COUNTER_UNBLOCK_CHV == 0..MAX_UNBLOCK
Modèle en B de la norme GSM 11-11 (fragment) – 2/4

PROPERTIES
FILES_CHILDREN : FILES <-> FILES &
FILES_CHILDREN = {(mf|->df_gsm), (mf|->ef_iccid),(df_gsm|->ef_lp),
(df_gsm|->ef_imsi),(df_gsm|->ef_ad)} &
PERMISSION_READ : EF --> PERMISSION &
PERMISSION_READ = {(ef_imsi|->never),(ef_lp|->always),
(ef_iccid|->chv),(ef_ad|->adm)} &
MAX_CHV = 3 &
MAX_UNBLOCK = 10 &
PUK : CODE &
PUK = a_3

VARIABLES
current_file,
current_directory,
counter_chv,
counter_unblock_chv,
blocked_chv_status,
blocked_status,
permission_session,
pin,
data
Modèle en B de la norme GSM 11-11 (fragment) – 3/4

INVARIANT
…
((blocked_chv_status = blocked) => ((chv|->false) : permission_session)) &
((counter_chv = 0) <=> (blocked_chv_status = blocked)) &
((counter_unblock_chv = 0) <=> (blocked_status = blocked))

INITIALISATION
current_file := {} ||
current_directory := mf ||
counter_chv := MAX_CHV ||
counter_unblock_chv := MAX_UNBLOCK ||
blocked_chv_status := unblocked ||
blocked_status := unblocked ||
permission_session := {(always|->true),(chv|->false),(adm|->false),(never|->false)} ||
pin := a_1 ||
data := {(ef_iccid|->d_1),(ef_lp|->d_2),(ef_imsi|->d_3),(ef_ad|->d_4)}
 Modèle en B de la norme GSM 11-11 (fragment) – 4/4

sw <-- VERIFY_CHV(code) =
PRE
code : CODE
THEN
IF (blocked_chv_status = blocked)
THEN
sw := 9840
ELSE
IF (pin = code)
THEN
counter_chv := MAX_CHV || permission_session(chv) := true || sw := 9000
ELSE
IF (counter_chv = 1)
THEN
counter_chv := 0 || blocked_chv_status := blocked ||
permission_session(chv) := false || sw := 9840
ELSE
counter_chv := counter_chv - 1 || sw := 9804
END
END
END
END;
Test Generation Process

Modélisation en B pour la génération de tests

sw  CHANGE_Pin(old_code, new_code) =
PRE
 Niveau Machine old_code  Nat  new_code  Nat
THEN
Abstraite (sans IF counter_pin = 0
THEN
raffinement, mono- sw := 9840
machine) ELSE
IF code_pin = old_code
 Permet une bonne THEN
code_pin := new_code ||
prise en compte counter_pin := 3
|
des données et des | permission_session := true
traitements || sw := 9000
ELSE IF counter_pin =1
 Bon niveau d’ab- THEN
counter_pin := 0 ||
straction permission_session := false ||
sw := 9840
ELSE
counter_pin := counter_pin – 1 ||
 sw :=
9804
END END END END END ;
Modéliser pour tester

Exemple 3 – Distributeur de boisson

Scénario d’utilisation :
2
1. Le client introduit les pièces 2€00
2. Il choisit une boisson
3. Le distributeur remet la
boisson choisie 1
4. Le cas échéant, la 3 4
monnaie est rendue

 Ce système est modélisé en UML au travers

d’un diagramme de classe et d’un diagramme
états / transitions.
Modéliser pour tester

Distributeur de boisson – Diagramme de classes

Distributeur de boisson :
Diagramme états/transitions
Modéliser pour tester

Distributeur de boisson :
Diagramme états/transitions (2)
Modéliser pour tester

Distributeur de boisson :
Diagramme états/transitions
(3)
Modéliser pour tester

Critères de choix d’une notation / type

d’application
 Applications type contrôle-commande
(automobile, énergie, aéronautique, …)
 Statecharts, Lustre
 Applications mobiles et logiciels enfouis (télécom,
électronique grand public, carte à puces, monétique,
…)
 Pré/Post conditions (UML/OCL, B, …)
 Systèmes d’information
 Modélisation objet (UML)
Modéliser pour tester

Stratégie de modélisation

“Partial formal models focused on a specific

feature or component of the software under
test, for the sole purpose of test generation,
is feasible and provide good results in a
realistic industrial setting”

Farchi – Hartman - Pinter - IBM Systems Journal 41:1 - 2002

Modéliser pour tester

Processus Model-Based Testing – Schéma 1

Analyse de
Ingénieur besoins
modélisation
Documentation
Modèle existant Support du
développement

Adaptation Ingénieur
validation

Génération Cas de test

des tests
Modéliser pour tester

Processus Model-Based Testing – Schéma 2

Spécifications Développement
fonctionnelles

Modèle pour le test

fonctionnel

Modélisation

Ingénieur
validation
Génération Cas de test
Pilotage des tests
Génération automatique de tests à partir de
spécifications
 Test à partir de modèles (Model-Based Testing)
 Modéliser pour tester
 Stratégies de génération
 Classes d’équivalence et test aux bornes
 Maîtriser la combinatoire
 Sélection des tests – Critères de couverture
 LEIRIOS Test Generator
 Etudes de cas
ratégies de génération

Génération de tests fonctionnels

Automatise les stratégies classiques :

 Analyse partitionnelle des données d’entrée
 Test aux bornes
 Couverture de toutes les décisions

 Sélection des Données de Tests

Objectif : Optimiser le ratio couverture
du modèle / nombre de tests réalisés
Stratégies de génération

Analyse partitionnelle des domaines des données

d’entrée

Une classe d’équivalence

Invalid inputs Valid inputs correspond à un ensemble de
données de tests qui activent
le même comportement.
System

La définition des classes

d’équivalence permet de passer
d’un nombre infinis de données
d’entrée à un nombre fini et
Outputs limité de données de test.
Stratégies de génération

Test aux bornes des domaines des variables du modèle

4 10
3 11

Inférieur à De 4 à Supérieur à
4 10 10

Le test aux bornes produit à la fois des cas de test

nominaux (dans l’intervalle) et de robustesse (hors
intervalle)
Stratégies de génération

Analyse partitionnelle - Exemple

Invariant
x  -1000 .. 1000
Preop P1
x  100
Postop
IF x  0 THEN y := default
P2
ELSE IF x  40
THEN y := low
ELSE y:= high
END END P3
Classes de
comportements P1: x  0 Ensemble de tous les états
P2: x > 0  x  40 du système qui permettent
P3: x > 40  x  d’activer l’opération
100
Stratégies de génération

Calcul des données de test aux bornes

Prédicats après partitionnement

P1: x  0
P2: x > 0  x  40 X
P3: x > 40  x  100 BG1
P1
X BG2
BG3 X
Tests aux bornes
BG1 x = -1000 P2 X
BG2 x = 0 BG5
BG3 x = 1 BG4 X
BG4 x = 40 P3
BG5 x = 41 X BG6
BG6 x = 100
Stratégies de génération

Calcul des données de test aux bornes

Prédicats après partitionnement

P1: x  0
P2: x > 0  x  40 X
P3: x > 40  x  100 BG1
P1
X BG2
BG3 X
Tests aux bornes
BG1 x = -1000 P2 X
BG2 x = 0 BG5
BG3 x = 1 BG4 X
BG4 x = 40 P3
BG5 x = 41 X BG6
BG6 x = 100
Stratégies de génération

Maîtriser la combinatoire : exemple de la validation

terminal Carte Bancaire

2,64 Milliards de
MagIC 500
combinaisons de données
Schlumberger device
possibles

1570 Classes de
comportements comportements du
système

3140 Tests pour toutes les configurations

tests cartes possibles et les valeurs aux
bornes
240
Tests pour une
configuration particulière
2-4 - Génération automatique de tests à partir
de spécifications
 Test à partir de modèles (Model-Based Testing)
 Modéliser pour tester
 Stratégies de génération
 Sélection des tests – Critères de couverture
 critères de couverture du modèle
 critères de sélection sur le modèle
 LEIRIOS Test Generator
 Etudes de cas
élection des tests

Génération des tests à partir de critères

 Critères de couverture du modèle

– Obtenir le niveau de dépliage et de
couverture souhaité à partir du modèle
 Critères de sélection
– Focaliser la génération sur certains comportements
 Evolution du modèle
– Sélectionner les tests par différentiel de
comportements entre deux versions du
modèle
 Cas utilisateur
– Animer le modèle pour définir des cas de test
élection des tests

Critères de couverture

 Critères de conditions multiples dans les décisions

– Toutes les décisions (DC)
– Toutes les conditions/décisions (D/CC)
– Toutes les décisions / conditions modifiées (MC/DC)
– Toutes les conditions multiples (MCC)
Diagramme d’états du contrôleur de vitesse

Conditions multiples
Sélection des tests

Critères de couverture

 Critères de conditions multiples dans les décisions

– Toutes les décisions (DC)
– Toutes les conditions/décisions (D/CC)
– Toutes les décisions / conditions modifiées (MC/DC)
– Toutes les conditions multiples (MCC)
 Critères de couvertures des valeurs aux
bornes équivalentes
– Une valeur
– Toutes les valeurs
Diagramme d’états du contrôleur de vitesse

Valeurs aux limites

Sélection des tests

Critères de couverture

 Critères de conditions multiples dans les décisions

– Toutes les décisions (DC)
– Toutes les conditions/décisions (D/CC)
– Toutes les décisions / conditions modifiées (MC/DC)
– Toutes les conditions multiples (MCC)
 Critères de couvertures des valeurs limites équivalentes
– Une valeur
– Toutes les valeurs
 Critères de couverture des transitions
– Toutes les transitions
– Toutes les paires de transitions
Diagramme d’états du contrôleur de vitesse

Transition
Sélection des tests

Critères de sélection

Focus sur le modèle

 Sélection sur le choix des opérations /
événements activables
 Sélection par choix sur les variables / valeurs du modèle

Evolution du modèle
 Test de tous les comportements ajoutés ou modifiés
 Test des comportements inchangés

Cas définis par l’utilisateur

 Animation du modèle pour définir des séquences
d’activation: le générateur de test permet la production de
l’oracle de test
2-4 - Génération automatique de tests à partir
de spécifications
 Test à partir de modèles (Model-Based Testing)
 Modéliser pour tester
 Stratégies de génération
 Sélection des tests – Critères de couverture
 LEIRIOS Test Generator
 Etudes de cas
eirios Test Generator

L’outil LEIRIOS Test Generator

 Approche : tester tous les comportements du système

définis dans la spécification avec des données d’entrée aux
bornes

 Caractéristiques de la technologie :
– Génération automatique des tests et du résultat attendu
– Traduction des séquences de tests abstraits en
scripts exécutables concrets
– Génération des tests nominaux (cas de test positifs)
et des tests de robustesse (cas de tests négatifs)
– Génération de la matrice de traçabilité Exigences /
cas de tests
eirios Test Generator

LEIRIOS Test Generator

 Technologie issue de travaux de recherche démarré en 1996

à l’Université de Franche-Comté (LIFC) :
– S’appuie sur une animation symbolique en Programmation
en Logique avec Contraintes du modèle formel
 Applications industrielles depuis 1999 :
– Carte à puces avec Schlumberger/Axalto,
– Systèmes monétiques (EMV 2000, CB 5.2) avec Parkeon et G.
Carte Bancaire
– Systèmes embarqués dans l’automobile avec PSA Peugeot Citroën
– Systèmes critiques avec IRSN, ESA
 La société LEIRIOS créée en septembre 2003 à partir de
l’équipe BZ-Testing-Tools du LIFC :
– Développe et commercialise l’outil LEIRIOS Test Generator – LTG
eirios Test Generator

LEIRIOS Test Generator

Caractéristiques principales

 LTG supporte actuellement trois notations :

– Notation B (niveau machine abstraite)
– Statecharts Statemate
– UML (diagrammes de classe et états /
transitions avec des expressions OCL)

 LTG propose des

critères de couverture et
de sélection pour piloter
la génération de tests
Process de génération
Modèle fonctionnel
(B, Statecharts, UML,
Modélisation
…)
Fonctionnelle
Validation du
modèle
LTG
Animateur

Spécifications
Techniques de
Besoins
Critères
de Génération
LTG génération des cas de
Générateur tests
de tests
LTG
Cas de test
Automate
Simulator Générateur
De scripts

Pattern de
scripts
Environnement
Génération
d’exécution des tests
des scripts de
test
Leirios Test Generator

Pilotage du banc de test et simulation de

l’environnement
 A partir des cas de tests abstraits, d’un source de test
générique et d’une table d’observabilité et
d’exécutabilité, les scripts exécutables sur le banc cible
sont générés.
 Le pilotage du banc permet une exécution des tests et
un verdict automatiques.

Pattern de test Table d’observabilité et

générique d’exécutabilité

Cas de test Génération des scripts Script de tests

générés de tests exécutables exécutables
Leirios Test Generator

La génération de tests : un processus piloté par

l’ingénieur
validation
Spécifications

Traducteur

Conditions
P
Calcul des multiples Valeurs I
Prédicats de
comportements L
comportement
aux bornes Couv. O
T
A
des transitions
G
E
IHM
Etats limites et Evolution du
Génération de tests
modèle

Critères de
Scénarii de tests
couverture

Interfaçage Banc de test

Leirios Test Generator

Au cœur de la technologie LEIRIOS Test Generator :

moteur d’animation symbolique des spécifications

- Fondée sur des

Etat initial
résultats originaux en
résolution de
contraintes …
Etat 1 Etat i Etat n
- Permet de calculer le
système de contraintes
suivant l’activation
d’un comportement Etat 1.1 Etat 1.2 … Etat 1.n
du système

 Maîtrise de l’explosion combinatoire du calcul des cas de test

 Optimise le nombre de cas de test / couverture du modèle
Leirios Test Generator

LEIRIOS Test Generator – Interface de pilotage

Leirios Test Generator

LEIRIOS Test Generator – Liaison avec le banc

Leirios Test Generator

LEIRIOS TEST GENERATOR

Exemple d’applications

• GSM 11-11 – gestion puce SIM • Fonctions visibilité générique –

• Java Card – JCVM mécanisme de essuyage, dégivrage, lavage
transaction • Contrôleur de climatisation
• Gestion des clés, des identités et de la
sécurité

• Algorithme de validation tickets

Metro/RER
Groupement des Cartes Bancaires • Validation terminal de paiement
(CB 5.2)
• Authentification du porteur
2-4 - Génération automatique de tests à partir
de spécifications
 Test à partir de modèles (Model-Based Testing)
 Modéliser pour tester
 Sélection des tests – Critères de couverture
 Stratégies de génération
 LEIRIOS Test Generator
 Etudes de cas
 Le régulateur de vitesse
 La norme carte à puces GSM 11-11
 Le distributeur de boissons
Diagramme d’activités du contrôleur de vitesse
Diagramme d’états du contrôleur de vitesse
Etudes de cas

Contrôleur de vitesse
 Variables : 12
Vitesse, régime moteur, état du contrôleur…
– Observable : 6
– Interne : 2
 Stimuli : 6
– Information persistante : Vitesse, moteur…
– Information non-persistante : activation/désactivation
du contrôleur, freinage…
 Activité : 1
 Etat : 9
 Transitions : 18 hiérarchiques
udes de cas

Contrôleur de vitesse

 Réguler la vitesse : vitesse de consigne

 Action sur le contrôleur :
– Activation / Désactivation
– Freinage
– Accélération
 Paramétrage :
– Vitesse minimal : 40 km/h
– Vitesse maximal : 130 km/h

=> 36 cas de test

Etudes de cas

Exemple de cas de test généré

Stimuli Explication Variable observable

ON/OFF Le conducteur active le contrôleur de SPEED_REQ = 40 km/h

vitesse CRUISECONTROL_MODE = ON
SPEED = 0 km/h
ON/OFF = ON
ACCELERATIONREGUL = ACTIVE
DECELERATIONREGUL=UNACTIVE

Acceleration Le contrôleur fait accélère la voiture SPEED_REQ = 40 km/h

Regulator jusqu’à la vitesse demandé de 40 CRUISECONTROL_MODE = ON
km/h SPEED = 40 km/h
ON/OFF = ON
ACCELERATIONREGUL = UNACTIVE
DECELERATIONREGUL = UNACTIVE
Etudes de cas

Génération de tests sur l’application GSM 11.11

 Commandes :  Arborescence de fichiers

– Verify_Chv(chv,code),
– Change_Chv(chv,code1,code2),
– Disable_Chv(code),
MF
– Enable_Chv(code),
– Unblock_Chv(chv,code_unblock DF_GSM ed_iccid
1, code_unblock2),
– Select_File(ff),
– Read_Binary, ed_lp ed_imsi ed_ad
– Update_Binary(data),
– Reset,
Test Generation Process

Méthode de génération

Test de chaque comportement : chaque chemin

d’exécution pour chaque opération

Operation counter_pin=1 
counter_pin’=0
Change_Pin permission_session’=false
code_pin ≠ sw=9840
old_code

counter_pin ≠ 0
counter_pin’≠1 
counter_pin=counter_pin-1  sw=9804

code_pin=old_code  code_pin’=new_code
permission_session’=true counter_pin’=3  sw=9000

counter_pin = 0  sw = 9840
Prédicat de comportement == counter_pin ≠ 0  code_pin ≠ old_code  counter_pin=1
Etudes de cas

Valeurs limites pour la spécification GSM 11.11

 Couverture des  Exemples de valeurs limites :

comportements et des
états limites - LTG – counter_chv(chv1) = 0
– counter_chv(chv1) = 1
1. Extraction des comportements – counter_chv(chv1) = 3
2. Calcul des états limites
3. Construction des cas de tests – counter_unblock(chv1) = 0
– Préambule – counter_unblock(chv1) = 1
– Corps de test – counter_unblock(chv1) = 10
– Identification
– Postambule – enabled_chv1_status = enabled
– enabled_chv1_status =
disabled
 Activation d’un comportement de la commande VERIFY_CHV

sw <-- VERIFY_CHV(code) =
PRE
code : CODE
THEN
IF (blocked_chv_status = blocked)
THEN
sw := 9840
ELSE
IF (pin = code)
THEN
counter_chv := MAX_CHV || permission_session(chv) := true || sw := 9000
ELSE
IF (counter_chv = 1)
THEN
counter_chv := 0 || blocked_chv_status := blocked ||
permission_session(chv) := false || sw := 9840
ELSE
counter_chv := counter_chv - 1 || sw := 9804
END
END
END
END;
Etudes de cas

Séquences de test pour la spécification GSM 11.11

 Séquences de test de l ’état initial counter_chv(chv1) =

3 à la valeur limite counter_chv(chv1) = 0

 Préambule :

1. VERIFY_CHV (chv1) false code

2. VERIFY_CHV (chv1) false code

3. VERIFY_CHV (chv1) false code

udes de cas

Exemples de test à la valeur limite

counter_chv(chv1) = 0 (1)
 Test 1 : VERIFY_CHV(1) true code >>> 9840
– STATUS :
current_file []
enabled_chv1-status enabled
counter_chv [(chv1,0),(chv2,3)]
counter_unblock [(chv1,10),(chv2,10)]

 Test 2 : VERIFY_CHV(0) wrong code >>> 9840

– STATUS :
current_file []
enabled_chv1-status enabled
counter_chv [(chv1,0),(chv2,3)]
counter_unblock [(chv1,10),(chv2,10)]
Etudes de cas

Exemples de test à la valeur limite

counter_chv(chv1) = 0 (2)
 Test 3 : UNBLOCK_CHV(chv1,1,0) true code >>> 9000
– STATUS :
current_file []
enabled_chv1-status enabled
counter_chv [(chv1,3),(chv2,3)]
counter_unblock [(chv1,10),(chv2,10)]

 Test 4 : UNBLOCK_CHV(chv1,0,0) wrong code >>> 9804

– STATUS :
current_file []
enabled_chv1-status enabled
counter_chv [(chv1,0),(chv2,3)]
counter_unblock [(chv1,9),(chv2,10)]

Démonstration de l’outil LEIRIOS Test Generator

Etudes de cas

Distributeur de boissons – Modèle UML

 Les tests générés correspondent à des séquences d’appel de
méthode définies au niveau du diagramme de classes du
modèle

 La stratégie de génération explore les chemins d’activation

du diagramme états / transitions suivant les paramètres de
génération choisis (dépliage des conditions multiples, valeurs
des domaines)
 Les cas de test peuvent être visualisé sous la forme
de diagramme de séquence
udes de cas

Distributeur de boisson – Diagramme de classes

Etudes de cas

Distributeur de boisson – Exemple de cas de

test

1. InsertMoney(3) AmountRegistered = 3
2. SelectDrink(s1)
 giveDrink NumberOfAvailableDrink – 1
 returnMoney(1) AmountRegistered = 0
SumOfAmounts = SumOfAmounts
+ AmountRegistered

 Le test est vu depuis la classe DVM qui

constitue l’objectif de test
2-4 – Automatisation de l’exécution des
tests et de la remontée du verdict

 Problématique

 Traduire des tests abstraits en

scripts exécutables

 Environnement d’automatisation
de l’exécution

 Exemple du « Contrôleur de vitesse »

Process de génération de tests
Validation
Outils de modélisation (Statecharts, B ou UML) Du modèle

Modélisation
fonctionnelle

LTG
Animateur
des
spécifications

Spécifications
fonctionnelles

Banc de test
LTG LTG
Générateur Générateur
de tests de scripts
Modèle Cas de
des test
spécifications

corres
ponda
Pattern de test nce
et table de
Génération des scripts et exécution
de tests
Pilotage banc de tests

Problématique de la traduction des tests

générés en scripts exécutables
 Nomage des appels et variables : Les tests générés sont des
séquences d’appel sur les opérations ou stimuli définis au
niveau du modèle
Table de correspondance entre noms du modèle (variables et appels) et
noms de l’environnement d’exécution des tests
 langage de tests : L’environnement d’exécution des tests
prend en entrée un langage de définition des scripts
exécutables
Définition d’un pattern générique au sein duquel les appels seront insérés
 Verdict de test : Les tests générés comprennent le
résultat attendus
Le verdict est construit par comparaison entre le résultat attendu et le
résultat obtenu pendant l’exécution du script de test
Pilotage banc de tests

Processus de génération de scripts de test

Génération Format
Spécification de test
de test

Table d’exécutabilité Editeur de

Séquence
et pattern
de test
d’observabilité

Pattern
Table Réification
de test

Script
de test
Pilotage banc de tests

Table d’exécutabilité et d’observabilité

 Relation entre Abstrait et Concret :

– Stimuli
Spécification
– Variables : Interne, Entrée, Sortie

 Observabilité : Table d’exéutabilité

– Définir les éléments spécifiques au modèle et
– Les éléments identifiables d’observabilité

 Exécutabilité :
Table
– Appel concret
– Reconstruire les éléments (@)
– Gestion spécifique au langage destination
Table d’exécutabilité et
d’observabilité
Pilotage banc de tests

Editeur de patterns

 Automatisation de la génération : Format

de test
– Squelette générique : source à trous
– Tag pour l’insertion des parties du test

Editeur de
 Tag : pattern
– Information sur le test
– Préambule
– Postambule
Pattern
de test
Editeur de patterns
Pilotage banc de tests

Génération des scripts de test exécutables

 Générer automatique les scripts à partir :

– Séquence de test Séquence
de test
– Table d’exécutabilité et observabilité
– Pattern de test Pattern
Table Réification de test

Script
 Optimisation sur les scripts : de test
– Regrouper des séquences dans le même script
– Activation d’observation en dehors de l’identification
– Associer une séquence à différents patterns

=> Source à utiliser dans les environnement

Interface de
réification
Pilotage banc de tests

Exécution sur le banc de test

Pilotage banc de tests

Problèmes

 Interprétation du cahier des charges :

– Non dit
– Optimisation
– Ordre des traitements
=> Expérimentation
 Niveau d’observation (qui, où, quoi)
– Information directe : variable ou méthode
– Reconstructible : calcul ou appel
– Non-observable
=> Réalisation du modèle
Classification des techniques de génération

2-4 - Caractéristiques des outils de génération

de tests à partir de modèles
1. Nature du modèle
2. Pilotage de la génération
o Spécifications de tests
o Critères de couvertures
3. Techniques de calcul pour la génération
4. Contrôle de l’exécution des tests générés
assification des techniques de génération

1- Nature du modèle
 Spécification formelle du système sous test
– Comportements attendus du système dans son environnement
» Ex.: LTG
 Modèle du système + Modèle de l’environnement
– Le modèle d’environnement permet de restreindre l’espace
de calcul
» Ex. : GATEL (CEA)
 Modèle des exécutions attendues (Observateur)
– Définition des traces à tester
» Ex. : Conformiq
Classification des techniques de génération

2- Notation de modélisation
 Systèmes de transitions :
– IOLTS (STG – IRISA, TORX – Univ. Nijmegen)
– Statecharts (AGATHA – CEA)

 Pré/post conditions – Machine abstraites

– ASML (Microsoft Research)
– B (LTG)
– UML/OCL (LTG, UML-Casting, …)

 Langages synchrones
– Lustre (GATEL – CEA)
assification des techniques de génération

3- Pilotage de la génération (1)

1. Spécifications de tests
o Même notation que le modèle
o Propriétés LUSTRE dans l’outil GATEL
o IOLTS pour définir l’objectif de test dans STG
o Notation différentes
o FlowGraph pour spécifier l’objectif de test en Z (P.
Strooper – Univ. Queensland Australie)
o Propriétés PLTL pour spécifier l’objectif de tests
assification des techniques de génération

3- Pilotage de la génération (2)

2. Critères de couverture
o Couverture structurelle du modèle
o Flot de contrôle
o Couverture des états, des transitions ou paires de transitions (LTS, Statecharts)
o Couverture d’un partitionnement des post-conditions, DNF (B, Z, VDM, OCL)
o Couverture des règles (ASM)
o Couverture des décisions multiples : DC, D/CC, FPC, MC/DC, MCC
o Flot de données
o All-Definitions, All-Uses, All-Definitions-Uses
o Couvertures des données (variables d’entrée, d’états)
o Données aux bornes (boundary testing)
o Choix Random, stochastiques
o Couverture des exigences (traçabilité)
assification des techniques de génération

4- Techniques de calcul pour la génération

 Model-Checking
– Techniques de parcours du modèle éprouvée
– La négation de l’objectif de tests est vue comme une propriété à
démontrer (un contre-exemple ≈ cas de test)
– Problème d’explosion combinatoire si méthode valuée
» Model-Checking symbolique
 Interprétation abstraite
– Propagation des équations sur le modèle à partir d’entrée symbolique
– Nécéssite de pouvoir instancier des cas de test concrets
» Résolution de contraintes
 Programmation en Logique avec Contraintes
– Calcul des conditions de chemin par résolution de contraintes
– Le système de contraintes courant représente un ensemble d’état possible
du système
assification des techniques de génération

5- Contrôle de l’exécution des tests générés

 Calcul et passage des tests à la volée
– Ex. STG : calcul d’un graphe complet de test à partir du modèle et de
la spécification de test ; ce graphe est exploité dynamiquement pour
l’exécution des tests
– Avantages : bonne gestion du non déterminisme (choix à la volée
en fonction des réponses du système sous test)
– Inconvénients : Problème du temps de calcul des tests à la volée
 Traduction des tests abstraits en scripts exécutables et
exécution en mode batch
– Ex. LTG – Réification des tests générés en scripts exécutables
– Avantages : S’inscrit dans le processus de test (tests de non régression)
– Inconvénients : Prise en compte du non-déterminisme de contrôle
plus difficile
Apports et limites de la génération automatique de tests

 Couverture fonctionnelle des spécifications

 Cohérence des spécifications

 Maturité du process de test

pports de la génération de tests

Apports de la génération automatique – Couverture

du modèle

 Couverture systématique des spécifications suivant

– tous les comportements
– Traçabilité entre les exigences et les tests
 Maîtrise de la couverture de tests

 Génération du nombre minimal de données de tests

– En fonction des critères de couverture sélectionnés
 Maîtrise de l’explosion combinatoire du
nombre de cas de tests
Apports de la génération de tests

Apports de la génération automatique –

Cohérence des spécifications
 Le modèle est
– validé par animation
– vérifié par preuve de consistance (les comportements sont cohérents)
 Validation des spécifications

 En cas d’évolutions fonctionnelles

– génération des tests correspondant aux nouveaux comportements
– tests des comportements inchangés
 Automatise le test des changements fonctionnels
et des effets de bords (test de non-regression)
Apports de la génération de tests

Apports de la génération automatique –

Maturité du process de validation
 L’automatisation de la génération des scripts de tests, permet
à l’ingénieur validation de se consacrer à l’essentiel
– le pilotage de la génération (objectif de tests)
– l’analyse des anomalies détectées
 Meilleure maturité du process de validation
 Une fois la chaîne automatisée
– reproductibilité de la génération
– suppression de l’écriture des scripts
 Réduction de l’effort de test et du « time to
market »
Apports de la génération automatique

Réduction du temps de test - Source K. Stobie

Test Architect - Microsoft Corporation – SASQAG – Janvier 2003

“In a typical application of this approach, test engineer productivity has

increased by a factor of five to ten over conventional manual approaches”.

SASQAG : Seattle Area Software Quality Assurance Group

Apports de la génération automatique

Exemples de résultats obtenus avec LTG

 Sur l’application GSM 11-11: comparaison par rapport
à une suite manuelle très mature
– 50% de couverture fonctionnelle en plus
– Réduction de 30% de l’effort de conception des tests

 Sur l’application Validation Terminal de Paiement

sur Automate – Transaction de débit CB 5.2
– Couverture 3 fois supérieure aux pratiques antérieures
– Temps moyen de spécification de test très inférieur
pports de la génération automatique

Quand mettre en œuvre la génération

automatique à partir des spécifications ?
Critères décisifs :
 Fort besoin en validation
 Croissance forte des fonctionnalités
 Besoin de réduire l’effort et les temps de

test Systèmes embarqués, logiciels enfouis

Control Systems
Consumer
Electronics
Autonomous Systems
Automobile Industry
Transport
Smart cards
Telecommunication
Energy, Medical,
….
Apports de la génération automatique

Automatiser le test pour mieux valider !

 L’automatisation du test fonctionnel s’appuie sur

la mise en place d’une chaîne continue :

A partir des
spécifications
fonctionnelles

Modélisation Génération Environnement

de tests et D’exécution
de scripts des tests
3- Méthodes de test structurel
 Le test structurel s ’appuie sur l ’analyse du code source
de l’application (ou d’un modèle de celui-ci) pour établir
les tests en fonction de critères de couverture

 Basés sur le graphe de flot de contrôle (toutes les

instructions, toutes les branches, tous les chemins,
…)
 Basés sur la couverture du flot de données (toutes
les définitions de variable, toutes les utilisations, …)
 Basés sur les fautes (test par mutants)
3-1 Graphe de flot de contrôle

 Soit le programme P1 suivant : a

if x <= 0 then x := - x <= 0 x >0
x else x := 1 - x;
if x = -1 then x := -x b c
x=1 else x := x := 1-x
x+1; writeln(x) d
x = -1 x  -1
Ce programme admet le graphe de
contrôle G1. x := 1 f e
x := x + 1

g
G1 Writeln(x)
Chemins dans le graphe de contrôle
 Le graphe G1 est un graphe de contrôle qui admet
une entrée - le nœud a - , une sortie - le nœud g.
– le chemin [a, c, d, e, g] est un chemin de contrôle,
– le chemin [b, d, f, g] n ’est pas un chemin de contrôle.

 Le graphe G1 comprend 4 chemins de contrôle :

– 1 = [a, b, d, f, g]
– 2 = [a, b, d, e, g]
– 3 = [a, c, d, f, g]
– 4 = [a, c, d, e, g]
Expression des chemins de contrôle
 Le graphe G1 peut-être exprimé sous forme
algébrique sous la forme suivante :
G1 = abdfg + abdeg + acdfg + acdeg
le signe + désigne le « ou » logique entre chemins.

 Simplification de l ’expression de chemins

G1 = a (bdf + bde + cdf + cde) g G1
= a (b + c) d (e + f) g
Calcul de l ’expression des chemins de
contrôle
 On associe une opération d’addition ou de multiplication
à toutes les structures primitives apparaissant dans le
graphe de flot de contrôle
b

a b
Forme séquentielle : ab a d

Forme alternative :
a b c d
a (b + c) d

Forme itérative : ab (cb)* d

Chemins de contrôle avec boucles
 Soit le programme P2 suivant : i := 1;
a found := false
i := 1;
found := false;
while (not found) f
do b found
begin not found
if (a[i] = E) then
c found := true;
begin s := i;
found := true; a[i] = E
a[i] <> E d
s := i;
end;
i := i + 1; e
end;
G2 = ab [c (1 + d) eb]* f i := i +1 G2
Expressions de chemins - Exercice
 Soit le programme P3 suivant :

if n <= 0 then n := 1-n

end;
if 2 div n
then n := n / 2
else n := 3*n + 1
end ;
write(n);

 Etablir le graphe de flot de contrôle de ce programme

 Fournir l ’expression des chemins
Graphe de flot de contrôle du programme P3

G3 a
n <= 0

n>0
n := 1 - n b

G3 = a (1 + b) c (e + d) f
2 div n
c not 2 div n

d n := n / 2
e n := 3*n + 1

f write(n)
Expressions de chemins - Exercice
 Soit le programme P4 suivant :

read(i);
s := 0;
while (i <= 3) do
begin
if a[i] > 0 then s := s + a[i];
i := i + 1;
end
end;

 Etablir le graphe de flot de contrôle de ce programme

 Fournir l ’expression des chemins
Graphe de flot de contrôle du programme P4

G4 a read(i);
s := 0

i>3
b f

i<= 3
c G4 = ab [c (1 + d) eb]* f
a[i] > 0
a[i] <= 0
d s := s + a[i]

e
i := i +1
Problème des chemins non exécutables

a
b<c
d := 2 * b; y := x; • L ’arc g-h n’est
f := 3 * c; b d e := c; pas activable :
x >= 0 2b < 2c donc d < a

y=0 • Le problème de la
b >= c c e
détection de chemin non
f a := f - e; exécutable est un problème
x<0 difficile, indécidable dans le
y cas général
g
0
d<a
d >= a
h i writeln(a);
Méthodes de test structurel : couverture de
tous-les-nœuds
 Taux de couverture :

nb de nœuds couverts
nb total de nœuds

Soit le programme P5 (somme avec erreur) : a

x=0
x0
function sum (x,y : integer) : integer;
begin b c
sum := x + y;
if (x = 0) then sum := x sum := x;
else sum := x + y
end; d

 L ’erreur est détectée par l’exécution du chemin [acd]

Limites du critère tous-les-nœuds

Soit le programme P6 (avec erreur) : read(x);

a
x
read(x); 0 x=0
…
x := 1;
if (x <> 0) then x := 1; b c
…
y := 1/x;
d y := 1/x;

 Le critère tous-les-nœuds est satisfait par le chemin [abcd]

sans que l ’erreur ne soit détectée.
Méthodes de test structurel : couverture de
tous-les-arcs
 Taux de couverture :

nb des arcs couverts

nb total des arcs

 La couverture de tous les arcs équivaut à la couverture de

toutes les valeurs de vérité pour chaque nœud de
décision.

 Lorsque le critère tous-les-arcs est totalement réalisé,

cela implique que le critère tous-les-nœuds est satisfait
Cas des conditionnelles composées (1)
 Exemple : a
(a >= 2) or (b  a) (a < 2) and (b = a)
if ((a < 2) and (b = a))
then x := 2 -
b c
a else x := a -
x := 2 - a;
x := a - 2;
2

 Le jeu de test DT1 = {a=b=1}, DT2 = {a=b=3}

satisfait le critère tous-les-arcs sans couvrir toutes les
décisions possibles - ex. DT3 = {a=3, b=2}.
Cas des conditionnelles composées (2)
 Le graphe de flot de contrôle doit décomposer
les conditionnelles :

a a >= 2
a< Données de test :
2
c • DT1 = {a=b=1}
b
a b=a • DT2 = {a=1, b=0}
b • DT3 = {a=3, b=2}
b=a b • DT4 = {a=b=3}
a e x := a - 2;
x := 2 - a; d

f
Critère de couverture de condition-décision
multiple
 Le critère de condition-décision multiple est satisfait si :
– Le critère tous-les-arcs est satisfait
– En plus, chaque sous-expression dans les conditions prend
toutes les combinaisons de valeurs possibles

– Si A & B Then ……….. Nécessite :

 A = B = vrai
 A = B = faux
 A = vrai, B = faux
 A = faux, B = vrai

– Problème de la combinatoire lors d’expression logique complexe

Sensibilité au compilateur
 Problème : sensibilité au traitement des conditionnelles
par le compilateur
a
a >= 2 Le nombre d ’arcs dépend
a<2
de la manière dont l
’algorithme est codé et
b
compilé.
b=a b
a c x := a - 2;
x := 2 - a; d

e
Limites des critères tous-les-arcs et condition-
décision multiple
 Il n ’y a pas détection d ’erreurs en cas de non-
exécution d ’une boucle
Soit le programme P7 (avec erreur) :

read(inf, sup);
i := inf;
sum := 0;

while (i <= sup) do

begin
sum := sum + a[i];
i := i + 1;
end;
writeln (1/sum);
Limites des critères tous-les-arcs et condition-
décision multiple
 Il n ’y a pas détection d ’erreurs en cas de non-
exécution d ’une boucle

read(inf, sup);
La donnée de test DT1 :
a i := inf; DT1= {a[1]=50, a[2]=60,
sum := 0;
a[3]=80, inf=1, sup=3}
i > sup c couvre le critère tous-les-arcs
b writeln (1/sum)

i <= sup
Problème non détecté par le critère
d sum := sum + a[i]; tous-les-arcs : si inf >sup erreur sur 1/sum
i := i + 1;
Méthodes de test structurel : couverture de
tous-les-chemins-indépendants
 Le critère tous-les-chemins-indépendants vise à parcourir
tous les arcs dans chaque configuration possible (et non
pas au moins une fois comme dans le critère tous-les-
arcs)
 Lorsque le critère tous-les-chemins-indépendants
est satisfait, cela implique :
– le critère tous-les-arcs est satisfait,
– le critère tous-les-nœuds est satisfait.
 Sur le programme P7, l ’arc [c-e] est sensibilisé lorsque i
> sup à la fois dans le contexte sum = 0 (la boucle n ’est
pas activée) et sum  0 (la boucle est activée)
Procédure : tous-les-chemins-indépendants
 1 - Evaluer le nombre de décisions par analyse
des conditionnelles
 2 - Produire une DT couvrant le maximum de nœuds
de décisions du graphe
 3 - Produire la DT qui modifie la valeur de vérité de
la première instruction de décision de la dernière DT
calculée.
Recommencer l ’étape 3 jusqu ’a la couverture de toutes
les décisions.
Critère tous-les-chemins-indépendants -
Exemple
 Soit le programme P8 suivant :

function goodstring (var count : integer) while (ch=‘ b ’) or (ch=‘ c ’) do

: boolean;
begin
var ch : char;
count := count + 1;
begin
read(ch);
goodstring := false;
end;
count := 0;
if ch = ‘ x ’ then
read(ch);
goodstring = true;
if ch = ‘ a ’ then
end;
begin
end;
read(ch)
Critère tous-les-chemins-indépendants -
Exemple
goodstring := false;
0
count := 0;
G7 read(ch);
ch ‘b ’
DT1 = {abcx}
DT2 = {b}
1 DT3 = {acx}
6 DT4 = {ax}
ch = ‘ a ’ 3 DT5 = {aba}
ch = ‘ b ’ ch = ‘ c’
2 ch ‘ c ’
read(ch);
count := 7
count + 1; 4
ch = ‘x’
ch ‘ a ’
ch ‘
x’
8 goodstring := true;
5
read(ch);
9
Couverture des chemins limites et intérieurs (1)
 Les chemins limites traversent la boucle mais ne l
’itèrent pas;
 Les chemins intérieurs itèrent la boucle une seule fois;

chemin limite : [abc]

a a

chemin
b b intérieur : [abcbd]
chemin
intérieur : [ababc]

c d c
Couverture des chemins limites et intérieurs (2)

1 Chemins limites :
• [1,2,3,5,6]
• [1,2,4,5,6]
2
vrai faux
Chemins intérieurs :
3 4 • [1,2,3,5,2,3,5,6]
• [1,2,3,5,2,4,5,6]
5 • [1,2,4,5,2,3,5,6]
• [1,2,4,5,2,4,5,6]

6 Chemins intérieurs : exécute n fois la boucle

Méthodes de test structurel - Exercice

Soit le programme P3 suivant :

If n  0 then n := 1-n
end;
If n pair
then n := n / 2
else n := 3*n + 1
end ;
Write(n);  Calculer les DT suivant les critères :
– tous-les-nœuds,
– tous-les-arcs,
– tous-les-chemins-indépendants.
Méthodes de test structurel - Exercice

G3  Critères de test :
a
– tous-les-nœuds
n
0 » n = 0, n = -1
n>0 – tous-les-arcs
n := 1 - n b
» n = 2, n = -2
– tous-les-chemins-indépendants
n pair
c n impair » n = -1, n = -2, n = 1, n = 2

d n := n / 2
e n := 3*n + 1

f write(n)
Méthodes de test structurel - Exercice
 Soit le programme P9 suivant :
while i <= 2 do
program p (input, output) ; begin
var a : array[1..2] of integer; if (a[i] = E) then found := true;
E, i : integer; else found := false;
begin i := i + 1;
read(i, E, a[1], a[2]); end;
found := false; writeln(found);
end;
 Calculer les DT suivant les critères :
– tous-les-nœuds,
– tous-les-arcs,
– tous-les-chemins-indépendants.
Méthodes de test structurel - Exercice
read(i); DT1 = {i=3}
1 found := false;
DT2 = {i=1, E=10, a[1]=20, a[2]=10}
DT3 = {i=1, E=10, a[1]=10, a[2]=20}
DT4 = {i=1, E=10, a[1]=10, a[2]=10}
i>2 DT5 = {i=1, E=10, a[1]=20, a[2]=30}
2
i2 7
writeln(found);
3
a[i]  E a[i] = E
found :=
false; 4 5
found := true;

6 i := i + 1;
Couverture du critère Portion Linéaire de
Code suivie d’un Saut - PLCS
 Principes :
– On considère, dans le graphe de flot de contrôle, l’entrée, la
sortie et les nœuds qui constituent l’arrivée d’un branchement –
type (a)
– , et les autres nœuds – type (b).
– On appelle PLCS un chemin partant d’un nœud de type (a) et
aboutissant à nouveau à un nœud de type (a); l’avant dernier et
le dernier nœud doivent constituer le seul saut du chemin.
– On définit le critère TER3 :
PLCS couvertes
Total des PLCS
Couverture du critère PLCS – Exemple
INPUT A, C K5 K20 A=A+1
Soit le programme suivant : B=2*A

K30
005 INPUT A, C
A0
010 B = 2 * A
020 A = A + 1 A<0 K40 B = -A
PRINT A + B
030 IF A < 0 THEN GOTO 60
040 B = -A K60
050 PRINT A + B B
B = 2*C
060 IF B = 2 * C THEN GOTO 80 2*C K70 A
070 A = 1 : GOTO 90 =1
080 A = -2 : GOTO 20 K80 A = -2
090 PRINT A
100 END
K90 PRINT A
K5 Nœud type (a)

K70 Nœud type (b) K100

Couverture du critère PLCS – Exemple
INPUT A, K5 K20 A=A+1
Ce programme comprend 10 PLCS : CB=2*A

K30
1) [K5, K20, K30, K60]
A0
2) [K5, K20, K30, K40, K60, K80]
3) [K5, K20, K30, K40, K60, K70, K90] A<0 K40 B = -A
PRINT A + B
4) [K20, K30, K60]
5) [K20, K30, K40, K60, K80] K60
6) [K20, K30, K40, K60, K70, K90] B
B = 2*C
7) [K60, K80] 2*C K70 A
8) [K60, K70, K90] =1
9) [K80, K20] K80 A = -2
10) [K90, K100]
K90 PRINT A
K5
Nœud type (a)

Nœud type (b) K100

K70
Critères de type PLCS
 Autres critères de type PLCS

TER4 Chemins composés de 2 PLCS

= Total des chemins composés de 2 PLCS

TER5 Chemins composés de 3 PLCS

= Total des chemins composés de 3 PLCS
Hiérarchie des critères basés sur le flot de
contrôle

tous-les-chemins
TERn

tous-les-chemins-indépendants
TER4

TER3

tous-les-arcs
(TER2)

est plus fort que tous-les-nœuds

(TER1)
3-2 Critères de couverture basés sur le flot de
données
 Les critères basés sur le flot de données sélectionnent
les données de test en fonction des définitions et des
utilisations des variables du programme
 Définitions sur les occurrences de variables :
– une variable est définie lors d’une instruction si la valeur de
la variable est modifiée (affectations),
– Une variable est dite référencée si la valeur de la variable
est utilisée.
 Si la variable référencée est utililsée dans le prédicat
d’une instruction de décision (if, while, …), il s’agit
d’une p-utilisation, dans les autres cas (par exemple dans
un calcul), il s’agit d ’une c-utilisation.
Critères basés sur le flot de données
 Notion d’instruction utilisatrice :
– Une instruction J2 est utilisatrice d’une variable x par rapport à
une instruction J1, si la variable x qui a été définie en J1 est peut
être directement référencée dans J2, c’est-à-dire sans
redéfinition de x entre J1 et J2

Exemple : Considérons l’instruction (5) :

(1) x := 7;
(2) a := x+2; (5) est c-utilisatrice de (1) pour
(3) b := a*a; la variable x
(4) a := a+1; (5) est c-utilisatrice de (4) pour
(5) y := x + a; la variable a
Critères basés sur le flot de données
 Notion de chemin d’utilisation
– Un chemin d’utilisation relie l’instruction de définition d’une
variable à une instruction utilisatrice; un tel chemin est
appelé chemin dr-strict

Exemple :
Le chemin [1,2,3,4,5] est
(1) x := 7;
(2) a := x+2; un chemin dr-strict pour la
(3) b := a*a; variable x (mais pas pour
(4) a := a+1;
(5) y := x + a;
la variable a)
Critères toutes-les-définitions et tous-les-
utilisateurs
 toutes-les-définitions : pour chaque définition, il y a
au moins un chemin dr-strict dans un test
 tous-les-utilisateurs : pour chaque définition et pour
chaque référence accessible à partir de cette définition,
couverture de tous les utilisateurs (nœuds c-utilisateurs
ou arcs p-utilisateurs)

tous-les-utilisateurs  toutes-les-définitions
 Critères toutes-les-définitions et tous-les-
utilisateurs - exemple

Couverture du critère
x pair 1 read (x, y); toutes-les-définitions
:
x impair [1,3,5]
2
x := y+x/2 [1,2,3,5]
3
Couverture du critère
x0 x<0 tous-les-utilisateurs :

4 5 [1,3,4]
writeln (y); writeln (y+2)
[1,2,3,4]
[1,3,5]
[1,2,3,5]
Autrès critères basés sur le flot de données
 Le critère tous-les-utilisateurs nécessite souvent la
sensibilisation d’un grand nombre de chemin, deux autres
critères, intermédiaires entre tous-les-utilisateurs et toutes-
les- définitions sont proposés :
– tous-les-p-utilisateurs/quelques-c-utilisateurs : pour chaque
définition, et pour chaque p-utilisation accessible à partir de cette
définition et pour chaque branche issue de la condition associée, il y a
un chemin dr-strict prolongé par le premier segment de cette branche ;
s’il n’y a aucune p-utilisation, il suffit d’avoir un chemin dr-strict
entre la définition et l’une des c-utilisation,
– tous-les-c-utilisateurs/quelques-p-utilisateurs : pour chaque
définition, et pour chaque c-utilisation accessible à partir de cette
définition, il y a un chemin dr-strict ; s’il n’y a aucune c-utilisation, il
suffit d’avoir un chemin dr-strict entre la définition et l’une des p-
utilisation.
Critère tous-les-p-utilisateurs/quelques-c-
utilisateurs - exemple

Couverture du critère
x pair 1 read (x, y); tous-les-p-utilisateurs/
quelques-c-utilisateurs
x impair :
2
x := y+x/2 [1,3,4]
3 [1,2,3,5]
x0 x<0

4 5
writeln (y); writeln (y+2)
 Limite du critère tous-les-utilisateurs
read (x); Couverture du critère
1 tous-les-utilisateurs :

x<0 x0
2 [1,2,4,5,7]
y := 1; 3 [1,3,4,6,7]
y := 2;
4 Ces deux tests ne couvrent
x pair x impair pas tous les chemins
d’utilisation :
5 7 z := 3; 6
z := 1;

code := y+z; writeln(code);

( t vari
7 r able
) i y
p c
e e => critère
u tous-les-
d
t du-
e
ê chemins
t (
r 2
e )
u p
t o
i u
l r
i l
s a
a
Critère tous-les-du-chemins
 Ce critère rajoute au critère tous-les-utilisateurs le fait
qu’on doit couvrir tous les chemins possibles entre la
définition et la référence, en se limitant aux chemins
sans cycle.
 Sur l’exemple précédent, ce critère sensibilise :

[1,2,4,5,7]
[1,3,4,6,7]
[1,2,4,6,7]
[1,3,4,5,7]
 Hiérarchie des critères basés sur le flot de
données
tous-les-chemins
est plus fort que

tous-les-du-chemins

tous-les-utilisateurs

tous-les-c-utilisateurs/ tous-les-p-utilisateurs/
quelques-p-utilisateurs quelques-c-utilisateurs

toutes-les-définitions tous-les-arcs

tous-les-nœuds
Méthodes de test structurel basés sur la
couverture du flot de données - Exercice
read (x, y);  Critères de test :
a
– toutes-les-définitions
x0
– tous-les-utilisateurs
x>0
y := y + x b

y pair
c y impair

d n := x / 2
e n := 3*y + 1

f write(n)
Méthodes de test structurel basés sur la
couverture du flot de données - Solution
read (x, y);  Critères de test :
a
– toutes-les-définitions
x0
» [a,c,d,f] : x=1 & y=3
x>0 » [a,b,c,e,f] : x=-1 & y=3
y := y + x b
– tous-les-utilisateurs
» [a,c,d,f] : x=1 & y=3
y pair
c y impair » [a,c,e,f] : x=-1 & y=3
» [a,b,c,e,f] : x=0 & y=2
d n := x / 2
e n := 3*y + 1 » [a,b,c,d,f] : x=0 & y=3

f write(n)
3-3 Critères de couverture basés sur les fautes
– le test mutationnel
 L’idée est de considéré des variantes du programme –
les mutants – ne diffèrent que par une instruction
 Par exemple, pour l’instruction suivante dans
un programme p quelconque :
– if a > 8 then x := y
on peut considérer les mutants suivants :
– if a < 8 then x := y
– if a >= 8 then x := y
– if a >10then x := y La création des mutants est
– if a > 8 then x := y+1 basée sur des modèles de
– if a > 8 then x := x faute
– ……….
Le test mutationnel
 Cette technique vise à évaluer les Données de Tests vis-à-vis de la
liste des fautes les plus probables qui ont été envisagées (modèles
de fautes).
 Les mutations correspondent à des transformations
syntaxiques élémentaires de programme
 Pour un programme P, soit M(P) l’ensemble de tous les mutants
obtenus par le modèle de faute. Certains mutants peuvent avoir le
même comportement que P, noter E(P). On fait exécuter la suite de
tests T à chacun des mutants de M(P) et on note DM(P) l’ensemble
de ceux qui ne fournissent pas le même résultat que P.
 Le score de mutation MS(P,T) correspond à :

MS(P,T)= DM(P)
M(P) – E(P)
Le test mutationnel - Synthèse
 Le test mutationnel est plus une approche pour évaluer
la qualité d’une suite de tests : combien de mutants
fonctionnellement distinguables sont « tués »,
 Cette méthode est couteuse de mise en œuvre, en
particulier pour établir les mutants
fonctionnement distinguables des autres
=> test mutationnel faible : que sur des composants élémentaires
Règles de mutations d’opérateurs
(instructions)
operator set
1. expression deletion
2. boolean expression negation
3. term associativity shift
4. arithmetic operator by arithmetic operator
5. relational operator by relational operator
6. logical operator by logical operator
7. logical negation
8. variable by variable replacement
9. variable by constant replacement
10. constant by required constant replacement
Opérateurs de mutations (Statecharts)

Statecharts operator set

1. wrong-start-state
2. arc-missing
3. event-missing
4. event-extra
5. event-exchanged
6. destination-exchanged
7. output-missing
8. output-exchanged
4- Les outils de l’automatisation du test
 Le test de logiciels est une activité très coûteuse qui gagne à être
supportée par des outils.

 Plus de 278 outils référencés sur le site spécialisé www.stickminds.com

 Les principales catégories d’outils concernent :
o L’exécution des tests
o La gestion des campagnes
o Le test de performance
o La génération de tests fonctionnels
o La génération de tests structurels
Outils d’aide à l’exécution des tests
 Principales fonctions :
– Capture et re-exécution des scripts réalisés sur une IHM
– Sauvegarde des tests et des résultats de tests
– Génération de scripts de test en fonction des langages et des
plate- formes

 Exemples de produits :
– Mercury Winrunner
– IBM Rational Robot
– Segue Silktest
Outils de gestion des campagnes de test
 Principales fonctions :
– Définition d’une campagne de test
– Historisation des résultats
– Gestion des tests de non-regression

 Exemples de produits :
– IBM Rational Test Manager (inclut dans la Suite TestStudio)
– Segue Silkplan Pro
Outils de test de performance
 Principales fonctions :
– Test de montée en charge
– Simulation d’environnement
– Evolution aggressive de l’accès aux ressources

 Exemples de produits :
– Empirix e-Load
– Mercury LoadRunner
– Segue Silkperformer
Outils de génération de tests fonctionnels
 Principales fonctions :
– Génération des tests à partir d’un modèle des spécifications
– Animation des cas de tests
– Traçabilité des tests

 Exemple de produits :
– Leirios Test Generator
– T-Vec
– Reactis
– Conformiq
Outils de génération de tests structurels
 Principales fonctions :
– Critères de couvertures
– Evaluation du ratio de couverture
– Simulation d’environnement – Bouchonnage (Stubbing)

 Exemples de produits :
– IPL Cantata ++
– Parasoft CodeWizard