ISTQB FL Syllabus 2011 Released FR

Testeur Certifi
Syllabus Niveau Fondation
Version 2011 FR
International Software Testing Qualifications Board

Comit Franais des Tests Logiciels
Testeur Certifi
Comit
Franais
des
Tests
Logiciels
International
Software Testing
Qualifications
Board
Copyright
Ce document peut tre copi dans son intgralit, ou partiellement, si la source est mentionne.
Copyright Notice International Software Testing Qualifications Board (ci-aprs appel ISTQB)
ISTQB est une marque enregistre de lInternational Software Testing Qualifications Board,
Copyright 2011 les auteurs pour la mise jour 2011 (Thomas Mller (responsable),
Debra Friedenberg, et l'ISTQB Fondation WG Level)
Copyright 2010 les auteurs pour la mise jour 2010 (Thomas Mller (responsable), Armin Beer,
Martin Klonk, Rahul Verma)
Copyright 2007 les auteurs pour la mise jour 2007 (Thomas Mller (responsable), Dorothy
Graham, Debra Friedenberg et Erik van Veenendaal)
Copyright 2005, les auteurs (Thomas Mller (responsable), Rex Black, Sigrid Eldh, Dorothy
Graham, Klaus Olsen, Maaret Pyhjrvi, Geoff Thompson et Erik van Veenendaal).
Tous droits rservs.
Les auteurs transfrent leurs droits lInternational Software Testing Qualifications Board (ci-aprs
appel ISTQB). Les auteurs (en tant que possesseurs actuels des droits dauteurs) et lISTQB (en tant
que possesseur futur des droits dauteurs) ont conclu laccord suivant portant sur les conditions
dutilisation :
1)
Tout individu ou organisme de formation peut utiliser ce syllabus comme base pour une
formation si les auteurs et lISTQB sont cits comme source et possesseurs des droits de ce
syllabus, et pour autant que toute publicit sur une telle formation mentionne ce syllabus
uniquement aprs demande daccrditation officielle de cette formation auprs dun Comit
National reconnu par lISTQB ;
2)
Tout individu ou groupe dindividus peut utiliser ce syllabus comme une base pour des
articles, livres, ou autres crits drivs, si les auteurs et lISTQB sont reconnus comme source
et possesseurs des droits de ce syllabus ;
3)
Tout Comit National reconnu par lISTQB peut traduire ce syllabus et permettre lutilisation
de ce syllabus par des tiers.
Version 2011
Page 2 de 82
31-Mar-2010
Testeur Certifi
4)
Comit
Franais des
Tests
Logiciels
International
Software Testing
Qualifications Board
Historique des modifications
Version
CFTL 2011FR
Date
3-Nov-2011
CFTL 2010FR
1-Sept-2010
ISTQB 2010
30-Mars-2010
ISTQB 2007
01-Mai-2007
CFTL 2005FR
ISTQB 2005
ASQF V2.2
01-Juillet-2005
01-Juillet-2005
Juillet-2003
ISEB V2.0
25-Fvrier-1999
Remarques
Testeur Certifi Niveau Fondation Mise jour
voir Annexe E Changements intgrs dans le
Syllabus 20101
Testeur Certifi Niveau Fondation Mise jour
voir Annexe E Changements intgrs dans le
Syllabus 2010
Certified Tester Foundation Level Syllabus
Maintenance Release voir Annexe E
Changements intgrs dans le Syllabus 2010
Maintenance Release voir Appendix E Release
Notes Syllabus 2007
Testeur Certifi Niveau Fondation
ASQF Syllabus Foundation Level Version 2.2
Lehrplan Grundlagen des Software-testens
ISEB Software Testing Foundation Syllabus V2.0
25 February 1999
Traduction franaise: Bernard HOMES, Eric RIOU du COSQUER, Alain RIBAULT, Bertrand
CORNANGUER, Cyrille RIVIERE, Olivier DENOO, Vronique JOURDY-COTTEN
Version 2011
Page 3 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Table des Matires

Remerciements........................................................................................................................................ 7
Introduction ce syllabus ........................................................................................................................ 8
1.
Fondamentaux des Tests (K2)...................................................................................................... 10
1.1
Pourquoi les tests sont-ils ncessaires? (K2) ...................................................................... 11
1.1.1 Contexte des systmes logiciels (K1) .............................................................................. 11
1.1.2 Origine des dfauts logiciels (K2) ................................................................................... 11
1.1.3 Rle des tests dans le dveloppement, la maintenance et lopration des logiciels (K2)11
1.1.4 Tests et qualit (K2) ........................................................................................................ 11
1.1.5 Combien de test est suffisant? (K2) ................................................................................. 12
1.2
Que sont les tests ? (K2) ..................................................................................................... 13
1.3
Les 7 principes gnraux des tests (K2) .............................................................................. 14
1.4
Processus de test fondamental (K1) .................................................................................... 15
1.4.1 Planification et contrle des tests (K1) ............................................................................ 15
1.4.2 Analyse et Conception des tests (K1) .............................................................................. 15
1.4.3 Implmentation et excution des tests (K1)..................................................................... 16
1.4.4 Evaluer les critres de sortie et informer (K1) ................................................................. 16
1.4.5 Activits de clture des tests (K1) ................................................................................... 16
1.5
La psychologie des tests (K2) .............................................................................................. 18
1.6
Code dthique ..................................................................................................................... 20
2.
Tester Pendant le Cycle de Vie Logiciel (K2) ............................................................................... 21
2.1
Modles de Dveloppement Logiciel (K2) .......................................................................... 22
2.1.1 Modle en V (K2) ............................................................................................................. 22
2.1.2 Modle de dveloppement itratif (K2) ............................................................................ 22
2.1.3 Tester au sein dun modle de cycle de vie (K2) ............................................................. 22
2.2
Niveaux de tests (K2) ........................................................................................................... 24
2.2.1 Tests de composants (K2) ............................................................................................... 24
2.2.2 Tests dintgration (K2) .................................................................................................... 25
2.2.3 Tests systme (K2) .......................................................................................................... 25
2.2.4 Tests dacceptation (K2) .................................................................................................. 26
2.3
Types de tests (K2) .............................................................................................................. 28
2.3.1 Tests des fonctions (tests fonctionnels) (K2) ................................................................... 28
2.3.2 Tests des caractristiques non fonctionnelles des produits logiciels (tests nonfonctionnels) (K2) .......................................................................................................................... 28
2.3.3 Tests de la structure / architecture logicielle (tests structurels) (K2) ............................... 29
2.3.4 Tests lis au changement (tests de confirmation et de rgression) (K2) ........................ 29
2.4
Tests de maintenance (K2) .................................................................................................. 30
3.
Techniques Statiques (K2) ............................................................................................................ 31
3.1
Techniques statiques et processus de test (K2) .................................................................. 32
3.2
Processus de revue (K2) ...................................................................................................... 33
3.2.1 Phases dune revue formelle (K1) ................................................................................... 33
3.2.2 Rles et responsabilits (K1) ........................................................................................... 33
3.2.3 Types de revues (K2) ....................................................................................................... 34
3.2.4 Facteurs de succs des revues (K2) ............................................................................... 35
3.3
Analyse statique avec des outils (K2) .................................................................................. 36
4.
Techniques de Conception de Tests (K3) .................................................................................... 37
4.1
Le processus de dveloppement de test (K3) ..................................................................... 38
4.2
Catgories de techniques de conception de tests (K2) ....................................................... 39
4.3
Techniques bases sur les spcifications ou techniques bote noire (K3) .......................... 40
4.3.1 Partitions dquivalence (K3) ........................................................................................... 40
4.3.2 Analyse des valeurs limites (K3) ...................................................................................... 40
4.3.3 Tests par tables de dcisions (K3) .................................................................................. 40
4.3.4 Test de transition dtats (K3) .......................................................................................... 41
4.3.5 Tests de cas dutilisation (K2) .......................................................................................... 41
Version 2011
Page 4 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
4.4
Technique de conception base sur la structure ou technique de conception bote
blanche (K3) ...................................................................................................................................... 42
4.4.1 Test des instructions et couverture (K3) .......................................................................... 42
4.4.2 Test des dcisions et couverture (K3) ............................................................................. 42
4.4.3 Autres techniques bases sur les structures (K1) ........................................................... 42
4.5
Techniques bases sur lexprience (K2) ............................................................................ 44
4.6
Slectionner les techniques de tests (K2) ............................................................................ 45
5.
Gestion des Tests (K3) ................................................................................................................. 46
5.1
Organisation des tests (K2) .................................................................................................. 48
5.1.1 Organisation du test et indpendance (K2) ..................................................................... 48
5.1.2 Tches du responsable des tests et des testeurs (K1) ................................................... 48
5.2
Estimation et planification des tests (K3) ............................................................................. 50
5.2.1 Planification des tests (K2) .............................................................................................. 50
5.2.2 Activits de planification des tests (K3) ........................................................................... 50
5.2.3 Critres dentre (K2) ....................................................................................................... 50
5.2.4 Critres de sortie (K2) ...................................................................................................... 51
5.2.5 Estimation des tests (K2) ................................................................................................. 51
5.2.6 Stratgie de test, Approche de test (K2) .......................................................................... 51
5.3
Suivi et contrle du droulement des tests (K2) .................................................................. 53
5.3.1 Suivi de lavancement des tests (K1)............................................................................... 53
5.3.2 Reporting des tests (K2) .................................................................................................. 53
5.3.3 Contrle des tests (K2) .................................................................................................... 53
5.4
Gestion de configuration (K2) .............................................................................................. 55
5.5
Test et risques (K2) .............................................................................................................. 56
5.5.1 Risques lis au projet (K2) ............................................................................................... 56
5.5.2 Risques lis au produit (K2) ............................................................................................. 56
5.6
Gestion des incidents (K3) ................................................................................................... 58
6.
Outils de Support aux Tests (K2) .................................................................................................. 60
6.1
Types d'outils de test (K2) .................................................................................................... 61
6.1.1 Outils de support aux tests (K2) ...................................................................................... 61
6.1.2 Classification des outils de test (K2) ................................................................................ 61
6.1.3 Outils daide la gestion du test et des tests (K1) .......................................................... 62
6.1.4 Outils daide aux tests statiques (K1) .............................................................................. 62
6.1.5 Outils daide la spcification des tests (K1) .................................................................. 63
6.1.6 Outils daide l'excution et lenregistrement des tests (K1) ....................................... 63
6.1.7 Outils de support de performance et de surveillance (K1) .............................................. 64
6.1.8 Outils de support pour des besoins de tests spcifiques (K1)......................................... 64
6.2
Utilisation efficace des outils : Bnfices potentiels et Risques (K2) ................................... 65
6.2.1 Bnfices potentiels et risques lis aux outils de test (pour tous les outils) (K2) ............ 65
6.2.2 Considrations spciales pour quelques types d'outil (K1) ............................................. 65
6.3
Introduire un outil dans une organisation (K1) ..................................................................... 67
7.
Rfrences .................................................................................................................................... 68
Standards .......................................................................................................................................... 68
Livres ................................................................................................................................................. 68
8.
Annexe A Informations sur le syllabus ....................................................................................... 70
Historique de ce document................................................................................................................ 70
Objectifs de la qualification internationale (adapt de la runion ISTQB de Novembre 2001
Sollentuna) ........................................................................................................................................ 70
9.
Annexe B Objectifs de connaissance/Niveaux de connaissance .............................................. 72
Niveau 1: Se souvenir (K1) ............................................................................................................... 72
Niveau 2: comprendre (K2) ............................................................................................................... 72
Niveau 3: Appliquer (K3) ................................................................................................................... 72
Niveau 4: Analyser (K4) .................................................................................................................... 72
10.
Annexe C Rgles appliques au syllabus ISTQB niveau Fondation .................................... 74
10.1.1 Rgles gnrales ............................................................................................................. 74
10.1.2 Contenu actualis ............................................................................................................ 74
10.1.3 Objectifs de connaissance ............................................................................................... 74
Version 2011
Page 5 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
10.1.4 Structure gnrale ........................................................................................................... 74

11.
Annexe D Note pour les organismes de formation................................................................ 76
12.
Tous les objectifs de niveau K3 et K4 ncessitent de pratiquer des exercices. Annexe E
Changements intgrs dans le Syllabus 2010 ...................................................................................... 77
Version 2011 .......................................................................................................................................... 77
13.
Index ......................................................................................................................................... 79
Version 2011
Page 6 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Remerciements
International Software Testing Qualifications Board Working Group Foundation Level (Edition
2011): Thomas Mller (chair), Debra Friedenberg. Le groupe de travail remercie lquipe de revue
(Dan Almog, Armin Beer, Rex Black, Julie Gardiner, Judy McKay, Tuula Pkknen, Eric Riou du
Cosquier Hans Schaefer, Stephanie Ulrich, Erik van Veenendaal) et tous les Comits Nationaux
pour leurs suggestions pour la version actuelle du syllabus.
2010): Thomas Mller (responsable), Rahul Verma, Martin Klonk et Armin Beer. Le groupe de
travail remercie lquipe de revue (Rex Black, Mette Bruhn-Pederson, Debra Friedenberg, Klaus
Olsen, Tuula Pkknen, Meile Posthuma, Hans Schaefer, Stephanie Ulrich, Pete Williams, Erik
van Veenendaal) et tous les Comits Nationaux pour leurs suggestions pour la version actuelle du
syllabus.
2007): Thomas Mller (responsable), Dorothy Graham, Debra Friedenberg, et Erik van
Veendendaal Le groupe de travail remercie lquipe de revue (Hans Schaefer, Stephanie Ulrich,
Meile Posthuma, Anders Pettersson, et Wonil Kwon) et tous les Comits Nationaux pour leurs
suggestions.
2005): Thomas Mller (responsable), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret
Pyhjrvi, Geoff Thompson , Erik van Veenendaal et l'quipe de revue ainsi que tous les Comits
Nationaux pour leurs suggestions.
Version 2011
Page 7 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Introduction ce syllabus
Objectif de ce document
Ce syllabus forme la base du niveau Fondation de la qualification Internationale en tests de
logiciels. LInternational Software Testing Qualifications Board (ISTQB) et le Comit Franais des
Tests Logiciels (ci-aprs appel CFTL) fournissent ce syllabus aux comits nationaux dexamens
pour accrditer les fournisseurs de formations et pour en driver des questions dexamens dans
leur langue nationale. Les fournisseurs de formations produiront leurs cours et dtermineront les
mthodes de formation appropries pour laccrditation, et le syllabus aidera les candidats se
prparer aux examens.
Des informations sur lhistorique et le contexte du syllabus peuvent tre trouves en Annexe A.
Le Niveau Fondation pour les Testeurs de Logiciels Certifis

La qualification de niveau fondation vise toutes les personnes impliques dans les tests de logiciels.
Ceci inclut les personnes ayant des rles de testeurs, analystes de tests, ingnieurs de tests,
consultants en tests, gestionnaires de tests, testeurs en phase dacceptation utilisateur et
dveloppeurs de logiciels. Cette qualification de niveau Fondation est aussi approprie pour toute
personne souhaitant une comprhension de base des tests de logiciels, tels que les gestionnaires
de projets, responsables qualit, responsables de dveloppements logiciels, analystes mtier et
consultants en management. Les possesseurs du Certificat Fondation seront capables de continuer
afin datteindre un niveau suprieur de certification en tests de logiciels.
Objectifs de connaissance /niveaux de connaissance

Les niveaux de connaissance sont fournis pour chaque section de ce syllabus et classs de la
faon suivante
o K1: se souvenir;
o K2: comprendre;
o K3: utiliser;
o K4: analyser
De plus amples dtails et des exemples dobjectifs de connaissance sont donns en Annexe B.
Tous les termes lists sous la rubrique termes aprs les titres de chapitre seront retenus (K1),
mme sils ne sont pas explicitement mentionns dans les objectifs de connaissance.
Lexamen
Lexamen pour lobtention du Certificat Fondation sera bas sur ce syllabus. Les rponses aux
questions dexamen peuvent requrir lutilisation dinformations contenues dans plus dune section
de ce syllabus. Toutes les sections de ce syllabus peuvent donner lieu des questions dexamen.
Le format de lexamen est un questionnaire choix multiples.
Les examens peuvent faire partie dune formation accrdite ou tre passs indpendamment
(p.ex. dans un centre dexamen ou lors dun examen public). La participation une formation
accrdite nest pas un pr-requis au passage de lexamen.
Accrditation
Les fournisseurs de formations dont le contenu du cours suit ce syllabus peuvent tre accrdits
par un comit national reconnu par lISTQB et le CFTL. Les directives daccrditation doivent tre
obtenues auprs de lorganisme ou du comit effectuant laccrditation. Un cours accrdit est
reconnu comme se conformant ce syllabus, et peut inclure un examen ISTQB CFTL comme
partie du cours.
Pour de plus amples informations destination des fournisseurs de formation, voir lAnnexe D.
Version 2011
Page 8 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Niveau de dtail
Le niveau de dtail dans ce syllabus permet un enseignement et des examens compatibles
internationalement. Pour atteindre cet objectif, le syllabus contient :
Des objectifs gnraux dinstruction, dcrivant les intentions du niveau fondation

Une liste des informations enseigner, incluant une description, et des rfrences des
sources additionnelles si besoin.
Des objectifs de connaissance pour chaque domaine de connaissance, dcrivant les rsultats
cognitifs denseignements et la mentalit acqurir.
Une liste de termes que les tudiants doivent se rappeler et comprendre.
Une description des concepts cl enseigner, incluant des sources comme des normes ou de
la littrature reconnue.
Le contenu du syllabus nest pas une description de lensemble du domaine de connaissance en

tests de logiciels; il reflte le niveau de dtail devant tre couvert par les cours et formations du
niveau fondation.
Organisation du syllabus
Ce syllabus comprend six chapitres majeurs. Le titre principal de chaque chapitre montre lobjectif
dapprentissage couvert par le chapitre, et spcifie la dure minimale pour traiter ce chapitre. Par
exemple:
2. Tester pendant le Cycle de Vie (K2)
115 minutes
Ce titre indique que le Chapitre 2 a un objectif de connaissance K1 (suppos quand un niveau

suprieur est spcifi) et K2 (mais pas K3), et quune dure de 115 minutes est suggre pour
couvrir le matriel de ce chapitre.
Chaque chapitre comporte plusieurs sections. Chaque section possde aussi un objectif de
connaissance et la dure requise en minutes. Les sous-sections qui nont pas de dure prcise
sont inclues dans la dure totale de la section.
Version 2011
Page 9 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
1.
Comit
Franais des
Tests
Logiciels
Fondamentaux des Tests (K2)
International
Software Testing
155 minutes
Objectifs de connaissance pour Fondamentaux des Tests

Les objectifs identifient ce que vous serez en mesure de faire en fin de chaque module.
1.1 Pourquoi les tests sont-ils ncessaires ? (K2)

LO-1.1.1
LO-1.1.2
LO-1.1.3
LO-1.1.4
LO-1.1.5
Dcrire, avec des exemples, la manire par laquelle un dfaut dans un logiciel peut
causer des dommages des personnes, lenvironnement ou la socit. (K2)
Faire la diffrence entre la cause initiale du dfaut et ses effets. (K2)
Donner des raisons pour lesquelles les tests sont ncessaires en donnant des
exemples. (K2)
Dcrire pourquoi les tests font partie de lassurance qualit et donner des exemples sur
comment les tests contribuent une qualit accrue. (K2)
Expliquer et comparer les termes faute, dfaut, dfaillance et les termes associs
erreur et bug. (K2)
1.2 Que sont les tests ? (K2)

LO-1.2.1
LO-1.2.2
LO-1.2.3
Rappeler les objectifs habituels des tests. (K1)

Fournir des exemples pour les objectifs des tests lors des diffrentes phases du cycle
de vie logiciel (K2)
Faire la diffrence entre tester et dboguer (K2)
1.3 Les 7 Principes gnraux des tests (K2)

LO-1.3.1
Expliquer les 7 principes gnraux des tests (K2)
1.4 Processus de test fondamental (K1)

LO-1.4.1
Rappeler les 5 activits de test fondamentales et les tches associes, de la

planification aux activits de clture (K1)
1.5 La psychologie des tests (K2)

LO-1.5.1
LO-1.5.2
Rappeler les facteurs psychologiques ayant une influence sur le succs des tests (K1)
Comparer la mentalit dun testeur avec celle dun dveloppeur (K2)
Version 2011
Page 10 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
1.1
Comit
Franais des
Tests
Logiciels
Pourquoi les tests sont-ils ncessaires? (K2)
International
Software Testing
20 minutes
Termes
Bug, dfaut, erreur, dfaillance, dfaut, mprise, qualit, risques, logiciel, test.
1.1.1
Contexte des systmes logiciels (K1)
Les systmes logiciels deviennent une part intgrante de notre existence, des applications
commerciales (p.ex. bancaires) aux produits de grande consommation (p.ex. automobiles). La
plupart dentre nous ont eu lexprience dun logiciel qui na pas fonctionn comme attendu. Des
logiciels ne fonctionnant pas correctement peuvent gnrer de nombreux problmes, depuis des
pertes financires, de temps ou de rputation, et pouvant mme aller jusqu causer des blessures
ou la mort.
1.1.2
Origine des dfauts logiciels (K2)
Un tre humain peut faire une erreur (mprise), qui produit un dfaut (bug) dans le code, dans un
logiciel ou un systme, ou dans un document. Si un dfaut dans du code est excut, le systme
neffectuera pas ce quil aurait d faire (ou fera ce quil naurait pas d faire), gnrant une
dfaillance. Des dfauts dans les logiciels, systmes ou documents peuvent gnrer des
dfaillances, mais tous les dfauts ne le font pas.
Les dfauts apparaissent parce que les humains peuvent se tromper et cause des chanciers
serrs, de la complexit du code et des infrastructures, des modifications de technologies et/ou de
multiples interactions entre les systmes.
Les dfaillances peuvent tre aussi causes par des conditions denvironnement : radiations,
magntisme, champs lectroniques et pollution peuvent causer des dfauts dans les
microprogrammes ou influencer lexcution des logiciels en modifiant les conditions matrielles.
1.1.3 Rle des tests dans le dveloppement, la maintenance et lopration

