Test Et Validation Du Logiciel: Mcinfo4 - Asr Tests

Test et Validation du Logiciel
McInfo4_ASR Tests
J anvier 2009
Patrick FELIX
pat r i ck. f el i x@l abr i . f r
IUT Bordeaux 1
2 P.Flix ~IUT Bordeaux 1 Dpt Info - S4 - McInfo4_ASR Tests - J anvier 2009
Plan
Introduction : Pourquoi de la VVT ?
1 Introduction au test de logiciels
2 Le test fonctionnel
2.1 Le test de conformit de systmes ractifs
2.2 Le test fonctionnel de logiciel
3 Le test structurel
4 Le test dans un projet logiciel
Introduction :
Pourquoi de la VVT ?
VVT : Validation, Vrification & Test des logiciels
Des bogues, des consquences dsastreuses
Banque de New York [21 novembre 1985] : pertes financires
normes
Le Therac-25 [juillet 1985 ->avril 1986] : 3 morts
Le crash d'AT&T [15 janvier 1990] : pertes financires normes
+ la rputation d'AT&T entache.
Le Pentium [juin 1994] : pertes financires normes + psychose
Ariane 5-01 [4 juin 1996]
Ariane 5-01 (4 juin 1996)
Le 23 juillet, la commission d'enqute remet son rapport : La fuse a eu un
comportement nominal jusqu' la 36me seconde de vol. Puis les systmes de
rfrence inertielle (SRI) ont t simultanment dclars dfaillants. Le SRI n'a
pas transmis de donnes correctes parce qu'il tait victime d'une erreur
d'oprande trop leve du "biais horizontal" . . .
Les raisons :
1 Un bout de code dAriane IV (concernant le positionnement et la vitesse de la
fuse) repris dans Ariane V
2 il contenait une conversion dun flottant sur 64 bits en un entier sign sur 16 bits
3 pour Ariane V, la valeur du flottant dpassait la valeur maximale pouvant tre
convertie
4 ) dfaillance dans le systme de positionnement
5 ) la fuse a corrigsa trajectoire
6 ) suite une trop grande dviation, Ariane V sest dtruite !
Le cot dun Bogue ?
Cot du bogue de lan 2000 ?
Quelques chiffres avancs : 300, 1600 ou mme 5 000
milliards de dollars
Quel impact ?
Scurit des personnes,
Retour des produits,
Relations contractuelles,
Notorit, image,

