e Test des logiciels

Le test de logiciels

Yves Le Traon

e Test des logiciels

Plan du cours 1
Introduction: importance du test et positionnement dans un contexte de GL
Hirarchisation des tests Etapes de test

Le test statique Le test dynamique

techniques lmentaires de test fonctionnel
lanalyse partitionnelle le test aux limites les graphes cause-effet

test structurel unitaire

Test dintgration: stratgies de base

e Test des logiciels

De la difficult de la validation intracomposant: Programming-in-the small

Acqurir une valeur positive n Acqurir une valeur positive n Tant que n > 1 faire Tant que n > 1 faire si n est pair si n est pair alors n := n //2 alors n := n 2 sinon n := 3n+1 sinon n := 3n+1 Sonner alarme; Sonner alarme;

Prouver que lalarme est sonne pour tout n? Indcidabilit de certaines proprits
problme de larrt 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 !

e Test des logiciels

Programming-in-the-Large
Compilateur Systme de commutation X25 Contrle de sous-marin nuclaire Station spatiale

10 KLOC (C) 100 KLOC (C) 1 MLOC (ADA) 10 MLOC (ADA

e Test des logiciels

Programming-in-the-Large
Gestion de la complexit due la taille
(diffrence entre le bricoleur et larchitecte) Mthodes bases sur la modularit (SADT, UML) Gestion des ressources (matrielles, humaines) et des synchronisation de tches => multiplication des risques derreur => impossibilit dobtenir des certitudes => se convaincre que, notion de confiance

e Test des logiciels

Validit inter-composants : Peut-on (r)-utiliser un composant?

e Test des logiciels

Ex: Ariane 501 Vol de qualification Kourou,

ELA3 -- 4 Juin 1996,12:34 H0 -> H0+37s : nominal Dans SRI 2:
BH (Bias Horizontal) > 2^15 convert_double_to_int(BH) fails! exception SRI -> crash SRI2 & 1

UT

OBC disoriented
Angle attaque > 20, charges arodynamiques leves Sparation des boosters

e Test des logiciels

Ariane 501 : Vol de qualification

Kourou, ELA3 -- 4 Juin 1996,12:34 UT

H0 + 39s: auto-destruction (cot:

500M)

e Test des logiciels

Pourquoi ? (cf. IEEE Comp. 01/97)

Pas une erreur de programmation
Non-protection de la conversion = dcision de conception ~1980

Pas une erreur de conception

Dcision justifie vs. trajectoire Ariane 4 et contraintes TR

Problme au niveau du test dintgration

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

e Test des logiciels

Pourquoi? (cf. IEEE Computer 01/97)

Rutilisation dans Ariane 5 dun composant de Ariane 4 ayant une contrainte cache !
Restriction du domaine de dfinition
Prcondition : abs(BH) < 32768.0

Valide pour Ariane 4, mais plus pour Ariane 5

Pour la rutilisation, pour une architecture rpartie =>

Spcification = contrat entre un composant et ses clients

e Test des logiciels

La maintenance : Programming-in-the-Duration Etalement sur 10 ans ou plus dune ligne de produits Age moyen dun systme : 7 ans 26% des systmes ont plus de 10 ans
(Cf. Application banquaire et Cobol)

e Test des logiciels

Problmatique
Problme analyse des besoins

Dfinition des besoins conception Spcification globale dtaille implmentation programme

Maintenance Programme livrable

tests

e Test des logiciels

Problmatique
Le cot du test dans le dveloppement

Implm. Spcif. An. b Test

analyse des besoins spcification Implmentation test

+ maintenance = 80 % du cot global de dveloppement !!!

e Test des logiciels

Problmatique: une dfinition !

conformit du produit par rapport sa spcification Vrification/preuve

La validation

tests

e Test des logiciels

Problmatique
Pourquoi ?

Cot

Effort

Confiance

e Test des logiciels

Vocabulaire
Testabilit faute erreur Test de Robustesse bogue Fiabilit (Reliability)

dfaillance

Test statique Tolrance aux fautes Squence de test Donnes de test Sret de fonctionnement (Dependability) Jeu de test Cas de test Test statistique

Test de non-rgressio

e Test des logiciels

Problmatique
Objectifs du test
examiner ou excuter un programme dans le but dy trouver des erreurs ventuellement mise lpreuve de :
la robustesse (test hors bornes/domaine) des performances (test en charge) de conformit (protocoles normaliss) de proprits de sret

e Test des logiciels

Hirarchisation des tests

But : sparer les plans
Typiquement confusion entre fautes hardware et software fautes fonctionnelles/structurelles faute temps-rel / fautes classiques utilisateur

Exemple : dcodeur numrique

Noyau tps-rel mou

service

Dcodeur
Couche applicative

90% des fautes tps-rel sont en fait des fautes logicielles classiques dtectes trop tard

e Test des logiciels

Hirarchisation des tests

But : sparer les plans Risques : perte d information d un plan l autre
Mauvaise comprhension des fonctions raliser Introduction de dfauts de conception Tendance repousser les problmes aux niveaux infrieurs

Mais on n a encore rien trouv de mieux

moins que l objet n offre des solutions

e Test des logiciels

Maintenanc

Hirarchisation des tests

Problme analyse des besoins Dfinition des besoins
Plan de test systme (fonctionnel)

Programme livrable

Test de recett (avec client) Systme Tests systmes

Cahier des charges Conception globale

Plan de test dintgration

Intgration

Tests d intgration

? Conception dtaille implmentation programme

Composants unitaires

Tests unitaires

le cycle en V

e Test des logiciels

Niveau unitaire
Unit Level Components
=> implement specified functions how can you trust them ? How using/reusing them safely ?
off-the-shelf
LOCAL_NAME CALL_PROC_CALL E_FEATURE + is_deferred : Boolean = initval INSTRUCTION

A component has a stability an identified interface

BASE_CLASS + is_manifest_string+ path : String : Boolean + is_result : Boolean+ is_deferred : Boolean + is_void : Boolean + is_expanded : Boolean /+ is_generic : Boolean + is_any : Boolean = initval + is_general : Boolean

EXPORT_ITEM RENAME_PAIR FEATURE_NAME_LIST

(from InheritanceClause) InheritanceClause) (from

e Test des logiciels

Intgration
INSTRUCTION

E_RETRY E_CHECK IFTHENELSE ONCE_PROCEDURE ONCE_FUNCTION DEFERRED_FUNCTION DEFERRED_PROCEDURE NATIVE_C NATIVE_SMALL_EIFFEL NATIVE_JVM IFTHEN EXTERNAL_FUNCTION EXTERNAL_PROCEDURE

Integration/Evolution
How integrating them safely ? How optimizing integration?
TYPE

E_DEBUG

+then_compound ONCE_ROUTINE FUNCTION PROCEDURE COMPOUND

E_LOOP

EFFECTIVE_ROUTINE DEFERRED_ROUTINE EXTERNAL_ROUTINENATIVE +native

WRITABLE_ATTRIBUTE CST_ATT E_INSPECT WHEN_LISTE_WHEN WHEN_ITEM LOCAL_VAR_LIST ROUTINE REVERSE_ASSIGNMENT EXPRESSION CREATION_CALL PROC_CALL ASSIGNMENT +call +type WHEN_ITEM_1 ATTRIBUTE

DECLARATION + count : Integer

E_FEATURE + is_deferred : Boolean = initval DECLARATION_LIST FORMAL_ARG_LIST

A Transition Step

+result_type EXPRESSION CALL_PROC_CALL GLOBALS 1 +writable 1 DECLARATION_GROUP DECLARATION_1 +target 0..* +arguments SMALLEIFFEL LOCAL_NAME ARGUMENT_NAME FEATURE_CLAUSE +list

CALL

+ magic_count : Integer +list TYPE + is_ready : Boolean + load_class() + get_started() +name_list +to_runnable + falling_down() +result_type+ afd _check() +name FEATURE_CLAUSE_LIST +feature_clause_list +base_class_dictionary +base_class +base_class

+result_type +clients TYPE +clients CLIENT_LIST

FEATURE_NAME + is_frozen : Boolean

LOCAL_ARGUMENT CLASS_NAME

+list CLASS_NAME

+names CREATION_CLAUSE FEATURE_NAME_LIST +procedure_list +list

NAME BASE_CLASS + is_manifest_string+ path : String : Boolean + is_result : Boolean+ is_deferred : Boolean + is_void : Boolean + is_expanded : Boolean /+ is_generic : Boolean + is_any : Boolean = initval + is_general : Boolean +origin_base_class +base_class EXPORT_ITEM RENAME_PAIR FEATURE_NAME_LIST
(from InheritanceClause) InheritanceClause) (from

CREATION_CLAUSE_LIST EXPRESSION FEATURE_NAME

+creation_clause_list +base_class

+base_class SIMPLE_FEATURE_NAME FROZEN_FEATURE_NAME INFIX_NAME PREFIX_NAME

+export_list +rename_list +undefine_list +parent_list PARENT_LIST +redefine_list (from InheritanceClause) +select_list PARENT
(from InheritanceClause)

+current_type

TYPE / path : String +generic_list

FORMAL_GENERIC_ARG + +constraint : boolean constrained + rank : Integer

+list FORMAL_GENERIC_LIST

TYPE_CHARACTER

+formal_generic_list +formal_generic_list TYPE_GENERIC TYPE_FORMAL_GENERIC TYPE_CLASS

(from TYPE) (from TYPE) (from TYPE)

TYPE_POINTER TYPE_ANY TYPE_NONE

e Test des logiciels

Test systme
E_RETRY

System
= a coherent components set
=>implement specified functions => a more elaborated component

E_CHECK 0..* INSTRUCTION IFTHENELSE

ONCE_PROCEDURE ONCE_FUNCTION DEFERRED_FUNCTION DEFERRED_PROCEDURE NATIVE_C NATIVE_SMALL_EIFFEL NATIVE_JVM IFTHEN EXTERNAL_FUNCTION EXTERNAL_PROCEDURE

+then_compound ONCE_ROUTINE FUNCTION PROCEDURE +else_compound COMPOUND E_DEBUG E_LOOP +loop_body +initialize +else_compound +local_vars E_INSPECT +list +list WHEN_LISTE_WHEN WHEN_ITEM LOCAL_VAR_LIST

+routine_body EFFECTIVE_ROUTINE DEFERRED_ROUTINE EXTERNAL_ROUTINENATIVE +native + language_name : String +rescue_compound WRITABLE_ATTRIBUTE CST_ATT

ROUTINE REVERSE_ASSIGNMENT WHEN_ITEM_1 WHEN_ITEM_2

+value ATTRIBUTE EXPRESSION

CREATION_CALL PROC_CALL ASSIGNMENT +call +type TYPE +left_side +right_side

DECLARATION + count : Integer

E_FEATURE +arguments DECLARATION_LIST FORMAL_ARG_LIST+ is_deferred : Boolean = initval

+result_type EXPRESSION CALL_PROC_CALL GLOBALS 1 +writable 1 DECLARATION_GROUP DECLARATION_1 +target 0..* +arguments

LOCAL_NAME ARGUMENT_NAME TYPE CALL

FEATURE_CLAUSE +list SMALLEIFFEL + magic_count : Integer +list + is_ready : Boolean +result_type +clients TYPE +clients CLIENT_LIST

+ load_class() + get_started() +name_list +to_runnable + falling_down() +result_type+ afd _check() +name FEATURE_NAME + is_frozen : Boolean LOCAL_ARGUMENT CLASS_NAME +name +base_class_dictionary +base_class +base_class FEATURE_CLAUSE_LIST +feature_clause_list

A finalized system has a stability an identified interface

+list CLASS_NAME

System = Component

+names CREATION_CLAUSE FEATURE_NAME_LIST +procedure_list +list

NAME BASE_CLASS + is_manifest_string+ path : String : Boolean + is_result : Boolean+ is_deferred : Boolean + is_void : Boolean + is_expanded : Boolean /+ is_generic : Boolean + is_any : Boolean = initval + is_general : Boolean +origin_base_class +base_class EXPORT_ITEM RENAME_PAIR FEATURE_NAME_LIST
(from InheritanceClause) InheritanceClause) (from

CREATION_CLAUSE_LIST EXPRESSION FEATURE_NAME

+creation_clause_list +base_class

+base_class FROZEN_FEATURE_NAME INFIX_NAME PREFIX_NAME SIMPLE_FEATURE_NAME

+export_list +rename_list +undefine_list +parent_list PARENT_LIST +redefine_list (from InheritanceClause) +select_list PARENT
(from InheritanceClause)

+current_type

TYPE / path : String +generic_list

FORMAL_GENERIC_ARG + +constraint : boolean constrained + rank : Integer

+list FORMAL_GENERIC_LIST

TYPE_CHARACTER

+formal_generic_list +formal_generic_list TYPE_GENERIC TYPE_CLASS TYPE_FORMAL_GENERIC

(from TYPE) (from TYPE) (from TYPE)

TYPE_POINTER TYPE_ANY TYPE_NONE

e Test des logiciels

Des composants au systme?

Integration

Evolution

Unit component

System component

A Classical View...

e Test des logiciels

Hirarchisation des tests

Dveloppements spcifiques au test
Test unitaire: drivers (lanceur des tests), oracle (succs/chec), intrumentation (mesure couverture) Test intgration: idem + bouchons de tests (stubs), pour simuler les modules non disponibles Test systme : test des fonctions + environnement matriel + performances.

e Test des logiciels

Conditions (thorique) de possibilit du test

H1 : programmeur comptent Pralis = (Pidal) H2 : Axiome de couplage (optionel)
anomalies complexes = combinaison danomalies simples

e Test des logiciels

Etapes de test
Gnration Cas de test Excution Programm e Rsultat Oracle Rsultat-Correct ? oui Critre d'arrt non Dfaillanc e

Diagnostic Correction

Arrt des tests

e Test des logiciels

Etapes de test
Gnration Cas de test Excution Programm e Rsultat Oracle Rsultat-Correct ? oui Critre d'arrt non Dfaillanc e

Diagnostic Correction

Arrt des tests

e Test des logiciels

Etapes de test
4 Test fonctionnel
a b c d e f

s1 s2

e Test des logiciels

Etapes de test
4 Test fonctionnel ou test structurel
a b c d e f s1 s2

C1 M1 C2

M2 M3

Gnration alatoire ou dterministe

e Test des logiciels

Etapes de test
4 Test fonctionnel ou test structurel
a b c d e f s1 s2

C1 M1 C2

M2 M3

Gnration alatoire ou dterministe

dterministe difficult gnration

alatoire

e Test des logiciels

Etapes de test
4 Test fonctionnel ou test structurel
a b c d e f s1 s2

C1 M1 C2

M2 M3

Gnration alatoire ou dterministe

dterministe difficult gnration

alatoire difficult oracle

e Test des logiciels

Etapes de test
4 Test fonctionnel ( black-box , bote noire)
Indpendant de l implmentation Planifier partir de la spcification fonctionnelle Rutilisables

4 Test structurel ( glass box , bote blanche ou de verre ) 4

Dpend de l implmentation

Gnration alatoire ou dterministe

dterministe difficult gnration

alatoire difficult oracle

e Test des logiciels

Etapes et hirarchisation des tests

Test structurel

Tests unitaires Tests d intgration

Test fonctionnel

Tests systme

e Test des logiciels

Le test en gnral
Problme : Gnration des cas de test
trouver les donnes efficaces pour rvler les fautes minimiser le nombre des donnes de test

Exemple : gnrateur alatoire une addition sur 32 bits un ensemble

e Test des logiciels

Le test en gnral
Mthodes de gnration des tests :
1) Gnration dterministe
Gnration la main des cas de test et des oracles Deux critres : - couvrir une portion prcise du logiciel (critre stucturel) - couvrir les fonctions du logiciel (critre fonctionnel) Pas de mthode miracle