des logiciels (K2)
Des tests rigoureux des systmes et de la documentation peuvent aider rduire les risques
doccurrence de problmes dans lenvironnement oprationnel et contribuent la qualit des
systmes logiciels, si les dfauts dcouverts sont corrigs avant la livraison du systme pour un
usage oprationnel.
Les tests de logiciels peuvent aussi tre ncessaires pour respecter des exigences lgales ou
contractuelles, ou atteindre des normes industrielles spcifiques.
1.1.4
Tests et qualit (K2)
Avec laide des tests, il est possible de mesurer la qualit des logiciels en termes de dfauts
trouvs, pour des caractristiques et exigences tant fonctionnelles que non-fonctionnelles (p.ex.
fiabilit, utilisabilit, rentabilit, maintenabilit et portabilit). Pour plus dinformations sur les tests
non-fonctionnels voir Chapitre 2; pour plus dinformations sur les caractristiques logicielles voir
Software Engineering Software Product Quality (ISO 9126).
Les tests peuvent augmenter le niveau de confiance en la qualit dun logiciel sils trouvent peu ou
pas de dfauts. Un test conu correctement et qui est excut sans erreur rduit le niveau de
risque gnral du systme. Quand les tests trouvent des dfauts, la qualit du systme logiciel
saccrot quand ces dfauts sont corrigs.
Version 2011
Page 11 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Des leons devraient tre apprises partir des projets prcdents. En comprenant les causes
premires des dfauts trouvs dans dautres projets, les processus peuvent tre amliors, ce qui
ensuite peut prvenir lapparition de ces dfauts et, en consquence, amliorer la qualit des
systmes futurs. Cest un aspect de lassurance qualit.
Les tests devraient tre intgrs comme une activit de lassurance qualit (p.ex. au ct des
standards de dveloppement, de la formation et de lanalyse des dfauts).
1.1.5
Combien de test est suffisant? (K2)
Dcider de combien de test est suffisant devrait prendre en compte le niveau de risque, incluant les
risques techniques, les risques lis la suret et au projet, ainsi que les contraintes du projet telles
que le temps et le budget. Les risques seront dvelopps au chapitre 5.
Les tests doivent fournir suffisamment dinformations pour que les responsables puissent prendre
des dcisions informes concernant la mise en production du logiciel ou du systme en cours de
test, pour ltape de dveloppement suivante ou la livraison aux clients.
Version 2011
Page 12 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
1.2
Comit
Franais des
Tests
Logiciels
Que sont les tests ? (K2)
International
Software Testing
30 minutes
Termes
dbogage, exigences, revues, cas de test, test, objectifs des tests, test,
Contexte
Une perception habituelle des tests est quils consistent uniquement en lexcution de tests, en fait
excuter le logiciel. Cest une partie des tests, mais pas lensemble des activits de test.
Des activits de test existent avant et aprs lexcution des tests. Ces activits incluent la
planification et le contrle, la slection des conditions de test, la conception et lexcution des cas
de tests, la vrification des rsultats, lvaluation des critres de sortie, linformation sur le
processus de test et sur le systme en cours de test ; elles incluent aussi la ralisation et la
finalisation des activits de clture dfinitive la fin dune phase de test. Les tests incluent aussi la
revue de documents (incluant le code source) et les analyses statiques.
Les tests dynamiques et les tests statiques peuvent tre utiliss comme des moyens pour atteindre
des objectifs similaires, et fourniront des informations permettant lamlioration du systme tester
et des processus de dveloppement et de test.
Les objectifs de tests peuvent varier :
o Trouver des dfauts
o Acqurir de la confiance sur le niveau de qualit
o Fournir de linformation utile aux prises de dcision
o Prvenir des dfauts
Le processus de rflexion et les activits visant concevoir des tests tt dans le cycle de vie
(vrifier les bases de tests via la conception des tests) peuvent aider prvenir lintroduction de
dfauts dans le code. Les revues de documents (p.ex. exigences), lidentification et la rsolution de
problmes peuvent aussi aider prvenir lapparition de dfauts dans le code.
Les points de vue diffrents des tests prennent en compte des objectifs diffrents. Par exemple,
dans les tests de dveloppement (p.ex. tests des composants, dintgration ou systme), lobjectif
principal peut tre de gnrer le plus de dfaillances possible de faon identifier et corriger les
dfauts dans le logiciel. Dans les tests dacceptation, lobjectif principal peut tre de confirmer que
le systme fonctionne comme attendu, pour sassurer quil atteint les exigences. Dans certains cas
lobjectif principal des tests peut tre dvaluer la qualit dun logiciel (sans chercher trouver des
anomalies), de faon fournir aux responsables de linformation sur les risques de distribuer un
systme un moment prcis. Les tests de maintenance incluent souvent des tests pour sassurer
que de nouvelles anomalies nont pas t introduites pendant le dveloppement des volutions.
Pendant les tests dopration, les objectifs principaux peuvent tre dvaluer les caractristiques du
systme telles la disponibilit ou la fiabilit.
Tester et dboguer sont diffrents. Les tests dynamiques peuvent montrer des dfaillances
causes par des dfauts. Dboguer est lactivit de dveloppement qui trouve, analyse et supprime
les causes de la dfaillance. Les tests de confirmation ultrieurs effectus par un testeur assurent
que la correction rsout effectivement la dfaillance. La responsabilit de chaque activit est
diffrente : les testeurs testent, les dveloppeurs dboguent.
Le processus de test et les activits de test sont expliqus en Section 1.4.
Version 2011
Page 13 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
1.3
Comit
Franais des
Tests
Logiciels
Les 7 principes gnraux des tests (K2)
International
Software Testing
35 minutes
Termes
Tests exhaustifs.
Principes
Un nombre de principes de test ont t suggrs au cours des 40 dernires annes et offrent des
indications communes tous les tests.
Principe 1 Les tests montrent la prsence de dfauts
Les tests peuvent prouver la prsence de dfauts, mais ne peuvent pas en prouver labsence. Les
tests rduisent la probabilit que des dfauts restent cachs dans le logiciel mais, mme si aucun
dfaut nest dcouvert, ce nest pas une preuve dexactitude.
Principe 2 Les tests exhaustifs sont impossibles
Tout tester (toutes les combinaisons dentres et de pr-conditions) nest pas faisable sauf pour des
cas triviaux. Plutt que des tests exhaustifs, nous utilisons lanalyse des risques et des priorits
pour focaliser les efforts de tests.
Principe 3 Tester tt
Pour trouver des dfauts tt, les activits de tests devraient commencer aussi tt que possible dans
le cycle de dveloppement du logiciel ou du systme, et devraient tre focalises vers des objectifs
dfinis.
Principe 4 Regroupement des dfauts
Leffort de test devrait tre fix proportionnellement la densit des dfauts prvus et constats
dans les diffrents modules. Un petit nombre de modules contiennent gnralement la majorit des
dfauts dtects lors des tests pr-livraison, ou affichent le plus de dfaillances en opration.
Principe 5 Paradoxe du pesticide
Si les mmes tests sont rpts de nombreuses fois, il arrivera que le mme ensemble de cas de
tests ne trouvera plus de nouveaux dfauts. Pour prvenir ce paradoxe du pesticide, les cas de
tests doivent tre rgulirement revus et rviss, et de nouveaux tests, diffrents, doivent tre crits
pour couvrir dautres chemins dans le logiciel ou le systme de faon permettre la dcouverte de
nouveaux dfauts.
Principe 6 Les tests dpendent du contexte
Les tests sont effectus diffremment dans des contextes diffrents. Par exemple, les logiciels de
scurit critique seront tests diffremment dun site de commerce lectronique.
Principe 7 Lillusion de labsence derreurs
Trouver et corriger des dfauts naide pas si le systme conu est inutilisable et ne comble pas les
besoins et les attentes des utilisateurs.
Version 2011
Page 14 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
1.4
Comit
Franais des
Tests
Logiciels
International
Software Testing
Processus de test fondamental (K1)
35 minutes
Termes
Tests de confirmation, incident, test de rgression, base de tests , conditions de tests, couverture
de test, donnes de tests, excution des tests, critres de sortie, registre de test, plan de test,
stratgie de test,procdure de test, politique de test, suite de test, rapport de synthse de tests,
testware.
Contexte
La partie la plus visible des tests est lexcution des tests. Mais pour tre efficaces et rentables, les
plans de tests devraient aussi inclure du temps pour planifier les tests, concevoir les cas de tests,
prparer les excutions et valuer ltat.
Le processus de test fondamental comprend les activits principales suivantes:
Planification des tests et contrle

Analyse et conception des tests
Implmentation et excution des tests
Evaluer les critres de sortie et informer
Activits de clture des tests
Bien que logiquement squentielles, les activits du processus peuvent se chevaucher

partiellement ou tre concurrentes. Une adaptation de ces activits principales au contexte du
systme ou du projet est en gnral requise.
1.4.1
Planification et contrle des tests (K1)
La planification des tests consiste dfinir les objectifs du test et spcifier les activits de test
mettre en uvre pour atteindre les objectifs et la mission.
Le contrle des tests est une activit continue de comparaison de lavancement actuel par rapport
au plan, et dinformation sur ltat, y compris les dviations par rapport au plan. Cela implique de
prendre les actions ncessaires pour atteindre la mission et les objectifs du projet. Afin de contrler
les tests, les activits de test devraient tre contrles tout au long du projet. La planification des
tests prend en compte le feed-back des activits de contrle et de suivi.
Les tches de planification et contrle sont dfinies au chapitre 5 de ce syllabus.
1.4.2
Analyse et Conception des tests (K1)
Lanalyse et la conception des tests reprsentent les activits o les objectifs de test gnraux sont
transforms en des conditions de test et des conceptions de test tangibles.
Lanalyse et la conception des tests se composent des tches majeures suivantes:
1
o Rviser les bases du test (telles que les exigences, le niveau dintgrit logiciel (niveau de
risque), les rapports danalyse de risque, larchitecture, la conception et les interfaces)
o Evaluer la testabilit des exigences et du systme
o Identifier et prioriser les conditions de test sur la base de lanalyse des articles de test, la
spcification, le comportement et la structure du logiciel
1
Le degr de conformit auquel le logiciel satisfait ou doit satisfaire par rapport un ensemble de caractristiques
slectionnes par les parties-prenantes ou bases sur les systmes logiciels, et devant tre dfinies pour reflter
limportance du logiciel pour les personnes concernes (p.ex: complexit logicielle, niveau de suret, niveau de scurit,
performance souhaite, robustesse ou cot).
Version 2011
Page 15 de 80
3-Nov201131-Mar-2010
Testeur Certifi
o
o
o
o
Comit
Franais des
Tests
Logiciels
International
Software Testing
Concevoir et prioriser les tests de haut niveau

Identifier les donnes de test ncessaires pour les conditions de test et les cas de test
Concevoir linitialisation de lenvironnement de test et identifier les infrastructures et outils
requis
Crer une traabilit bi-directionnelle entre les bases de test et les cas de test
1.4.3
Implmentation et excution des tests (K1)
Limplmentation et lexcution des tests est lactivit o les procdures ou scripts de test sont
spcifis en arrangeant les cas de test selon un ordre prcis et en ajoutant toute information utile
pour lexcution des tests; lenvironnement est initialis et les tests sont lancs.
Limplmentation et lexcution des tests se composent des tches majeures suivantes:
o Finaliser, dvelopper et prioriser les cas de test (yc lidentification des donnes de test)
o Dvelopper et prioriser les procdures de test, crer les donnes de test et, ventuellement,
prparer les harnais de test et crire les scripts de tests automatiques
o Crer des suites de tests partir des procdures de test pour une excution rentable des tests
o Vrifier que les environnements de tests ont t mis en place correctement
o Vrifier et mettre jour la traabilit bi-directionnelle entre les bases de test et les cas de test
o Excuter les procdures de test soit manuellement soit en utilisant des outils dexcution de
tests, en suivant la squence planifie
o Consigner les rsultats de lexcution des tests et enregistrer les identits et versions des
logiciels en test, outils de test et testware
o Comparer les rsultats actuels et les rsultats attendus.
o Signaler les divergences comme des incidents et les analyser de faon tablir leur cause
(p.ex. dfaut dans le code, dans les donnes de test, dans la documentation de test, ou
mprise dans la manire dexcuter le test)
o Rpter les activits de test en rponse aux actions prises pour chaque divergence. Par
exemple, rexcution dun test qui tait pralablement dfaillant de faon valider une
correction (test de confirmation), excution dun test corrig et/ou excution de tests de faon
sassurer que des dfauts nont pas t introduits dans des secteurs non modifis du logiciel ou
que le dfaut corrig na pas dcouvert dautres dfauts (test de rgression)
1.4.4
Evaluer les critres de sortie et informer (K1)
Evaluer les critres de sortie est lactivit o lexcution des tests est value en fonction des
objectifs dfinis. Ceci devrait tre fait pour chacun des niveaux de test.
Evaluer les critres de sortie contient les tches majeures suivantes:
o Vrifier les registres de tests en fonction des critres de sortie spcifis dans la planification
des tests
o Evaluer si des tests supplmentaires sont requis ou si les critres de sortie doivent tre
changs
o Ecrire un rapport de synthse des tests pour les parties prenantes
1.4.5
Activits de clture des tests (K1)
Les activits de clture des tests rassemblent les donnes des activits de tests termines de faon
consolider lexprience, les testwares, les faits et les valeurs. Ces activits sont menes aux
jalons dun projet, par exemple, quand un systme logiciel est mis en production, un projet de test
est termin (ou annul), un jalon est atteint, ou une version de maintenance est termine.
Les activits de clture des tests incluent les tches majeures suivantes:
o Vrifier quels livrables prvus ont t livrs
o Clturer les rapports dincidents ou crer des demandes dvolution pour ceux restant ouverts
o Documenter lacceptation du systme
Version 2011
Page 16 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
o
o
o
o
Comit
Franais des
Tests
Logiciels
International
Software Testing
Finaliser et archiver les testwares, environnements de test et infrastructures de test pour une
rutilisation future
Fournir les testwares lorganisation en charge de la maintenance
Analyser les leons apprises pour identifier les changements ncessaires pour les versions et
projets futurs
Utiliser linformation collecte pour amliorer la maturit des tests
Version 2011
Page 17 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
1.5
Comit
Franais des
Tests
Logiciels
La psychologie des tests (K2)
International
Software Testing
25 minutes
Termes
Estimation derreur, test indpendant.
Contexte
La tournure desprit utiliser pendant les tests et les revues est diffrente de celle utilise lors de
lanalyse ou du dveloppement. Avec la mentalit approprie, des dveloppeurs sont capables de
tester leur propre code, mais affecter cette responsabilit des testeurs permet typiquement de
focaliser leffort et de fournir des bnfices additionnels tels quune perspective indpendante par
des ressources de test entranes et professionnelles. Les tests indpendants peuvent tre
effectus nimporte quel niveau des tests
Un certain degr dindpendance (vitant le parti-pris de lauteur) est souvent plus efficace pour
dtecter des dfauts et des dfaillances. Lindpendance nest pas cependant un remplacement de
la familiarit, et les dveloppeurs peuvent efficacement trouver beaucoup derreurs dans leur propre
code. Plusieurs niveaux dindpendance peuvent tre dfinis, comme les niveaux suivants
prsents du plus faible au plus lev :
o Tests conus par la (les) personne(s) qui a (ont) crit le logiciel tester (niveau faible
dindpendance).
o Tests conus par une (des) autre(s) personne(s) (p.ex. de lquipe de dveloppement).
o Tests conus par une (des) personne(s) dun groupe diffrent au sein de la mme organisation
(p.ex. quipe de test indpendante) ou par des spcialistes de test (p.ex. spcialistes en tests
de performance ou utilisabilit)
o Tests conus par une (des) personne(s) dune organisation ou socit diffrente (p.ex. soustraitance ou certification par un organisme externe)
Les personnes et les projets sont dirigs par des objectifs. Les personnes ont tendance aligner
leurs plans en fonction des objectifs mis en place par le management et les autres responsables,
par exemple, pour trouver des dfauts ou confirmer quun logiciel fonctionne. De ce fait, il est
important de spcifier clairement les objectifs des tests.
Lidentification de dfaillances pendant les tests peut tre perue comme une critique contre le
produit et contre son(ses) auteur(s). Les tests sont, de ce fait, souvent vus comme une activit
destructrice, mme si cest trs constructif dans la gestion des risques du produit. Rechercher des
dfaillances dans un systme requiert de la curiosit, du pessimisme professionnel, un oeil critique,
une attention au dtail, une bonne communication avec ses pairs en dveloppement, et de
lexprience sur laquelle baser lestimation derreurs.
Si des erreurs, dfauts ou dfaillances sont communiqus de manire constructive, lanimosit
entre les testeurs et les analystes, concepteurs et dveloppeurs peut tre vite. Ceci sapplique
autant aux revues quaux tests.
Les testeurs et le responsable des tests ont besoin de bonnes comptences relationnelles pour
communiquer des informations factuelles sur les dfauts, les progrs et les risques, de manire
constructive. Pour lauteur du logiciel ou du document, une information sur les dfauts peut
permettre damliorer leur savoir-faire. Les dfauts trouvs et corrigs pendant les tests permettront
de gagner du temps et de largent plus tard, et de rduire les risques.
Des problmes de communication peuvent survenir, particulirement si les testeurs sont vus
uniquement comme messagers porteurs de mauvaises nouvelles concernant des dfauts.
Version 2011
Page 18 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Cependant, il existe plusieurs manires damliorer la communication et les relations entre les
testeurs et leurs interlocuteurs :
o
o
o
o
Commencer par une collaboration plutt que par des conflits rappeler chacun lobjectif
commun de systmes de meilleure qualit
Communiquer les dcouvertes sur le produit de faon neutre et factuelle sans critiquer la
personne responsable, par exemple, crire des rapports dincidents (ou des rsultats de
revues) objectifs et factuels
Essayer de comprendre ce que ressent une autre personne et pourquoi elle ragit comme elle
le fait
Confirmer que lautre personne a compris ce que lon a dit et vice versa
Version 2011
Page 19 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
1.6
Comit
Franais des
Tests
Logiciels
Code dthique
International
Software Testing
10 minutes
Limplication dans le test logiciel permet aux individus davoir accs des informations
confidentielles et privilgies. Un code dthique est ncessaire, notamment pour assurer que les
informations ne soient pas utilises dans des cas non appropris. En rfrence au code dthique
dACM et de lIEEE pour les ingnieurs, lISTQB dfinit le code dthique suivant :
PUBLIC les testeurs de logiciels certifis doivent agir en fonction de lintrt public
CLIENT ET EMPLOYEUR les testeurs de logiciels certifis doivent agir pour lintrt de leur
client et de leur employeur tout en respectant lintrt public
PRODUIT les testeurs de logiciels certifis doivent assurer que les fournitures quils produisent
(concernant les produits et les systmes quils testent) rpondent le plus possible aux
standards professionnels
JUGEMENT les testeurs de logiciels certifis doivent conserver leur intgrit et leur
indpendance dans leur jugement professionnel
GESTION les chefs de projet de test de logiciels certifis et les responsables doivent respecter
et promouvoir une approche morale dans la gestion de projets de test de logiciels
PROFESSION les testeurs de logiciels certifis doivent mettre en avant lintgrit et la
rputation du mtier en cohrence avec lintrt public
COLLEGUES les testeurs de logiciels certifis doivent tre loyaux, aider leurs collgues, et
promouvoir le partenariat avec les dveloppeurs de logiciels
PERSONNELLEMENT les testeurs de logiciels certifis doivent participer en permanence de
la formation pour leur mtier et doivent promouvoir une approche morale concernant sa
pratique.
References
1.1.5 Black, 2001, Kaner, 2002
1.2 Beizer, 1990, Black, 2001, Myers, 1979
1.3 Beizer, 1990, Hetzel, 1988, Myers, 1979
1.4 Hetzel, 1988
1.4.5 Black, 2001, Craig, 2002
1.5 Black, 2001, Hetzel, 1988
Version 2011
Page 20 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
2. Tester Pendant le Cycle de Vie Logiciel

(K2)
International
Software Testing
115 minutes
Objectifs de connaissance pour Tester Pendant le Cycle de Vie

Logiciel
Les objectifs identifient ce que vous serez capable de faire aprs avoir suivi ce module.
2.1 Les modles de dveloppement logiciel (K2)

LO-2.1.1
LO-2.1.2
LO-2.1.3
Comprendre les relations entre le dveloppement, les activits de test et les livrables
dans le cycle de vie de dveloppement, et donner des exemples bass sur des
caractristiques et contextes de produits et de projets (K2).
Reconnatre que les modles de dveloppement logiciel doivent tre adapts au
contexte du projet et aux caractristiques du produit (K1).
Rappeler que les bonnes pratiques de test sont applicables dans tous les modles de
cycle de vie (K1)
2.2 Niveaux de tests (K2)

LO-2.2.1
Comparer les diffrents niveaux de tests: objectifs principaux, types dobjets habituels
tester, types de tests habituels (p.ex. fonctionnels ou structurels) et livrables associs,
personnes en charge des tests, types de dfauts et de dfaillances identifier. (K2)
2.3 Types de tests: les cibles de tests (K2)

LO-2.3.1
LO-2.3.2
LO-2.3.3
LO-2.3.4
LO-2.3.5
Comparer les quatre types de tests (fonctionnels, non-fonctionnels, structurels et lis

aux changements) avec des exemples. (K2)
Reconnatre que les tests fonctionnels et structurels peuvent apparatre nimporte
quel niveau. (K1)
Identifier et dcrire des types de tests non-fonctionnels bass sur des exigences nonfonctionnelles. (K2)
Identifier et dcrire des types de tests bass sur lanalyse de la structure ou de
larchitecture dun systme logiciel. (K2)
Dcrire lutilit des tests de confirmation et des tests de rgression. (K2)
2.4 Tests de maintenance (K2)

LO-2.4.1
LO-2.4.2
LO-2.4.3
Comparer les tests de maintenance (tester un systme existant) et les tests dune
nouvelle application en ce qui concerne les types de tests, les dclencheurs des tests
et la quantit de tests. (K2)
Reconnaitre les indicateurs pour les tests de maintenance (modification, migration et
abandon). (K1)
Dcrire le rle des tests de rgression et de lanalyse dimpact en maintenance. (K2)
Version 2011
Page 21 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
2.1
Comit
Franais des
Tests
Logiciels
Modles de Dveloppement Logiciel (K2)
International
Software Testing
20 minutes
Termes
Logiciel commercial sur tagre (en anglais : Commercial Off The Shelf ou COTS), modle de
dveloppement incrmental niveaux de tests, validation, vrification, modle en V.
Contexte
Les tests nexistent pas de faon isole; les activits de test sont lies aux activits de
dveloppement logiciel. Les diffrents modles de cycle de dveloppement ncessitent des
approches de tests diffrentes.
2.1.1
Modle en V (K2)
Bien que des variantes du modle en V existent, un modle en V standard utilise quatre niveaux de
tests, correspondant aux quatre niveaux de dveloppement.
Les quatre niveaux utiliss dans le syllabus sont:
Tests de composants (unitaires);

Tests dintgration;
Tests systme;
Tests dacceptation.
En pratique, un modle en V peut avoir des niveaux de dveloppement et de tests diffrents, en

moins ou en plus, en fonction des projets et des produits logiciels. Par exemple, il peut y avoir des
tests dintgration des composants aprs les tests de composants, et des tests dintgration de
systmes aprs des tests systmes.
Les livrables logiciels (tels les scnarios dutilisation ou les cas demploi, les spcifications
dexigences, les documents de conception et le code) produits pendant le dveloppement sont
souvent les bases des tests dun ou plusieurs niveaux de tests. Des rfrences pour des livrables
gnriques sont disponibles dans le modle CMMI (Capability Maturity Model Integration) ou dans
lIEEE/IEC 12207 (Processus de cycle de vie logiciel Software life cycle processes). La vrification
et la validation (ainsi que la conception au plus tt des tests) peuvent tre effectues pendant le
dveloppement des livrables logiciels.
2.1.2
Modle de dveloppement itratif (K2)
Le mode de dveloppement itratif est une succession dactivits excutes comme une srie de
petits dveloppements: exigences, conception, construction et tests dun systme. Exemples :
prototypage, dveloppement rapide dapplications (RAD), Rational Unified Process (RUP) et les
modles de dveloppement agiles. Le systme logiciel rsultant (lincrment) dune itration peut
tre test plusieurs niveaux de tests chaque itration. Un incrment, ajout ceux dvelopps
pralablement, forme un systme partiel en croissance, qui devrait galement tre test. Les tests
de rgression sont de plus en plus importants sur toutes les itrations aprs la premire. La
vrification et la validation peuvent tre effectues sur chaque incrment.
2.1.3
Tester au sein dun modle de cycle de vie (K2)
Quel que soit le modle de cycle de vie, plusieurs bonnes pratiques de tests sappliquent:
A chaque activit de dveloppement, correspond une activit de test.

