istqb fl syllabus 2011 released fr

7/24/2019 ISTQB Fl Syllabus 2011 Released Fr

1/82

Testeur Certifi

Syllabus Niveau Fondation

Version 2011 FR

International Software Testing Qualifications Board

Comit Franais des Tests Logiciels


2/82

Testeur CertifiSyllabus Niveau Fondation

ComitFranaisdesTestsLogiciels

International

Software Testing

QualificationsBoard

Version 2011 Page 2 de 82 31-Mar-2010 International Software Testing Qualifications Board

CopyrightCe 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), DorothyGraham, Debra Friedenberg et Erik van Veenendaal)

Copyright 2005, les auteurs (Thomas Mller (responsable), Rex Black, Sigrid Eldh, DorothyGraham, Klaus Olsen, Maaret Pyhjrvi, Geoff Thompson et Erik van Veenendaal).

Tous droits rservs.

Les auteurs transfrent leurs droits lInternational Software Testing Qualifications Board (ci-aprsappel ISTQB). Les auteurs (en tant que possesseurs actuels des droits dauteurs) et lISTQB (en tantque possesseur futur des droits dauteurs) ont conclu laccord suivant portant sur les conditionsdutilisation:

1) Tout individu ou organisme de formation peut utiliser ce syllabus comme base pour uneformation si les auteurs et lISTQB sont cits comme source et possesseurs des droits de cesyllabus, et pour autant que toute publicit sur une telle formation mentionne ce syllabusuniquement aprs demande daccrditation officielle de cette formation auprs dun ComitNational reconnu par lISTQB;

2) Tout individu ou groupe dindividus peut utiliser ce syllabus comme une base pour desarticles, livres, ou autres crits drivs, si les auteurs et lISTQB sont reconnus comme sourceet possesseurs des droits de ce syllabus ;

3) Tout Comit National reconnu par lISTQB peut traduire ce syllabus et permettre lutilisationde ce syllabus par des tiers.


3/82

Testeur Certifi

Syllabus Niveau FondationComitFranais desTestsLogiciels

International

Software Testing

Qualifications Board

Version 2011 Page 3 de 80 3-Nov-201131-Mar-2010 International Software Testing Qualifications Board

4) Historique des modifications

Version Date RemarquesCFTL 2011FR 3-Nov-2011 Testeur Certifi Niveau Fondation Mise jour

voirAnnexe EChangements intgrs dans leSyllabus 20101

CFTL 2010FR 1-Sept-2010 Testeur Certifi Niveau Fondation Mise jourvoirAnnexe EChangements intgrs dans leSyllabus 2010

ISTQB 2010 30-Mars-2010 Certified Tester Foundation Level SyllabusMaintenance ReleasevoirAnnexe EChangements intgrs dans le Syllabus 2010

ISTQB 2007 01-Mai-2007 Certified Tester Foundation Level SyllabusMaintenance Releasevoir Appendix EReleaseNotes Syllabus 2007

CFTL 2005FR 01-Juillet-2005 Testeur Certifi Niveau FondationISTQB 2005 01-Juillet-2005 Certified Tester Foundation Level SyllabusASQF V2.2 Juillet-2003 ASQF Syllabus Foundation Level Version 2.2

LehrplanGrundlagen des Software-testensISEB V2.0 25-Fvrier-1999 ISEB Software Testing Foundation Syllabus V2.0

25 February 1999

Traduction franaise: Bernard HOMES, Eric RIOU du COSQUER, Alain RIBAULT, BertrandCORNANGUER, Cyrille RIVIERE, Olivier DENOO, Vronique JOURDY-COTTEN


4/82

Testeur Certifi


International

Software Testing



Table des Matires

Remerciements ........................................................................................................................................ 7

Introduction ce syllabus ........................................................................................................................ 81.

Fondamentaux des Tests (K2)...................................................................................................... 10

1.1 Pourquoi les tests sont-ils ncessaires? (K2)...................................................................... 111.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)111.1.4

Tests et qualit (K2) ........................................................................................................ 11

1.1.5 Combien de test est suffisant? (K2) ................................................................................. 121.2

Que sont les tests ? (K2)..................................................................................................... 13

1.3 Les 7 principes gnraux des tests (K2).............................................................................. 141.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)..................................................................... 161.4.4

Evaluer les critres de sortie et informer (K1) ................................................................. 16

1.4.5 Activits de clture des tests (K1) ................................................................................... 161.5

La psychologie des tests (K2).............................................................................................. 18

1.6 Code dthique..................................................................................................................... 202.

Tester Pendant le Cycle de Vie Logiciel (K2) ............................................................................... 21

2.1

Modles de Dveloppement Logiciel (K2).......................................................................... 22

2.1.1 Modle en V (K2) ............................................................................................................. 222.1.2

Modle de dveloppement itratif (K2) ............................................................................ 22

2.1.3 Tester au sein dun modle de cycle de vie(K2) ............................................................. 222.2

Niveaux de tests (K2)........................................................................................................... 24

2.2.1

Tests de composants (K2) ............................................................................................... 24

2.2.2 Tests dintgration (K2).................................................................................................... 252.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 non-fonctionnels) (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) ........................ 292.4

Tests de maintenance (K2).................................................................................................. 30

3. Techniques Statiques (K2) ............................................................................................................ 313.1

Techniques statiques et processus de test (K2).................................................................. 32

3.2 Processus de revue (K2)...................................................................................................... 333.2.1 Phases dune revue formelle (K1)................................................................................... 333.2.2

Rles et responsabilits (K1) ........................................................................................... 33

3.2.3 Types de revues (K2) ....................................................................................................... 343.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) .................................................................................... 374.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) ...................................................................................... 404.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


5/82

Testeur Certifi


International

Software Testing



4.4

Technique de conception base sur la structure ou technique de conception boteblanche (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)............................................................................ 455.

