Le test de logiciels
Download
1 / 84

irisa.fr - PowerPoint PPT Presentation


  • 213 Views
  • Updated On :

Le test de logiciels. Yves Le Traon. Plan du cours 1. Introduction: importance du test et positionnement dans un contexte de GL Hiérarchisation des tests Etapes de test Le test statique Le test dynamique 2 techniques élémentaires de test fonctionnel l’analyse partitionnelle

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'irisa.fr' - Anita


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Slide1 l.jpg

Le test de logiciels

Yves Le Traon


Plan du cours 1 l.jpg
Plan du cours 1

  • Introduction: importance du test et positionnement dans un contexte de GL

    • Hiérarchisation des tests

    • Etapes de test

  • Le test statique

  • Le test dynamique

    • 2 techniques élémentaires de test fonctionnel

      • l’analyse partitionnelle

      • le test aux limites


De la difficult de la validation intra composant programming in the small l.jpg
De la difficulté de la validation intra-composant: Programming-in-the small

Acquérir une valeur positive n

Tant que n > 1 faire

si n est pair

alors n := n / 2

sinon n := 3n+1

Sonner alarme;

  • Prouver que l’alarme est sonnée pour tout n?

  • Indécidabilité de certaines propriétés

    • problème de l’arrêt de la machine de Turing...

  • Recours au test

    • ici, si machine 32 bits, 2^31 = 10^10 cas de tests

    • 5 lignes de code => 10 milliards de valeurs !


Programming in the large l.jpg
Programming-in-the-Large Programming-in-the small

  • Compilateur …………… 10 KLOC (C)

  • Système de commutation X25… 100 KLOC (C)

  • Contrôle de sous-marin nucléaire … 1 MLOC (ADA)

  • Station spatiale……… 10 MLOC (ADA)


Programming in the large5 l.jpg
Programming-in-the-Large Programming-in-the small

Gestion de la complexité due à la taille

(différence entre le bricoleur et l’architecte)

  • Méthodes basées sur la modularité (SADT, UML)

  • Gestion des ressources (matérielles, humaines) et des synchronisation de tâches

    => multiplication des risques d’erreur

    => impossibilité d’obtenir des certitudes

    => “se convaincre que”, notion de “confiance”


Validit inter composants peut on r utiliser un composant l.jpg
Validité inter-composants : Programming-in-the smallPeut-on (ré)-utiliser un composant?


Ex ariane 501 vol de qualification kourou ela3 4 juin 1996 12 34 ut l.jpg
Ex: Ariane 501 Vol de qualification Programming-in-the smallKourou, ELA3 -- 4 Juin 1996,12:34 UT

  • H0 -> H0+37s : nominal

  • Dans SRI 2:

    • BH (Bias Horizontal) > 2^15

    • convert_double_to_int(BH) fails!

    • exception SRI -> crash SRI2 & 1

  • OBC disoriented

    • Angle attaque > 20°,

    • charges aérodynamiques élevées

    • Séparation des boosters


Ariane 501 vol de qualification kourou ela3 4 juin 1996 12 34 ut l.jpg
Ariane 501 : Vol de qualification Programming-in-the smallKourou, ELA3 -- 4 Juin 1996,12:34 UT

  • H0 + 39s: auto-destruction (coût: 500M€)


Pourquoi cf ieee comp 01 97 l.jpg
Pourquoi ? Programming-in-the small(cf. IEEE Comp. 01/97)

  • Pas une erreur de programmation

    • Non-protection de la conversion = décision de conception ~1980

  • Pas une erreur de conception

    • Décision justifiée vs. trajectoire Ariane 4 et contraintes TR

  • Problème au niveau du test d’intégration

    • As always, could have theoretically been caught. But huge test space vs. limited resources


Pourquoi cf ieee computer 01 97 l.jpg
Pourquoi? Programming-in-the small(cf. IEEE Computer 01/97)

  • Réutilisation dans Ariane 5 d’un composant de Ariane 4 ayant une contrainte « cachée » !

    • Restriction du domaine de définition

      • Précondition : abs(BH) < 32768.0

    • Valide pour Ariane 4, mais plus pour Ariane 5

  • Pour la réutilisation, pour une architecture répartie =>

    • Spécification = contrat entre un composant et ses clients