Avantage ? : ncessitant une forte implication humaine les tests plus efficaces ?

e Test des logiciels

Le test en gnral
Mthodes de gnration des tests :
2) Gnration alatoire des donnes

Profil oprationnel Freq T

120 750

Performances Seuil_alerte

P (bars)

Crash ou grosses dfaillances

4.5

e Test des logiciels

Le test en gnral
Mthodes de gnration des tests :
2) Gnration alatoire des donnes
Test par mutation Variantes Test statistique On ne connat pas les donnes d entre Exemples : Le flot d entre est fourni par le client Le flot d entre est obtenu via une antenne etc.

e Test des logiciels

Le test en gnral
2) Gnration guide 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 accs au code)

e Test des logiciels

Le test en gnral

Limites du test alatoire : couvre toujours les mmes cas

Nb_fautes

Test alatoire

Test dterministe compromis Analyse aux limites (contraintes)

Nb_cas_test

AT

AT

AT

e Test des logiciels

Le test en gnral
Problmes : excution des tests
environnement de dveloppement propre environnement de test debugger (points d arrt, suivi de l tat des donnes du programme sous test) instrumentation automatique du code/outils d observation (couverture etc.) -> logiscope & Co.

on ne teste que rarement le systme tel quil sera chez le client (partie simule, systmes embarqus, parties non-termines ou Exemple : sous traites ailleurs ) -> environnement de simulation ARIANE V (potentiellement bogu)