Gestion des Tests (K3) ................................................................................................................. 46

5.1

Organisation des tests (K2).................................................................................................. 48

5.1.1 Organisation du test et indpendance (K2) ..................................................................... 485.1.2

Tches du responsable des tests et des testeurs (K1) ................................................... 48

5.2 Estimation et planification des tests (K3)............................................................................. 505.2.1

Planification des tests (K2) .............................................................................................. 50

5.2.2

Activits de planification des tests (K3) ........................................................................... 50

5.2.3 Critres dentre (K2)....................................................................................................... 505.2.4

Critres de sortie (K2) ...................................................................................................... 51

5.2.5

Estimation des tests (K2) ................................................................................................. 515.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) ............................................................................... 535.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) ............................................................................................... 565.5.2

Risques lis au produit (K2) ............................................................................................. 56

5.6

Gestion des incidents (K3) ................................................................................................... 58

6. Outils de Support aux Tests (K2) .................................................................................................. 606.1

Types d'outils de test (K2).................................................................................................... 61

6.1.1

Outils de support aux tests (K2) ...................................................................................... 616.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) .............................................................................. 626.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) .............................................. 646.1.8

Outils de support pour des besoins de tests spcifiques (K1)......................................... 64

6.2 Utilisation efficace des outils : Bnfices potentiels et Risques (K2)................................... 656.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 .......................................................................................................................................... 68Livres ................................................................................................................................................. 68

8.

Annexe AInformations sur le syllabus ....................................................................................... 70

Historique de ce document................................................................................................................ 70Objectifs de la qualification internationale (adapt de la runion ISTQB de Novembre 2001 Sollentuna) ........................................................................................................................................ 70

9.

Annexe BObjectifs de connaissance/Niveaux de connaissance .............................................. 72

Niveau 1: Se souvenir (K1) ............................................................................................................... 72

Niveau 2: comprendre (K2) ............................................................................................................... 72Niveau 3: Appliquer (K3) ................................................................................................................... 72

Niveau 4: Analyser (K4) .................................................................................................................... 7210.

Annexe CRgles appliques au syllabus ISTQB niveau Fondation .................................... 74

10.1.1

Rgles gnrales ............................................................................................................. 74

10.1.2

Contenu actualis ............................................................................................................ 7410.1.3

Objectifs de connaissance ............................................................................................... 74


6/82

Testeur Certifi


International

Software Testing



10.1.4

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

11. Annexe DNote pour les organismes de formation ................................................................ 7612.

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


7/82

Testeur Certifi


International

Software Testing



Remerciements

International Software Testing Qualifications Board Working Group Foundation Level (Edition2011): 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 duCosquier Hans Schaefer, Stephanie Ulrich, Erik van Veenendaal) et tous les Comits Nationauxpour leurs suggestions pour la version actuelle du syllabus.

International Software Testing Qualifications Board Working Group Foundation Level (Edition2010): Thomas Mller (responsable), Rahul Verma, Martin Klonk et Armin Beer. Le groupe detravail remercie lquipe de revue (Rex Black, Mette Bruhn-Pederson, Debra Friedenberg, KlausOlsen, Tuula Pkknen, Meile Posthuma, Hans Schaefer, Stephanie Ulrich, Pete Williams, Erikvan Veenendaal) et tous les Comits Nationaux pour leurs suggestions pour la version actuelle dusyllabus.

International Software Testing Qualifications Board Working Group Foundation Level (Edition2007): Thomas Mller (responsable), Dorothy Graham, Debra Friedenberg, et Erik vanVeendendaal 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 leurssuggestions.

International Software Testing Qualifications Board Working Group Foundation Level (Edition2005): Thomas Mller (responsable), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, MaaretPyhjrvi, Geoff Thompson , Erik van Veenendaal et l'quipe de revue ainsi que tous les ComitsNationaux pour leurs suggestions.


8/82

Testeur Certifi


International

Software Testing



Introduction ce syllabus

Objectif de ce documentCe syllabus forme la base du niveau Fondation de la qualification Internationale en tests delogiciels. LInternational Software Testing Qualifications Board (ISTQB) et le Comit Franais desTests Logiciels (ci-aprs appel CFTL) fournissent ce syllabus aux comits nationaux dexamenspour accrditer les fournisseurs de formations et pour en driver des questions dexamens dansleur langue nationale. Les fournisseurs de formations produiront leurs cours et dtermineront lesmthodes de formation appropries pour laccrditation, et le syllabus aidera les candidats seprparer 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 utilisateuretdveloppeurs de logiciels. Cette qualification de niveau Fondation est aussi approprie pour toutepersonne souhaitant une comprhension de base des tests de logiciels, tels que les gestionnairesde projets, responsables qualit, responsables de dveloppements logiciels, analystes mtier etconsultants en management. Les possesseurs du Certificat Fondation seront capables de continuerafin 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 lafaon suivanteo 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.

LexamenLexamen pour lobtention du Certificat Fondation sera bas sur ce syllabus. Les rponses auxquestions dexamen peuvent requrir lutilisation dinformations contenues dans plus dune sectionde 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 partic ipation une formationaccrdite nest pas un pr-requis au passage de lexamen.

AccrditationLes fournisseurs de formations dont le contenu du cours suit ce syllabus peuvent tre accrditspar un comit national reconnu par lISTQBet le CFTL. Les directives daccrditation doivent treobtenues auprs de lorganisme ou du comit effectuant laccrditation. Un cours accrdit estreconnu comme se conformant ce syllabus, et peut inclure un examen ISTQB CFTL commepartie du cours.

Pour de plus amples informations destination des fournisseurs de formation, voir lAnnexe D.


9/82

Testeur Certifi


International

Software Testing