La maintenance programming in the duration l.jpg
La maintenance : Programming-in-the-Duration Programming-in-the small

  • Etalement sur 10 ans ou plus d’une “ligne de produits”

  • Age moyen d’un système : 7 ans

  • 26% des systèmes ont plus de 10 ans

    (Cf. Application banquaire et Cobol)


Probl matique l.jpg

Problème Programming-in-the small

Définition des besoins

Spécification globale

détaillée

programme

Problématique

analyse des besoins

conception

Maintenance

Programme

livrable

tests

implémentation


Probl matique13 l.jpg
Problématique Programming-in-the small

Le coût du test dans le développement

analyse des

besoins

Implém.

spécification

Spécif.

Test

An. b

Implémentation

test

+ maintenance = 80 % du coût global de développement !!!


Probl matique une d finition l.jpg
Problématique: une définition ! Programming-in-the small

conformité du produit

par rapport à sa spécification

La validation

Vérification/preuve

tests


Probl matique15 l.jpg
Problématique Programming-in-the small

Pourquoi ?

Coût

Effort

Confiance


Slide16 l.jpg

Vocabulaire Programming-in-the small

Testabilité

faute

bogue

erreur

Fiabilité (Reliability)

défaillance

Test de Robustesse

Test statique

Tolérance aux fautes

Séquence de test

Test de non-régression

Données de test

Sûreté de fonctionnement (Dependability)

Jeu de test

Test statistique

Cas de test


D faillances l.jpg
Défaillances Programming-in-the small

  • Catastrophe humaine ou financière:

    • Automobile (2004) – régulateur de vitesse

    • Therac-25 (1985-1987) – radiologie et contrôle d'injection de substances radioactives

    • London Ambulance System (1992) – central et dispatch ambulances

    • Iran Air Flight 655 (1988) – guerre d'Irak et missile américain – système radar

    • Ariane 5 (1996)

    • SI du FBI (2005) – SI qui n'a pas pu être déployé

    • Mars Climate Orbiter (1999) – kilos – pounds

    • Bourse de Londres (Taurus, 1993) – SI qui n'a pas pu être déployé

  • Image de marque :

    • FT et Bouygues en 2004 – crash des serveurs – indisponibilité 48h

  • Succès financier: Windows

  • Sans conséquence mais énervant : bogue Irisa


Dues des bugs l.jpg
Dues à des bugs Programming-in-the small

  • USS Yorktown (1998)

    • Une division par zéro coupe les moteurs

  • Ariane 5 (1996)

    • Mauvaise réutilisation

  • Mars orbiter (1999)

    • Plusieurs unités de mesure

  • Système de guidage (2002)

    • Initialisation erronée

  • The Patriot and the Scud

    • mauvais arrondi dans une soustraction


Dues au processus l.jpg
Dues au processus Programming-in-the small

  • Therac-25 (official report)

    • The software code was not independently reviewed.

    • The software design was not documented with enough detail to support reliability modelling.

    • The system documentation did not adequately explain error codes.

    • AECL personnel were at first dismissive of complaints.

    • The design did not have any hardware interlocks to prevent the electron-beam from operating in its high-energy mode without the target in place.

    • Software from older models had been reused without properly considering the hardware differences.

    • The software assumed that sensors always worked correctly, since there was no way to verify them. (see open loop)

    • Arithmetic overflows could cause the software to bypass safety checks.

    • The software was written in assembly language. While this was more common at the time than it is today, assembly language is harder to debug than high-level languages.

    • ….


Processus cf ieee spectrum 09 2005 l.jpg
Processus (cf. IEEE Spectrum 09/2005) Programming-in-the small

  • Système d’information du FBI

    • abandonné en avril 2005 : coût 170 M $

    • mauvaise spécification, exigences mal exprimées

    • réutilisation dans un contexte inadapté

    • trop d’acteurs concurrents (hommes politiques, agents secrets, informaticiens)