e Test des logiciels

Le test en gnral
Problmes : oracle (ou verdict)
Oracle : expression boolenne caractrisant la dtection d une erreur Gnralement = (resultat_attendu = rsultat_obtenu) Ou bien : leve d une exception
Exemple : gnration alatoire des donnes de test

Donnes gnres alatoirement

Systme

Rsultat correct

e Test des logiciels

Avant le test mieux vaut prvenir que gurir

Un principe : plus une faute est dtecte tard, plus elle cote cher Moralit : Mieux vaut prvenir que gurir 2 moyens principaux
a) Analyse de testabilit b) test statique

e Test des logiciels

Too late!

Avant le test mieux vaut prvenir que gurir

$
Faute de conception

Testabilit Traabilit Spcifications non ambigus

Conception

Impl.

Tests unit.

Tests int.

Tests Syst. Maintenance.

e Test des logiciels

Test statique
Techniques de test statique
Dfinition : ne requiert pas l excution du logiciel soustest sur des donnes relles

runions de 4 personnes environ pour inspecter le code

1 modrateur, le programmeur, le concepteur et 1 inspecteur

e Test des logiciels

Test statique
Prparation: Distribution des documents quelques jours avant la
sance (code, spec, ventuellement cas de test prvus)

Dure : 1h30 2h max But : le programmeur lit et explique son programme