Niveau de dtailLe 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 entests de logiciels; il reflte le niveau de dtail devant tre couvert par les cours et formations duniveau fondation.

Organisation du syllabusCe syllabus comprend six chapitres majeurs. Le titre principal de chaque chapitre montre lobjectifdapprentissage couvert par le chapitre, et spcifie la dure minimale pour traiter ce chapitre. Parexemple:

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 niveausuprieur est spcifi) et K2 (mais pas K3), et quune dure de 115 minutes est suggre pourcouvrir le matriel de ce chapitre.Chaque chapitre comporte plusieurs sections. Chaque section possde aussi un objectif deconnaissance et la dure requise en minutes. Les sous-sections qui nont pas de dure prcisesont inclues dans la dure totale de la section.


10/82

Testeur Certifi


International

Software Testing



1. Fondamentaux des Tests (K2) 155 minutes

Objectifs de connaissance pour Fondamentaux des TestsLes 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 Dcrire, avec des exemples, la manire par laquelle un dfaut dans un logiciel peut

causer des dommages des personnes, lenvironnement ou la socit. (K2) LO-1.1.2 Faire la diffrence entre la cause initiale du dfaut et ses effets. (K2)LO-1.1.3 Donner des raisons pour lesquelles les tests sont ncessaires en donnant des

exemples. (K2)LO-1.1.4 Dcrire pourquoi les tests font partie de lassurance qualit et donner des exemples sur

comment les tests contribuent une qualit accrue. (K2)LO-1.1.5 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 Rappeler les objectifs habituels des tests. (K1)LO-1.2.2 Fournir des exemples pour les objectifs des tests lors des diffrentes phases du cycle

de vie logiciel (K2)LO-1.2.3 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 Rappeler les facteurs psychologiques ayant une influence sur le succs des tests (K1)LO-1.5.2 Comparer la mentalit dun testeur avec celle dun dveloppeur(K2)


11/82

Testeur Certifi


International

Software Testing



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

TermesBug, 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 applicationscommerciales (p.ex. bancaires) aux produits de grande consommation (p.ex. automobiles). Laplupart dentre nous ont eu lexprience dun logiciel qui na pas fonctionn comme attendu. Deslogiciels ne fonctionnant pas correctement peuvent gnrer de nombreux problmes, depuis despertes financires, de temps ou de rputation, et pouvant mme aller jusqu causer des blessuresou 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 unlogiciel ou un systme, ou dans un document. Si un dfaut dans du code est excut, le systmeneffectuera pas ce quil aurait d faire (ou fera ce quil naurait pas d faire), gnrant unedfaillance. Des dfauts dans les logiciels, systmes ou documents peuvent gnrer desdfaillances, mais tous les dfauts ne le font pas.

Les dfauts apparaissent parce que les humains peuvent se tromper et cause des chanciersserrs, de la complexit du code et des infrastructures, des modifications de technologies et/ou demultiples 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 lesmicroprogrammes ou influencer lexcution des logiciels en modifiant les conditions matrielles.

1.1.3 Rle des tests dans le dveloppement, la maintenance et loprationdes logiciels (K2)

Des tests rigoureux des systmes et de la documentation peuvent aider rduire les risquesdoccurrence de problmes dans lenvironnement oprationnel et contribuent la qualit dessystmes logiciels, si les dfauts dcouverts sont corrigs avant la livraison du systme pour unusage 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 dfautstrouvs, pour des caractristiques et exigences tant fonctionnelles que non-fonctionnelles (p.ex.fiabilit, utilisabilit, rentabilit, maintenabilit et portabilit). Pour plus dinformations sur les testsnon-fonctionnels voir Chapitre 2; pour plus dinformations sur les caractristiques logicielles voirSoftware Engineering Software Product Quality (ISO 9126).

Les tests peuvent augmenter le niveau de confiance en la qualit dun logiciel sils trouvent peu oupas de dfauts. Un test conu correctement et qui est excut sans erreur rduit le niveau derisque gnral du systme. Quand les tests trouvent des dfauts, la qualit du systme logicielsaccrot quand ces dfauts sont corrigs.


12/82

Testeur Certifi


International

Software Testing



Des leons devraient tre apprises partir des projets prcdents. En comprenant les causespremires des dfauts trouvs dans dautres projets, les processus peuvent tre amliors, ce quiensuite 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 desstandards 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 lesrisques techniques, les risques lis la suret et au projet, ainsi que les contraintes du projet tellesque le temps et le budget. Les risques seront dvelopps au chapitre 5.

Les tests doivent fournir suffisamment dinformations pour que les responsables puissent prendredes dcisions informes concernant la mise en production du logiciel ou du systme en cours detest, pour ltape de dveloppement suivante ou la livraison aux clients.


13/82

Testeur Certifi


International

Software Testing



1.2 Que sont les tests ? (K2) 30minutes

Termesdbogage, exigences, revues, cas de test, test, objectifs des tests, test,

ContexteUne perception habituelle des tests est quils consistent uniquement en lexcution de tests, en faitexcuter 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 laplanification et le contrle, la slection des conditions de test, la conception et lexcution des casde tests, la vrification des rsultats, lvaluation des critres de sortie, linformation sur leprocessus de test et sur le systme en cours de test ; elles incluent aussi la ralisation et lafinalisation 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 atteindredes objectifs similaires, et fourniront des informations permettant lamlioration du systme testeret des processus de dveloppement et de test.