Probl matique du test l.jpg
Problématique du test Programming-in-the small

  • Un jeune diplômé sur trois commence par faire du test

  • 50% des start-up échouent à cause du trop grand nombre de bugs

    • mauvaise campagne de test

    • maintenance difficile

    • pas de non régression


Probl matique22 l.jpg
Problématique Programming-in-the small

  • Objectifs du test

    • examiner ou exécuter un programme dans le but d’y trouver des erreurs

    • éventuellement mise à l’épreuve de :

      • la robustesse (test hors bornes/domaine)

      • des performances (test en charge)

      • de conformité (protocoles normalisés)

      • de propriétés de sûreté


Hi rarchisation des tests l.jpg
Hiérarchisation des tests Programming-in-the small

But :séparer les plans

Typiquement confusion entrefautes hardware et software

fautes fonctionnelles/structurelles

faute temps-réel / fautes classiques

Exemple :décodeur numérique

utilisateur

service

Noyau tps-réel « mou »

Décodeur

Couche applicative

90% des fautes « tps-réel » sont en fait des fautes logicielles classiques détectées trop tard


Hi rarchisation des tests24 l.jpg
Hiérarchisation des tests Programming-in-the small

But :séparer les plans

Risques :

perte d ’information d ’un plan à l ’autre

Mauvaise compréhension des fonctions à réaliser

Introduction de défauts de conception

Tendance à repousser les problèmes aux niveaux inférieurs

Maison n ’a encore rien trouvé de mieux …

à moins que l ’objet n ’offre des solutions


Hi rarchisation des tests25 l.jpg

Problème Programming-in-the small

Système

Intégration

Composants unitaires

Définition des besoins

Conception globale

programme

Hiérarchisation des tests

Maintenance

Programme livrable

analyse des besoins

Test de recette

(avec client)

Plan de test système (fonctionnel)

Tests systèmes

Cahier des charges

Plan de test d’intégration

Tests d ’intégration

?

Tests unitaires

Conception détaillée

implémentation

le cycle en « V »


Hi rarchisation des tests26 l.jpg
Hiérarchisation des tests Programming-in-the small

Développements spécifiques au test

  • Test unitaire: drivers (lanceur des tests), oracle (succès/échec), intrumentation (mesure couverture)

  • Test intégration: idem + “bouchons” de tests (stubs), pour simuler les modules non disponibles

  • Test système : test des fonctions + environnement matériel + performances.


Conditions th orique de possibilit du test l.jpg
Conditions (théorique) de possibilité du test Programming-in-the small

  • H1 : programmeur “compétent”

    Préalisé = (Pidéal)

  • H2 : Axiome de couplage (optionel)

    anomalies complexes = combinaison d’anomalies simples


Etapes de test l.jpg

G Programming-in-the small

é

n

é

r

a

t

i

o

n

C

a

s

d

e

t

e

s

t

E

x

é

c

u

t

i

o

n

D

i

a

g

n

o

s

t

i

c

P

r

o

g

r

a

m

m

e

C

o

r

r

e

c

t

i

o

n

R

é

s

u

l

t

a

t

O

r

a

c

l

e

n

o

n

R

é

s

u

l

t

a

t

-

C

o

r

r

e

c

t

D

é

f

a

i

l

l

a

n

c

e

?

o

u

i

C

r

i

t

è

r

e

d

'

a

r

r

ê

t

A

r

r

ê

t

d

e

s

t

e

s

t

s

Etapes de test


Etapes de test29 l.jpg

C Programming-in-the small

r

i

t

è

r

e

d

'

a

r

r

ê

t

Etapes de test

G

é

n

é

r

a

t

i

o

n

C

a

s

d

e

t

e

s

t

E

x

é

c

u

t

i

o

n

D

i

a

g

n

o

s

t

i

c

P

r

o

g

r

a

m

m

e

C

o

r

r

e

c

t

i

o

n

R

é

s

u

l

t

a

t

O

r