Chaque niveau de test a des objectifs de tests spcifiques pour ce niveau.
Lanalyse et la conception des tests pour un niveau de test devraient commencer pendant
lactivit correspondante de dveloppement.
Version 2011
Page 22 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Les testeurs doivent tre impliqus dans la revue des documents aussi tt que des brouillons
sont disponibles dans le cycle de dveloppement.
Les niveaux de tests peuvent tre combins ou rorganiss selon la nature du projet ou de
larchitecture du systme. Par exemple, pour lintgration dun logiciel sur tagre (COTS) dans un
systme, lacheteur peut effectuer des tests dintgration au niveau systme (Ex. intgration dans
linfrastructure et les autres systmes, ou dploiement du systme) ainsi que des tests
dacceptation (fonctionnels et/ou non-fonctionnels, et tests dacceptation utilisateurs et/ou
oprationnels).
Version 2011
Page 23 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
2.2
Comit
Franais des
Tests
Logiciels
Niveaux de tests (K2)
International
Software Testing
40 minutes
Termes
Alpha tests, Beta tests, tests de composant (aussi connus comme tests unitaires, de modules ou de
programmes), tests dacceptation contractuelle, pilotes, tests sur le terrain, exigences
fonctionnelles, intgration, tests dintgration, exigences non-fonctionnelles, tests de robustesse,
bouchons, tests systme, environnement de test, niveau de tests, dveloppement dirig par les
tests, tests dacceptation utilisateurs.
Contexte
Pour chaque niveau de tests, les aspects suivants peuvent tre identifis: les objectifs gnriques,
le(s) livrable(s) rfrenc(s) pour driver des cas de tests (cest dire la base de test), les objets de
tests (cd. ce qui est test), les dfauts et les dfaillances typiques trouver, les exigences en
harnais de tests et en support doutils, ainsi que les approches et responsabilits spcifiques au
niveau.
Les tests des donnes de configuration du systme doivent tre pris en compte au cours de la
plannification des tests.
2.2.1
Tests de composants (K2)
Bases de tests:
Exigences des composants
Conception dtaille
Code
Objets habituels de test:
Composants
Programmes
Conversions de donnes / utilitaires ou programmes de migration
Modules de bases de donnes
Les tests de composants (galement connus sous les noms de tests unitaires, de modules ou de
programmes) cherchent des dfauts dans, et vrifient le fonctionnement des, logiciels (p.ex.
modules, programmes, objets, classes, etc.) qui sont testables sparment. Cela peut se faire de
faon isole par rapport au reste du systme, en fonction du contexte du cycle de dveloppement
du logiciel et du systme. Des bouchons, pilotes et simulateurs peuvent tre utiliss.
Les tests de composants peuvent inclure des tests de fonctionnalits et des tests de
caractristiques non-fonctionnelles, telles que le comportement des ressources (p.ex. fuites
mmoire) ou des tests de robustesse, ainsi que des tests structurels (p.ex. couverture des
branches). Les cas de test sont drivs des livrables tels que les spcifications des composants
(spcifications dtailles), la conception du logiciel ou le modle de donnes.
La plupart du temps, les tests de composants se font avec laccs au code du logiciel test et sur
un environnement de dveloppement comme un framework de tests unitaire ou avec les outils de
dbogage. En pratique ils impliquent gnralement le programmeur ayant crit le code.
Habituellement, les dfauts sont corrigs ds quils sont trouvs, sans formellement enregistrer des
incidents.
Une approche des tests de composants est de prparer et automatiser des cas de tests avant le
codage. Cela sappelle lapproche Tester dabord (en anglais : test first )ou Dveloppement
pilot par les tests. Cette approche, fortement itrative est base sur des cycles de dveloppement
de cas de tests, puis construction et intgration de petits bouts de code, puis excution des tests de
composants et correction des dfauts trouvs jusqu leur russite.
Version 2011
Page 24 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
2.2.2
Comit
Franais des
Tests
Logiciels
International
Software Testing
Tests dintgration (K2)
Bases de Tests:
Conception du logiciel et du systme
Architecture
Workflows
Cas dutilisation
Sous-systmes
Implmentation de bases de donnes
Infrastructure
Interfaces
Configuration systme et donnes de configuration
Les tests dintgration testent les interfaces entre les composants, les interactions entre diffrentes
parties dun systme comme par exemple le systme dexploitation, le systme de fichiers, le
matriel ou les interfaces entre les systmes.
Plusieurs niveaux de tests dintgration peuvent tre effectus sur des objets de taille variable. Par
exemple:
Tests dintgration des composants testant les interactions entre les composants logiciels et
effectus aprs les tests de composants;
Tests dintgration systme testant lintgration entre les diffrents systmes ou entre logiciel
et matriel et pouvant tre effectus aprs les tests systme. Dans ce cas, lorganisation en
charge du dveloppement peut ne contrler quun ct de linterface. Cela peut tre considr
comme un risque mtier. Les processus commerciaux mis en uvre comme les workflows
peuvent impliquer plusieurs systmes. Les aspects inter-plateformes peuvent tre significatifs.
Plus la porte de lintgration est vaste, plus il devient difficile disoler les dfauts lis un
composant ou un systme particulier. Cela peut conduire un accroissement des risques et du
temps ncessaire pour rsoudre les problmes.
Des stratgies dintgration systmatique peuvent tre bases sur larchitecture des systmes
(telles que top-down ou bottom-up), les tches fonctionnelles, les squences dexcution de
transactions, ou dautres aspects du systme ou du composant. Afin disoler facilement les fautes,
et dtecter les dfauts au plus tt, lintgration devrait normalement tre incrmentale plutt qutre
effectue en une fois (big bang).
Les tests de caractristiques non-fonctionnelles particulires (p.ex. performances) peuvent tre
inclus dans les tests dintgration.
A chaque tape de lintgration, les testeurs se concentrent uniquement sur lintgration elle mme.
Par exemple, sils sont en train dintgrer le module A avec le module B, les testeurs sappliquent
tester la communication entre les modules et non pas leurs fonctionnalits individuelles. Les
approches fonctionnelles et structurelles peuvent toutes deux tre utilises.
Idalement, les testeurs devraient comprendre larchitecture et influencer le planning dintgration.
Si les tests dintgration sont prvus avant que les composants ou les systmes ne soient
fabriqus, les tests pourront tre conus dans le bon ordre pour tre efficaces et efficients.
2.2.3
Tests systme (K2)
Bases de Test:
Spcifications dexigences Systme et logiciel
Version 2011
Page 25 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Cas dutilisation
Spcifications fonctionnelles
Rapports danalyse des risques
Objets de tests habituels:

Manuels systme, utilisateur et oprationnels
Configuration systme et donnes de configuration
Les tests systmes traitent le comportement dun systme/produit complet. Le primtre des tests
doit tre clairement dfini dans le plan de test maitre ou le plan de test du niveau.
Pour les tests systme, lenvironnement de test devrait correspondre la cible finale ou un
environnement de production de faon minimiser les risques de dfaillances dues
lenvironnement.
Les tests systme peuvent inclure des tests bass sur les risques et/ou sur les spcifications et les
exigences, les processus commerciaux, les cas dutilisation, ou autres descriptions de haut niveau
du comportement du systme, les modles de comportement, les interactions avec le systme
dexploitation et les ressources systme.
Les tests systme devraient examiner la fois les exigences fonctionnelles et les nonfonctionnelles du systme ainsi que la qualit des donnes. Les testeurs doivent galement
sadapter aux exigences peu ou pas documentes. Les tests fonctionnels au niveau systme
commencent par lutilisation des techniques de spcification de tests les plus appropries (bote
noire). Par exemple, une table de dcision peut tre cre pour les combinaisons deffets dcrits
dans les processus commerciaux. Les techniques bases sur les structures (bote blanche)
peuvent ensuite tre utilises pour valuer la minutie des tests par rapport un lment comme la
structure de menu ou la navigation dans la page web. (voir Chapitre 4.)
Une quipe de tests indpendante excute souvent des tests systme.
2.2.4
Tests dacceptation (K2)
Bases de test:
Exigences utilisateur
Exigences du systme
Cas dutilisation
Processus mtier
Rapports danalyse des risques
Processus mtier sur lintgralit du systme
Processus oprationnels de maintenance
Procdures utilisateur
Formulaires
Rapports
Donnes de configuration
Les tests dacceptation relvent souvent de la responsabilit des clients ou utilisateurs dun
systme; dautres responsables (parties prenantes) peuvent aussi tre impliqus.
Les objectifs des tests dacceptation sont de prendre confiance dans le systme, dans des parties
du systme ou dans des caractristiques non-fonctionnelles du systme. La recherche danomalies
nest pas lobjectif principal des tests dacceptation. Les tests dacceptation peuvent valuer si le
systme est prt tre dploy et utilis, bien que ce ne soit pas ncessairement le dernier niveau
Version 2011
Page 26 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
de tests. Par exemple, une intgration systme grande chelle peut arriver aprs les tests
dacceptation du systme.
Les tests dacceptation peuvent se faire plusieurs niveaux de tests, par exemple:
Des tests dacceptation peuvent avoir lieu sur un composant sur tagre quand il est install
ou intgr.
Les tests dacceptation de lutilisabilit dun composant peuvent tre effectus pendant les
tests unitaires.
Les tests dacceptation dune volution fonctionnelle peuvent tre excuts avant les tests
systme.
Les formes habituelles des tests dacceptation incluent :
Tests dacceptation utilisateur
Ces tests vrifient laptitude et lutilisabilit du systme par des utilisateurs.
Tests (dacceptation) oprationnelle
Lacceptation du systme par les administrateurs systme, dont:
Tests des backups et restaurations;
Reprise aprs sinistre;
Gestion des utilisateurs;
Tches de maintenance;
Chargements de donnes et tches de migration
Vrification priodique des vulnrabilits de scurit.
Tests dacceptation contractuelle et rglementaire
Les tests dacceptation contractuelle sont excuts sur base des critres dacceptation contractuels
pour la production de logiciels dvelopps sur mesure. Les critres dacceptation devraient tre
dfinis lors de la rdaction du contrat.
Les tests dacceptation rglementaires sont excuts par rapport aux rglements et lgislations qui
doivent tre respects, telles que les obligations lgales, gouvernementales ou de scurit.
Tests alpha et beta (ou sur le terrain)
Les dveloppeurs de logiciels pour le public, ou de COTS (logiciel commercial sur tagre),
souhaitent souvent recueillir lavis des clients potentiels ou existants sur leur march, avant de
mettre en vente.
Les Alpha tests sont excuts sur le site de lorganisation effectuant le dveloppement mais pas
par les quipes de dveloppement. Les Bta tests ou tests sur le terrain sont excuts par des
personnes sur leurs sites propres.
Les organisations peuvent aussi utiliser dautres termes, tels que tests dacceptation usine ou
tests dacceptation sur site pour des systmes qui sont tests avant dtre transfrs sur le site
client.
Version 2011
Page 27 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
2.3
Comit
Franais des
Tests
Logiciels
Types de tests (K2)
International
Software Testing
40 minutes
Termes
tests bote noire, couverture du code, tests fonctionnels, tests dinteroprabilit, tests de charge,
tests de maintenabilit, tests de performances, tests de portabilit, tests de fiabilit, tests de
scurit, tests de stress, tests structurels, tests dutilisabilit, tests bote blanche.
Contexte
Un groupe dactivits de tests peut tre ax sur la vrification du systme logiciel (ou dune partie
du systme) pour une raison ou une cible particulire.
Un type de tests est focalis sur un objectif de tests particulier, qui peut tre
le test dune fonction devant tre effectue par le logiciel;
une caractristique non-fonctionnelle, telle que la fiabilit ou lutilisabilit,
la structure ou larchitecture du logiciel ou du systme;
li aux changements, p.ex. confirmer que des anomalies ont t corriges (tests de
confirmation) et pour rechercher la prsence de modifications non voulues (tests de
rgression).
Un modle du logiciel peut tre dvelopp et/ou utilis dans des tests structurels et fonctionnels
(p.ex un diagramme de contrle de flux ou une structure de menu), dans des tests non fonctionnels
(modles de menaces de scurit), dans les tests fonctionnels (p.ex un diagramme de flux de
processus, un diagramme de transitions dtat ou des spcifications en langage naturel).
2.3.1
Tests des fonctions (tests fonctionnels) (K2)
Les fonctionnalits quun systme, sous-systme ou composant doit effectuer peuvent tre dcrites
dans des livrables tels que des spcifications dexigences, les cas dutilisation, ou les spcifications
fonctionnelles, ou encore non documentes. Les fonctions sont ce que fait le systme.
Les tests fonctionnels sont bass sur ces fonctions et caractristiques (dcrites dans des
documents ou comprises par les testeurs), et leur interoprabilit avec dautres systmes. Ils
peuvent tre excuts tous les niveaux de tests (p.ex. les tests dun composant peuvent tre
bass sur les spcifications du composant).
Des techniques bases sur les spcifications peuvent tre utilises pour driver des conditions de
tests et des cas de tests partir des fonctionnalits du logiciel ou du systme (voir Chapitre 4.) Les
tests fonctionnels concernent le comportement extrieur du logiciel (tests bote noire).
Un type de test fonctionnel, le test de scurit, examine les fonctions (p.ex. pare-feu) lies la
dtection de menaces, comme des virus, provenant de tiers malveillants. Un autre type de test
fonctionnel, le test dinteroprabilit, value la capacit du logiciel interagir avec un ou plusieurs
composants ou systmes spcifis.
2.3.2 Tests des caractristiques non fonctionnelles des produits logiciels (tests
non-fonctionnels) (K2)
Les tests non-fonctionnels incluent, mais pas uniquement, les tests de performances, tests de
charge, tests de stress, tests dutilisabilit, tests de maintenabilit, tests de fiabilit et les tests de
portabilit. Ces tests valuent comment le systme fonctionne.
Les tests non-fonctionnels peuvent tre effectus tous les niveaux de tests. Le terme de tests
non-fonctionnels dcrit les tests requis pour mesurer les caractristiques des systmes et logiciels
qui peuvent tre quantifies sur une chelle variable, comme les temps de rponse pour les tests
Version 2011
Page 28 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
de performances. Ces tests peuvent tre rfrencs dans un modle qualit tel que celui dfini par
lISO9126 Ingnierie Logicielle Qualit des Produits Logiciels (Software Engineering Software
Product Quality). Les tests non fonctionnels concernent laspect extrieur du logiciel et la plupart du
temps utilisent les techniques de conception de tests bote noire.
2.3.3
Tests de la structure / architecture logicielle (tests structurels) (K2)
Les tests structurels (bote blanche) peuvent tre effectus tous les niveaux de tests. Les
techniques structurelles sont utilises de faon optimale aprs les techniques bases sur les
spcifications, pour aider mesurer lampleur des tests via lvaluation de la couverture dun type
de structure.
La couverture indique quel point une structure a t teste par une suite de tests. Elle est
exprime en pourcentage dlments couverts. Si la couverture nest pas de 100%, alors de
nouveaux tests peuvent tre conus pour tester les lments manquants et ainsi augmenter la
couverture. Les techniques de couverture sont traites dans le chapitre 4.
A tous les niveaux de tests, mais spcialement dans les tests de composants et les tests
dintgration de composants, des outils peuvent tre utiliss pour mesurer la couverture du code
des lments, telle que les instructions ou les dcisions. Les tests structurels peuvent tre bass
sur larchitecture du systme comme par exemple la hirarchie dappels.
Les approches de tests structurels peuvent tre aussi appliques au niveau systme, lintgration
systme ou aux niveaux de tests dacceptation (p.ex. pour les processus mtier ou les structures de
menus).
2.3.4
Tests lis au changement (tests de confirmation et de rgression) (K2)
Quand un dfaut est dtect et corrig, le logiciel devrait tre re-test pour confirmer que le dfaut
original a t correctement t. Ceci est appel test de confirmation. Le dbogage (localisation et
correction de dfaut) est une activit de dveloppement, pas une activit de tests.
R-excuter des tests sur un programme dj test sappelle test de rgression . Cela se fait
aprs que des modifications du programme aient eu lieu, pour identifier tout nouveau dfaut d
ce(s) changement(s). Ces dfauts peuvent se trouver soit dans le logiciel en cours de tests, soit
dans dautres composants logiciels lis ou non. Les tests de rgression sont excuts quand le
logiciel, ou son environnement, est modifi. Le primtre des tests de rgression est bas sur le
risque de ne pas trouver danomalie dans un logiciel fonctionnant auparavant.
Les tests devraient tre rptables sils sont utiliss pour des tests de confirmation ou pour les tests
de rgression.
Les tests de rgression peuvent tre excuts tous les niveaux de tests, et sappliquent aux tests
fonctionnels, non-fonctionnels et structurels. Les suites de tests de rgression sont excutes
plusieurs fois et voluent gnralement lentement. Donc les tests de rgression sont de bons
candidats lautomatisation.
Version 2011
Page 29 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
2.4
Comit
Franais des
Tests
Logiciels
Tests de maintenance (K2)
International
Software Testing
15 minutes
Termes
Analyse dimpact, tests de maintenance
Contexte
Une fois dploy, un systme logiciel est souvent en service pendant des annes, voire des
dizaines dannes. Pendant ce temps, le systme, son paramtrage et son environnement sont
frquemment corrigs, modifis ou tendus. La planification au plus tt des livraisons est cruciale
pour le succs des tests de maintenance. Une distinction doit tre faite entre les livraisons
planifies et les mises jour chaud (hot fixes). Les tests de maintenance sont effectus sur un
systme oprationnel existant et sont dclenchs par des modifications, migrations ou suppression
de logiciels ou de systmes.
Les modifications incluent les changements ds aux volutions planifies (p.ex. livraisons de
nouvelles versions), aux modifications correctives et durgence, ainsi quaux changements
denvironnements tels que les montes en version planifies des systmes dexploitation, des
bases de donnes ou des COTS. Elles incluent galement les patchs de correction des
vulnrabilits de scurit potentielles ou dcouvertes dun systme dexploitation.
Les tests de maintenance lors de migrations (p.ex. dune plate-forme une autre) devraient inclure
les tests oprationnels du nouvel environnement tout comme les tests des modifications du logiciel.
Les tests de migration (tests de conversion) sont galement ncessaires lorsque les donnes dune
autre application seront migres dans le systme maintenir.
Les tests de maintenance pour la suppression (mise au rebut) dun systme incluent le test de la
migration des donnes ou leur archivage si de longues priodes de stockage de donnes sont
ncessaires.
En plus des tests des lments changs, les tests de maintenance incluent des tests de rgression
sur les parties du systme qui nont pas t modifies. Le primtre des tests de maintenance est
fonction des risques lis aux modifications, la taille du systme existant et la taille des
modifications effectues. Selon le changement, les tests de maintenance peuvent tre effectus
chacun ou tous les niveaux de tests et pour certains ou tous les types de tests.
Dterminer comment un systme existant est affect par les changements est appel analyse
dimpact, et est utilis pour dcider de la quantit de tests de rgression devant tre excuts.
Lanalyse dimpacts peut tre utilise pour dterminer les suites de tests de rgression.
Les tests de maintenance peuvent tre difficiles si les spcifications sont primes ou manquantes,
ou si les testeurs ayant la connaissance fonctionnelle ne sont pas disponibles.
Rfrences
2.1.3 CMMI, Craig, 2002, Hetzel, 1998, IEEE 12207
2.2 Hetzel, 1998
2.2.4 Copeland, 2004, Myers, 1979
2.3.1 Beizer, 1990, Black, 2001, Copeland, 2004
2.3.2 Black, 2001, ISO 9126
2.3.3 Beizer, 1990, Copeland, 2004, Hetzel, 1998
2.3.4 Hetzel, 1998, IEEE 829
2.4 Black, 2001, Craig, 2002, Hetzel, 1998, IEEE 829
Version 2011
Page 30 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
3.
Comit
Franais des
Tests
Logiciels
Techniques Statiques (K2)
International
Software Testing
60 minutes
Objectifs de connaissance pour Techniques Statiques

Les objectifs identifient ce que vous serez capable de faire la suite de chaque module.
3.1 Techniques statiques et processus de test (K2)

LO-3.1.1 Reconnatre les livrables qui peuvent tre examins par les diffrentes techniques
statiques. (K1)
LO-3.1.2 Dcrire limportance et la valeur de lutilisation de techniques statiques dans lvaluation
de livrables logiciels. (K2)
LO-3.1.3 Expliquer les diffrences entre les techniques statiques et dynamiques, en considrant les
objectifs, les types de dfauts identifier et le rle de ces techniques dans le cycle de vie du
logiciel. (K2)
3.2 Processus de revue (K2)

LO-3.2.1 Rappeler les activits, rles et responsabilits dune revue formelle typique. (K1)
LO-3.2.2 Expliquer les diffrences entre les diffrents types de revues: revue informelle, revue
technique, relecture technique et inspection. (K2)
LO-3.2.3 Expliquer les facteurs lis lexcution de revues couronnes de succs. (K2)
3.3 Analyse statique outille (K2)

LO-3.3.1 Rappeler les dfauts et erreurs typiques identifies par les analyses statiques et les
comparer ceux dtects par les revues et tests dynamiques. (K1)
LO-3.3.2 Dcrire, en utilisant des exemples, les avantages typiques des analyses statiques. (K2)
LO-3.3.3 Lister les dfauts typiques dans le code et la conception qui peuvent tre identifis par
des outils danalyse statique. (K1)
Version 2011
Page 31 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
3.1
Comit
Franais des
Tests
Logiciels
Techniques statiques et processus de test (K2)
International
Software Testing
15 minutes
Termes
Test dynamique, test statique.
Contexte
Contrairement au test dynamique, qui exige lexcution du logiciel, les techniques de tests
statiques reposent sur lexamen manuel (revues) ou lanalyse(analyse statique) du code ou de la
documentation du projet sans excution du code.
Les revues sont une manire de tester des produits logiciels (y compris du code) et peuvent tre
excutes bien avant lexcution de tests dynamiques. Les dfauts dtects pendant les revues
effectues tt dans le cycle de vie sont souvent bien moins coteux ter que les dfauts dtects
lors de lexcution des tests (p.ex. dfauts trouvs dans les exigences).
Une revue pourrait tre effectue entirement manuellement, mais il existe aussi des outils de
support. Lactivit manuelle principale est dexaminer le produit et den faire des commentaires.
Tout produit logiciel peut tre revu, y compris les exigences, les spcifications, les spcifications de
conception, le code, les plans de test, les spcifications de test, les cas de test, les scripts de test,
les guides utilisateur ou pages web.
Les bnfices des revues incluent une dtection et une correction anticipes des dfauts , des
amliorations de productivit dans le dveloppement, des dures de dveloppement rduites, des
dures et des cots de tests rduits, des rductions de cots tout au long de lexistence du logiciel,
moins de dfauts et une meilleure communication. Les revues peuvent dtecter des omissions, par
exemple, dans des exigences, dont la dtection pendant les tests dynamiques est peu probable.
Les revues, les analyses statiques et les tests dynamiques ont le mme objectif identifier des
dfauts. Ils sont complmentaires : les diffrentes techniques peuvent trouver diffrents types de
dfauts efficacement et rapidement. Contrairement aux tests dynamiques, les techniques statiques
trouvent les causes des dfauts plutt que les dfaillances elles-mmes.
Les dfauts typiques plus faciles trouver lors de revues que pendant les tests dynamiques sont :
dviations par rapport aux standards, dfauts dexigences, dfauts de conception, maintenabilit
insuffisante et spcifications incorrectes dinterfaces.
Version 2011
Page 32 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
3.2
Comit
Franais des
Tests
Logiciels
Processus de revue (K2)
International
Software Testing
25 minutes
Termes
Critre dentre, revue formelle, revue informelle, inspection, mtriques, modrateur, revue de
pairs, rviseur, scribe, revue technique, relecture technique.
Contexte
Les diffrents types de revues varient de informel , caractris par labsence dinstructions
crites pour les relecteurs, systmatique , caractris par la participation de lquipe, des
rsultats documents de la revue, et des procdures documentes pour mener la revue. La
formalit dun processus de revue est lie des facteurs tels que la maturit du processus de
dveloppement, toute disposition lgale ou exigence rglementaire ou la ncessit de traces
daudit.
La manire dont une revue est excute dpend des objectifs convenus pour la revue (p.ex. trouver
des dfauts, augmenter la comprhension, former les testeurs et les nouveaux membres dune
quipe ou organiser la discussion et dcider par consensus).
3.2.1
Phases dune revue formelle (K1)
Une revue formelle typique comprend les phases principales suivantes:

1. Planification :
Dfinir les critres de revues
Choisir le personnel
Allouer les rles
Dfinition des critres dentre et de sortie pour des types de revues plus formels (p.ex.,
inspections)
Slectionner la partie des documents revoir
Vrification des critres dentre (pour des types de revues plus formels)
2. Lancement:
Distribuer les documents
Expliquer les objectifs, le processus et les documents aux participants
3. Prparation individuelle
Prparer la runion de revue en revoyant le(s) document(s)
Ecriture des dfauts potentiels, questions et commentaires
4. Examen/valuation/enregistrement des rsultats (runion de revue):
Discuter ou enregistrer, avec des rsultats ou minutes documents (pour des types de
revues plus formels)
Noter les dfauts, faire des recommandations concernant le traitement des dfauts,
prendre des dcisions propos des dfauts
Examen/valuation et enregistrement pendant toutes les runions physiques ou
enregistrement de toutes les communications lectroniques
5. Re travail
Correction des dfauts dtects (ralis gnralement par lauteur)
Enregistrer le statut modifi des dfauts (dans les revues formelles)
6. Suivi:
Vrifier que les dfauts ont bien t traits
Rcolter les mtriques
Contrle sur la base des critres de sorties (pour des types de revues plus formels)
3.2.2
Rles et responsabilits (K1)
Une revue formelle typique inclura les rles ci-dessous :

Version 2011
Page 33 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Manager : dcide lexcution des revues, alloue le temps dans la planification du projet et
dtermine si les objectifs de revue ont t atteints.
Modrateur: la personne qui dirige la revue du document ou de lensemble des documents,
incluant la planification de la revue, lexcution de la revue, et le suivi post-runion. Si besoin,
le modrateur peut servir dintermdiaire entre les diffrents points de vue et est souvent la
personne sur qui repose le succs dune revue.
Auteur : lauteur ou la personne qui incombe la responsabilit principale du ou des
document(s) revoir.
Rviseurs : les individus avec une culture technique ou mtier spcifique (aussi appels
vrificateurs ou inspecteurs) qui, aprs la prparation ncessaire, identifient et dcrivent les
constatations (p.ex. dfauts) dans le produit en cours de revue. Les rviseurs devraient tre
choisis pour reprsenter les perspectives et rles diffrents dans le processus de revue et
prennent part toute runion de revue.
Scribe (ou greffier): documente tous les aspects, problmes et points ouverts identifis
pendant la runion.
En examinant des documents selon diffrentes perspectives, et en utilisant des check-lists, les
revues peuvent devenir plus efficaces et rentables, par exemple, une check-list base sur la
perspective dun utilisateur, dun mainteneur, dun testeur ou dun oprateur, ou une check-list
reprenant des problmes dexigences typiques.
3.2.3
Types de revues (K2)
Un produit logiciel unique ou les lments associs peuvent tre le sujet de plusieurs revues. Si
plus dun type de revue est utilis, lordre peut varier. Par exemple, une revue informelle peut tre
effectue avant une revue technique, ou une inspection peut tre effectue sur une spcification
dexigences, avant une relecture technique avec des clients. Les caractristiques principales,
options et objectifs des types de revues habituelles sont:
Revue informelle
Pas de processus formel;
Peut inclure la programmation par paires ou une revue de conception et de code par un
responsable technique;
Les rsultats peuvent tre documents;
Peut varier en utilit selon les rviseurs;
Objectif principal : manire bon march dobtenir des rsultats.
Relecture technique
Runion dirige par lauteur;
Peut prendre la forme de scnarios, rptitions blanc, participation de groupes de pairs;
Sessions sans limite de dure;
o Optionnellement une runion de prparation de revue par les rviseurs
o Optionnellement prparation dun rapport de revue incluant une liste de constatations
Optionnellement un scribe (qui nest pas lauteur) ;
Varie en pratique de quasiment informel trs formel;
Objectifs principaux: apprendre, gagner en comprhension, trouver des dfauts.
Revue technique
Documente, processus de dtection de dfauts dfini incluant des pairs et des experts
techniques avec optionnellement la participation de lencadrement;
Peut tre effectue comme une revue de pairs sans participation de lencadrement;
Idalement dirige par un modrateur form (pas lauteur);
Runion de prparation par les rviseurs;
Peut optionnellement utiliser des check-lists ;
Version 2011
Page 34 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Prparation dun rapport de revue incluant la liste de constatations, le verdict indiquant si le

produit logiciel rpond ses exigences et, si appropri, des recommandations relatives aux
constatations ;
Peut varier en pratique de quasiment informelle trs formelle;
Objectifs principaux: discuter, dcider, valuer des alternatives, trouver des dfauts, rsoudre
des problmes techniques et vrifier la conformit aux spcifications, plans, rglementations
et standards.
Inspection
Dirige par un modrateur form (pas lauteur);
Gnralement mene comme un examen par les pairs;
Rles dfinis;
Inclut des mtriques ;
Processus formel bas sur des rgles et des check-lists ;
Critres dentre et de sortie spcifis pour lacceptation du produit logiciel ;
Runion de prparation;
Rapport dinspection incluant la liste de constatations;
Processus formel de suivi (inclut le processus facultatif damlioration des composants);
Lecteur (facultatif);
Objectif principal: trouver des dfauts.
Les relectures techniques, les revues techniques et les inspections peuvent tre ralises au sein
dun groupe de pairs, cd. des collgues ayant le mme niveau dans lorganisation. Ce type de revue
est appel revue de pairs .
3.2.4
Facteurs de succs des revues (K2)
Les facteurs de succs des revues incluent:
Chaque revue a des objectifs prdfinis et clairs.

Les personnes impliques sont adquates pour les objectifs de la revue.
Les testeurs sont des rviseurs de valeur qui contribuent la revue et ainsi prennent
connaissance du produit afin de pouvoir prparer les tests plus tt.
Les dfauts trouvs sont bien accepts, et exprims objectivement.
Les aspects personnels et psychologiques sont traits (p.ex. en faisant de cela une
exprience positive pour lauteur)).
La revue est mene dans une atmosphre de confiance ; les rsultats ne sont pas utiliss
pour valuer les participants ;
Les techniques de revue adaptes aux objectifs, adaptes aux types et au niveau de livrable
logiciel, et adaptes aux types et niveau des rviseurs, sont appliques.
Des check-lists ou des rles sont utiliss lorsque cela est appropri, afin daugmenter
lefficacit de dtection des dfauts.
Des formations sont donnes sur les techniques de revue, en particulier celles concernant les
techniques plus formelles telles que les inspections.
Lencadrement supporte un bon processus de revue (p.ex. en incorporant du temps pour les
activits de revue dans les plannings des projets).
Laccent est mis sur lapprentissage et lamlioration du processus.
Version 2011
Page 35 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
3.3
Comit
Franais des
Tests
Logiciels
International
Software Testing
Analyse statique avec des outils (K2)
20 minutes
Termes
Compilateur, complexit, flux de contrle, flux de donnes, analyse statique.
Contexte
Lobjectif de lanalyse statique est de trouver des dfauts dans le code source et les modles
logiciels. Lanalyse statique est effectue sans vraiment excuter le code examin par loutil ; les
tests dynamiques excutent le code logiciel. Lanalyse statique peut dtecter des dfauts qui sont
difficiles trouver par les tests dynamiques. Comme pour les revues, lanalyse statique trouve des
dfauts plutt que des dfaillances. Les outils danalyse statique analysent le code du programme
(p.ex. les flux de contrle et les flux de donnes), ainsi que les sorties gnres telles que HTML
et/ou XML.
La valeur des tests statiques est :
La dtection trs tt de dfauts avant lexcution des tests.
Une information trs tt sur certains aspects suspects du code ou de la conception, par le
calcul de mtriques, par exemple une mesure de complexit leve.
Lidentification de dfauts difficilement dtectables par des tests dynamiques.
La dtection de dpendances et dinconsistances dans les modles logiciels tels que des liens
dans les modles logiciels
Lamlioration de la maintenabilit du code et de la conception.
La prvention des dfauts, si les leons sont prises en compte lors du dveloppement.
Les dfauts typiques dcouverts par des outils danalyse statique incluent :
Rfrencement dune variable avec une valeur indfinie;
Interface inconsistante entre modules et composants;
Variables qui ne sont jamais utilises ou dclares de faon incorrecte;
Code non accessible (code mort);
Logique absente et errone (potentiellement des boucles infinies) ;
Constructions trop compliques ;
Violation des standards de programmation;
Vulnrabilits de scurit;
Violation de syntaxe dans le code et les modles logiciels.
Les outils danalyse statique sont typiquement utiliss par des dveloppeurs (vrification par rapport
des rgles prdfinies ou des standards de programmation) avant et pendant les tests de
composants et les tests dintgration, ou pendant la mise jour du code dans les outils de gestion
de configuration, et par les concepteurs pendant la modlisation logicielle. Les outils danalyse
statique peuvent produire un nombre important de messages davertissement qui doivent tre grs
convenablement afin de permettre une utilisation optimale de loutil.
Les compilateurs peuvent offrir un certain support aux analyses statiques, notamment en incluant le
calcul de mtriques.
Rfrences
3.2 IEEE 1028
3.2.2 Gilb, 1993, van Veenendaal, 2004
3.2.4 Gilb, 1993, IEEE 1028
3.3 van Veenendaal, 2004
Version 2011
Page 36 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
4. Techniques de Conception de Tests

(K3)
International
Software Testing
255 minutes
Objectifs de connaissance pour Techniques de Conception de Tests

Les objectifs identifient les capacits que vous aurez la fin de chaque module.
4.1 Le processus de dveloppement de test (K3)

LO-4.1.1 Diffrencier la spcification de conception de test de la spcification des cas de test et
des spcifications de procdures de test. (K2)
LO-4.1.2 Comparer les termes : condition de test, cas de test et procdure de test. (K2)
LO-4.1.3 Evaluer la qualit des cas de test en terme de traabilit vers les exigences et les
rsultats attendus (K2)
LO-4.1.4 Traduire les cas de test en des spcifications de procdures de tests correctement
structures avec le niveau de dtail adquat par rapport au niveau de connaissance des testeurs.
(K3)
4.2 Catgories de techniques de conception de tests (K2)

LO-4.2.1 Rappeler les raisons pour lesquelles les approches bases sur les spcifications (botenoire) et celles bases sur les structures (bote blanche) sont utiles, et lister les techniques
habituelles pour chacune dentre elles. (K1)
LO-4.2.2 Expliquer les caractristiques, les points communs et diffrences entre les tests bass sur
les spcifications, les tests bass sur les structures et les tests bass sur lexprience. (K2)
4.3 Techniques bases sur les spcifications ou bote noire (K3)

LO-4.3.1 Ecrire les cas de test pour un modle logiciel donn en utilisant les partitions
dquivalence, lanalyse des valeurs limites, les tables de dcision et les diagrammes/tables de
transition dtats (K3)
LO-4.3.2 Expliquer les objectifs principaux de chacune des quatre techniques, quel niveau et type
de test peut utiliser la technique, et comment la couverture peut tre mesure. (K2)
LO-4.3.3 Expliquer les concepts des tests bass sur les cas dutilisation et ses avantages. (K2)
4.4 Techniques bases sur la structure ou bote blanche (K3)

LO-4.4.1 Dcrire le concept et limportance de la couverture du code. (K2)
LO-4.4.2 Expliquer les concepts de couverture des instructions et des dcisions, et donner les
raisons pour lesquelles ces concepts peuvent aussi tre utiliss pour dautres niveaux de tests que
les tests de composants (p.ex. sur les procdures mtier au niveau systme). (K2)
LO-4.4.3 Ecrire les cas de test partir des donnes du flux de contrle en utilisant les techniques
de conception de tests de couverture des instructions et couverture des dcisions. (K3)
LO-4.4.4 Evaluer la compltude des couvertures dinstructions et des dcisions en respectant les
critres de sortie dfinis. (K4)
4.5 Techniques bases sur lexprience (K2)

LO-4.5.1 Rappeler les raisons justifiant lcriture des cas de test bass sur lintuition, lexprience et
la connaissance des dfauts communs. (K1)
LO-4.5.2 Comparer les techniques bases sur lexprience avec les techniques bases sur les
spcifications. (K2)
4.6 Slectionner les techniques de test (K2)

LO-4.6.1 Classer les techniques de conception de tests en fonction de leur adaptation un
contexte donn, pour la base de tests, les caractristiques respectives aux modles et au logiciel.
(K2)
Version 2011
Page 37 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
4.1
Comit
Franais des
Tests
Logiciels
Le processus de dveloppement de test (K3)
International
Software Testing
15 minutes
Termes
Spcification de cas de test, conception de tests, ordonnancement de lexcution de tests,
spcification des procdures de test, script de test, traabilit.
Contexte
Le processus de dveloppement de test dcrit dans cette section peut tre effectu de diverses
manires, de trs informelles avec peu ou pas de documentation, trs formelles (comme
dcrit dans cette section). Le niveau de formalisme dpend du contexte des tests incluant la
maturit des tests et des processus de dveloppement, des contraintes de temps, des exigences
de suret de fonctionnement ou rglementaires et des personnes impliques.
Pendant lanalyse de conception des tests, la documentation de la base des tests est analyse de
faon dterminer ce qui est tester, cest dire identifier les conditions de test. Une condition
de test est dfinie comme un article ou vnement qui peut tre vrifi par un ou plusieurs cas de
test (p.ex. une fonction, transaction, caractristique qualit ou lment structurel).
Etablir la traabilit des conditions de tests vers les spcifications et exigences permet la fois
lanalyse dimpact, quand les exigences changent, et une couverture des exigences dfinir pour
un ensemble de tests. Pendant lanalyse de conception des tests, les approches dtailles de tests
sont implmentes pour slectionner des techniques de tests bases sur, entre autres
considrations, les risques identifis (voir Chapitre 5 pour plus dinformations sur les analyses de
risques).
Pendant la conception des tests, les cas de test et donnes de test sont crs et spcifis. Un cas
de test se compose d un ensemble de valeurs dentre, de pr-conditions dexcution, de rsultats
attendus et de post-conditions dexcution, conu pour couvrir certains objectifs de tests et
conditions de tests. Le Standard pour la Documentation de Tests Logiciel (Standard for Software
Test Documentation IEEE 829-1998) dcrit le contenu des spcifications de conception de tests
(contenant les conditions de test) et des spcifications des cas de test.
Les rsultats attendus devraient tre produits comme faisant partie des spcifications de cas de
test et inclure les sorties, modifications de donnes et dtats, et toute autre consquence du test.
Si des rsultats attendus nont pas t dfinis alors un rsultat plausible mais erron peut tre
interprt comme un rsultat correct. Les rsultats attendus devraient idalement tre dfinis avant
lexcution des tests.
Pendant limplmentation des tests, les cas de test sont dvelopps, implments, prioriss et
organiss dans la spcification de procdure de test (IEEE STD 829-1998). La procdure de tests
spcifie la squence des actions pour lexcution dun test. Si les tests sont excuts avec un outil
dexcution des tests, la squence dactions est spcifie dans un script de tests (qui est une
procdure de test automatise).
Les diverses procdures de tests et scripts de tests automatiss sont ensuite consolides en un
planning dexcution de tests qui dfinit lordre dans lequel les diverses procdures de test, et
potentiellement les scripts de tests automatiss, sont excuts. Les plannings dexcution des tests
prendront en compte les facteurs tels que les tests de rgression, de priorisation, et de
dpendances technique et logique.
Version 2011
Page 38 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
4.2
Catgories de techniques de conception de

tests (K2)
International
Software Testing
15 minutes
Termes
Technique de conception bote noire, technique de conception base sur lexprience, technique de
conception de test, technique bote blanche.
Contexte
Lobjectif de la technique de conception des tests est didentifier les conditions de tests, les cas de
test et les donnes de tests.
Il est frquent de faire la distinction entre les techniques de tests bote blanche et les techniques de
test bote noire. Les techniques de conception bote noire (aussi appeles techniques bases sur
les spcifications) sont une faon de driver et de slectionner les conditions de tests, les cas de
test ou les donnes de test en se basant sur une analyse de la documentation de la base des tests.
Ceci inclut les tests fonctionnels et non fonctionnels. Le test bote noire, par dfinition, nutilise
aucune information concernant la structure interne dun composant ou systme tester. Les
techniques de conception bote blanche (aussi dites techniques structurelles ou bases sur les
structures) sont bases sur une analyse de la structure du composant ou du systme. Les tests
bote noire et bote blanche peuvent aussi tre combins avec des techniques sinspirant de
lexprience des dveloppeurs, des testeurs et des utilisateurs pour dterminer ce qui doit tre
test.
Quelques techniques se retrouvent dans une seule catgorie, dautres comprennent des lments
de plus dune catgorie.
Ce syllabus rfrence comme techniques bote noire les approches bases sur les spcifications,
et rfrence comme techniques bote blanche les approches bases sur les structures. De plus, les
techniques de conception bases sur lexprience sont couvertes.
Caractristiques habituelles des techniques de conception bases sur les spcifications:
Les modles, soit formels soit informels, sont utiliss pour la spcification des problmes
rsoudre, des logiciels ou des composants.
Depuis ces modles les cas de test sont drivs de faon systmatique.
Caractristiques habituelles des techniques de conception bases sur la structure:
Linformation sur la manire dont le logiciel est construit est utilise pour driver les cas de
test (par exemple, le code et les informations de conception dtaille).
Le niveau de couverture du logiciel peut tre mesur partir de cas de test existants, et des
cas de test complmentaires peuvent tre drivs de faon systmatique pour augmenter la
couverture.
Caractristiques habituelles des techniques de conception bases sur lexprience:
La connaissance et lexprience des personnes sont utilises pour driver les cas de test.
La connaissance des testeurs, dveloppeurs, utilisateurs et autres parties prenantes
concernant le logiciel, son utilisation et son environnement sont autant de sources
dinformation;
La connaissance des dfauts possibles et de leur distribution est une autre source
dinformation.
Version 2011
Page 39 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
4.3
Techniques bases sur les spcifications ou

techniques bote noire (K3)
International
Software Testing
120 minutes
Termes
Analyse des valeurs limites, tests par tables de dcisions, partitions dquivalence, tests de
transition dtats, tests de cas dutilisation.
4.3.1
Partitions dquivalence (K3)
Pour les partitions dquivalence, les entres dun logiciel ou systme sont divises en groupes qui
doivent montrer un comportement similaire, de ce fait elles auront un traitement identique. Les
partitions (ou classes) dquivalence peuvent tre trouves pour des donnes valides, cest--dire
des donnes qui devraient tre acceptes et des donnes invalides, cest--dire des valeurs qui
devraient tre rejetes. Les partitions peuvent aussi tre identifies pour les sorties, les valeurs
internes, les valeurs lies au temps (p.ex. avant ou aprs un vnement) et pour les paramtres
dinterface (p.ex. composants intgrs en cours de test pendant les tests dintgration). Des tests
peuvent tre conus pour couvrir toutes les partitions valides et invalides. Les partitions
dquivalence sont applicables tous les niveaux de tests.
Les partitions dquivalence peuvent tre utilises pour atteindre des objectifs de couverture
dentres et de sorties. Elles peuvent tre appliques aux entres humaines, aux entres via
linterface du systme, ou aux paramtres dinterface des tests dintgration.
4.3.2
Analyse des valeurs limites (K3)
Le comportement au bord de chaque partition dquivalence risque plus dtre incorrect qu

lintrieur, donc les limites sont des zones plus propices pour dcouvrir des dfauts. Les valeurs
maximum et minimum dune partition sont ses valeurs limites. Une valeur limite pour une partition
valide est une valeur limite valide; la limite dune partition invalide est une valeur limite invalide. Des
tests peuvent tre conus pour couvrir les valeurs limites valides et invalides. Quand on conoit des
cas de test, une valeur de chaque limite est slectionne pour un test.
Lanalyse des valeurs limites peut tre applique tous les niveaux de tests. Cest relativement
ais appliquer et la capacit de dtection de dfauts est leve. Des spcifications dtailles sont
utiles pour dterminer les limites intressantes.
Cette technique est souvent considre comme une extension des partitions dquivalences ou
autre technique de conception bote noire. Elle peut tre utilise pour les classes dquivalence
aussi bien sur les donnes dentres humaines ou cran, par exemple, que sur des limites de
temps (par exemple, le time out, les exigences de rapidit de transactions) ou sur des limites de
tableaux (par exemple, une taille de tableau de 256*256).
4.3.3
Tests par tables de dcisions (K3)
Les tables de dcisions sont une bonne faon de capturer des exigences systme contenant des
conditions logiques, et pour documenter la conception systme interne. Elles peuvent tre utilises
pour enregistrer les rgles de gestion complexes que doit implmenter un systme. Lors de la
cration des tables de dcisions, la spcification est analyse, et les actions et conditions du
systme sont identifies. Les conditions dentre et les actions sont souvent dcrites de faon ce
quelles peuvent tre soit vraies soit fausses (Boolen). Les tables de dcision contiennent les
conditions de dclenchement, souvent des combinaisons de vrais et faux pour toutes les conditions
dentre, et sur les actions rsultantes pour chaque combinaison de conditions. Chaque colonne de
la table correspond une rgle de gestion qui dfinit une combinaison unique de conditions qui
rsultent en lexcution de laction associe cette rgle. La couverture standard gnralement
utilise avec les tables de dcisions est davoir au moins un test par colonne, ce qui implique
typiquement de couvrir toutes les combinaisons de conditions de dclenchement.
Version 2011
Page 40 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
La force des tests par les tables de dcisions est la cration de combinaisons de conditions qui
autrement nauraient pas t traites pendant les tests. Cela peut tre appliqu toutes les
situations quand laction du logiciel dpend de plusieurs dcisions logiques.
4.3.4
Test de transition dtats (K3)
Un systme peut montrer plusieurs rponses diffrentes en fonction des conditions actuelles ou
passes (son tat). Dans ce cas, cet aspect du systme peut tre montr par un diagramme dtats
et de transitions. Cela permet au testeur de visualiser le logiciel en termes dtats, de transitions
entre les tats, de donnes dentres ou des vnements qui dclenchent des changements dtat
(transitions) et des actions qui peuvent rsulter de ces transitions. Les tats du systme ou de
lobjet sous test sont spares, identifiables et en nombre fini.
Une table des tats montre la relation entre les tats et les entres, et peut mettre en lumire des
transitions possibles invalides.
Des tests peuvent tre conus pour couvrir une squence typique dtats, pour couvrir chaque tat,
pour excuter toutes les transitions, pour excuter une squence spcifique de transitions ou tester
des transitions invalides.
Les tests de transitions dtats sont frquemment utiliss dans lindustrie du logiciel embarqu et
gnralement dans lautomatisation technique. Cependant, la technique est aussi utilisable pour
modliser les objets mtier possdant des tats spcifiques ou pour tester les dialogues
dinterfaces cran (p.ex. pour les applications Internet ou les scnarios mtier).
4.3.5
Tests de cas dutilisation (K2)
Les tests peuvent tre spcifis partir de cas dutilisation. Un cas dutilisation dcrit linteraction
entre acteurs ( utilisateurs et systme), qui produit un rsultat ayant une valeur pour lutilisateur du
systme ou le client. Les cas dutilisation peuvent tre dcrits un niveau abstrait (cas dutilisation
mtier, indpendant de la technologie, niveau processus mtier). Chaque cas dutilisation a des
pr-conditions, qui doivent tre atteintes pour que ce cas dutilisation soit excut avec succs.
Chaque cas dutilisation se termine par des post-conditions, qui sont les rsultats observables et
ltat final du systme aprs la fin de lexcution du cas dutilisation. Un cas dutilisation a
gnralement un scnario dominant (cest dire le plus plausible), et parfois des scnarios
alternatifs.
Les cas dutilisation dcrivent les flux du processus dans un systme, bas sur une utilisation
probable, donc les cas de test drivs des cas dutilisation sont extrmement utiles pour dcouvrir
les dfauts dans le flux de traitement pendant lutilisation relle du systme. Les cas dutilisation,
souvent appels scnarios, sont trs utiles pour concevoir des tests dacceptation avec la
participation du client/utilisateur. Ils permettent aussi de dcouvrir des dfauts dintgration causs
par linteraction et les interfrences entre divers composants, ce que ne dcouvrent pas les tests
individuels de composants. La conception de cas de test partir des cas dutilisation peut tre
combine avec dautres techniques de tests bases sur les spcifications.
Version 2011
Page 41 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
4.4
Technique de conception base sur la structure