Les objectifs de tests peuvent varier :o Trouver des dfautso Acqurir de la confiance sur le niveau de qualito Fournir de linformation utile aux prises de dcisiono 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 dedfauts dans le code. Les revues de documents (p.ex. exigences), lidentification et la rsolution deproblmes 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), lobjectifprincipal peut tre de gnrer le plus de dfaillances possible de faon identifier et corriger lesdfauts dans le logiciel. Dans les tests dacceptation, lobjectif principal peut tre de confirmer quele systme fonctionne comme attendu, pour sassurer quil atteint les exigences. Dans certains caslobjectif principal des tests peut tre dvaluer la qualit dun logiciel (sans chercher trouver desanomalies), de faon fournir aux responsables de linformation sur les risques de distribuer unsystme un moment prcis. Les tests de maintenance incluent souvent des tests pour sassurerque de nouvelles anomalies nont pas t introduites pendant le dveloppement des volutions.Pendant les tests dopration, les objectifs principaux peuvent tre dvaluer les caractristiques dusystme telles la disponibilit ou la fiabilit.

Tester et dboguer sont diffrents. Les tests dynamiques peuvent montrer des dfaillancescauses par des dfauts. Dboguer est lactivit de dveloppement qui trouve, analyse et supprimeles causes de la dfaillance. Les tests de confirmation ultrieurs effectus par un testeur assurentque la correction rsout effectivement la dfaillance. La responsabilit de chaque activit estdiffrente : les testeurs testent, les dveloppeurs dboguent.Le processus de test et les activits de test sont expliqus en Section 1.4.


14/82

Testeur Certifi


International

Software Testing



1.3 Les 7 principes gnraux des tests (K2) 35 minutes

TermesTests exhaustifs.

PrincipesUn nombre de principes de test ont t suggrs au cours des 40 dernires annes et offrent desindications communes tous les tests.

Principe 1Les tests montrent la prsence de dfauts

Les tests peuvent prouver la prsence de dfauts, mais ne peuvent pas en prouver labsence. Lestests rduisent la probabilit que des dfauts restent cachs dans le logiciel mais, mme si aucundfaut nest dcouvert, ce nest pas une preuve dexactitude.

Principe 2Les tests exhaustifs sont impossiblesTout tester (toutes les combinaisons dentres et de pr-conditions) nest pas faisable sauf pour descas triviaux. Plutt que des tests exhaustifs, nous utilisons lanalyse des risques et des prioritspour focaliser les efforts de tests.

Principe 3Tester tt

Pour trouver des dfauts tt, les activits de tests devraient commencer aussi tt que possible dansle cycle de dveloppement du logiciel ou du systme, et devraient tre focalises vers des objectifsdfinis.

Principe 4Regroupement des dfauts

Leffort de test devrait tre fix proportionnellement la densit des dfauts prvus et constatsdans les diffrents modules. Un petit nombre de modules contiennent gnralement la majorit desdfauts dtects lors des tests pr-livraison, ou affichent le plus de dfaillances en opration.

Principe 5Paradoxe du pesticideSi les mmes tests sont rpts de nombreuses fois, il arrivera que le mme ensemble de cas detests ne trouvera plus de nouveaux dfauts. Pour prvenir ce paradoxe du pesticide, les cas detests doivent tre rgulirement revus et rviss, et de nouveaux tests, diffrents, doivent tre critspour couvrir dautres chemins dans le logiciel ou le systme de faon permettre la dcouverte denouveaux dfauts.

Principe 6Les 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 7Lillusion de labsence derreursTrouver et corriger des dfauts naide pas si le systme conu est inutilisable et ne comble pas lesbesoins et les attentes des utilisateurs.


15/82

Testeur Certifi


International

Software Testing



1.4 Processus de test fondamental (K1) 35 minutes

TermesTests de confirmation, incident, test de rgression, base de tests , conditions de tests, couverturede 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.

ContexteLa partie la plus visible des tests est lexcution des tests. Mais pour tre efficaces et rentables, lesplans 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 chevaucherpartiellement ou tre concurrentes. Une adaptation de ces activits principales au contexte dusystme 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 rapportau plan, et dinformation sur ltat, y compris les dviations par rapport au plan. Cela implique deprendre les actions ncessaires pour atteindre la mission et les objectifs du projet. Afin de contrlerles tests, les activits de test devraient tre contrles tout au long du projet. La planification destests 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 testsreprsentent les activits o les objectifs de test gnraux sonttransforms en des conditions de test et des conceptions de test tangibles.

Lanalyse et la conception des tests se composent des tches majeures suivantes:o Rviser les bases du test (telles que les exigences, le niveau dintgrit logiciel1(niveau de

risque), les rapports danalyse de risque,larchitecture, la conception et les interfaces)o Evaluer la testabilit des exigences et du systmeo 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

1Le 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 reflterlimportance du logiciel pour les personnes concernes (p.ex: complexit logicielle, niveau de suret, niveau de scurit,performance souhaite, robustesse ou cot).


16/82

Testeur Certifi


International

Software Testing



o Concevoir et prioriser les tests de haut niveauo Identifier les donnes de test ncessaires pour les conditions de test et les cas de testo Concevoir linitialisation de lenvironnement de test et identifier les infrastructures et outils

requiso Crer une traabilit bi-directionnelle entre les bases de test et les cas de test

1.4.3 Implmentation et excution des tests(K1)

Limplmentationet lexcution des testsest lactivit o les procdures ou scripts de test sontspcifis en arrangeant les cas de test selon un ordre prcis et en ajoutant toute information utilepour 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 automatiqueso Crer des suites de tests partir des procdures de test pour une excution rentable des testso Vrifier que les environnements de tests ont t mis en place correctemento Vrifier et mettre jour la traabilit bi-directionnelle entre les bases de test et les cas de testo Excuter les procdures de test soit manuellement soit en utilisant des outils dexcution de

tests, en suivant la squence planifieo Consigner les rsultats de lexcution des tests et enregistrer les identits et versions des

logiciels en test, outils de test et testwareo 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, oumprise dans la manire dexcuter le test)