a

c

l

e

n

o

n

R

é

s

u

l

t

a

t

-

C

o

r

r

e

c

t

D

é

f

a

i

l

l

a

n

c

e

?

o

u

i

A

r

r

ê

t

d

e

s

t

e

s

t

s


Etapes de test30 l.jpg
Etapes de test Programming-in-the small

Test fonctionnel

a

b

s1

c

d

s2

e

f


Etapes de test31 l.jpg

a Programming-in-the small

b

s1

C1

M2

c

d

s2

M1

M3

e

C2

f

Etapes de test

Test fonctionnel ou test structurel

Génération aléatoire ou déterministe


Etapes de test32 l.jpg

a Programming-in-the small

b

s1

C1

M2

c

d

s2

M1

M3

e

C2

f

déterministe

aléatoire

Etapes de test

Test fonctionnel ou test structurel

Génération aléatoire ou déterministe

difficulté génération


Etapes de test33 l.jpg

a Programming-in-the small

b

s1

C1

M2

c

d

s2

M1

M3

e

C2

f

déterministe

aléatoire

Etapes de test

Test fonctionnel ou test structurel

Génération aléatoire ou déterministe

difficulté génération

difficulté oracle


Etapes de test34 l.jpg

déterministe Programming-in-the small

aléatoire

Etapes de test

Test fonctionnel

(« black-box », boîte noire)

Test structurel

(« glass box », boîte blanche ou « de verre »)

Génération aléatoire ou déterministe

Indépendant de l ’implémentation

Planifier à partir de la spécification fonctionnelle

Réutilisables

Dépend de l implémentation

difficulté génération

difficulté oracle


Etapes et hi rarchisation des tests l.jpg
Etapes et hiérarchisation des tests Programming-in-the small

Tests unitaires

Tests d ’intégration

Tests système

Test structurel

Test fonctionnel


Slide36 l.jpg

Le test en général Programming-in-the small

Problème :Génération des cas de test

  • trouver les données efficaces pour révéler les fautes

  • minimiser le nombre des données de test

Exemple :

générateur aléatoire

une addition sur 32 bits

un ensemble


Le test en g n ral l.jpg
Le test en général Programming-in-the small

Méthodes de génération des tests :

1) Génération déterministe

Génération « à la main » des cas de test et des oracles

Deux critères :

- couvrir une portion précise du logiciel (critère stucturel)

- couvrir les fonctions du logiciel (critère fonctionnel)

Pas de méthode miracle

Avantage ? :nécessitant une forte implication humaine

les tests plus efficaces ?


Le test en g n ral38 l.jpg
Le test en général Programming-in-the small

Méthodes de génération des tests :

2) Génération aléatoire des données

Profil opérationnel

Freq

Performances

Seuil_alerte

120

750

P (bars)

Crash ou grosses défaillances

1

4.5


Le test en g n ral39 l.jpg
Le test en général Programming-in-the small

Méthodes de génération des tests :

2) Génération aléatoire des données

Test par mutation

Variantes

Test statistique

On ne connaît pas les données d ’entrée

Exemples :

Le flot d ’entrée est fourni par le client

Le flot d ’entrée est obtenu via une antenne etc.


Le test en g n ral40 l.jpg
Le test en général Programming-in-the small

2) Génération guidée par les contraintes (analyse symbolique)

Procedure lissage(in: integer; var out :integer)

begin

if in < Val1 then

begin

if in > Val2 then out := trt1;

out:=trt2;

end

else out:=trt3;

Val2

Val1

trt2

trt1;

trt2;

trt3

Contraintes rapidement trop complexes

Uniquement test structurel (on a accès au code)


Le test en g n ral41 l.jpg
Le test en général Programming-in-the small

Limites du test aléatoire : couvre toujours les mêmes cas

Nb_fautes

Test aléatoire

Test déterministe

compromis

Analyse aux limites

(contraintes)

Nb_cas_test

AT

AT

AT


Le test en g n ral42 l.jpg

! Programming-in-the small

Le test en général