ou technique de conception bote blanche (K3)
International
Software Testing
60 minutes
Termes
Couverture de code, couverture des dcisions, couverture des instructions, tests structurels.
Contexte
Les tests bass sur la structure ou tests bote blanche suivent la structure identifie du logiciel ou
du systme, comme dcrit dans les exemples suivants:
Niveau composant: la structure dun composant logiciel cest dire instructions, dcisions,
branches ou mme des chemins distincts
Niveau intgration: la structure peut tre un arbre (ou graphe) dappel (un diagramme o des
modules appellent dautres modules).
Niveau systme: la structure peut tre une structure de menus, des processus mtier ou la
structure dune page web.
Dans cette section, trois techniques structurelles lies la couverture du code, portant sur les
instructions et les dcisions, sont discutes. Pour les tests des dcisions, un diagramme de
contrle de flux peut tre utilis pour visualiser les alternatives de chaque dcision.
4.4.1
Test des instructions et couverture (K3)
Dans les tests de composants, la couverture des instructions est lvaluation du pourcentage
dinstructions excutables qui ont t exerces par une suite de cas de test. Le test des instructions
drive des cas de test pour excuter des instructions spcifiques, gnralement pour accrotre la
couverture des instructions.
La couverture des instructions est dtermine par le nombre dinstructions excutables couvertes
par des cas de test (conus ou excuts) divis par le nombre de toutes les instructions
excutables dans le code test.
4.4.2
Test des dcisions et couverture (K3)
La couverture des dcisions, lies aux tests de branches, est lvaluation des pourcentages de
rsultats de dcisions (p.ex. les options Vrai et Faux dune instruction IF) qui ont t traites par
une suite de cas de test. Les cas de test provenant des tests de dcisions sont amens excuter
des rsultats de dcisions spcifiques. Les branches trouvent leur origine dans les points de
dcision du code et montrent le transfert du contrle vers diffrents endroits du code.
La couverture des dcisions est dtermine par le nombre de tous les rsultats des dcisions
couvertes par des cas de test (conus ou excuts) divis par le nombre de tous les rsultats
possibles des dcisions dans le code sous test.
Les tests de dcisions sont une forme de contrle de flux car ils gnrent un flux spcifique de
contrle entre des points de dcisions. La couverture des dcisions est suprieure la couverture
des instructions: une couverture de 100% des dcisions garantit une couverture 100% des
instructions, mais linverse nest pas vrai.
4.4.3
Autres techniques bases sur les structures (K1)
Il existe des niveaux de couverture structurelle plus forts que les couvertures de dcisions, par
exemple les couvertures de conditions et les couvertures de conditions multiples.
Version 2011
Page 42 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Le concept de couverture peut aussi tre appliqu aux autres niveaux de tests. Par exemple, au
niveau intgration, le pourcentage des modules, composants ou classes qui ont t exerces par
une suite de cas de test peut tre exprim comme une couverture de modules, composants ou
classes.
Laide via des outils est utile pour le test structurel de code.
Version 2011
Page 43 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
4.5
Comit
Franais des
Tests
Logiciels
Techniques bases sur lexprience (K2)
International
Software Testing
30 minutes
Termes
Tests exploratoires, (faute) attaque.
Contexte
Le test bas sur lexprience a lieu lorsque les tests sont conus partir des comptences des
testeurs, de leur intuition et de leur exprience avec des applications et technologies similaires.
Quand ils sont utiliss pour amliorer les techniques systmatiques, les tests intuitifs peuvent tre
utiles pour identifier des tests spciaux, difficilement atteints par des approches formelles.
Cependant, cette technique peut donner des degrs defficacit extrmement diffrents, selon
lexprience des testeurs.
Une technique base sur lexprience communment utilise est lestimation derreur.
Gnralement, les testeurs anticipent les dfauts bass sur lexprience. Une approche structure
pour la technique destimation derreurs est dnumrer une liste des dfauts possibles et de
concevoir des tests pour mettre en vidence ces dfauts. Cette approche systmatique est appele
attaque par faute . Ces listes de dfauts et de dfaillances peuvent tre construites sur la base
de lexprience, des donnes disponibles sur les dfauts et anomalies, et de la connaissance
commune sur les causes de dfaillances.
Les tests exploratoires comprennent la conception et lexcution des tests, lcriture des rsultats
de tests et lapprentissage (de lapplication), bass sur une charte de tests contenant les objectifs
de tests, et effectus dans des priodes de temps dlimites. Cest lapproche la plus utile pour
augmenter ou complter dautres mthodes de tests plus formelles lorsque les spcifications sont
rares ou non adquates, et que le test est soumis de svres contraintes de temps. Cela peut
servir comme vrification de processus de tests, pour sassurer que les dfauts les plus srieux
sont trouvs.
Version 2011
Page 44 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
4.6
Comit
Franais des
Tests
Logiciels
Slectionner les techniques de tests (K2)
International
Software Testing
15 minutes
Termes
Pas de terme spcifique.
Contexte
Le choix des techniques de tests utiliser dpend de diffrents facteurs incluant le type de
systme, les standards rglementaires, les exigences client ou contractuelles, le niveau de risque,
le type de risque, les objectifs de test, la documentation disponible, la connaissance des testeurs, le
temps disponible et le budget, le cycle de vie de dveloppement utilis, les modles de cas
dutilisation et lexprience sur les dfauts dcouverts prcdemment.
Quelques techniques sont plus applicables que dautres certaines situations et niveaux de tests,
dautres sont applicables tous les niveaux de tests.
Lors de la cration de cas de test, les testeurs utilisent gnralement une combinaison de
techniques de tests incluant les techniques orientes processus, rgles et donnes pour assurer
une couverture adquate de lobjet test.
Rfrences
4.1 Craig, 2002, Hetzel, 1998, IEEE 829
4.2 Beizer, 1990, Copeland, 2004
4.3.1 Copeland, 2004, Myers, 1979
4.3.2 Copeland, 2004, Myers, 1979
4.3.3 Beizer, 1990, Copeland, 2004
4.3.5 Copeland, 2004
4.5 Kaner, 2002
4.6 Beizer, 1990, Copeland, 2004
Version 2011
Page 45 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
5.
Comit
Franais des
Tests
Logiciels
Gestion des Tests (K3)
International
Software Testing
170 minutes
Objectifs de connaissance pour la gestion des tests

Les objectifs identifient les capacits que vous aurez la fin de chaque module
5.1 Organisation des tests (K2)

LO-5.1.1 Reconnatre limportance du test indpendant. (K1)
LO-5.1.2 numrer les avantages et inconvnients du test indpendant pour une organisation.
(K2)
LO-5.1.3 Reconnatre les diffrents membres dune quipe envisager lors de la formation dune
quipe de test. (K1)
LO-5.1.4 Rappeler les tches typiques dun responsable de test et dun testeur. (K1)
5.2 Estimation et planification du test (K3)

LO-5.2.1
LO-5.2.2
LO-5.2.3
LO-5.2.4
LO-5.2.5
LO-5.2.6
LO-5.2.7
LO-5.2.8
LO-5.2.9
Reconnatre les diffrents niveaux et objectifs de la planification du test. (K1)

Rsumer le but et le contenu des documents plan de test, conception de tests,
spcification de tests et procdure de test suivant le guide Standard for Software Test
Documentation (IEEE 829). (K2)
Faire la diffrence entre des approches de test conceptuellement diffrentes, telles que
des approches analytiques; bases sur des modles; mthodiques des fins de
compatibilit avec un processus ou un standard; dynamique/heuristique; consultative et
visant empcher la rgression. (K2)
Faire la diffrence entre la planification des tests pour un systme et lordonnancement
de lexcution des tests. (K2)
Ecrire un calendrier dexcution des tests pour une srie de cas de test donns en
tenant compte des priorits ainsi que des dpendances logiques et techniques (K3)
Lister les activits de prparation et dexcution des tests qui doivent tre prises en
compte lors de la planification des tests (K1)
Rappeler les facteurs typiques qui influencent leffort de test (K1)
Faire la diffrence entre deux approches destimation conceptuellement diffrentes :
lapproche base sur des mesures et lapproche base sur lexpertise. (K2)
Reconnatre et justifier les critres de dbut et de fin de test appropris des niveaux
de test spcifiques et des groupes de cas de test (par exemple, test dintgration, test
de recette ou cas de test pour un test dutilisabilit). (K2)
5.3 Suivre et contrler le droulement du test (K2)

LO-5.3.1
LO-5.3.2
LO-5.3.3
Rappeler les mesures habituelles utilises pour suivre la prparation et lexcution du

test (K1)
Comprendre et interprter les mesures de test pour la documentation et le contrle du
test (par exemple, les dfauts trouvs et corrigs, les tests russis et dfaillants) en
fonction du contexte (K2)
Rsumer le but et le contenu du rapport de synthse tabli selon le guide Standard
for Software Test Documentation (IEEE Std 829-1998) (K2)
5.4 Gestion de configuration (K2)

LO-5.4.1
Rsumer la manire dont la gestion de configuration assiste le test. (K2)
5.5 Test et risques (K2)

LO-5.5.1
LO-5.5.2
Dcrire un risque comme un problme probable qui peut compromettre latteinte des
objectifs de projet dun ou de plusieurs acteurs (K2)
Se rappeler que le niveau de risque est dtermin par sa probabilit (doccurrence) et
son impact (dommages en rsultant) (K1)
Version 2011
Page 46 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
LO-5.5.3
LO-5.5.4
LO-5.5.5
Comit
Franais des
Tests
Logiciels
International
Software Testing
Distinguer entre les risques lis au projet et ceux lis au produit (K2)
Reconnatre les risques typiques du produit et du projet (K1)
Dcrire, avec lappui dexemples, comment utiliser lanalyse et la gestion de risques
pour la planification du test (K2)
5.6 Gestion dincidents (K3)

LO-5.6.1
LO-5.6.2
Reconnatre le contenu du rapport dincident tabli selon le guide Standard for

Software Test Documentation (IEEE Std 829-1998) (K1)
Rdiger un rapport dincident couvrant lobservation dune dfaillance pendant le test.
(K3)
Version 2011
Page 47 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
5.1
Comit
Franais des
Tests
Logiciels
Organisation des tests (K2)
International
Software Testing
30 minutes
Termes
Testeur, responsable du test, gestionnaire du test.
5.1.1
Organisation du test et indpendance (K2)
Lefficacit de la dcouverte danomalies par le test et les revues peut tre amliore par lemploi
de testeurs indpendants. Les options pour lindpendance sont les suivantes :
o
o
o
o
o
o
Pas de testeurs indpendants, dveloppeurs testant leur propre code

Testeurs indpendants incorpors lquipe de dveloppement.
quipe ou groupe de test indpendant au sein de lorganisation, qui rfre au gestionnaire du
projet ou aux responsables dcisionnaires.
Testeurs indpendants de lorganisation, de la communaut des utilisateurs et de
lInformatique.
Spcialistes de test indpendants pour des objectifs spcifiques de test tels que des tests
dutilisabilit, de scurit informatique ou de certification (qui certifient un produit logiciel par
rapport des normes ou rglementations).
Testeurs indpendants externes lorganisation
Pour des projets de grande taille, complexes ou prsentant un niveau de scurit critique, il est
habituellement prfrable davoir plusieurs niveaux de tests, dont certains ou tous sont traits par
des testeurs indpendants. Lquipe de dveloppement peut prendre part aux tests, plus
spcialement aux plus bas niveaux, mais son manque dobjectivit limite son efficacit. Les testeurs
indpendants peuvent avoir lautorit pour exiger et dfinir des processus et rgles, mais les
testeurs ne devraient accepter ce rle touchant aux processus quen prsence dun mandat clair du
management.
Les avantages de lindpendance comprennent les suivants :
Des testeurs indpendants voient des dfauts diffrents et dune autre nature et sont
impartiaux.
Un testeur indpendant peut vrifier les hypothses faites pendant la spcification et
limplmentation du systme.
Les inconvnients comprennent les suivants :
Dconnexion vis--vis de lquipe de dveloppement (en cas de totale indpendance).

Les dveloppeurs perdent le sens de la responsabilit pour la qualit.
Des testeurs indpendants peuvent constituer un goulet dtranglement comme dernier point
de vrification et tre accuss des retards.
Les tches de test peuvent tre excutes par des personnes jouant un rle spcifique du test,
mais aussi par quelquun exerant un autre rle, comme le responsable de projet, le gestionnaire
de la qualit, un dveloppeur, un expert mtier ou domaine, infrastructure ou exploitation de
linformatique.
5.1.2
Tches du responsable des tests et des testeurs (K1)
Deux fonctions sont abordes dans ce syllabus, celles du responsable du test et du testeur. Les
activits et tches accomplies par des personnes dans ces deux rles dpendent du contexte du
produit et du projet, ainsi que des personnes jouant ces rles et de lorganisation.
Version 2011
Page 48 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Parfois, le responsable de test est appel gestionnaire de test ou coordinateur de test. Ce rle peut
tre rempli par un chef de projet, un responsable de dveloppement, un responsable de la qualit
ou un responsable dun groupe de test. Typiquement, le responsable de test planifie, surveille et
contrle les activits et tches de test dfinies dans la section 1.4.
Les tches habituelles du responsable de test peuvent comprendre les suivantes :
o
o
o
o
o
o
o
o
o
o
o
o
Coordonner la stratgie et le plan du test avec le chef de projet et dautres acteurs.

tablir ou rviser une stratgie de test pour le projet ainsi quune politique de test pour
lorganisation.
Apporter le point de vue du test aux autres activits du projet, comme la planification de
lintgration.
Planifier les tests en considrant le contexte et en comprenant les objectifs et les risques y
compris la slection des approches de test, lestimation du temps, de leffort et des cots du test,
lacquisition des ressources, la dfinition des niveaux de test, les cycles, lapproche et les objectifs
ainsi que la planification de la gestion dincidents;
Dmarrer la spcification, la prparation, limplmentation et lexcution des tests ainsi que
surveiller et contrler lexcution.
Adapter le planning en fonction des rsultats et de lavancement du test (parfois document
dans un rapport dtat davancement) et entreprendre les actions ncessaires pour rsoudre les
problmes
Mettre en place une gestion de configuration adquate du logiciel de test des fins de traabilit.
Introduire des mesures appropries pour mesurer lavancement du test et valuer la qualit du
test et du produit
Dcider ce qui devrait tre automatis, quel degr et comment.
Slectionner les outils pour aider le test et organiser la formation des testeurs lusage des outils.
Dcider de la mise en uvre de lenvironnement de test.
tablir des rapports de synthse de test partir des informations recueillies pendant le test.
Les tches habituelles des testeurs peuvent comprendre les suivantes :

o
o
o
o
o
o
o
o
o
o
Passer en revue les plans du test et y contribuer.

Analyser, passer en revue et valuer, quant leur testabilit, les exigences utilisateurs, les
spcifications et les modles.
Crer des spcifications de test.
Mettre en place lenvironnement de test (souvent en coordination avec ladministration systme et
la gestion de rseau).
Prparer et obtenir les donnes de test.
Implmenter des tests tous les niveaux, excuter et consigner les tests, valuer les rsultats et
documenter les carts vis--vis des rsultats attendus.
Employer les outils dadministration ou de gestion des tests et les outils de surveillance des tests
en fonction du besoin.
Automatiser les tests (ventuellement avec laide dun dveloppeur ou dun expert en
automatisation de test).
Mesurer les performances des composants et systmes (si pertinent).
Passer en revue les tests dvelopps par dautres.
Les personnes travaillant sur lanalyse, la conception des tests, sur des types de tests spcifiques
ou lautomatisation des tests peuvent tre des spcialistes de ces rles. Selon le niveau de test et
les risques du projet ainsi que ceux du produit, des personnes diffrentes peuvent jouer le rle de
testeur, en gardant un certain niveau dindpendance. Typiquement, les testeurs au niveau du test
de composants et dintgration seront des dveloppeurs, ceux du test dacceptation seront des
experts mtier et des utilisateurs et ceux pour lacceptation oprationnelle seront des oprateurs.
Version 2011
Page 49 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
5.2
Comit
Franais des
Tests
Logiciels
Estimation et planification des tests (K3)
International
Software Testing
40 minutes
Termes
Approche de test, stratgie de test
5.2.1
Planification des tests (K2)
Cette section couvre lobjectif de la planification du test dans des projets de dveloppement et
dimplmentation ainsi que pour des activits de maintenance. La planification peut tre
documente dans un plan de projet ou un plan de test matre ainsi que dans des plans de test
spars pour les niveaux de test, tels que le test systme ou le test dacceptation. Le schma des
documents de planification de test est dfini dans le guide Standard for Software Test
Documentation (IEEE Std 829-1998).
La planification est influence par la politique de test de lorganisation, la porte du test, les
objectifs, les risques, les contraintes, la criticit, la testabilit et la disponibilit des ressources. Au
fur et mesure de lavancement du projet et de la planification des tests, davantage dinformations
seront disponibles et davantage de dtails pourront tre inclus dans le plan.
La planification du test est une activit continue et est effectue tout au long des processus et
activits du cycle de dveloppement. Le retour issu des activits de test est employ pour constater
lvolution des risques et modifier alors la planification.
5.2.2
Activits de planification des tests (K3)
Les activits de la planification des tests pour un systme ou pour une partie de celui-ci peuvent
tre:
o
o
o
o
o
o
o
o
o
o
Dfinir le primtre du test, les risques et identifier les objectifs du test

Dfinir lapproche gnrale du test (stratgie de test), y compris la dfinition des niveaux de test
ainsi que celle des critres dentre et de sortie.
Intgrer et coordonner des activits de test dans les activits du cycle de dveloppement :
acquisition, fourniture, dveloppement, exploitation et maintenance.
Prendre des dcisions quant ce qui doit tre test, quels rles vont exercer quelles activits,
quand et comment ces activits doivent tre exerces, comment valuer les rsultats des tests et
quand arrter les tests (critres de sortie).
Planifier les activits danalyse et de conception des tests
Planifier les activits de conception, dexcution et dvaluation des tests
Assigner les ressources aux diffrentes tches dfinies.
Dfinir le volume, le niveau de dtail, la structure et les modles pour la documentation du test.
Slectionner des mesures pour suivre et contrler la prparation et lexcution des tests,
llimination des dfauts et la rsolution des problmes relatifs aux risques.
Dterminer le niveau de dtail pour les procdures de test de faon fournir suffisamment de
dtails pour permettre une prparation et une excution reproductibles des tests.
5.2.3
Critres dentre (K2)
Les critres dentre dfinissent quand dmarrent les tests (par exemple quand dbute un niveau
de test, quand un jeu de test est prt tre excut)
Typiquement, les critres dentre peuvent couvrir:
o Disponibilit et prparation de lenvironnement de test
o Prparation des outils de tests dans lenvironnement de test
o Disponibilit de code testable
o Disponibilit des jeux de donnes
Version 2011
Page 50 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
5.2.4
Comit
Franais des
Tests
Logiciels
International
Software Testing
Critres de sortie (K2)
Lobjectif des critres de sortie est de dfinir quand arrter le test, par exemple, la fin dun niveau
de test ou lorsquune srie de tests a atteint un objectif donn.
Typiquement, les critres de sortie peuvent comprendre les suivants :
o
o
o
o
o
Des mesures dexhaustivit, comme la couverture de code, de fonctionnalits ou de risques.