o Rpter les activits de test en rponse aux actions prises pour chaque divergence. Parexemple, rexcution dun test qui tait pralablement dfaillant de faon valider unecorrection (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 ouque 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 desobjectifs 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 testso Evaluer si des tests supplmentaires sont requis ou si les critres de sortie doivent tre

changso 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 auxjalons dun projet, par exemple, quand un systme logiciel est mis en production, un projet de testest 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 livrso Clturer les rapports dincidentsou crer des demandes dvolution pour ceux restant ouverts o

Documenter lacceptation du systme


17/82

Testeur Certifi


International

Software Testing



o Finaliser et archiver les testwares, environnements de test et infrastructures de test pour unerutilisation future

o Fournir les testwares lorganisation en charge de la maintenance

o Analyser les leons apprises pour identifier les changements ncessaires pour les versions etprojets futurso Utiliser linformation collecte pour amliorer la maturit des tests


18/82

Testeur Certifi


International

Software Testing



1.5 La psychologie des tests (K2) 25 minutes

TermesEstimation derreur, test indpendant.

Contexte

La tournure desprit utiliser pendant les tests et les revues est diffrente de celle utilise lors delanalyse ou du dveloppement. Avec la mentalit approprie, des dveloppeurs sont capables detester leur propre code, mais affecter cette responsabilit des testeurs permet typiquement defocaliser leffort et de fournir des bnfices additionnels tels quune perspective indpendante pardes ressources de test entranes et professionnelles. Les tests indpendants peuvent treeffectus nimporte quel niveau des tests

Un certain degr dindpendance (vitant le parti-pris de lauteur) est souvent plus efficace pourdtecter des dfauts et des dfaillances. Lindpendance nest pas cependant un remplacement dela familiarit, et les dveloppeurs peuvent efficacement trouver beaucoup derreurs dans leur proprecode. Plusieurs niveaux dindpendance peuvent tre dfinis, comme les niveaux suivantsprsents 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 testsde performance ou utilisabilit)

o Tests conus par une (des) personne(s) dune organisation ou socit diffrente (p.ex. sous -traitance ou certification par un organisme externe)

Les personnes et les projets sont dirigs par des objectifs. Les personnes ont tendance alignerleurs 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 estimportant de spcifier clairement les objectifs des tests.

Lidentification de dfaillances pendant les tests peut tre perue comme une critique contre leproduit et contre son(ses) auteur(s). Les tests sont, de ce fait, souvent vus comme une activitdestructrice, mme si cest trs constructif dans la gestion des risques du produit. Rechercher desdfaillances 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 delexprience sur laquelle baser lestimation derreurs.

Si des erreurs, dfauts ou dfaillances sont communiqus de manire constructive, lanimositentre les testeurs et les analystes, concepteurs et dveloppeurs peut tre vite. Ceci sappliqueautant aux revues quaux tests.

Les testeurs et le responsable des tests ont besoin de bonnes comptences relationnelles pourcommuniquer des informations factuelles sur les dfauts, les progrs et les risques, de manireconstructive. Pour lauteur du logiciel ou du document, une information sur les dfauts peutpermettre damliorer leur savoir-faire. Les dfauts trouvs et corrigs pendant les tests permettrontde gagner du temps et de largent plus tard, et de rduire les risques.

Des problmes de communication peuvent survenir, particulirement si les testeurs sont vusuniquement comme messagers porteurs de mauvaises nouvelles concernant des dfauts.


19/82

Testeur Certifi


International

Software Testing



Cependant, il existe plusieurs manires damliorer la communication et les relations entre lestesteurs et leurs interlocuteurs :

o Commencer par une collaboration plutt que par des conflitsrappeler chacun lobjectifcommun de systmes de meilleure qualito 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 derevues) objectifs et factuels

o Essayer de comprendre ce que ressent une autre personne et pourquoi elle ragit comme ellele fait

o Confirmer que lautre personne a compris ce que lon a dit et vice versa


20/82

Testeur Certifi


International

Software Testing



1.6 Code dthique 10 minutes

Limplication dans le test logiciel permet aux individus davoir accs des informationsconfidentielles et privilgies. Un code dthique est ncessaire, notamment pour assurer que lesinformations ne soient pas utilises dans des cas non appropris. En rfrence au code dthiquedACM et de lIEEE pour les ingnieurs, lISTQB dfinit le code dthique suivant :

PUBLICles testeurs de logiciels certifis doivent agir en fonction de lintrt publicCLIENT ET EMPLOYEURles testeurs de logiciels certifis doivent agir pour lintrt de leur

client et de leur employeur tout en respectant lintrt public PRODUITles testeurs de logiciels certifis doivent assurer que les fournitures quils produisent

(concernant les produits et les systmes quils testent) rpondent le plus possible auxstandards professionnels

JUGEMENTles testeurs de logiciels certifis doivent conserver leur intgrit et leurindpendance dans leur jugement professionnelGESTIONles 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 logicielsPROFESSIONles testeurs de logiciels certifis doivent mettre en avant lintgrit et la

rputation du mtier en cohrence avec lintrt publicCOLLEGUESles testeurs de logiciels certifis doivent tre loyaux, aider leurs collgues, et

promouvoir le partenariat avec les dveloppeurs de logicielsPERSONNELLEMENTles testeurs de logiciels certifis doivent participer en permanence de

la formation pour leur mtier et doivent promouvoir une approche morale concernant sapratique.

References

1.1.5 Black, 2001, Kaner, 20021.2 Beizer, 1990, Black, 2001, Myers, 19791.3 Beizer, 1990, Hetzel, 1988, Myers, 19791.4 Hetzel, 19881.4.5 Black, 2001, Craig, 20021.5 Black, 2001, Hetzel, 1988


21/82

Testeur Certifi


International

Software Testing



2. Tester Pendant le Cycle de Vie Logiciel

(K2)

115 minutes

Objectifs de connaissance pour Tester Pendant le Cycle de VieLogicielLes 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 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 descaractristiques et contextes de produits et de projets (K2).