Problèmes :exécution des tests

  • environnement de développement « propre »

  • environnement de test

  • debugger (points d ’arrêt, suivi de l ’état des données du programme sous test)

  • instrumentation automatique du code/outils d ’observation (couverture etc.) -> logiscope & Co.

  • on ne teste que rarement le système tel qu’il sera chez le client (partie simulée, systèmes embarqués, parties non-terminées ou sous traitées ailleurs …) -> environnement de simulation (potentiellement bogué)

Exemple :

ARIANE V


Le test en g n ral43 l.jpg
Le test en général Programming-in-the small

Problèmes: oracle (ou verdict)

Oracle :expression booléenne caractérisant la détection d ’une erreur

Généralement = (resultat_attendu = résultat_obtenu)

Ou bien : levée d ’une exception

Exemple : génération aléatoire des données de test

Système

Données générées aléatoirement

?

Résultat correct


Avant le test mieux vaut pr venir que gu rir l.jpg
Avant le test… Programming-in-the smallmieux vaut prévenir que guérir

Un principe : plus une faute est détectée tard, plus elle coûte cher

Moralité : Mieux vaut prévenir que guérir

2 moyens principaux

a) Analyse de testabilité

b) « test statique »


Avant le test mieux vaut pr venir que gu rir45 l.jpg

Too late! Programming-in-the small

Avant le test…mieux vaut prévenir que guérir

$

Testabilité

Traçabilité

Spécifications non ambiguës

Faute de conception

Tests unit.

Tests int.

Tests Syst.

Conception

Implé.

Maintenance.


Test statique l.jpg
Test statique Programming-in-the small

Techniques de « test statique »

Définition : ne requiert pas l ’exécution du logiciel sous-test sur des données réelles

réunions de 4 personnes environ pour inspecter le code

1 modérateur, le programmeur, le concepteur et 1 inspecteur


Test statique47 l.jpg
Test statique Programming-in-the small

Préparation:Distribution des documents quelques jours avant la séance (code, spec, éventuellement cas de test prévus)

Durée :1h30 à 2h max

But :le programmeur lit et explique son programme

le concepteur et l ’inspecteur apportent leur expertise

les fautes sont listées

(pas corrigées-> à la charge du programmeur)


Test statique48 l.jpg
Test statique Programming-in-the small

Efficacité :plus de 50 % de l ’ensemble des fautes d ’un projet sont détectées lors des inspections si il y en a (en moyenne plus de 75%)

Défaut :mise en place lourde, nécessité de lien transversaux entre équipes, risques de tension…tâche plutôt fastidieuse


Test statique49 l.jpg
Test statique Programming-in-the small

  • Règles

    • être méthodique (cf. transparents suivants)

    • un critère : le programme peut-il être repris par quelqu’un qui ne l’a pas fait

    • un second critère : les algorithmes/l’architecture de contrôle apparaît-elle clairement ?

    • > décortiquer chaque algo et noter toute redondance curieuse (coller) et toute discontinuité lorsqu’il y a symétrie (ce qui peut révéler une modif incomplète du programme)


Test statique50 l.jpg
Test statique Programming-in-the small

Exemple: vérification de la clarté (procédural)

R1 :Détermination des paramètres globaux

et de leur impact sur les fonctions propres

program recherche_tricho;

uses crt;

const

max_elt = 50;

choix1 = 1;

choix2 = 2;

fin = 3;

type

Tliste = array[1..max_elt] of integer;

var

liste : Tliste;

taille, choix, val : integer;

complex : integer;

But du programme non exprimé

Manque de commentaires

Identificateurs non explicites


Test statique51 l.jpg
Test statique Programming-in-the small

Exemple: vérification de la clarté

R2 : Existence d’un entête clair pour chaque fonction

{--------------------------------------------------------------------------

Recherche recursive d'une valeur dans une liste triee

--------------------------------------------------------------------------}


Test statique pour chaque fonction l.jpg
Test statique: pour chaque fonction Programming-in-the small

  • Commentaires minimum

  • manque

  • le nom de la fonction

  • dépendance avec autres variables/fonctions