Lestimation de la densit des anomalies ou des mesures de fiabilit.
Le cot.
Les risques rsiduels, comme les anomalies non corriges ou le manque de couverture du test
dans certaines parties.
Un calendrier, par exemple, bas sur la date de mise sur le march.
5.2.5
Estimation des tests (K2)
Deux approches pour lestimation de leffort de test sont couvertes par le prsent syllabus :
o Estimation de leffort de test base sur des mesures issues de projets antrieurs ou similaires ou
base sur des valeurs typiques.
o Lapproche experte : estimation des tches par le dtenteur de ces tches ou par des experts.
Une fois que leffort de test a t estim, il est possible didentifier les ressources ncessaires et
dtablir un chancier.
Leffort de test peut dpendre dun certain nombre de facteurs, dont les suivants :
o
o
o
Les caractristiques du produit : la qualit des exigences et autres informations utilises pour les
modles de test (cest--dire la base de test), la taille du produit, la complexit du domaine, les
exigences de fiabilit et de scurit ainsi que celles de la documentation.
Les caractristiques du processus de dveloppement : la stabilit de lorganisation, les outils
employs, le processus de test, le savoir-faire des personnes impliques et les contraintes de
temps.
Les rsultats du tests : le nombre de dfauts et le volume des reprises exiges.
5.2.6
Stratgie de test, Approche de test (K2)
Lapproche de test est la mise en uvre dune stratgie de test pour un projet spcifique. Elle est
dfinie et affine dans les plans et scnarii de test. Elle comprend typiquement les dcisions
bases sur le projet (de test), ses buts ainsi quune analyse des risques. Elle constitue le point de
dpart pour la planification du processus de test, pour slectionner les types et techniques de test
qui seront appliqus ainsi que pour dfinir les critres dentre et de sortie.
Lapproche slectionne dpend du contexte et peut prendre en considration les risques, la
scurit et les dangers, les ressources disponibles et leur niveau dexpertise, la technologie et la
nature du systme (par exemple spcifique ou gnrique (COTS)), les objectifs, les normes et
rglements en vigueur.
Les approches typiques peuvent comprendre:
o
o
o
Une approche analytique, comme le test bas sur les risques o le test est focalis sur les parties
plus haut risque.
Les approches bases sur les modles, comme le test stochastique qui utilise des informations
statistiques sur les taux derreurs (comme les modles de croissance de fiabilit) ou sur
lutilisation (comme les profils oprationnels).
Les approches mthodiques, comme le test bas sur les erreurs (y compris lestimation derreurs
et lattaque par faute), bases sur des listes de vrification et sur des caractristiques de la
qualit.
Version 2011
Page 51 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
o
o
o
o
Comit
Franais des
Tests
Logiciels
International
Software Testing
Des approches bases sur la conformit aux processus et normes, tels que ceux spcifis par
des normes industrielles spcifiques ou les diverses mthodes agiles.
Les approches dynamiques et heuristiques, comme le test exploratoire o le test est plutt ractif
aux vnements que planifi, et o lexcution et lvaluation sont des tches parallles.
Les approches consultatives, comme celles o la couverture de test est principalement dfinie par
les avis et le guidage dexperts mtier ou en technologie trangers lquipe de test.
Les approches bases rgression, comme celles qui comportent le remploi de matriel de test
existant, une automatisation extensive du test de rgression fonctionnel et des suites de tests
standard.
Diffrentes approches peuvent tre combines, par exemple, une approche dynamique base sur
les risques.
Version 2011
Page 52 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
5.3
Comit
Franais des
Tests
Logiciels
Suivi et contrle du droulement des tests
International
Software Testing
20 minutes
(K2)
Termes
Densit de dfauts, taux de dfaillance, contrle des tests, suivi des tests, rapport de test
5.3.1
Suivi de lavancement des tests (K1)
Lobjectif du suivi du test est de fournir un retour et une visibilit sur les activits de test. Les
informations suivre peuvent tre recueillies manuellement ou automatiquement et peuvent tre
utilises pour valuer les critres de sortie, comme la couverture. Des mesures peuvent aussi tre
utilises pour valuer lavancement par rapport au calendrier et au budget planifis. Les mesures
de test habituelles sont:
o
o
o
o
o
o
o
o
Le pourcentage du travail consacr la prparation des cas de test (ou pourcentage des cas
de test planifis et prpars).
Pourcentage du travail consacr la prparation de lenvironnement de test.
Lexcution de cas de test (par exemple, nombre de cas de test excuts ou non et nombre de
cas de test russis ou chous).
Les informations sur les dfauts (par exemple, densit des dfauts, dfauts trouvs et corrigs,
taux des dfaillances et rsultats du re-test).
Couverture par le test des exigences, des risques ou du code.
Confiance subjective des testeurs dans le produit.
Dates des jalons du test.
Cot du test, y compris le cot de lavantage de trouver le prochain dfaut compar celui de
lexcution du test suivant.
5.3.2
Reporting des tests (K2)
Le reporting des tests consiste rsumer les informations relatives lentreprise du test ; il
comprend les activits suivantes :
o
o
Ce qui sest pass pendant une phase de test, comme les dates o les critres de sortie ont t
atteints.
Les informations et mesures analyses pour tayer les recommandations et dcisions pour de
futures actions, comme une valuation des dfauts restants, les avantages conomiques de
tests prolongs, les risques non couverts et le niveau de confiance dans le logiciel test.
Le descriptif dun rapport de synthse de test se trouve dans le guide Standard for Software Test
Des mesures devraient tre recueillies pendant et la fin dun niveau de test dans le but dvaluer :
o
o
o
Ladquation des objectifs du test avec ce niveau de test.

Ladquation des approches du test empruntes.
Lefficacit du test par rapport ses objectifs.
5.3.3
Contrle des tests (K2)
Le contrle du test dcrit les actions dorientation et de correction entreprises comme rsultat des
informations et mesures recueillies et consignes. Ces actions peuvent couvrir toute activit de test
et influencer toute autre activit ou tche du cycle de vie logiciel.
Exemples dactions de contrle des tests :
o Prendre des dcisions sur la base des informations recueillies lors du suivi des tests
Version 2011
Page 53 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
o
o
o
Comit
Franais des
Tests
Logiciels
International
Software Testing
Une nouvelle affectation de priorits aux tests en cas de mise en vidence dun risque identifi
(par exemple, retard de livraison du logiciel).
Une modification du calendrier de test en raison de la disponibilit dun environnement de test.
Dfinition dun critre dentre exigeant que des corrections soient testes par le dveloppeur
avant de les accepter dans une version.
Version 2011
Page 54 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
5.4
Comit
Franais des
Tests
Logiciels
Gestion de configuration (K2)
International
Software Testing
10 minutes
Termes
Gestion de configuration, contrle de versions
Contexte
Lobjectif de la gestion de configuration est dtablir et de maintenir lintgrit des produits
(composants, donnes et documentation) du logiciel ou du systme durant le cycle de vie du projet
et du produit.
Pour le test, la gestion de configuration peut permettre dassurer que :
o
Tous les lments faisant partie du testware sont identifis, sous contrle de versions, que les
changements sont identifis et re-traables, relis les uns aux autres et aux lments de
dveloppement (objets de test), de sorte que la traabilit peut tre maintenue pendant tout le
processus du test.
Tous les documents identifis et les lments du logiciel sont rfrencs de manire non
ambigu dans la documentation de test.
La gestion de configuration aide le testeur identifier de manire unique (et reproduire) llment
test, les documents de test, les tests et le harnais de test.
Pendant la planification du test, les procdures et linfrastructure (outils) de la gestion de
configuration devraient tre choisis, documents et implments.
Version 2011
Page 55 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
5.5
Comit
Franais des
Tests
Logiciels
International
Software Testing
Test et risques (K2)
30 minutes
Termes
Risques lis au produit, risques lis au projet, risques, test bas sur les risques
Contexte
Un risque peut tre dfini comme la probabilit quun vnement, un danger, une menace ou une
situation arrive, et que les consquences indsirables qui en dcoulent constituent un problme
potentiel. Le niveau de risque sera dtermin par la probabilit quun vnement adverse arrive et
par limpact de ce dernier (les dommages rsultant de cet vnement).
5.5.1
Risques lis au projet (K2)
Les risques lis au projet sont les risques menaant la capacit de ce dernier atteindre ses
objectifs, tels que :
o
Facteurs organisationnels :
Manque de comptence et de formation du personnel ;
Problmes de personnel;
Problmes politiques, tels que
problmes dus au fait que des testeurs ne communiquent pas leurs besoins et
les rsultats du test ;
incapacit suivre les informations recueillies pendant le test et les revues (par
exemple, ne pas amliorer les pratiques de dveloppement et de test).
Attitude ou attentes inappropries vis--vis du test (par exemple, ne pas apprcier la valeur de
la dcouverte de dfauts durant le test).
Problmes techniques :
Problmes pour dfinir des exigences correctes ;
La mesure selon laquelle les exigences seront satisfaites en fonction de contraintes
existantes ;
Environnement de test indisponible
Conversion des donnes tardive ; planning de migration et de dveloppement ; conversion
des donnes de test / outils de migration
Qualit de la conception, du code et des tests
Problmes dacquisition :
Dfaillance dune tierce partie ;
Problmes contractuels.
Pour analyser, grer et diminuer ces risques, le gestionnaire de test suivra les principes bien tablis
de la gestion de projet. Le guide Standard for Software Test Documentation (IEEE Std 8291998) pour le plan de test exige que les risques et contingences soient documents..
5.5.2
Risques lis au produit (K2)
Les dfaillances potentielles (vnements futurs indsirables ou dangers) des parties du logiciel ou
du systme sont dfinies comme des risques lis au produit, puisquelles reprsentent un risque
pour la qualit du produit, comme :
o
o
o
o
Livraison dun logiciel dfectueux.

Possibilit quun logiciel ou systme entrane des dommages des personnes ou des
entreprises.
Caractristiques logicielles de moindre qualit (par exemple, fonctionnalit, scurit, fiabilit,
utilisabilt et performances).
Intgrit et qualit des donnes de faible qualit (par exemple en raison de problmes lis
leur migration, leur conversion, leur transport, un non respect des standards)
Version 2011
Page 56 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Logiciel noffrant pas les fonctionnalits voulues.
Les risques sont employs pour dcider quand commencer tester et o tester davantage ; le test
est utilis pour rduire le risque quun vnement indsirable ne survienne ou pour rduire limpact
de ce dernier.
Les risques relatifs au produit sont un type particulier de risque pour le succs dun projet. Le test,
comme activit de contrle des risques fournit un retour quant aux risques restants par la mesure
de lefficacit de llimination des dfauts critiques et des plans de contingence.
Une approche des tests base sur les risques fournit des possibilits proactives de rduire le
niveau des risques relatifs au produit, en partant des premires tapes dun projet. Elle comprend
lidentification des risques lis au produit et de leur emploi comme guide pour la planification du
test, la spcification, la prparation et lexcution des tests. Dans une approche base sur les
risques, les risques identifis peuvent tre utiliss pour :
o
o
o
o
dterminer les techniques de test employer,

dterminer le volume du test effectuer.
dfinir les priorits affecter aux tests dans le but de trouver les dfauts critiques le plus tt
possible.
dterminer si des activits ne faisant pas partie du test pourraient aider rduire les risques
(par exemple, une formation fournie aux dveloppeurs inexpriments).
Le test bas sur les risques repose sur les connaissances et la comprhension collectives des
acteurs dun projet pour dterminer les risques et les niveaux de test ncessaires pour couvrir ces
derniers.
Pour sassurer que la probabilit de dfaillance dun produit est minimise, les activits de gestion
des risques fournissent une approche discipline pour :
o
o
o
estimer (et re-estimer rgulirement) ce qui peut faillir (les risques),

dterminer quels sont les risques importants couvrir,
entreprendre des actions pour couvrir ces risques.
De plus, le test peut aider identifier de nouveaux risques, dterminer quels risques doivent tre
minimiss et rduire lincertitude relative aux risques.
Version 2011
Page 57 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
5.6
Comit
Franais des
Tests
Logiciels
Gestion des incidents (K3)
International
Software Testing
40 minutes
Termes
Consignation dincidents, gestion des incidents, rapport dincidents
Contexte
Comme lun des objectifs du test est de dcouvrir des dfauts, les diffrences entre les rsultats
attendus et les rsultats effectifs doivent tre consignes en tant quincidents. Un incident doit tre
analys et peut par la suite devenir un dfaut. Des actions adquates doivent tre dfinies afin de
traiter les incidents et les dfauts. Les incidents et les dfauts doivent tre suivis depuis leur
dcouverte et classification jusqu leur correction et la confirmation de leur rsolution. Pour pouvoir
grer tous les incidents jusqu la fin dun projet, une organisation devrait tablir un processus de
gestion des incidents et des rgles pour leur classification.
Les incidents peuvent survenir pendant le dveloppement, les revues, le test ou lutilisation dun
produit logiciel. Ils peuvent survenir en raison de problmes dans le code, dans le systme
oprationnel ou dans tout type de documentation, notamment les documents de dveloppement,
les documents de test ou les informations destines lutilisateur tels que le manuel dutilisation ou
le manuel dinstallation.
Les rapports dincidents peuvent avoir les objectifs suivants :
o Fournir aux dveloppeurs et aux autres parties un retour sur le problme concern pour en
permettre lidentification, la localisation et la correction ncessaires.
o Fournir aux responsables du test le moyen de suivre la qualit dun systme sous test et
lavancement du test.
o Fournir des ides pour lamlioration du processus de test.
Les dtails du rapport dincident peuvent inclure:
o Date de lincident, organisation faisant part de lincident, auteur
o Rsultats attendus et effectifs.
o Identification ou lment de configuration du logiciel ou systme.
o Processus du cycle de vie du logiciel ou du systme au cours duquel lincident a t observ
o Description de lanomalie pour permettre son limination, y compris les traces, extraits de la
base de donnes ou captures dcrans
o Degr de limpact sur les intrts des dtenteurs denjeux.
o Svrit de limpact sur le systme.
o Urgence ou priorit de la correction.
o Etat de lincident (par exemple, ouvert, soumis, doublon, en attente de correction, corrig en
attente de test de confirmation, cltur).
o Conclusions et recommandations.
o Problmes globaux, comme dautres parties pouvant tre impactes par une modification
rsultant de lincident.
o Historique des modifications, telles que la squence des actions entreprises par des membres de
lquipe du projet afin de localiser lincident, de corriger et den confirmer la correction.
o Rfrences, incluant lidentit du cas de test ou la spcification qui a permis didentifier le
problme
La structure dun rapport dincident est couverte par le guide Standard for Software Test
References
5.1.1 Black, 2001, Hetzel, 1988
5.1.2 Black, 2001, Hetzel, 1988
5.2.5 Black, 2001, Craig, 2002, IEEE Std 829-1998, Kaner 2002
Version 2011
Page 58 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
5.3.3 Black, 2001, Craig, 2002, Hetzel, 1988, IEEE Std 829-1998
5.4 Craig, 2002
5.5.2 Black, 2001 , IEEE Std 829-1998
5.6 Black, 2001, IEEE Std 829-1998
Version 2011
Page 59 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
6.
Comit
Franais des
Tests
Logiciels
Outils de Support aux Tests (K2)
International
Software Testing
80 minutes
Objectifs de connaissance pour les outils de support aux tests

Les objectifs identifient ce que vous aurez la fin de chacun des modules.
6.1 Les types d'outils de tests (K2)

LO-6.1.1
LO-6.1.3
Classer les diffrents types doutils de test selon leur sujet et les activits du processus
de tests et le cycle de vie logiciel. (K2)
Reconnatre les outils qui peuvent aider les dveloppeurs dans leurs tests. (K2)
6.2 Utilisation pertinente des outils : Avantages et risques potentiels (K2)

LO-6.2.1
LO-6.2.2
Rsumer les bnfices et risques potentiels dautomatisation et dutilisation doutils

pour les tests. (K2)
Reconnatre les considrations spcifiques pour les outils dexcution des tests,
lanalyse statique, et les outils de gestion de tests. (K1)
6.3 Introduire un outil dans une organisation (K1)

LO-6.3.1
LO-6.3.2
LO-6.3.3
Exposer les principes majeurs lis lintroduction dun outil dans une organisation. (K1)
Exposer les objectifs dune preuve de concept pour lvaluation dun outil et une phase
de pilotage pour limplmentation dun outil. (K1)
Reconnatre que des facteurs autres que lacquisition dun outil sont ncessaires pour
un bon support des tests par les outils. (K1)
Version 2011
Page 60 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
6.1 Types d'outils de test (K2)
International
Software Testing
45 minutes
Termes
Outils de gestion de configuration, outils de mesure de couverture, outils de dbogage, outils
danalyse dynamique, outils de gestion dincidents, outils de tests de charge, outils de modlisation,
outils de monitoring, outils de tests de performances, effet de sonde, outils de gestion dexigences,
outils de support de revues, outils de scurit, outils danalyse statique, outils de test de stress,
comparateur de tests, outils de prparation de donnes de tests, outils de conception de tests,
harnais de tests, outils dexcution des tests, outils de gestion des tests, outils de tests unitaires et
structurels.
6.1.1 Outils de support aux tests (K2)

Des outils de test peuvent tre utiliss pour une ou plusieurs activits que supporte le test. Ceux-ci
incluent :
1. Outils qui sont directement utiliss dans le test tel que les outils d'excution de test, outils
de gnration de donnes de test et outils de comparaison de rsultats.
2. Outils qui aident en contrlant le processus de test comme ceux employs pour grer les
tests, des rsultats de test, des donnes, des conditions, des incidents, des dfauts, etc., et
pour reporter et contrler l'excution des tests
3. Outils qui sont utiliss dans la reconnaissance, ou, en termes simples : exploration (par
exemple, outils qui contrle l'activit d'un fichier pour une application)
4. N'importe quel outil qui facilite le test (un tableur est galement un outil de test dans cette
signification)
Loutil de support au test peut avoir un ou plusieurs des buts suivants selon le contexte :
Amliorer l'efficacit des activits de test en automatisant des tches rptitives ou en
supportant des activits de test manuelles comme la planification des tests, la conception
de tests, le compte-rendu et le contrle des tests
Automatiser les activits qui exigent les ressources importantes une fois faites
manuellement (par exemple, tests statiques)
Automatiser les activits qui ne peuvent pas tre excutes manuellement (par exemple,
test de performance exhaustif des applications client-serveur)
Augmenter la fiabilit du test (par exemple, en automatisant la comparaison de beaucoup
de donnes ou en simulant le comportement)
Le terme "framework de test" est galement frquemment utilis dans l'industrie, avec au moins
trois significations :
Bibliothques rutilisables et extensibles de test qui peuvent tre employes pour
construire des outils de test (appeles aussi harnais de tests)
Un type de conception d'automatisation des tests (par exemple, pilots par les donnes,
pilot par mots-cls)
Processus globaux d'excution de test
Dans ce syllabus, le terme "framework de test" est utilis dans ses deux premires significations
comme dcrit dans la section 1.1.6.
6.1.2 Classification des outils de test (K2)

Il y a un certain nombre d'outils qui supportent les diffrents aspects du test. Des outils peuvent tre
classs selon plusieurs critres tels que le but, commercial/ libre / logiciel libre / shareware,
technologie utilise et ainsi de suite. Dans le prsent syllabus, ces outils sont classs selon les
activits du test quils assistent.
Version 2011
Page 61 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Certains outils supportent clairement une seule activit; dautres supportent plus dune activit,
mais sont classs dans la rubrique relative lactivit laquelle ils sont plus troitement associs.
Des outils d'un fournisseur unique, particulirement ceux qui ont t conus pour fonctionner
ensemble, peuvent tre empaquets dans un module.
Quelques types doutil de test peuvent tre intrusifs, ce qui signifie qu'ils peuvent affecter le rsultat
obtenu par le test. . Par exemple, une mesure de temps peut varier cause des instructions
supplmentaires excutes par loutil., ou vous pouvez obtenir une mesure de couverture de code
diffrente. La consquence des outils intrusifs s'appelle l'effet de sonde.
Quelques outils offrent une assistance davantage tourne vers les dveloppeurs (cd. pendant les
tests de composants et dintgration des composants). Ces outils sont nots avec un (D) dans les
classifications ci-dessous.
6.1.3 Outils daide la gestion du test et des tests (K1)

Les outils de gestion sappliquent toutes les activits de tests pendant toute la dure du cycle de
vie du logiciel.
Outils de gestion des tests

Ces outils fournissent des interfaces pour excuter des tests, dpister des dfauts et grer les
exigences, avec une aide pour l'analyse quantitative et le rapport des objets de tests. Ils supportent
galement la traabilit des objets de tests vers les spcifications des exigences. Ils peuvent
possder des fonctionnalits de gestion de version indpendantes ou sinterfacer avec un outil de
gestion de version externe.
Outils de gestion des exigences
Ces outils enregistrent les noncs des exigences, enregistrent les attributs des exigences (priorit
y compris), fournissent des identifiants uniques et supportent la traabilit des exigences vers les
tests individuels. Ces outils peuvent galement aider identifier des exigences contradictoires ou
manquantes.
Outils de gestion d'incidents (outils de suivi de dfauts)
Ces outils enregistrent et grent les rapports d'incidents, c.--d. les dfauts, les dfaillances, les
demandes de modification ou les problmes et anomalies rencontrs. Ils aident grer le cycle de
vie des incidents, ventuellement avec le support de l'analyse statistique.
Outils de gestion de configuration

Bien que pas strictement des outils de test, ceux-ci sont ncessaires pour le stockage et la gestion
de version du testware et du logiciel associ particulirement lorsque sont configurs plusieurs
environnements matriel/logiciel en termes de versions du systme d'exploitation, compilateurs,
navigateurs web, etc.
6.1.4 Outils daide aux tests statiques (K1)

Les outils de test statique fournissent une manire rentable de trouver plus de dfauts une tape
amont dans le processus de dveloppement.
Outils de revue
Ces outils aident aux revues des processus, des check-lists, des directives de revue et sont utiliss
pour enregistrer et communiquer les commentaires des revues, et les rapports sur les dfauts et les
essais. Ils peuvent tre dune aide supplmentaire en fournissant l'assistance pour des revues en
ligne pour des quipes de taille importante ou gographiquement disperses.
Outils d'analyse statique (D)
Version 2011
Page 62 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Ces outils aident les dveloppeurs et les testeurs trouver des dfauts avant le test dynamique en
fournissant une aide pour introduire des normes de codage (codage scuris y compris), l'analyse
des structures et des dpendances. Ils peuvent galement aider dans la planification ou lanalyse
de risque en fournissant des mtriques pour le code (par exemple, complexit).
Outils de modlisation (D)
Ces outils sont employs pour valider les modles de logiciel (par exemple, modle de donnes
physiques (MDP) pour une base de donnes relationnelle), en numrant des incohrences et en
trouvant des dfauts. Ces outils peuvent souvent aider en produisant quelques cas de test bass
sur le modle.
6.1.5 Outils daide la spcification des tests (K1)

Outils de conception de tests
Ces outils sont utiliss pour gnrer des entres de tests ou des tests excutables et/ou des
oracles de tests partir des exigences, des interfaces utilisateur graphiques, des modles de
conception (tat, donnes ou objet) ou partir du code.
Outils de prparations de donnes de tests
Les outils de prparation des donnes agissent sur des bases de donnes, fichiers ou transferts de
donnes afin dlaborer des donnes de tests utilisables lors de lexcution des tests, ceci en
assurant la scurit des donnes grce leur anonymisation.
6.1.6 Outils daide l'excution et lenregistrement des tests (K1)

Outils dexcution des tests
Ces outils permettent des tests d'tre excuts automatiquement, ou semi-automatiquement,
utilisant les entres enregistres et les rsultats prvus, par l'utilisation dun langage de script et
fournissent habituellement un registre de test pour chaque excution de test. Ils peuvent
galement tre employs pour enregistrer des tests, et disposent habituellement dun langage de
script ou une configuration via une interface graphique utilisateur pour le paramtrage des donnes
et toute autre personnalisation dans les tests.
Harnais de tests/Outils framework de tests unitaires (D)
Un harnais ou framework de tests unitaires facilite le test des composants ou des parties d'un
systme en simulant l'environnement dans lequel cet objet de tests s'excutera, par la fourniture
d'objets factices comme des bouchons ou des pilotes.
Comparateurs de tests
Les comparateurs de tests dterminent des diffrences entre les fichiers, bases de donnes ou
rsultats de tests. Les outils d'excution des tests incluent en gnral des comparateurs
dynamiques, mais les comparaisons post-excution peuvent tre faites par un outil de comparaison
distinct. Un comparateur de tests peut utiliser un oracle de tests, en particulier s'il est automatis.
Outils de mesure de couverture (D)
Ces outils, par des moyens intrusifs ou non intrusifs, mesurent le pourcentage de certains types de
structures de code qui ont t exercs (par exemple, des dclarations, des branches ou des
dcisions, et appels de module ou fonction) par un ensemble de tests.
Outils de test de scurit
Ces outils sont utiliss pour valuer les caractristiques de scurit du logiciel. Ceci inclut
lvaluation de la capacit du logiciel protger la confidentialit, l'intgrit, l'authentification,
l'autorisation, la disponibilit, et la non-rpudiation des donnes. Les outils de scurit sont en
grande partie concentrs sur une technologie, une plate-forme, et un but particulier.
Version 2011
Page 63 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
6.1.7 Outils de support de performance et de surveillance (K1)

Outils d'analyse dynamique (D)
Les outils danalyse dynamique dtectent des dfauts qui ne se manifestent que lors de lexcution
du logiciel, telles que les dpendances temporelles ou les fuites de mmoire. Ils sont typiquement
utiliss dans des tests de composants et dintgration de composants, et dans les tests de
middleware.
Outils de test de performance/test de charge/test de stress
Les outils de test de performance surveillent et rapportent sur la faon dont se comporte un
systme selon une grande varit de conditions dusage simules en termes de nombre
d'utilisateurs simulans, de leur modle de monte en charge, de frquence et de pourcentage
relatif de transactions. La simulation de la charge est ralise au moyen de la cration
d'utilisateurs virtuels effectuant un ensemble choisi de transactions diffuses travers divers
machines de test identifis comme injecteurs de charge.
Outils de surveillance
Les outils de surveillance analysent continuellement, vrifient et rendent compte de l'utilisation de
ressources systmes spcifiques, et donnent des alertes sur de possibles problmes de service.
6.1.8 Outils de support pour des besoins de tests spcifiques (K1)