LO-2.1.2 Reconnatre que les modles de dveloppement logiciel doivent tre adapts aucontexte du projet et aux caractristiques du produit (K1).

LO-2.1.3 Rappeler que les bonnes pratiques de test sont applicables dans tous les modles decycle 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 Comparer les quatre types de tests (fonctionnels, non-fonctionnels, structurels et lis

aux changements) avec des exemples. (K2)LO-2.3.2 Reconnatre que les tests fonctionnels et structurels peuvent apparatre nimporte

quel niveau. (K1)LO-2.3.3 Identifier et dcrire des types de tests non-fonctionnels bass sur des exigences non-fonctionnelles. (K2)

LO-2.3.4 Identifier et dcrire des types de tests bass sur lanalyse de la structure ou delarchitecture dun systme logiciel. (K2)

LO-2.3.5 Dcrire lutilit des tests de confirmation et des tests de rgression. (K2)

2.4 Tests de maintenance (K2)LO-2.4.1 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 testset la quantit de tests. (K2)

LO-2.4.2 Reconnaitre les indicateurs pour les tests de maintenance (modification, migration etabandon). (K1)

LO-2.4.3 Dcrire le rle des tests de rgression et de lanalyse dimpact en maintenance. (K2)


22/82

Testeur Certifi


International

Software Testing



2.1 Modles de Dveloppement Logiciel (K2) 20 minutes

TermesLogiciel commercial sur tagre (en anglais : Commercial Off The Shelf ou COTS), modle dedveloppement incrmental niveaux de tests, validation, vrification, modle en V.

ContexteLes tests nexistent pas de faon isole; les activits de test sontlies aux activits dedveloppement logiciel. Les diffrents modles de cycle de dveloppement ncessitent desapproches 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, enmoins ou en plus, en fonction des projets et des produits logiciels. Par exemple, il peut y avoir destests dintgration des composants aprs les tests de composants, et des tests dintgration desystmes aprs des tests systmes.

Les livrables logiciels (tels les scnarios dutilisation ou les cas demploi, les spcificationsdexigences, les documents de conception et le code) produits pendant le dveloppement sontsouvent les bases des tests dun ou plusieurs niveaux de tests. Des rfrences pour des livrablesgnriques sont disponibles dans le modle CMMI (Capability Maturity Model Integration) ou danslIEEE/IEC 12207 (Processus de cycle de vie logiciel Software life cycle processes). La vrificationet la validation (ainsi que la conception au plus tt des tests) peuvent tre effectues pendant ledveloppement des livrables logiciels.

2.1.2 Modle de dveloppement itratif(K2)Le mode de dveloppement itratif est une succession dactivits excutes comme une srie depetits dveloppements: exigences, conception, construction et tests dun systme. Exemples :

prototypage, dveloppement rapide dapplications(RAD), Rational Unified Process (RUP) et lesmodles de dveloppement agiles. Le systme logiciel rsultant (lincrment) dune itration peuttre test plusieurs niveaux de tests chaque itration. Un incrment, ajout ceux dveloppspralablement, forme un systme partiel en croissance, qui devrait galement tre test. Les testsde rgression sont de plus en plus importants sur toutes les itrations aprs la premire. Lavrification 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 testdevraient commencer pendant

lactivit correspondante de dveloppement.


23/82

Testeur Certifi


International

Software Testing



Les testeurs doivent tre impliqus dans la revue des documents aussi tt que des brouillonssont disponibles dans le cycle de dveloppement.

Les niveaux de tests peuvent tre combins ou rorganiss selon la nature du projet ou delarchitecture du systme. Par exemple, pour lintgration dun logiciel sur tagre (COTS) dans unsystme, lacheteur peut effectuer des tests dintgration au niveau systme (Ex. intgration danslinfrastructure et les autres systmes, ou dploiement du systme) ainsi que des testsdacceptation (fonctionnels et/ou non-fonctionnels, et tests dacceptation utilisateurs et/ouoprationnels).


24/82

Testeur Certifi


International

Software Testing



2.2 Niveaux de tests (K2) 40 minutes

TermesAlpha tests, Beta tests, tests de composant (aussi connus comme tests unitaires, de modules ou deprogrammes), tests dacceptation contractuelle, pilotes, tests sur le terrain, exigencesfonctionnelles, intgration, tests dintgration, exigences non-fonctionnelles, tests de robustesse,bouchons, tests systme, environnement de test, niveau de tests, dveloppement dirig par lestests, tests dacceptationutilisateurs.

ContextePour 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 detests (cd. ce qui est test), les dfauts et les dfaillances typiques trouver, les exigences enharnais 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 laplannification 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 deprogrammes) 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 defaon isole par rapport au reste du systme, en fonction du contexte du cycle de dveloppementdu 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 decaractristiques 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 desbranches). 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 surun environnement de dveloppement comme un framework de tests unitaire ou avec les outils dedbogage. En pratique ils impliquent gnralement le programmeur ayant crit le code.Habituellement, les dfauts sont corrigs ds quils sont trouvs, sans formellement enregistrer desincidents.

Une approche des tests de composants est de prparer et automatiser des cas de tests avant lecodage. Cela sappelle lapproche Tester dabord (en anglais : test first )ou Dveloppementpilot par les tests. Cette approche, fortement itrative est base sur des cycles de dveloppementde cas de tests, puis construction et intgration de petits bouts de code, puis excution des tests decomposants et correction des dfauts trouvs jusqu leur russite.


25/82

Testeur Certifi


International

Software Testing



2.2.2 Tests dintgration (K2)

Bases de Tests: Conception du logiciel et du systme Architecture Workflows Cas dutilisation

Objets habituels de test: 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 diffrentesparties dun systme comme par exemple le systme dexploitation, le systme de fichiers, lematriel ou les interfaces entre les systmes.