{ parametres d'entree : liste L

la valeur recherchee

indice gauche

indice droit

resultat : complexite de la recherche }

Interface

Spécifiée

?

Interface implantée

function rech_rec(L : Tliste ; val, g, d : integer) : integer ;


Test statique53 l.jpg
Test statique Programming-in-the small

Quézako ?

var i, pt, dt : integer;

begin

affiche(L, g, d);

if g<d

then

begin

pt :=g+(d-g) div 3;

if val > L[pt]

then

begin

dt := (pt+1+d) div 2;

if val > L[pt]

then rech_rec:=2+rech_rec(L, val, dt+1, d)

else rech_rec:=2+rech_rec(L, val, pt+1, dt)

end

else rech_rec:=1+rech_rec(L, val, g, pt)

end

else rech_rec:=0

end; { rech_rec }

Action non spécifiée

Répétition ?


Test statique54 l.jpg
Test statique Programming-in-the small

Autre méthodes :

revues,

métriques (contraintes etc.),

analyse d ’anomalies

(du graphe de contrôle/de données),

règles (de bon sens!)

identificateurs clairs,

découpage fonctionnel « naturel »

limiter les effets de bords

(interfaces, variables globales)

preuves d ’algorithmes,

exécution symbolique,

simulation de modèles, etc.


Test dynamique vocabulaire l.jpg
Test dynamique : Vocabulaire Programming-in-the small

  • DT : Donnée de Test = une (séquence) d’entrée(s)

  • JT = {DT}

  • D = domaine d’entrée du programme P sous test

  • Soient F, les fonctions spécifiées du logiciel

    F : D -> Sorties

    Le problème du test dynamique est :

    D  Sorties

    Pratiquement : TD : tTP(t)=F(t)

F=P ?


Test dynamique l.jpg
Test dynamique Programming-in-the small

  • DEUX REGLES :

    • Conserver les tests déjà écrits

    • Conserver les réponses correctes correspondantes


Test dynamique57 l.jpg
Test dynamique Programming-in-the small

Exemple simplissime:

exe < fichier_testi

  • quand correct : exe < fichier_testi > res_testi

  • Lorsque intégration : Driver de test existe déjà

  • Lorsque évolution : Tests de non-régression

    newexe < fichier_testi > res_test_newexe

    diff res_test_newexe

C’est plus simple en OO (classes autotestables)


Test dynamique structurel l.jpg
Test dynamique structurel Programming-in-the small

“Testing can prove the presence of bugs, but never their absence” (Dijkstra)

Critère de test : adéquat


Le test structurel abstraire pour obtenir un crit re formel l.jpg
Le test structurel: abstraire pour obtenir un critère formel

C

si C alors I1

sinon I2

I1

I2


Le test unitaire structurel l.jpg
Le test unitaire structurel formel

  • Graphe de Contrôle (langages procéduraux/actionnels)

    • But : représenter tous les chemins d’exécution potentiels

    • Graphe orienté : avec un noeud d’entrée E et un nœud de sortie S

      (nœud fictif ajouté si plusieurs sorties)

    • Sommets :

      blocs élémentaires du programme, ou prédicats des conditionnelles /boucles, ou nœuds de jonction “vide” associé à un noeud prédicat

      Bloc élémentaire : séquence maximale d’instructions séquentielles

    • Arcs :

      enchaînement d’exécution possibles entre deux sommets


Le test unitaire structurel61 l.jpg

E formel

B1

P1

P2

B2

B3

B4

S

Le test unitaire structurel

Exemple : PGCD de 2 nombres

Précondition: p et q entiers naturels positifs lus au clavier

Effet : result = pgcd(p, q)

En pseudo-langage

pgcd: integer is

local p,q : integer;

do

read(p, q)

while p<> q do

if p > q

then p := p-q

else q:= q-p

end -- if

end -- while

result:=p

end-- pgcd

p=q

p<>q

B1

P1

p>q

p<=q

P2

B2

B3

B4