Evaluation de la qualit des donnes
Les donnes sont au centre de certains projets tels que des projets de conversion/migration des
donnes et des applications comme le stockage de donnes. Leurs caractristiques peuvent varier
en termes de criticit et volume. Dans de tels contextes, des outils dvaluation de la qualit des
donnes doivent tre utiliss pour revoir et vrifier les rgles de conversion et de migration des
donnes, pour s'assurer que les donnes traites sont correctes, compltes et se conforment une
norme prdfinie spcifique au contexte.
D'autres outils de test existent pour le test d'utilisabilit.
Version 2011
Page 64 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
6.2 Utilisation efficace des outils : Bnfices
International
Software Testing
20 minutes
potentiels et Risques (K2)

Termes
Tests pilots par les donnes, tests pilots par mots cl, langage de script
6.2.1 Bnfices potentiels et risques lis aux outils de test (pour tous
les outils) (K2)
Le simple achat, ou la location dun outil ne garantit par le succs. Chaque type doutil ncessite
des efforts supplmentaires pour atteindre des bnfices rels et durables. Sil existe des
opportunits potentielles de bnfices utiliser des outils dans le test, il existe aussi des risques.
Bnfices potentiels lutilisation doutils :
Rduction du travail rptitif (p.ex. excution de tests de rgression, rintroduction des
mmes donnes de tests, et vrification du respect de standards de codage).
Rptabilit et cohrence accrues (p.ex. tests excuts par un outil suivant un ordre et une
frquence prcis et tests dduits des exigences).
Evaluation objective (p.ex. mesure statiques, couverture).
Facilit daccs aux informations concernant les tests ou leur excution (p.ex. statistiques
et graphiques sur lavancement des tests, le taux dincidents et les performances).
Risques lis lutilisation doutils :
Attentes irralistes places dans loutil (dont la facilit dutilisation et la fonctionnalit).
Sous-estimation du temps, du cot et de leffort pour lintroduction initiale dun outil (dont la
formation et lexpertise externe).
Sous-estimation du temps et de leffort ncessaires pour obtenir de loutil des bnfices
significatifs et continus de loutil (incluant le besoin de modification du processus de tests et
lamlioration continue dans la manire dutiliser loutil).
Sous-estimation de leffort requis pour maintenir les acquis gnrs par loutil.
Confiance excessive dans loutil (comme substitut la conception des tests ou alors que
des tests manuels seraient plus appropris).
Ngligence du contrle de version des lments de test dans l'outil
Ngligence des problmes de relation et interoprabilit entre les outils critiques, tels que
des outils de gestion d'exigences, des outils de contrle de version, des outils de gestion
d'incidents, des outils de suivi de dfauts et des outils de diffrents diteurs
Risque de faillite de lditeur d'outil, de retirer l'outil, ou de vendre l'outil un autre diteur
Faible ractivit du vendeur pour le support, les mises jour, et corrections des dfauts
Risque de suspension dun logiciel ou projet open-source ou libre
Imprvu, comme l'incapacit de support d'une nouvelle plate-forme
6.2.2 Considrations spciales pour quelques types d'outil (K1)

Outils dexcution des tests
Les outils d'excution de tests excutent des objets de tests utilisant des scripts de test
automatiss. Ce type doutil ncessite souvent un effort important pour obtenir des bnfices
significatifs.
Saisir des tests en enregistrant les actions dun testeur manuel semble sduisant, mais cette
approche ne peut pas tre applique lorsque le nombre de tests automatiss est important. Un
script captur est une reprsentation linaire avec des donnes et actions spcifiques faisant partie
de chaque script. Ce type de script peut tre instable lors de loccurrence dvnements inattendus.
Version 2011
Page 65 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Une approche guide par les donnes isole les entres de tests (les donnes), habituellement au
moyen dun tableur et utilise un script plus gnrique qui peut lire les donnes de test et effectuer le
mme test avec des donnes diffrentes. Les testeurs qui ne sont pas familiariss avec le langage
de scripts peuvent alors entrer des donnes de tests pour ces scripts prdfinis.
Il y a d'autres techniques utilises avec des techniques pilotes par les donnes, o au lieu des
combinaisons codes en dur de donnes places dans un tableur, des donnes sont produites
utilisant des algorithmes bass sur des paramtres configurables lors de l'excution et fournis
l'application. Par exemple, un outil peut utiliser un algorithme, qui produit un identifiant de
l'utilisateur de faon alatoire, et pour la rptabilit dans le modle, une injection est utilise pour
en contrler le caractre alatoire.
Dans une approche par mots-cls, le tableur contient des mots-cls dcrivant les actions
effectuer (aussi appels mots daction ou action words), et des donnes de tests. Les testeurs
(mme sils ne sont pas familiers avec le langage de script) peuvent ensuite dfinir des tests en
utilisant les mots-cls, qui peuvent tre adapts en fonction de lapplication tester.
Une expertise technique quant au langage de script est requise pour toutes les approches (soit par
les testeurs, soit par des spcialistes en automatisation des tests).
Quelle que soit la technique de script utilise, le rsultat attendu pour chaque test est archiv pour
une comparaison ultrieure.
Outils d'analyse statique
Les outils danalyse statique appliqus au code source peuvent imposer des standards de codage,
mais sils sont appliqus du code existant, peuvent engendrer de nombreux messages. Les
messages davertissement nempchent pas le code dtre traduit en programme excutable, mais
doivent tre pris en compte afin de faciliter la maintenance du code dans le futur. Une
implmentation graduelle avec des filtres initiaux pour exclure certains messages constitue une
approche efficace.
Outils de gestion des tests
Les outils de gestion des tests doivent sinterfacer avec dautres outils ou des tableurs de faon
produire les informations dans le format le mieux adapt aux besoins prsents de lorganisation.
Version 2011
Page 66 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
6.3 Introduire un outil dans une organisation (K1)
International
Software Testing
15 minutes
Termes
Aucun terme spcifique.
Contexte
Les principes principaux lis lintroduction dun outil dans une organisation incluent:
Evaluation de la maturit de lorganisation, de ses forces et de ses faiblesses et identification
des possibilits damlioration du processus de test par le support doutils.
Evaluation au regard dexigences claires et de critres objectifs.
Une preuve de concept, l'aide d'un outil de test pendant la phase d'valuation pour
vrifier quil fonctionne efficacement avec le logiciel en cours de test et dans l'infrastructure
courante ou pour identifier des modifications requises de cette infrastructure pour utiliser
l'outil efficacement
Evaluation du vendeur (aspects de formation, de support et de commerce y compris) ou
des fournisseurs de service de support en cas d'outils non commerciaux
Identification des exigences internes pour le soutien et la tutelle dans l'utilisation de l'outil
Evaluation de besoin de formation par rapport aux comptences en automatisation de tests
de l'quipe de test courante
Evaluation du rapport cot/bnfice bas sur un cas mtier concret
Introduire l'outil choisi dans une organisation commence par un projet pilote, qui a les objectifs
suivants :
Apprendre loutil plus en profondeur.
Voir comment loutil sadapte des processus et pratiques existants, et comment ces derniers
devraient voluer.
Dcider dune manire standard dutiliser, de grer, de stocker et de maintenir loutil et le
testware (p.ex. dcider dune convention de nommage pour les fichiers et les tests, crer des
bibliothques et dfinir la modularit des suites de tests).
Evaluer si les bnfices escompts seront atteints pour un cot raisonnable.
Les facteurs de succs du dploiement dun outil dans une organisation incluent :
Etendre loutil au reste de lorganisation de faon incrmentale.
Adapter et amliorer les processus de faon les adapter lutilisation de loutil.
Fournir de la formation et une assistance aux nouveaux utilisateurs.
tablir des guides dutilisation.
Implmenter une manire de tirer des enseignements de lutilisation de loutil.
Surveiller lutilisation de loutil et les bnfices recueillis
Fournir le support pour l'quipe de test pour un outil donn
Recueillir l'exprience acquise de toutes les quipes
Rfrences
6.2.2 Buwalda, 2001, Fewster, 1999
6.3 Fewster, 1999
Version 2011
Page 67 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
7.
Comit
Franais des
Tests
Logiciels
International
Software Testing
Rfrences
Standards
Glossaire des tests de logiciel - 2 1 F ISTQB.pdf
ISTQB Glossary of terms used in Software Testing Version 2.1
[CMMI] Chrissis, M.B., Konrad, M. and Shrum, S. (2004) CMMI, Guidelines for Process Integration
and Product Improvement, Addison Wesley: Reading, MA
Voir Section 2.1
[IEEE Std 829-1998] IEEE Std 829 (1998) IEEE Standard for Software Test Documentation,
Voir Sections 2.3, 2.4, 4.1, 5.2, 5.3, 5.5, 5.6
[IEEE 1028] IEEE Std 1028 (2008) IEEE Standard for Software Reviews and Audits,
Voir Section 3.2
[IEEE 12207] IEEE 12207/ISO/IEC 12207-2008, Software life cycle processesVoir Section 2.1
[ISO 9126] ISO/IEC 9126-1:2001, Software Engineering Software Product Quality,
Voir Section 2.3
Livres
[Beizer, 1990] Beizer, B. (1990) Software Testing Techniques (3rd edition), Van Nostrand Reinhold:
Boston
Voir Sections 1.2, 1.3, 2.3, 4.2, 4.3, 4.4, 4.6
[Black, 2001] Black, R. (2001) Managing the Testing Process (2nd edition), John Wiley & Sons:
New York
Voir Sections 1.1, 1.2, 1.4, 1.5, 2.3, 2.4, 5.1, 5.2, 5.3, 5.5, 5.6
[Buwalda, 2001] Buwalda, H. et al. (2001) Integrated Test Design and Automation, Addison Wesley:
Reading, MA
Voir Section 6.2
[Copeland, 2004] Copeland, L. (2004) A Practitioners Guide to Software Test Design, Artech
House: Norwood, MA
Voir Sections 2.2, 2.3, 4.2, 4.3, 4.4, 4.6
[Craig, 2002] Craig, Rick D. and Jaskiel, Stefan P. (2002) Systematic Software Testing, Artech
House: Norwood, MAVoir Sections 1.4.5, 2.1.3, 2.4, 4.1, 5.2.5, 5.3, 5.4
[Fewster, 1999] Fewster, M. and Graham, D. (1999) Software Test Automation, Addison Wesley:
Reading, MA
Voir Sections 6.2, 6.3
[Gilb, 1993]: Gilb, Tom and Graham, Dorothy (1993) Software Inspection, Addison Wesley:
Reading, MA
Voir Sections 3.2.2, 3.2.4
[Hetzel, 1988] Hetzel, W. (1988) Complete Guide to Software Testing, QED: Wellesley, MA
Voir Sections 1.3, 1.4, 1.5, 2.1, 2.2, 2.3, 2.4, 4.1, 5.1, 5.3
[Kaner, 2002] Kaner, C., Bach, J. and Pettticord, B. (2002) Lessons Learned in Software Testing,
John Wiley & Sons: New York
Voir Sections 1.1, 4.5, 5.2
[Myers 1979] Myers, Glenford J. (1979) The Art of Software Testing, John Wiley & Sons: New York
Version 2011
Page 68 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Voir Sections 1.2, 1.3, 2.2, 4.3

[van Veenendaal, 2004] van Veenendaal, E. (ed.) (2004) The Testing Practitioner (Chapters 6, 8,
10), UTN Publishers: The Netherlands
Voir Sections 3.2, 3.3
Version 2011
Page 69 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Annexe A Informations sur le syllabus
8.
Historique de ce document
Ce document a t prpar entre 2004 et 2011 par un groupe de travail compos de membres de
lInternational Software Testing Qualifications Board (ISTQB). Il a t initialement rvis par une
commission de rvision, puis par des reprsentants de la communaut internationale des testeurs
de logiciels. Les rgles utilises pour la conception de ce document sont dcrites en Annexe C.
Ce document est le syllabus pour le certificat niveau Fondation en Tests de Logiciels, le premier
niveau du schma de qualification international approuv par lISTQB (www.istqb.org).
Objectifs de la qualification Certificat Fondation
Acqurir une reconnaissance des tests comme une spcialisation professionnelle et

essentielle de lingnierie logicielle.
Fournir un cadre standard pour le dveloppement des carrires des testeurs.
Permettre une reconnaissance des testeurs qualifis professionnellement par les employeurs,
clients et leurs pairs, et accrotre le profil des testeurs.
Promouvoir de bonnes pratiques, rgulires, dans les disciplines de lingnierie logicielle.
Identifier des thmes de tests qui sont pertinents et valables pour lindustrie.
Permettre aux fournisseurs de logiciels dembaucher des testeurs certifis et gagner ainsi un
avantage commercial sur la comptition en annonant leur politique de recrutement.
Fournir une opportunit aux testeurs et aux personnes intresses par les tests dacqurir
une qualification reconnue internationalement sur le sujet.
Objectifs de la qualification internationale (adapt de la runion ISTQB

de Novembre 2001 Sollentuna)
o
o
o
o
o
o
o
o
o
o
Permettre de comparer les comptences des tests de pays diffrents

Permettre aux testeurs de traverser les frontires plus facilement.
Faciliter une comprhension commune des aspects de tests dans les projets multi-nationaux
et/ou internationaux
Augmenter le nombre de testeurs qualifis dans le monde
Avoir plus dimpact ou de valeur en tant quinitiative internationale quune approche nationale
spcifique
Dvelopper une comprhension et une connaissance commune internationale sur les tests via
un syllabus et une terminologie, et accrotre le niveau de connaissance des tests de tous les
participants
Promouvoir les tests en tant que profession dans plus de pays
Permettre aux testeurs dacqurir une qualification reconnue dans leur langue maternelle
Faciliter le partage de connaissances et de ressources entre les pays.
Fournir une reconnaissance internationale des testeurs et de cette qualification par une
participation de nombreux pays
Conditions dentre pour cette certification

Le critre dentre pour passer lexamen du certificat de Testeur de Logiciels Certifi CFTL niveau
Fondation (ISTQB Foundation Certificate in Software Testing) est que le candidat dmontre un
intrt dans les tests logiciels. Cependant il est fortement recommand que le candidat :
o Possde une connaissance minimale soit du dveloppement de logiciels, soit des tests de
logiciels, tels quun minimum de six mois dexprience en tests systmes ou tests dacceptation
utilisateurs, ou en tant que dveloppeur de logiciels
o Suive un cours accrdit CFTL ou au niveau des standards ISTQB (par un des comits
nationaux reconnus par lISTQB)
Version 2011
Page 70 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
Contexte et histoire du Certificat Fondation en Tests de Logiciels

La certification indpendante des testeurs de logiciels a commenc en Grande Bretagne avec le
Information Systems Examination Board (ISEB) du British Computer Society, quand un Comit
des Tests Logiciels a t mis en place en 1998 (www.bcs.org.uk/iseb). En 2002, ASQF en
Allemagne commena a supporter un schma de qualification allemand (www.asqf.de). Ce syllabus
est bas sur les syllabus ISEB et ASQF; il inclut une rorganisation et une mise jour du contenu,
ainsi que du contenu supplmentaire, et une emphase est mise sur les points qui fourniront une
aide pratique aux testeurs.
Un Certificat en Tests de Logiciels niveau Fondation existant (p.ex. de lISEB, de lASQF ou dun
comit national reconnu par lISTQB) dcern avant la publication de ce Certificat International,
sera considr comme quivalent au Certificat International. Le Certificat niveau Fondation nexpire
pas et ne doit pas tre renouvel. La date dattribution est indique sur le Certificat.
Dans chaque pays participant, les aspects locaux sont contrls par un Comit National des Tests
Logiciels reconnu par lISTQB. Les devoirs des comits nationaux sont spcifis par lISTQB, mais
implments dans chaque pays. Les devoirs des comits nationaux incluent laccrditation des
organismes de formation et la tenue des examens.
Version 2011
Page 71 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
9. Annexe B Objectifs de connaissance/Niveaux de

connaissance
Les objectifs de connaissance suivants sont dfinis comme sappliquant ce syllabus. Chaque
aspect de ce syllabus sera examin en fonction de son objectif de connaissance.
Niveau 1: Se souvenir (K1)

Le candidat reconnatra, se rappellera et se souviendra des termes ou des concepts.
Mots cls: Se souvenir, retrouver, reconnatre, mmoriser, savoir
Exemple
Peut reconnatre la dfinition de dfaillance comme :
o
o
non livraison dun service lutilisateur final ou tout autre personne implique ou
Dviation constate du composant ou systme de la fourniture, service ou rsultat attendu.
Niveau 2: comprendre (K2)

Le candidat peut slectionner les raisons ou explications pour des affirmations lies au sujet trait,
et peut rsumer, diffrencier, classer et donner des exemples sur les concepts de test
Mots cls: Rsumer, classer, comparer, relier, opposer, donner des exemples, interprter, traduire,
reprsenter, dduire, conclure, construire des modles, classer, gnraliser, faire abstraction
Exemples
Peut expliquer les raisons pour lesquelles les tests doivent tre excuts aussi tt que possible :
o Pour trouver des dfauts quand il est intressant de les supprimer.
o Pour trouver dabord les dfauts les plus importants.
Peut expliquer les similitudes et les diffrences entre les tests dintgration et les tests systme :
o Similitudes : tester plus dun composant, et tester des aspects non-fonctionnels.
Diffrences : les tests dintgration se concentrent sur les interfaces et les interactions, les tests
systme se focalisent sur les aspects de systmes entiers, tels le processus de bout en bout.
Niveau 3: Appliquer (K3)

Le candidat peut slectionner lapplication correcte dun concept ou dune technique et lappliquer
un contexte donn.
Mots cls: Implmenter, excuter, utiliser, suivre une procdure, appliquer une procdure
Exemple
o Peut identifier les valeurs limites pour des partitions valides et invalides
o Peut slectionner les cas de test ncessaires la couverture de toutes les transitions pour un
diagramme dtat donn
Niveau 4: Analyser (K4)

Le candidat peut dcomposer linformation relative la procdure ou la technique en diffrentes
parties pour une meilleure comprhension et peut faire la diffrence entre des faits et les
conclusions qui en sont tires. Une application classique est de proposer, aprs lanalyse dun
document, dun logiciel ou de la situation dun projet, les actions appropries pour rsoudre un
problme ou une tche.
Mots cls: Analyser, diffrencier, slectionner, structurer, cibler, attribuer, dconstruire, organiser,
trouver la cohrence, intgrer, mettre en vidence, parcourir, distinguer, cibler, discriminer
Exemple
Version 2011
Page 72 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
o
o
Comit
Franais des
Tests
Logiciels
International
Software Testing
Analyser les risques produit et proposer des activits correctives et prventives pour les
attnuer
Dcrire quelles parties dun rapport dincident sont factuelles et quelles parties ont t dduites
des rsultats.
Rfrences
(pour les niveaux cognitifs des objectifs dapprentissage)
Anderson, L. W. and Krathwohl, D. R. (eds) (2001) A Taxonomy for Learning, Teaching, and
Assessing: A Revision of Bloom's Taxonomy of Educational Objectives, Allyn & Bacon
Version 2011
Page 73 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
10. Annexe C Rgles appliques au syllabus ISTQB

niveau Fondation
Les rgles listes ci-aprs ont t utilises dans le dveloppement et la revue de ce syllabus. (une
rfrence TAG est prcise aprs chaque rgle pour rfrencer celle-ci.)
10.1.1 Rgles gnrales

SG1. le syllabus doit tre comprhensible et absorbable par des personnes ayant de 0 6 mois
(ou plus) dexprience en tests. (6-MOIS)
SG2. Le syllabus doit tre pratique plutt que thorique. (PRATIQUE)
SG3. Le syllabus doit tre clair et non ambigu pour son lectorat prvu. (CLAIR)
SG4. Le syllabus doit tre comprhensible par des personnes de pays diffrents, et facilement
traduisible en diffrentes langues. (TRADUISIBLE)
SG5. Le syllabus doit utiliser la tournure amricaine de langlais. (ANGLAIS-AMERICAIN)
10.1.2 Contenu actualis

SC1. Le syllabus doit inclure des concepts de tests rcents et doit reflter les meilleures pratiques
actuelles en tests de logiciels l o elles sont gnralement acceptes. Le syllabus est sujet
revue tous les trois ou cinq ans. (RECENT)
SC2. Le syllabus doit minimiser les aspects lis au temps, telles que les conditions du march, pour
lui permettre dtre valide pour une priode de trois cinq ans. (DUREE-DE-VIE).
10.1.3 Objectifs de connaissance

LO1. Les objectifs de connaissance doivent distinguer entre des aspects reconnaitre/mmoriser
(niveau cognitive K1), les aspects que le candidat doit comprendre conceptuellement (K2), des
aspects que le candidat doit tre capable dutiliser et de mettre en pratique (K3) et des aspects que
le candidat doit tre capable dutiliser pour analyser un document, du logiciel, la situation dun projet
dans son contexte (K4). (NIVEAU DE CONNAISSANCE)
LO2. La description du contenu doit tre consistante avec les objectifs de connaissance. (LOCONSISTANT)
LO3. Pour illustrer les objectifs de connaissance, des exemples de questions dexamen pour
chacune des sections majeures seront fournies avec le syllabus. (LO-EXAMEN)
10.1.4 Structure gnrale

ST1. La structure du syllabus doit tre claire et permettre une rfrence croise partir de (et vers)
chaque partie, depuis les questions dexamen et depuis dautres documents pertinents. (CROSSREF)
ST2. Le recouvrement entre les sections du syllabus doit tre minimis. (RECOUVREMENT)
ST3. Chaque section du syllabus doit avoir la mme structure. (CONSISTANCE STRUCTURELLE)
ST4. Le syllabus doit contenir version, date dmission et numro de page sur chaque page.
(VERSION)
Version 2011
Page 74 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
ST5. Le syllabus doit inclure une information sur le temps passer sur chaque section (pour reflter
limportance relative de chaque aspect). (TEMPS PASSE)
Rfrences
SR1. Sources et Rfrences seront fournis pour les concepts du syllabus pour aider les
fournisseurs de formations trouver plus dinformation sur le sujet. (REFS)
SR2. Si la source nest pas clairement identifie et/ou claire, plus de dtails doit tre fourni dans le
syllabus. Par exemple, les dfinitions sont dans le Glossaire, donc seuls les termes sont lists dans
le syllabus. (NON-REF DETAIL)
Sources dinformations
Les termes utiliss dans le syllabus sont ceux dfinis dans le Glossaire CFTL/ISTQB des termes
utiliss en tests de logiciels. Une version de ce glossaire est disponible sur les sites de lISTQB et
du CFTL.
Une liste de livres recommands sur les tests de logiciels est aussi fournie en parallle ce
syllabus. La liste principale de livres est incluse dans la section rfrence.
Version 2011
Page 75 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
11.
Comit
Franais des
Tests
Logiciels
International
Software Testing
Annexe D Note pour les organismes de formation
Chaque titre de sujet principal de ce syllabus est associ une dure en minutes. Lobjectif de
cette instruction est de donner des indications sur la proportion de temps allouer chaque section
dans un cours accrdit, et en mme temps fournir une dure minimum approximative pour
enseigner chaque section. Les fournisseurs de formations peuvent passer plus de temps quindiqu
et les candidats peuvent prendre plus de temps en lectures et en recherche. Un curriculum de
cours ne doit pas spcifiquement suivre le mme ordre que le syllabus.
Le syllabus contient des rfrences des normes tablies, qui doivent tre utilises dans la
prparation du matriel de formation. Chaque norme utilise doit tre dans la version mentionne
dans ce syllabus. Dautres publications, modles ou standards non rfrencs dans ce syllabus
peuvent aussi tre utiliss et rfrencs, mais ne seront pas examins.
Version 2011
Page 76 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
12. Tous les objectifs de niveau K3 et K4 ncessitent de