Plusieurs niveaux de tests dintgration peuvent tre effectus sur des objets de taille variable. Parexemple:

Tests dintgration des composants testant les interactions entre les composants logiciels eteffectus aprs les tests de composants;

Tests dintgration systmetestant lintgration entre les diffrents systmes ou entre logicielet matriel et pouvant tre effectus aprs les tests systme. Dans ce cas, lorganisation encharge du dveloppement peut ne contrler quun ct de linterface. Cela peut tre considrcomme un risque mtier. Les processus commerc iaux 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 uncomposant ou un systme particulier. Cela peut conduire un accroissement des risques et dutemps 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 detransactions, ou dautres aspects du systme ou du composant. Afindisoler facilement les fautes,et dtecter les dfauts au plus tt, lintgration devrait normalement tre incrmentale plutt qutreeffectue 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. Lesapproches 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 systmesne soientfabriqus, 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


26/82

Testeur Certifi


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 testsdoit tre clairement dfini dans le plan de test maitre ou le plan de test du niveau.

Pour les tests systme, lenvironnement de testdevrait correspondre la cible finale ou unenvironnement 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 niveaudu comportement du systme, les modles de comportement, les interactions avec le systmedexploitation et les ressources systme.

Les tests systme devraient examiner la fois les exigences fonctionnelles et les non-fonctionnelles du systme ainsi que la qualit des donnes. Les testeurs doivent galementsadapter aux exigences peu ou pas documentes. Les tests fonctionnels au niveau systmecommencent par lutilisation des techniques de spcification de tests les plus appropries (botenoire). Par exemple, une table de dcision peut tre cre pour les combinaisons deffets dcritsdans 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 lastructure 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

Objets habituels de test: 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 dunsystme; dautres responsables (parties prenantes) peuvent aussi tre impliqus.

Les objectifs des tests dacceptation sont de prendre confiance dans le systme, dans des partiesdu systme ou dans des caractristiques non-fonctionnelles du systme. La recherche danomaliesnest pas lobjectif principal des tests dacceptation. Les tests dacceptation peuvent valuer si lesystme est prt tre dploy et utilis, bien que ce ne soit pas ncessairement le dernier niveau


27/82

Testeur Certifi


International

Software Testing



de tests. Par exemple, une intgration systme grande chelle peut arriver aprs les testsdacceptation 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 utilisateurCes tests vrifient laptitude et lutilisabilit du systme par des utilisateurs.

Tests (dacceptation) oprationnelleLacceptation 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 rglementaireLes tests dacceptation contractuellesont excuts sur base des critres dacceptation contractuelspour la production de logiciels dvelopps sur mesure. Les critres dacceptation devraient tredfinis lors de la rdaction du contrat.Les tests dacceptation rglementaires sont excuts par rapport aux rglements et lgislations quidoivent 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 demettre en vente.Les Alpha tests sont excuts sur le site de lorganisation effectuant le dveloppement mais paspar les quipes de dveloppement. Les Bta tests ou tests sur le terrain sont excuts par despersonnes 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.


28/82

Testeur Certifi


International

Software Testing



2.3 Types de tests (K2) 40 minutes

Termestests 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 descurit, tests de stress, tests structurels, tests dutilisabilit, tests bote blanche.

ContexteUn groupe dactivits de tests peut tre ax sur la vrification du systme logiciel (ou dune partiedu 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 dergression).

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 deprocessus, 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 dcritesdans des livrables tels que des spcifications dexigences, les cas dutilisation, ou les spcificationsfonctionnelles, ou encore non documentes. Les fonctions sont ce que fait le systme.

Les tests fonctionnels sont bass sur ces fonctions et caractristiques (dcrites dans desdocuments ou comprises par les testeurs), et leur interoprabilit avec dautres systmes. Ilspeuvent tre excuts tous les niveaux de tests (p.ex. les tests dun composant peuvent trebass sur les spcifications du composant).

Des techniques bases sur les spcifications peuvent tre utilises pour driver des conditions detests et des cas de tests partir des fonctionnalits du logiciel ou du systme (voir Chapitre 4.) Lestests 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 ladtection de menaces, comme des virus, provenant de tiers malveillants. Un autre type de testfonctionnel, le test dinteroprabilit, value la capacit du logiciel interagir avec un ou plusieurscomposants ou systmes spcifis.

2.3.2 Tests des caractristiques non fonctionnelles des produits logiciels (testsnon-fonctionnels) (K2)Les tests non-fonctionnels incluent, mais pas uniquement, les tests de performances, tests decharge, tests de stress, tests dutilisabilit, tests de maintenabilit, tests de fiabilit et les tests deportabilit. 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 logicielsqui peuvent tre quantifies sur une chelle variable, comme les temps de rponse pour les tests


29/82

Testeur Certifi


International

Software Testing