Le test unitaire structurel62 l.jpg
Le test unitaire structurel formel

  • Question : Sur ce modèle imaginer un critère de couverture

    • minimal

    • maximal


Le test unitaire structurel63 l.jpg
Le test unitaire structurel formel

  • Chemins : suite d’arcs rencontrés dans le graphe, en partant de E et finissant en S.

    • en général représenté sans perte d’information par une liste de sommets

  • Prédicat de chemin : conjonction des prédicats (ou de leur négation) rencontrés le long du chemin.

    • Pas toujours calculable

      E B1 P1 P2 B2 S : p1=q1 & p0 > q0 (pi = ième valeur de p)

      E B1 P1 P2 B3 S : p1=q1 & p0 <= q0 (pi = ième valeur de p)

      E B1 P1 (P2 B2)n S : pn=qn & (pi > qi i [0..n])

      Chemins infaisables : problème en général indécidable


  • Le test unitaire structurel64 l.jpg
    Le test unitaire structurel formel

    Sélection des tests fondés sur le flot de contrôle

    • Couverture des instructions : chaque bloc doit être exécuté au moins une fois

    • Couverture des arcs ou enchaînements

    • tous les chemins élémentaires ou 1-chemins

    • tous les i-chemins : de 0 à i passages dans les boucles

    • tous les chemins : si boucles, potentiellement infinis


    Le test unitaire structurel65 l.jpg
    Le test unitaire structurel formel

    • Question : différence entre couverture arcs et couverture instructions ?

    • Faire Exemple


    Le test unitaire structurel66 l.jpg

    E formel

    B1

    P1

    p<>q

    p=q

    P2

    B2

    p>q

    p<=q

    B3

    B4

    S

    Le test unitaire structurel

    Toutes les instructions:

    (E, B1, P1, P2, B2, P1, B4, S)

    (E, B1, P1, P2, B3, P1, B4, S)

    Tous les arcs : idem

    Tous les chemins élémentaires (1-chemin) :

    idem + (E, B1, P1, B4, S)

    Tous les 2-chemins :

    idem +

    (E, B1, P1, P2, B2, P1, P2, B2, P1, B4, S)

    (E, B1, P1, P2, B2, P1, P2, B3, P1, B4, S)

    (E, B1, P1, P2, B3, P1, P2, B2, P1, B4, S)

    (E, B1, P1, P2, B3, P1, P2, B3, P1, B4, S)


    Test unitaire structurel l.jpg

    Cf. diff formel

    if then imbriqués

    Couverture des prédicats

    Aspects données

    Couverture des dépendances entre variables

    Flot de données

    (Weyuker)

    Couverture des domaines d’entrée

    Pertinence des données - pas de modèle -

    (Mutation etc.

    Test unitaire structurel

    • Questions : qu’est-ce que ne capture pas ce modèle ?


    Le test unitaire structurel68 l.jpg
    Le test unitaire structurel formel

    • Graphe de Flot de Données (Weyuker)

      • But : représenter les dépendances entre les données du programme dans le flot d’exécution.

      • Graphe de contrôle décoré d’informations sur les données (variables) du programme.

      • Sommets :idem GC

        • une définition (= affectation) d’une variable v est notée def(v)

        • une utilisation d’une variable est v notée P_use(v) dans un prédicat et C_use(v) dans un calcul.


    Le test unitaire structurel69 l.jpg

    E formel

    B1

    P1

    p<>q

    p=q

    P2

    B2

    p>q

    p<=q

    B3

    B4

    S

    Le test unitaire structurel

    Exemple

    pgcd: integer is

    local p,q : integer;

    do

    read(p, q)

    while p<> q do

    if p > q

    then p := p-q

    else q:= q-p

    end -- if

    end -- while

    result:=p

    end-- pgcd

    Def(p)

    B1- Def(p), Def(q)

    Puse(p)

    P1 - Puse(p), Puse(q)

    P2- Puse(p), Puse(q)

    Puse(p)

    B2- Def(p), Cuse(q), Cuse(p)

    B3 - Def(q), Cuse(p),Cuse(q)

    Cuse(p)

    Cuse(p)

    Cuse(p)

    B4- Cuse(p),


    Slide70 l.jpg

    Le test en général: critères d ’arrêt formelunitaire : flot de données

    Autres critères structurels : lien definition-utilisation (Weyuker)

    Program pilote_automatique

    var

    probleme: boolean;

    direction : integer in [1..360]

    begin

    saisir_direction(direction);

    probleme := false;

    while notproblemedo

    begin piloter(avion, auto,direction) end;

    if capteur_pression < 120 thenprobleme := true end

    ifproblemethen traiter_probleme(capteur_pression)

    ….

    end

    Définition 1

    Utilisation 1.1

    Définition 2

    Utilisation 1.2

    Utilisation 2.1


    Le test unitaire structurel crit re d arr t complexit et flot de contr le l.jpg

    2 formel

    1

    Le test unitaire structurel: critère d ’arrêt, complexité et flot de contrôle

    Couverture de chemins : le nombre cyclomatique (Mc Cabe)

    le Npath (Nejmeh)

    1

    2

    6

    5

    3

    3

    6

    2

    4

    1

    4

    5

    V = 2

    V = 6

    V = 6

    Npath = 2

    Npath = 6

    Npath = 32


    Le test en g n ral crit res d arr t l.jpg
    Le test en général: critères d ’arrêt formel

    Nombre de chemins

    pour couvrir

    la structure de contrôle

    Nombre cyclomatique

    Npath

    Nombre total des chemins

    de contrôle

    effort de mise en œuvre d’une technique

    de test structurel


    Vers le test structurel d int gration l.jpg
    ...vers le test structurel d’intégration formel

    Couverture du graphe d ’appel

    Pilotage_manuel

    Pilote_automatique

    Saisir_direction

    piloter

    traiter_probleme

    ...

    ...

    Traitement_reconfiguration

    Traitement_urgence

    ...

    ...


    Le test d int gration l.jpg
    Le test d’intégration formel

    • But : vérifier les interactions entre composants (se base sur l’architecture de la conception)

    • Difficultés principales de l’intégration

      • interfaces floues

      • implantation non conforme au modèle architectural (dépendances entre composants non spécifiées)

      • réutilisation de composants (risque d’utilisation hors domaine)


    Le test d int gration75 l.jpg
    Le test d’intégration formel

    • Stratégies possibles (si architecture sans cycles)

      • big-bang : tout est testé ensemble. Peu recommandé !

      • bottom-up: de haut en bas. Peu courant. Ecriture uniquement de drivers de tests.

      • top-down: la plus classique. On intègre depuis les feuilles.


    Le test d int gration76 l.jpg
    Le test d’intégration formel

    D

    D

    Driver

    • 3 stratégies: bottom-up, Top-down, Big-Bang.

    S

    Stub

    T

    Composant testé

    Composant sous test

    Interface sous test

    Interface testée


    Le test d int gration77 l.jpg

    D formel

    D

    D

    T

    T

    T

    T

    Le test d’intégration

    • Bottom-up

    D

    D

    D

    D


    Le test d int gration78 l.jpg

    D formel

    D

    D

    D

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    Le test d’intégration


    Le test d int gration79 l.jpg
    Le test d’intégration formel

    D

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T


    Le test d int gration80 l.jpg

    T formel

    Le test d’intégration

    D

    D

    Top-Down

    S

    S

    S

    S

    S


    Le test d int gration81 l.jpg

    T formel

    Le test d’intégration

    D

    S

    S

    S


    Le test d int gration82 l.jpg

    T formel

    T

    T

    T

    T

    T

    T

    T

    T

    Le test d’intégration

    D

    D

    S

    S

    S

    S

    S

    S


    Le test d int gration83 l.jpg

    T formel

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    T

    Le test d’intégration

    D

    D


    Le test d int gration84 l.jpg
    Le test d’intégration formel

    • intégration Big-Bang

    • intégration Top-down

    • intégration bottom-up

    • intégration backbone

    • intégration par domaines de collaboration