le concepteur et l inspecteur apportent leur expertise les fautes sont listes (pas corriges-> la charge du programmeur)

e Test des logiciels

Test statique

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

Dfaut : mise en place lourde, ncessit de lien transversaux entre quipes, risques de tensiontche plutt fastidieuse

e Test des logiciels

Test statique
Rgles
tre mthodique (cf. transparents suivants) un critre : le programme peut-il tre repris par quelquun qui ne la pas fait un second critre : les algorithmes/larchitecture de contrle apparat-elle clairement ? > dcortiquer chaque algo et noter toute redondance curieuse (coller) et toute discontinuit lorsquil y a symtrie (ce qui peut rvler une modif incomplte du programme)

e Test des logiciels

Test statique
Exemple: vrification de la clart (procdural) R1 :Dtermination des paramtres 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

e Test des logiciels

Test statique
Exemple: vrification de la clart R2 : Existence dun entte clair pour chaque fonction
{-------------------------------------------------------------------------Recherche recursive d'une valeur dans une liste triee --------------------------------------------------------------------------}

e Test des logiciels

Test statique: pour chaque fonction

Commentaires minimum

{ parametres d'entree : liste L la valeur recherchee manque indice gauche e nom de la fonction indice droit dpendance avec resultat : complexite de la recherche } utres

Interface Spcifie
?

ariables/fonctions

Interface implante

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

e Test des logiciels

var i, pt, dt : integer;

Test statique

Quzako ?

begin affiche(L, g, d); Action non spcifie if g<d then begin pt :=g+(d-g) div 3; if val > L[pt] Rptition ? 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 }

e Test des logiciels

Test statique

Autre mthodes :
revues, mtriques (contraintes etc.), analyse d anomalies (du graphe de contrle/de donnes), rgles (de bon sens!) identificateurs clairs, dcoupage fonctionnel naturel limiter les effets de bords (interfaces, variables globales) preuves d algorithmes, excution symbolique, simulation de modles, etc.

e Test des logiciels

Test dynamique : Vocabulaire

DT : Donne de Test = une (squence) dentre(s) JT = {DT} D = domaine dentre du programme P sous test Soient F, les fonctions spcifies du logiciel

F : D -> Sorties Le problme du test dynamique est :

D Sorties Pratiquement : TD : tTP(t)=F(t)

F=P ?

e Test des logiciels

Test dynamique
DEUX REGLES :
Conserver les tests dj crits Conserver les rponses correctes correspondantes

e Test des logiciels

Test dynamique
Exemple simplissime: exe < fichier_testi quand correct : exe < fichier_testi > res_testi Lorsque intgration : Driver de test existe dj Lorsque volution : Tests de non-rgression newexe < fichier_testi > res_test_newexe diff res_test_newexe
Cest plus simple en OO (classes autotestables)

e Test des logiciels

Test dynamique structurel

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

e Test des logiciels

Le test structurel: abstraire pour obtenir un critre formel

C

si C alors I1 sinon I2

I1

I2

e Test des logiciels

Le test unitaire structurel

Graphe de Contrle (langages procduraux/actionnels)
But : reprsenter tous les chemins dexcution potentiels Graphe orient : avec un noeud dentre E et un nud de sortie S
(nud fictif ajout si plusieurs sorties)

Sommets :
blocs lmentaires du programme, ou prdicats des conditionnelles /boucles, ou nuds de jonction vide associ un noeud prdicat Bloc lmentaire : squence maximale dinstructions squentielles

Arcs :
enchanement dexcution possibles entre deux sommets

e Test des logiciels

Le test unitaire structurel

Exemple : PGCD de 2 nombres
Prcondition: 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 p=q read(p, q) B1 P1 while p<> q do if p > q then p := p-q else q:= q-p end -- if end -- while result:=p B4 end-- pgcd P2 B2 B3 S B4 E B1

P1 p<>q P2 p>q B2 p<=q B3

e Test des logiciels

Le test unitaire structurel

Question : Sur ce modle imaginer un critre de couverture

minimal maximal

e Test des logiciels

Le test unitaire structurel

Chemins : suite darcs rencontrs dans le graphe,
en partant de E et finissant en S.
en gnral reprsent sans perte dinformation par une liste de sommets

Prdicat de chemin : conjonction des prdicats

(ou de leur ngation) rencontrs le long du chemin.
Pas toujours calculable E B1 P1 P2 B2 S : p1=q1 & p0 > q0 (pi = ime valeur de p) E B1 P1 P2 B3 S : p1=q1 & p0 <= q0 (pi = ime valeur de p) E B1 P1 (P2 B2)n S : pn=qn & (pi > qi i [0..n])

Chemins infaisables : problme en gnral indcidable

e Test des logiciels

Le test unitaire structurel

Slection des tests fonds sur le flot de contrle
Couverture des instructions : chaque bloc doit tre excut au moins une fois Couverture des arcs ou enchanements tous les chemins lmentaires ou 1-chemins tous les i-chemins : de 0 i passages dans les boucles tous les chemins : si boucles, potentiellement infinis

e Test des logiciels

Le test unitaire structurel

Question : diffrence entre couverture arcs et couverture instructions ? Faire Exemple

e Test des logiciels

Le test unitaire structurel

E B1

P1 p=q P2 p>q B4 B2 p<=q B3

p<>q

Tous les noeuds: (E, B1, P1, P2, B2, P1, B4, S) (E, B1, P1, P2, B3, P1, B4, S) Tous les arcs : idem Tous les chemins lmentaires (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)

e Test des logiciels

Test unitaire structurel

Questions : quest-ce que ne capture pas ce modle ?
Couverture des prdicats Couverture des dpendances entre variables Couverture des domaines dentre
Cf. diff if then imbriqus

Aspects donnes

Flot de donnes (Weyuker)

Pertinence des donnes - pas de modle (Mutation etc.

e Test des logiciels

Le test unitaire structurel

Graphe de Flot de Donnes (Weyuker)
But : reprsenter les dpendances entre les donnes du
programme dans le flot dexcution.

Graphe de contrle dcor dinformations sur les donnes (variables) du programme. Sommets :idem GC
une dfinition (= affectation) dune variable v est note def(v) une utilisation dune variable est v note P_use(v) dans un prdicat et C_use(v) dans un calcul.

e Test des logiciels

Exemple

Le test unitaire structurel

E B1 Def(p)
Puse(p)

pgcd: integer is local p,q : integer; do B1- Def(p), Def(q) read(p, q) while p<> q do P1 - Puse(p), Puse(q)

P1 p=q

p<>

if p > q P2- Puse(p), Puse(q) then p := p-q B2- Def(p), Cuse(q), Cuse(p) else q:= q-p B3 - Def(q), Cuse(p),Cuse(q) end -- if B4 end -- while Cuse(p) result:=p B4- Cuse(p), end-- pgcd S

P2 Puse(p) p>q p<=q B2

Cuse(p)

B3
Cuse(p)

e Test des logiciels

Le test en gnral: critres d arrt unitaire : flot de donnes

Autres critres structurels : lien definition-utilisation (Weyuker)
Program pilote_automatique var probleme: boolean; direction : integer in [1..360] begin saisir_direction(direction); probleme := false; while not probleme do begin piloter(avion, auto, direction) end; if capteur_pression < 120 then probleme := true end if probleme then traiter_probleme(capteur_pression) . end

Dfinition 1 Utilisation 1.1 Dfinition Utilisation 1.2

Utilisation 2.

e Test des logiciels

Test structurel : relation dimplication entre critres

Dfinition : C1 C2 (subsumes) ssi P, JT satisfaisant C1 on a JT satisfait C2

e Test des logiciels

Test structurel : relation dimplication entre critres

Question : ordonner les critres selon cette dfinition
Tous les chemins chemins lmentaires

Lien dfinition-utilisatio (all-uses) all-p-uses/some-c-uses all-p-uses

K-chemins arcs all-c-uses/some-p-uses Couverture instructions all-defs

e Test des logiciels

Le test unitaire structurel: classement

Tous les chemins n-cycles chemins lmentaires Lien dfinition-utilisation (all-uses) all-p-uses/some-c-uses all-c-uses/some-p-uses all-p-uses

arcs all-defs Couverture instructions

e Test des logiciels

Le test unitaire structurel: critre d arrt, complexit et flot de contrle

1 2 5 3 2 2 1 1 4 6 6 3 4 5 V= 2 Npath = 2 V= 6 Npath = 6 V= 6 Npath = 32

Couverture de chemins : le nombre cyclomatique (Mc Cabe) le Npath (Nejmeh)

e Test des logiciels

Le test en gnral: critres d arrt

Nombre cyclomatique

Nombre de chemins pour couvrir la structure de contrle Nombre total des chemins de contrle effort de mise en uvre dune technique de test structurel

Npath

e Test des logiciels

...vers le test structurel dintgration

Couverture du graphe d appel

Pilote_automatique Pilotage_manuel

Saisir_direction

piloter

traiter_probleme

...

...
Traitement_reconfiguration

Traitement_urgenc

...

...

e Test des logiciels

Le test dintgration
But : vrifier les interactions entre composants (se base sur
larchitecture de la conception)

Difficults principales de lintgration

interfaces floues implantation non conforme au modle architectural (dpendances entre composants non spcifies) rutilisation de composants (risque dutilisation hors domaine)

e Test des logiciels

Le test dintgration
Stratgies possibles (si architecture sans cycles)
big-bang : tout est test ensemble. Peu recommand ! top-down : de haut en bas. Peu courant. Ecriture uniquement de drivers de tests. bottom-up : la plus classique. On intgre depuis les feuilles.

e Test des logiciels

Le test dintgration
3 stratgies: bottom-up, Top-down, Big-Bang.
D D S T
Driver Stub Composant test Composant sous test Interface sous test Interface teste

e Test des logiciels

Le test dintgration
Bottom-up

D D D T T

e Test des logiciels

Le test dintgration

D D D D T T T

T T T

T T

T T T

T T

T T

T T

e Test des logiciels

Le test dintgration
D

T T T T

T T T

T T

T T

e Test des logiciels

Le test dintgration
Top-Down D T S S S S D

e Test des logiciels

Le test dintgration
D T

e Test des logiciels

Le test dintgration
D T T T T T T T T D

S S

S S S

T S

e Test des logiciels

Le test dintgration
D T T T T T T T T T T D

T T

T T

T T

T T

T T

e Test des logiciels

Le test dintgration
intgration Big-Bang intgration Top-down intgration bottom-up intgration backbone intgration par domaines de collaboration