de performances. Ces tests peuvent tre rfrencs dans un modle qualit tel que celui dfini parlISO9126Ingnierie LogicielleQualit des Produits Logiciels (Software Engineering SoftwareProduct 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. Lestechniques structurelles sont utilises de faon optimale aprs les techniques bases sur lesspcifications, pour aider mesurer lampleur des tests via lvaluation de la couverture dun typede structure.

La couverture indique quel point une structure a t teste par une suite de tests. Elle estexprime en pourcentage dlments couverts. Si la couverture nest pas de 100%, alors denouveaux tests peuvent tre conus pour tester les lments manquants et ainsi augmenter lacouverture. 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 testsdintgration de composants, des outils peuvent tre utiliss pour mesurer la couverture du codedes lments, telle que les instructions ou les dcisions. Les tests structurels peuvent tre basssur larchitecture du systme comme par exemple la hirarchie dappels.

Les approches de tests structurels peuvent tre aussi appliques au niveau systme, lintgrationsystme ou aux niveaux de tests dacceptation (p.ex. pour les processus mtier ou les structures demenus).

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 dfautoriginal a t correctement t. Ceci est appel test de confirmation. Le dbogage (localisation etcorrection 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 faitaprs 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, soitdans dautres composants logiciels lis ou non. Les tests de rgression sont excuts quand lelogiciel, ou son environnement, est modifi. Le primtre des tests de rgression est bas sur lerisque 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 testsde rgression.

Les tests de rgression peuvent tre excuts tous les niveaux de tests, et sappliquent aux testsfonctionnels, non-fonctionnels et structurels. Les suites de tests de rgression sont excutesplusieurs fois et voluent gnralement lentement. Donc les tests de rgression sont de bonscandidats lautomatisation.


30/82

Testeur Certifi


International

Software Testing



2.4 Tests de maintenance (K2) 15 minutes

TermesAnalyse dimpact, tests de maintenance

ContexteUne fois dploy, un systme logiciel est souvent en service pendant des annes, voire desdizaines dannes. Pendant ce temps, le systme, son paramtrage et son environnement sontfrquemment corrigs, modifis ou tendus. La planification au plus tt des livraisons est crucialepour le succs des tests de maintenance. Une distinction doit tre faite entre les livraisonsplanifies et les mises jour chaud (hot fixes). Les tests de maintenance sont effectus sur unsystme oprationnel existant et sont dclenchs par des modifications, migrations ou suppressionde logiciels ou de systmes.

Les modifications incluent les changements ds aux volutions planifies (p.ex. livraisons denouvelles versions), aux modifications correctives et durgence, ainsi quaux changementsdenvironnements tels que les montes en version planifies des systmes dexploitation, desbases de donnes ou des COTS. Elles incluent galement les patchs de correction desvulnrabilits de scurit potentielles ou dcouvertes dun systme dexploitation.

Les tests de maintenance lors de migrations (p.ex. dune plate-forme une autre) devraient inclureles 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 duneautre application seront migres dans le systme maintenir.

Les tests de maintenance pour la suppression (mise au rebut) dun systme incluent le test de lamigration des donnes ou leur archivage si de longues priodes de stockage de donnes sontncessaires.

En plus des tests des lments changs, les tests de maintenance incluent des tests de rgressionsur les parties du systme qui nont pas t modifies. Le primtre des tests de maintenance estfonction des risques lis aux modifications, la taille du systme existant et la taille desmodifications 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 analysedimpact, 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.

Rfrences2.1.3 CMMI, Craig, 2002, Hetzel, 1998, IEEE 122072.2 Hetzel, 19982.2.4 Copeland, 2004, Myers, 19792.3.1 Beizer, 1990, Black, 2001, Copeland, 20042.3.2 Black, 2001, ISO 91262.3.3 Beizer, 1990, Copeland, 2004, Hetzel, 19982.3.4 Hetzel, 1998, IEEE 8292.4 Black, 2001, Craig, 2002, Hetzel, 1998, IEEE 829


31/82

Testeur Certifi


International

Software Testing



3. Techniques Statiques (K2) 60 minutes

Objectifs de connaissance pour Techniques StatiquesLes 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 techniquesstatiques. (K1)LO-3.1.2 Dcrire limportance et la valeur de lutilisation de techniques statiques dans lvaluationde livrables logiciels. (K2)LO-3.1.3 Expliquer les diffrences entre les techniques statiques et dynamiques, en considrant lesobjectifs, les types de dfauts identifier et le rle de ces techniques dans le cycle de vie dulogiciel. (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, revuetechnique, 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 lescomparer 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 pardes outils danalyse statique. (K1)


32/82

Testeur Certifi


International

Software Testing



3.1 Techniques statiques et processus de test (K2) 15 minutes

TermesTest dynamique, test statique.

ContexteContrairement au test dynamique, qui exige lexcution du logiciel, les techniques de testsstatiques reposent sur lexamen manuel(revues) ou lanalyse(analyse statique) du code ou de ladocumentation du projet sans excution du code.

Les revues sont une manire de tester des produits logiciels (y compris du code) et peuvent treexcutes bien avant lexcution de tests dynamiques. Les dfauts dtects pendant les revueseffectues tt dans le cycle de vie sont souvent bien moins coteux ter que les dfauts dtectslors de lexcution des tests (p.ex. dfauts trouvs dans les exigences).

Une revue pourrait tre effectue entirement manuellement, mais il existe aussi des outils desupport. 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 deconception, 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 , desamliorations de productivit dans le dveloppement, des dures de dveloppement rduites, desdures 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, parexemple, 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 objectifidentifier desdfauts. Ils sont complmentaires : les diffrentes techniques peuvent trouver diffrents types dedfauts efficacement et rapidement. Contrairement aux tests dynamiques, les techniques statiquestrouvent 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, maintenabilitinsuffisante et spcifications incorrectes dinterfaces.


33/82

Testeur Certifi


International

Software Testing



3.2 Processus de revue (K2) 25 minutes

TermesCritre dentre, revue formelle, revue informelle, inspection, mtriques, modrateur, revue depairs, rviseur, scribe, revue technique, relecture technique.

ContexteLes diffrents types de revues varient de informel , caractris par labsence dinstructionscrites pour les relecteurs, systmatique , caractris par la participation de lquipe, desrsultats documents de la revue, et des procdures documentes pour mener la revue. Laformalit dun processus de revue est lie des facteurs tels que la maturit du processus dedveloppement, toute disposition lgale ou exigence rglementaire ou la ncessit de tracesdaudit.

La manire dont une revue est excute dpend des objectifs convenus pour la revue (p.ex. trouverdes dfauts, augmenter la comprhension, former les testeurs et les nouveaux membres dunequipe 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 sortiepour 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

istqb fl syllabus 2011 released fr

Documents