pratiquer des exercices. Annexe E Changements intgrs dans
le Syllabus 2010
1. Changements des objectifs de connaissance (LO) pour y inclure des clarifications
a. Vocabulaire chang pour les LOs suivants (Le contenu et le niveau des LOs
demeure inchang): LO-1.2.2,LO-1.3.1, LO-1.4.1, LO-1.5.1, LO-2.1.1, LO-2.1.3,
LO-2.4.2, LO-4.1.3, LO-4.2.1, LO-4.2.2, , LO-4.3.1, LO-4.3.2, LO-4.3.3, LO-4.4.1,
LO-4.4.2, LO-4.4.3, LO-4.6.1, LO-5.1.2, LO-5.2.2, LO-5.3.2, LO-5.3.3, LO-5.5.2,
LO-5.6.1, LO-6.1.1, LO-6.2.2, LO-6.3.2
b. LO-1.1.5 a t rcrit et mis au niveau K2. Une comparaison des termes relatifs
aux defaults peut tre attendue.
c. LO-1.2.3 Le contenu du syllabus version 2007 le couvrait dj.
d. (K2) combine maintenant le contenu de LO-3.1.3 et LO-3.1.
e. LO-3.1.4 Supprim de la version 2010 car redondant en partie avec le LO-3.1.3.
f. LO-3.2.1 Rcrit en version 2010 pour amlioration du contenu.
g. LO-3.3.2 Mis jour. Passe du niveau K1 K2 pour compatibilit avec le LO-3.1.2
h. LO-4.4.4 a t modifi pour plus de clart et passe du niveau K3 K4.
Raison :rdaction identique un niveau K4.
i. LO-6.1.2 (K1) a t supprim de la version 2010 et remplac par LO-6.1.3 (K2).Il
nexiste pas de LO-6.4.2 dans la version 2010 du Syllabus.
2. Usage de lapproche de tests selon la dfinition du glossaire. Le terme Stratgie de tests
ne sera pas requis comme devant tre appris.
3. Le chapitre 1.4 contient maintenant le concept de traabilit entre les bases de tests et les
cas de test.
4. Le chapitre 2.x contient maintenant les objets de test et les bases de test.
5. Re-tester remplace maintenant Tests de confirmation en liaison avec le syllabus.
6. Les aspects Qualit des donnes et tests ont t ajout en plusieurs endroits du
syllabus: Qualit des donnes et risques dans les chapitres 2.2, 5.5, 6.1.8
7. Les critres dentre du chapitre 5.2.3 ont t ajouts comme un nouveau sous-chapitre.
Raison: La consistance du contenu des Critres de sortie (-> critre dentre ajout au LO5.2.9).
8. Utilisation des termes Stratgie de tests et Approche de tests conformment leur
dfinition dans le glossaire.
9. Le chapitre 6.1 a t raccourci car les descriptions des outils taient trop exhaustives pour
une leon de 45 minutes.
10. La norme IEEE Std 829:2008 est parue. Cette version du syllabus ne prend pas encore en
compte cette nouvelle dition. La section 5.2 fait rfrence au document Plan de Test. Le
contenu du Plan de Test Maitre est couvert par le concept qui dit que le Plan de test
couvre diffrents niveaux de planification de tests: Les plans de test sappliquent tous les
niveaux de tests comme au niveau projet qui lui couvrira plusieurs niveaux de tests. Ce
dernier est appel Plan de Test Maitre dans ce syllabus et dans le glossaire de lISTQB.
11. Le code dthique est dplac du syllabus Avanc vers le syllabus Fondation.
Version 2011
Changements raliss dans le version 2011
1. Toutes pages : mots Working Party remplacs par Working Group
2. Introduction : description des niveaux cognitifs retire car redondante avec lannexe B
3. Paragraphe 1.6 : parce que le but nest pas de dfinir un objectif dapprentissage au code
dethique , le niveau a t retir.
4. Paragraphes 2.2.1, 2.2.2, 2.2.3 and 2.2.4, 3.2.3: problme de formatage de liste rsolu.
5. Paragraphe 2.2.2 : mot dfaillance impropre difficile disoler les dfaillances lis un
composant .., remplac par dfaut .
Version 2011
Page 77 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
International
Software Testing
6. Paragraphe 2.3.4: mise jour de la description du dbogage pour cohrence avec le

glossaire.
7. Paragraphe 2.4 : retrait du mot appronfondis, phrase incluent des tests de rgression
approfondis car la profondeur dpend du changement (taille, risque, valeur, etc)
comme expliqu dans la phrase suivante.
8. Paragraphe 3.2.1: suite un probleme de formatage du paragraphe, le processus de revue
comprenait 12 activits principales au lieu de 6. Le formatage t repris et le contenu est
nouveau cohrent avec la version 2007 du syllabus
9. Paragraphe 4 : mot dvelopp remplac par conu car un cas de test est conu et
non dvelopp.
10. Paragraphe 4.2 : texte modifi pour clarifier lutilisation conjointe des tests boite noire et
boite blanche avec les techniques bases sur lexprience.
11. Paragraphe 4.3.5 : modification de texte linteraction entre des acteurs utilisateurs et
systme .
12. Paragraphe 4.3.5 : des branches alternatives remplac par des scnarios alternatifs
13. Paragraphe 4.4.2 : modification de texte pour clarifier le point sur les tests de branche.
14. Paragraphes 6.1 : modification du titre Comprendre la signification et le but des outils de
support aux tests en Outils de support aux tests
e
nde
15. Paragraphe 7 / Livres : la 3 dition du livre [Black,2001] remplace la 2 dition
16. Annexe D : liste des chapitres ncessitant des exercices remplace par l
obligation gnrique pour tous les objectifs d'apprentissage K3 et suprieur de pratiquer
des exercices. Obligation issue de l the ISTQB Accreditation Process (Version 1.26).
17. Annexe E : les diffrences entre la version 2007 et 2010 sont maintenant lists
correctement.
Version 2011
Page 78 de 80
201131-Mar-2010
3-Nov-
Testeur Certifi
13.
Comit
Franais des
Tests
Logiciels
International
Software Testing
Index
accrditation ............................................. 8
action words ............................................ 74
activits de planification des tests .......... 58
alpha tests .............................................. 24
analyse dimpact ............................... 31, 43
analyse de test ........................................ 43
analyse des valeurs limites ..................... 47
analyse statique ................................ 34, 39
approche base sur les risques .............. 65
approche de test ......................... 43, 58, 59
approche guide par les donnes .......... 74
approche par mots-cls .......................... 74
approche test first ................................... 25
approche tester dabord .......................... 25
architecture ............................................. 25
archivage ................................................ 31
attaque de faute ...................................... 60
attaque par faute..................................... 51
automatisation ........................................ 30
avantages de lindpendance ................. 55
base de tests .......................................... 15
bnfices lis lutilisation doutils ......... 73
beta tests .......................................... 24, 27
bottom-up ................................................ 25
bouchon .................................................. 24
bouchons ................................................ 24
bug .......................................................... 11
cas dutilisation ................................. 28, 48
cas de test13, 16, 28, 34, 41, 42, 43, 45, 46,
47, 48, 49, 50, 71
cause premire ....................................... 12
check-list ........................................... 36, 37
cibles de tests ................................... 21, 28
classe dquivalence............................... 47
classification des outils de test .... 69, 70
clture des tests ................................ 10, 17
code dthique ........................................ 20
comparateur de tests ........................ 69, 72
compilateur ............................................. 39
complexit ......................................... 39, 71
conception de test....................... 41, 43, 51
conception de tests ........................... 43, 45
conception des tests ............................... 15
condition de test.................... 16, 28, 43, 45
conditions de test .............................. 13, 43
conditions de tests .................................. 15
considrations spciales pour quelques
types doutils .................................... 73
consignation dincidents ......................... 66
contrle de flux ................................. 49, 50
contrle de versions................................ 63
contrle des tests........................ 15, 61, 62
corrections .............................................. 31
Version 2011
Page 79 de 80
201131-Mar-2010
couverture29, 41, 43, 45, 47, 48, 49, 50, 70,

72, 73
couverture de code ..................... 41, 49, 70
couverture de test ................................... 15
couverture des dcisions ............ 41, 49, 50
couverture des instructions ..................... 49
couverture des tests ................................ 61
couverture du code ................................. 28
critre dentre .................................. 35, 78
critre de sortie13, 15, 16, 35, 36, 37, 56, 59
dbogage .................................... 13, 24, 29
dfaillance ................................... 11, 39, 51
dfaut11, 13, 34, 35, 36, 37, 39, 42, 47, 48,
51, 52, 70, 71
densit de dfauts ................................... 61
dveloppement .. 21, 22, 34, 35, 39, 43, 52,
63, 71
dveloppement dirig par les tests ......... 24
dveloppement logiciel ........................... 22
dveloppement pilot par les tests ......... 25
dveloppement rapide dapplications (RAD) 22
donne de test ........................................ 45
donnes de test ...................................... 43
donnes de tests ......................... 15, 71, 74
effet de sonde ................................... 69, 70
effort de test ............................................ 59
enregistrement de rsultats .................... 51
environnement de test ................ 17, 24, 26
erreur................................................. 11, 51
estimation derreur ............................ 18, 51
estimation des tests ............................. 59
estimation et planification des tests ........ 58
examen ..................................................... 8
excution de test ......................... 39, 51, 71
excution des tests13, 15, 16, 34, 43, 53, 68
exigence ...................................... 13, 34, 36
exigences ................................................ 34
exigences de spcification ...................... 28
exigences fonctionnelles ................... 24, 26
exigences non-fonctionnelles............ 24, 26
facteurs de succs .................................. 37
faute ........................................................ 51
fiabilit ............................................... 28, 69
flux de contrle .................................. 39, 41
flux de donnes ....................................... 39
fonctionnalit ..................................... 24, 28
framework de test ................................... 69
framework de test unitaire ....................... 71
gestion de configuration .......................... 63
gestion des incidents .............................. 66
gestion des tests ..................................... 53
gestion d'incident .................................... 66
gestionnaire du test ................................. 55
greffier ..................................................... 36
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
harnais de tests ................................ 69, 71

implmentation de tests .......................... 43
implmentation des tests ........................ 16
incident ....................................... 15, 66, 70
inconvnients de l'indpendance ........... 55
indpendance ................................... 18, 55
inspection .................................... 35, 36, 37
intgration ................. 24, 25, 39, 47, 48, 50
introduction dun outil dans une organisation 68
introduire un outil dans une organisation 75
ISO 9126 ........................................... 29, 76
lancement ............................................... 35
langage de script .............................. 73, 74
langage de scripting................................ 71
logiciel ..................................................... 11
logiciel commercial sur tagre .............. 22
logiciel dvelopp sur mesure ................ 27
maturit ....................................... 17, 35, 43
mprise ................................................... 11
mtrique .................................................. 35
mtriques .......................................... 35, 37
modle de dveloppement incrmental.. 22
modle de dveloppement itratif ...... 22
modle de dveloppement logiciel ......... 21
modle en V ............................................ 22
modles de dveloppement logiciel ....... 22
modrateur ................................. 35, 36, 37
modifications durgence .......................... 31
mot daction ............................................ 74
niveau de test ................. 23, 41, 47, 50, 52
niveau de tests ........................................ 24
niveaux de tests .................... 21, 22, 24, 28
objectif de test................................... 51, 52
objectifs de connaissance 8, 10, 21, 33, 41,
53, 68
objectifs de la qualification Certificat
Fondation ........................................... 78
objectifs de la qualification internationale 78
objectifs des tests ................................... 13
oracle de test .......................................... 72
ordonnancement de lexcution de tests 43
organisation des tests ............................. 55
outil daide lexcution et
lenregistrement des tests ............... 71
outil daide la gestion du test et des
tests ................................................... 70
outil daide la spcification des tests ... 71
outil daide au test statique ................. 71
outil danalyse dynamique ...................... 69
outil danalyse statique ........................... 39
outil danalyse statique ........................... 69
outil dexcution ...................................... 72
outil dexcution de test .......................... 71
outil dexcution de tests .................. 43, 73
outil dexcution des tests ...................... 68
outil dexcution des tests ...................... 69
outil de conception de tests .................... 71
Version 2011
Page 80 de 80
201131-Mar-2010
International
Software Testing
outil de conception de tests .................... 69

outil de dbogage ................................... 69
outil de gestion ........................................ 70
outil de gestion dexigences .................... 69
outil de gestion dincident........................ 70
outil de gestion dincidents ...................... 69
outil de gestion de configuration ............. 70
outil de gestion de configuration ............. 69
outil de gestion des exigences ................ 70
outil de gestion des tests .................. 70, 74
outil de gestion des tests ........................ 69
outil de mesure de couverture ................ 69
outil de modlisation ............................... 71
outil de modlisation ............................... 69
outil de monitoring ................................... 69
outil de prparation des donnes de tests69
outil de scurit ....................................... 69
outil de suivi des dfauts ......................... 70
outil de support de performance et de
surveillance ....................................... 72
outil de support de revues ....................... 69
outil de test de performances.................. 72
outil de test de scurit ........................... 72
outil de test de stress .............................. 72
outil de test de stress .............................. 69
outil de test statique ................................ 71
outil de tests de charge ........................... 69
outil de tests de performances ................ 69
outil de tests unitaires et structurels ....... 69
outil framework de test unitaire ............... 71
outils danalyse dynamique ..................... 72
outils danalyse statique .......................... 74
outils de gestion ...................................... 70
outils de gestion des tests ....................... 74
outils de mesure de couverture .............. 72
outils de prparation des donnes .......... 71
paradoxe du pesticide ............................. 14
partie prenante ........................................ 46
parties prenantes .............................. 17, 27
partitions dquivalence .......................... 47
patch ....................................................... 31
pilote ........................................................ 24
pilotes ...................................................... 24
plan de test........................................ 15, 34
planification des tests .................. 15, 16, 54
planning dexcution de tests.................. 44
politique de test ....................................... 15
principes de test ...................................... 14
principes gnraux .................................. 14
procdure de test .................. 15, 41, 43, 44
processus de dveloppement de test ..... 43
produit sur tagre (COTS) .................... 23
prototypage ............................................. 22
qualit........................ 11, 13, 29, 41, 43, 71
rapport dincident .............................. 17, 66
rapport de synthse de tests................... 15
rapport de test ......................................... 61
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
Rational Unified Process (RUP) ............. 22

registre de test .................................. 15, 71
relecture technique ........................... 35, 36
rptable ................................................. 29
reporting des tests .................................. 61
responsabilits ........................................ 36
responsable du test ................................ 55
rsultat attendu ................................. 43, 74
rsultats attendus ................................... 43
rviseur ............................................. 35, 36
revue ................... 13, 34, 35, 36, 37, 38, 39
revue de pairs ......................................... 37
revue de pairs ................................... 35, 37
revue formelle ................................... 35, 36
revue informelle ................................ 35, 36
revue technique ...................................... 37
revue technique .......................... 35, 36, 37
risque .......................................... 11, 43, 52
risque ...................................................... 11
risque ...................................................... 25
risque ...................................................... 58
risque ...................................................... 64
risque ...................................................... 64
risque li au produit ............................. 64
risque li au projet ................................ 64
risque li auproduit ................................. 64
risque projet ............................................ 54
risques lis lutilisation doutils ............. 73
rle ........................................ 35, 36, 37, 57
scribe ................................................ 35, 36
script captur .......................................... 73
script de test ......................... 16, 34, 43, 44
scurit ................................................... 39
slectionner les techniques de tests ....... 52
squences de transaction ....................... 25
simulateur ............................................... 24
sources dinformations ............................ 83
spcification de cas de test .................... 41
spcification de cas de test .................... 66
spcification de procdure de test .... 41, 43
spcification des cas de test ................... 43
spcifications fonctionnelles ................... 28
stratgie de test .......................... 15, 58, 59
structure de test unitaire ......................... 24
suite de test ............................................ 15
suite de tests ........................................... 29
suivi ............................................. 35, 36, 37
suivi de lavancement des tests .............. 61
suivi des tests ......................................... 61
support doutils ........................................ 50
support outill ......................................... 68
support outill des tests .......................... 68
support par les outils......................... 68, 73
table de dcisions ................................... 48
tches .................................................... 56
tches des testeurs .............................. 56
tches du responsable de test ................ 56
Version 2011
Page 81 de 80
201131-Mar-2010
International
Software Testing
Tches du responsable des tests ....... 56

tches fonctionnelles .............................. 25
taux de dfaillance .................................. 61
technique base sur lexprience ..... 42, 45
technique base sur la structure ....... 45, 50
technique base sur les spcifications42, 45
technique base sur les spcifications ... 47
technique bote blanche .......................... 45
technique bote noire ........................ 41, 45
technique de conception base sur la
structure .............................................. 49
technique de conception bote blanche .. 49
technique de conception de test ....... 41, 45
technique de conception de tests ........... 45
technique de test ..................................... 43
technique statique ................................... 34
techniquebasesurlexprience .............. 51
techniques de conception de tests ......... 41
techniques statiques ............................... 33
test .................................................... 11, 13
test bas sur les cas dutilisation ............ 41
test bas sur les risques ......................... 65
test bas sur les spcifications ............... 41
test bas sur les structures ..................... 41
test dacceptation usine .......................... 27
test dintgration ...................................... 47
test dintgration de composants ............ 25
test de charge ......................................... 72
test de composant ....................... 41, 48, 49
test de confirmation ................................. 15
test de rgression ................................... 15
test de stress ........................................... 72
test de transition dtats .................... 47, 48
test des dcisions ................................... 49
test dynamique .................................. 34, 39
test fonctionnel ........................................ 28
test indpendant ..................................... 18
test statique ............................................. 34
test structurel..................................... 28, 50
tester ....................................................... 73
testeur ................................... 36, 48, 51, 55
tests alpha ............................................... 27
tests bass sur la structure ..................... 49
tests bote blanche ............................ 28, 49
tests bote noire ...................................... 28
tests dacceptation contractuelle ....... 24, 27
tests dacceptation oprationnelle .......... 27
tests dacceptation sur site ...................... 27
tests dacceptation utilisateur .................. 27
tests dacceptation utilisateurs ................ 24
tests dintgration .............................. 24, 39
tests dintgration systme ..................... 25
tests dinteroprabilit ............................. 28
tests dutilisabilit .............................. 28, 29
tests de cas dutilisation .................... 47, 48
tests de charge ................................. 28, 29
tests de composant ................................. 24
3-Nov-
Testeur Certifi
Comit
Franais des
Tests
Logiciels
tests de confirmation............................... 28
tests de fiabilit ................................. 28, 29
tests de maintenabilit ...................... 28, 29
tests de maintenance........................ 21, 31
tests de performances ...................... 28, 29
tests de portabilit............................. 28, 29
tests de rgression ................................. 28
tests de robustesse................................. 24
tests de scurit...................................... 28
tests de stress ................................... 28, 29
tests des dcisions ................................. 49
tests des instructions........................... 49
tests et qualit ......................................... 11
tests exhaustifs ....................................... 14
tests exploratoires................................... 51
tests fonctionnels .................................... 28
tests non-fonctionnels ............................. 29
Version 2011
Page 82 de 80
201131-Mar-2010
International
Software Testing
tests oprationnels .................................. 31

tests par tables de dcisions................... 47
tests pilots par les donnes .................. 73
tests pilots par mots cl ........................ 73
tests structurels ................................. 28, 49
tests sur le terrain ............................. 24, 27
tests systme .......................................... 24
testware............................................. 15, 16
top-down ................................................. 25
traabilit ........................................... 43, 56
types doutil de test ................................. 68
types doutils de test ......................... 69, 70
types de tests .................................... 21, 28
utilisabilit................................................ 28
validation ................................................. 22
vrification ............................................... 22
3-Nov-

ISTQB FL Syllabus 2011 Released FR

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ISTQB FL Syllabus 2011 Released FR

Transféré par

Droits d'auteur :

Formats disponibles

Testeur Certifi

Syllabus Niveau Fondation

International Software Testing Qualifications Board

Historique des modifications

Table des Matires

10.1.4 Structure gnrale ........................................................................................................... 74

Le Niveau Fondation pour les Testeurs de Logiciels Certifis

Objectifs de connaissance /niveaux de connaissance

Des objectifs gnraux dinstruction, dcrivant les intentions du niveau fondation

Le contenu du syllabus nest pas une description de lensemble du domaine de connaissance en

2. Tester pendant le Cycle de Vie (K2)

Ce titre indique que le Chapitre 2 a un objectif de connaissance K1 (suppos quand un niveau

Fondamentaux des Tests (K2)

Objectifs de connaissance pour Fondamentaux des Tests

1.1 Pourquoi les tests sont-ils ncessaires ? (K2)

1.2 Que sont les tests ? (K2)

Rappeler les objectifs habituels des tests. (K1)

1.3 Les 7 Principes gnraux des tests (K2)

Expliquer les 7 principes gnraux des tests (K2)

1.4 Processus de test fondamental (K1)

Rappeler les 5 activits de test fondamentales et les tches associes, de la

1.5 La psychologie des tests (K2)

Pourquoi les tests sont-ils ncessaires? (K2)

Contexte des systmes logiciels (K1)

Origine des dfauts logiciels (K2)

1.1.3 Rle des tests dans le dveloppement, la maintenance et lopration

Tests et qualit (K2)

Combien de test est suffisant? (K2)

Que sont les tests ? (K2)

Les 7 principes gnraux des tests (K2)

Processus de test fondamental (K1)

Planification des tests et contrle

Bien que logiquement squentielles, les activits du processus peuvent se chevaucher

Planification et contrle des tests (K1)

Analyse et Conception des tests (K1)

Concevoir et prioriser les tests de haut niveau

Implmentation et excution des tests (K1)

Evaluer les critres de sortie et informer (K1)

Activits de clture des tests (K1)

La psychologie des tests (K2)

2. Tester Pendant le Cycle de Vie Logiciel

Objectifs de connaissance pour Tester Pendant le Cycle de Vie

2.1 Les modles de dveloppement logiciel (K2)

2.2 Niveaux de tests (K2)

2.3 Types de tests: les cibles de tests (K2)

Comparer les quatre types de tests (fonctionnels, non-fonctionnels, structurels et lis

2.4 Tests de maintenance (K2)

Modles de Dveloppement Logiciel (K2)

Tests de composants (unitaires);

En pratique, un modle en V peut avoir des niveaux de dveloppement et de tests diffrents, en

Modle de dveloppement itratif (K2)

Tester au sein dun modle de cycle de vie (K2)

A chaque activit de dveloppement, correspond une activit de test.

Niveaux de tests (K2)

Tests de composants (K2)

Tests dintgration (K2)

Tests systme (K2)

Objets de tests habituels:

Tests dacceptation (K2)

Types de tests (K2)

Tests des fonctions (tests fonctionnels) (K2)

Tests de la structure / architecture logicielle (tests structurels) (K2)

Tests lis au changement (tests de confirmation et de rgression) (K2)