Ncessit de vrifier certains logiciels/systmes
Ncessit de VVT
Comment effectuer de telles vrifications ?
Mthodes formelles
1. Test
ncessaire : permet de dcouvrir des erreurs
pas suffisant : non exhaustif (prouve la prsence derreurs, pas leur
absence !)
2. Dmonstration automatique
exhaustif
mise en uvre difficile
3. Model-checking
exhaustif, partiellement automatique
mise en uvre moins difficile (modle formel+formalisation des
proprits)
VALIDATION VRIFICATION & TESTS
1, 2 et 3 sont des mthodes complmentaires :
- Test : non exhaustif mais facile mettre en uvre (bon rapport qualit/temps)
- Dmonstration automatique : exhaustive mais considre comme trop coteux
- Model-checking : un compromis (?)
Sans mthodes formelles :
Cot des tests : 50 60% du cot total, voire 70% !
Interprtation(s) des termes usuels (-> utilisation dUML)
Ambigut des mthodes semi-formelles (#smantiques UML).
Matrise difficile de certains types de programmations
[vnementielle / parallle / ]
Maintenance volutive difficile
Tendances actuelles ~ Mthodes formelles et
certification
Mthodes formelles :
Test, Dmonstration (semi-)automatique, Model-checking
Politique de certification
Certains niveaux de certification exigent des mthodes
formelles
Obligation de certification
Grandes entreprises
Application risques
Sous-traitance
Test & Validation dans les mthodes formelles
Objectif ~ Pouvoir raisonner sur les logiciels et les systmes afin de :
Connatre leurs comportements
Contrler leurs comportements
Tester leurs comportements.
Moyen ~ Les systmes sont des objets mathmatiques.
Processus :
1. Obtenir un modle formel du logiciel ou du systme. [Si la taille le permet,
le modle peut tre le logiciel ou le systme]
2. Analyser le modle formel par une technique formelle.
3. Gnrer des test par une technique formelle
4. Transposer les rsultats obtenus sur les modles aux logiciels et systmes
rels.
Problmes de l'approche :
Le modle est-il fidle ? Validition.
Peut-on tout vrifier ? Dcidabilit.
Peut-on tout tester ? Testabilit.
La transposition des rsultats est-elle toujours possible ? Abstraction.
Le test est-il correct ? Le test est-il exhaustif ?
Partie I : Le test.
1: Introduction au test de logiciels
Test en gnral
Toute fabrication de produit suit les tapes suivantes :
1-Conception
2-Ralisation
3-Test
Test : On sassure que le produit final correspond ce qui a t
demand selon divers critres.
Exemples de critres :
esthtique,
performance,
ergonomie,
fonctionnalit,
robustesse, etc.
Gnie Logiciel
La fabrication de logiciel = activit multi-facette avec une
panoplie de :
langages de programmation,
Exemples : C, ADA, C++, J ava, C#, POO,
programmation vnementielle Corba, .NET,
architecture 3-tier/n-tier, XML, webservice, Ajax, etc.
mthodes de programmation,
concepts,
outils,
mthodes,
technologies,
normes, etc. [+Constante volution !]
Gnie logiciel : domaine dont lobjectif essentiel est la matrise
(conceptualiser, rentabiliser, etc.) de lactivit de fabrication de
logiciel.
Assurance qualit
Lassurance qualit permet de mettre en uvre un ensemble de
dispositions qui vont tre prises tout au long des diffrentes
phases de fabrication dun logiciel pour accrotre les chances
dobtenir un logiciel qui corresponde ses objectifs (son cahier
des charges).
La dfinition et la mise en place des activits de test ne sont
quun sous-ensemble des activits de lassurance qualit, et le
test aura pour but de minimiser les chances dapparition dune
anomalie lors de lutilisation du logiciel.
Lobjet de ce cours consiste tudier comment mettre en uvre
des activits de test.
Erreur, dfaut et anomalie
Une anomalie (ou dfaillance) est un comportement observ diffrent du
comportement attendu ou spcifi.
Exemple. Le 4 juin 1996, on a constat
Chane de causalit : erreur => dfaut => anomalie
(nature de lerreur :spcification, conception, programmation)
Le terme bogue est malheureusement utilis pour dsigner aussi bien dfaut
quune anomalie.
dfaut anomalie
Exemple : Une anomalie (telle une maladie) trouve toujours son explication
dans un dfaut (agent pathogne) et un dfaut (un microbe latent) ne
provoquera pas ncessairement une anomalie.
Comme le test est en aval de lactivit de programmation, les erreurs (humaines)
dj commises, ainsi que la faon de les viter ne nous proccupent pas ! Nous
porterons notre attention sur les dfauts qui ont t malencontreusement
introduits afin de minimiser les anomalies qui risquent de se produire.
Sans nuire la suite de ce cours, nous pouvons confondre, par abus de langage,
erreur et dfaut (tendance humaine confondre cause et consquence !!!)
Classes de dfaut
Lensemble des dfauts pouvant affecter un logiciel est infini
Mais, des classes de dfaut peuvent tre identifies : calcul,
logique, E/S, traitement des donnes, interface, dfinition des
donnes
Les moyens pour dtecter des dfauts peuvent tre automatiques
ou manuels et sappliquent aussi bien sur le code source qu
son comportement.
Comment dfinir lactivit de test dans un projet logiciel ?
Le test : des dfinitions
Dfinition (issue de Le test des logiciels [SX-PR-CK-2000]) : Le
test dun logiciel est une activit qui fait partie du processus de
dveloppement. Il est men selon les rgles de lassurance de
la qualit et dbute une fois que lactivit de programmation est
termine. Il sintresse aussi bien au code source quau
comportement du logiciel. Son objectif consiste minimiser les
chances dapparitions dune anomalie avec des moyens
automatiques ou manuels qui visent dtecter aussi bien les
diverses anomalies possibles que les ventuels dfauts qui les
provoqueraient.
Dfinition (issue de la norme IEEE-STD729, 1983) : Le test est un
processus manuel ou automatique, qui vise tablir quun
systme vrifie les proprits exiges par sa spcification, ou
dtecter des diffrences entre les rsultats engendrs par le
systme et ceux qui sont attendus par la spcification.
Le test : des dfinitions(suite et fin)
Dfinition (issue de l'A.F.C.I.Q) : "Le test est une technique de
contrle consistant s'assurer, au moyen de son excution, que
le comportement d'un programme est conforme des donnes
prtablies".
AFCIQ : Association Franaise pour le Contrle Industriel et la
Qualit
Dfinition (issue de The art of software Testing [GJ M]) : Tester,
cest excuter le programme dans lintention dy trouver des
anomalies ou des dfauts".
Qq commentaires sur les dfinitions du test
Le test dun logiciel :
a pour objectif de rduire les risques d'apparition
d'anomalies avec des moyens manuels et informatiques.
fait partie du processus de dveloppement.
n'a pas pour objectif de :
de corriger le dfaut dtect (dbogage ou dverminage)
de prouver la bonne excution dun programme.
Procdure de test : On applique sur tout ou une partie du systme
informatique un chantillon de donnes d'entres et
d'environnement, et on vrifie si le rsultat obtenu est conforme
celui attendu. S'il ne l'est pas, cela veut dire que le systme
informatique test prsente une anomalie de fonctionnement.
(Le test du logiciel est galement appel vrification
dynamique.)
Difficults du test
1. Processus dintroduction des dfauts trs complexe
2. Mal peru par les informaticiens et dlaiss par les thoriciens
Difficults du test : Testabilit
Testabilit : Facilit avec laquelle les tests peuvent tre
dvelopps partir des documents de conception
Facteurs de bonne testabilit :
Prcision, compltude, traabilit des documents
Architecture simple et modulaire
Politique de traitements des erreurs clairement dfinie
Facteurs de mauvaise testabilit :
Fortes contraintes defficacit (espace mmoire, temps)
Architecture mal dfinie
Difficults du test : Limites thoriques
1-Indcidabilit : une proprit indcidable est une proprit quon
ne pourra jamais prouver dans le cas gnral (pas de procd
systmatique)
Exemples de proprits indcidables :
Lexcution dun programme termine
Deux programmes calculent la mme chose
Un programme na pas derreurs
2-Explosion combinatoire : un programme a un nombre infini (ou
extrmement grand !) dexcutions possibles
Le test nexamine quun nombre fini (ou trs petit) dexcutions
Heuristiques : approcher linfini (ou lextrmement grand) avec le
fini (trs petit).
=> Choisir les excutions tester !
Difficults du test : conclusion.
Conclusion : Impossibilit dune automatisation complte
satisfaisante !
volution du test
Aujourd'hui, le test de logiciel :
est la technique de validation la plus utilise pour s'assurer
de la correction du logiciel.
fait lobjet dune pratique trop souvent artisanale.
Demain, le test de logiciel devrait tre :
une activit rigoureuse,
fonde sur des modles et des thories
De plus en plus automatique
Approches du test
Lactivit de test se dcline selon 2 approches :
rechercher statiquement des dfaut simples et frquents
(contrle)
dfinir les entres (appeles donnes de test) qui seront
fournies au logiciel pendant une excution
Exemple de donnes de test (DT)
DT1={a=2, z=4.3}
Jeu de test : est un ensemble de donnes de test.
Scnario de test : actions effectuer avant de soumettre le jeu de
test
Le scnario de test produit un rsultat
Ce rsultat doit tre valu de manire manuelle ou automatique
pour produire un oracle
Exemple 1 de test avec oracle manuel
DT1={x=16} DT1={x=16}
DT2={x=1} DT2={x=1}
/ /
Calcul de la Calcul de la
racine carr racine carr e e
Sp Sp cifications de cifications de
la racine carr la racine carr e e
Entr Entr e x=16 e x=16
Testeur Testeur
R R sultat 4 sultat 4
R R sultat attendu 4 sultat attendu 4
OK ! OK !
Exemple 2 de test avec oracle manuel
DT1={x=16} DT1={x=16}
DT2={x=1} DT2={x=1}
/ /
Entr Entr e x=1 e x=1
Testeur Testeur
R R sultat 0 sultat 0
R R sultat attendu 1 sultat attendu 1
NON OK ! NON OK !
Exemple 3 de test avec oracle automatique
DT1={x=16} DT1={x=16}
DT2={x=1} DT2={x=1}
/ /
Entr Entr e e
R R sultat sultat
2 2
=Entr =Entr e e
OK ou pas OK OK ou pas OK
R R sultat sultat
Choix des jeux de test
Les donnes de test sont toutes les entres possibles :
test exhaustif
Idal, mais non concevable !!!
Les donnes de test constituent un chantillon reprsentatif de
toutes les entres possibles :
Exemple Racine carre
16, 1, 0, 2, 100, 65234, 826001234, -1, - 3
Critre de test (ou de slection) : Un critre permet de spcifier
formellement un objectif (informel) de test. Un critre de test
peut, par exemple, indiquer le parcours de toutes les branches
d'un programme, ou l'examen de certains sous-domaines d'une
opration.
Validit
Fiabilit
Validit, fiabilit, compltude dun critre de test
Validit : Un critre de test est dit valide si pour tout programme
incorrect, il existe un jeu de test non russi satisfaisant le critre.
P:programme, F:spcification,
TD est fiable
[pour tout tT F(t)=P(t) pour tout tD F(t)=P(t)]
Fiabilit : Un critre est dit fiable s'il produit uniquement des jeux
de test russis ou des jeux de test non russis.
Compltude : Un critre est dit complet pour un programme s'il
produit uniquement des jeux de test qui suffisent dterminer la
correction du programme (pour lequel tout programme passant
le jeu de test avec succs est correct)
Remarque : Tout critre valide et fiable est complet.
La compltude : un rve
Hypothse de test : La compltude tant hors d'atteinte en
gnral, on peut qualifier un jeu de test par des hypothses de
test qui caractrisent les proprits qu'un programme doit
satisfaire pour que la russite du test entrane sa correction
Classification des tests
Diffrentes classes de tests selon :
les critres de test utilises
Les entits utilises (spcification, code source, excutable)
Exemples de classes :
1. Les modalits de test : Statique / Dynamique
2. Les mthodes de test : Structurelle / Fonctionnelle
3. Manuel / Automatique
4. Les niveaux de tests : Unitaire / Intgration / Systme / Non-
rgression
5. Les caractristiques de test : Robustesse / Conformit /
Performance /
Les modalits de test
1. Test statique : Test par l'humain, sans machine, par lecture
du code
inspection ou revue de code;
runions (le programmeur, le concepteur, un programmeur
expriment, un testeur expriment, un modrateur)
le but : trouver des erreurs dans une ambiance de
coopration
2. Test dynamique : Test par l'excution du systme
Implantation du systme (IUT = Implementation Under
Test)
Une proprit / caractristique tester
un test russit (Passes) si les rsultats obtenus sont les
rsultats attendus, sinon il choue (Fails);
Les niveaux de tests
Tests unitaires (ou test de composant): s'assurer que les
composants logiciels pris individuellement sont conformes
leurs spcifications et prts tre regroups.
Tests d'intgration :s'assurer que les interfaces des composants
sont cohrentes entre elles et que le rsultat de leur intgration
permet de raliser les fonctionnalits prvues.
Tests systme : s'assurer que le systme complet, matriel et
logiciel, correspond bien la dfinition des besoins tels qu'ils
avaient t exprims. [validation]
Tests de non-rgression : vrifier que la correction des erreurs n'a
pas affect les parties dj testes. [Cela consiste
systmatiquement repasser les tests dj excuts]
Les mthodes de test
1. Les mthodes structurelles : repose sur des analyses du code source
Examen de la structure du programme (flot de contrle ou de donnes)
Aussi appeles test en bote blanche, ou test bas sur l'implantation.
possibilit de fixer finement la valeur des entres pour sensibiliser des
chemins particuliers du code;
conception des tests uniquement pour le code dj crit.
2. Les mthodes fonctionnelles : repose sur une spcification (formelle ou
informelle) du programme, le code source du programme nest pas utilis.
Aucune connaissance de l'implantation;
Aussi appeles test en bote noire, ou test bas sur la spcification.
permet d'crire les tests avant le codage;
Parfois : Combinaison des deux mthodes fonctionnelles et structurelles.
3. Les tests orients-erreurs :
les mthodes statistiques, le "semage" d'erreurs et les tests de mutation.
Test manuel / test automatis
1. Test manuel
le testeur entre les donnes de test par ex via une interface;
lance les tests;
observe les rsultats et les compare avec les rsultats attendus;
fastidieux, possibilit d'erreur humaine;
ingrable pour les grosses applications;
2. Test automatis
Avec le support d'outils qui dchargent le testeur :
du lancement des tests;
de l'enregistrement des rsultats;
parfois de la gnration de l'oracle;
test unitaire pour J ava: J Unit
gnration automatique de cas de test : de plus en plus courant (cf Objecteering).
3. Built-in tests
Code ajout une application pour effectuer des vrifications l'excution:
laide dassertions !
ne dispense pas de tester ! test embarqu diffrent de code auto-test !
permet un test unitaire "permanent", mme en phase de test systme;
test au plus tt;
assertions: permettent de gnrer automatiquement l'oracle;
Test de caractristiques
Quelques exemples :
test de robustesse : permet d'analyser le systme dans le cas o ses
ressources sont satures ou bien d'analyser les rponses du systme
aux sollicitations proche ou hors des limites des domaines de dfinition
des entres. La premire tche accomplir est de dterminer quelles
ressources ou quelles donnes doivent tre testes. Cela permet de
dfinir les diffrents cas de tests exercer. Souvent ces tests ne sont
effectus que pour des logiciels critiques, c'est--dire ceux qui
ncessitent une grande fiabilit.
test de performance : permet d'valuer la capacit du programme
fonctionner correctement vis--vis des critres de flux de donnes et de
temps d'excution. Ces tests doivent tre prcds tout au long du
cycle de dveloppement du logiciel d'une analyse de performance, ce
qui signifie que les problmes de performances doivent tre pris en
compte ds les spcifications.
Classification des tests
Classement des techniques de tests de logiciels selon :
Critres adopts pour choisir des DT reprsentatives
Entits utilises (spcification, code source, ou code
excutable)
Techniques fonctionnelles / structurelles
Techniques statiques / dynamiques
Techniques combinant fonctionnelles, structurelles, dynamiques
et statiques (cest le cas du test bote grise)
Un exemple de classement selon trois axes :
le niveau de dtail (tape dans le cycle de vie)
le niveau d'accessibilit
la caractristique
Classification des tests (suite)
Niveau de dtail
tests unitaires : vrification des fonctions une par une,
tests d'intgration : vrification du bon enchanement des fonctions
et des programmes,
tests de non-rgression : vrification qu'il n'y a pas eu de
dgradation des fonctions par rapport la version prcdente,
Niveau d'accessibilit
Bote noire : partir d'entre dfinie on vrifie que le rsultat final
convient.
Bote blanche : on a accs l'tat complet du systme que l'on
teste.
Bote grise : on a accs certaines information de ltat du
systme que l'on teste.
Caractristique :
test fonctionnel
test de robustesse
test de performance
Classification des tests (suite)
Syst Syst me me
Module Module
Int Int gration gration
Unitaire Unitaire
Fonctionnelle Fonctionnelle
Robustesse Robustesse
Performance Performance
Ergonomie Ergonomie
S S ret ret
S S curit curit
B
o
B
o

t
e

b
l
a
n
c
h
e
t
e

b
l
a
n
c
h
e
B
o
B
o

t
e

n
o
i
r
e
t
e

n
o
i
r
e
Niveau de d Niveau de d tail (%cycle de vie) tail (%cycle de vie)
Caract Caract ristiques(ce que l ristiques(ce que l on veut tester) on veut tester)
Niveau d Niveau d accessibilit accessibilit
D D apr apr s J. s J. Tretmans Tretmans Univ Univ. . Nijmegen Nijmegen
Quelques exemples dapplication
Test de programmes impratifs
modles disponibles : ceux issus de l'analyse de leur code source
Donc : mthodes de test structurelles pour couvrir le modle
Couverture suivant des critres lis au contrle ou aux donnes.
Test de conformit des systmes ractifs
Modle disponible : la spcification
Donc : mthodes de test fonctionnelles
gnration automatique de tests de conformit,
Test de systmes
Techniques de test d'intgration lors de la phase d'assemblage
Aspects mthodologiques
Test systme.
Stratgie de test
Une technique de test doit faire partie dune stratgie de test
adquation avec le plan qualit
Intgration dans le processus de dveloppement des logiciels
Une technique de test puissante restera sans effet si elle ne fait pas partie
dune stratgie de test
La stratgie dpend :
de la criticit du logiciel
du cot de dveloppement
Une stratgie dfinit :
Des ressources mises en uvre (quipes, testeurs, outils, etc.)
Les mcanismes du processus de test (gestion de configuration, valuation
du processus de test, etc.)
Une stratgie tient compte :
Des mthodes de spcif, conception
Langages de programmation utiliss
Du types dapplication (temps rel, protocole, base de donnes)
Lexprience des programmeurs
Etc.

Test Et Validation Du Logiciel: Mcinfo4 - Asr Tests

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Test Et Validation Du Logiciel: Mcinfo4 - Asr Tests

Hochgeladen von

Copyright:

Verfügbare Formate

Test et Validation du Logiciel

Das könnte Ihnen auch gefallen