SlideShare une entreprise Scribd logo
1  sur  18
Télécharger pour lire hors ligne
Validation de
logiciel
Le contenu de ce document est mis à disposition selon les termes de la
Licence Creative Commons Attribution - Partage dans les Mêmes Conditions 3.0 France.
1cc-by-sa Jean-Paul Carmona
Sommaire
• Pourquoi et comment valider un logiciel
• Déroulement d’une campagne de test
• Types de validation
• Cycle de vie d’une anomalie
• Outils pour la validation
2cc-by-sa Jean-Paul Carmona
Pourquoi valider un
logiciel
• Vérifier le bon fonctionnement
o Avant livraison au client, coté fournisseur ou MOE
o Avant utilisation (ou mise en production), coté client ou MOA
• Connaître techniquement le logiciel
o Combien d’utilisateurs simultanés ?
o Quel temps de réponse ?
o Sur quelle configuration l’installer ? Maitrise d'OuvrAge
ou client
Cahier des
charges
Conception,
Fabrication
Maitrise d'OEuvre
ou fournisseur
ValidationRecette
3cc-by-sa Jean-Paul Carmona
& techniques
Exigences
fonctionnelles
& techniques
Cas de tests
Campagne de
test #1
Anomalies
Cahier des
charges
Campagne de
testCampagnes de
test #3
a
b
c
d
e
f
h
i
v1 aa
bb
cc
dd
ee
ff
gg
hh
v3v3
aa
bb
cc
dd
ee
ff
gg
hh
aa
bb
cc
dd
ee
ff
gg
hh
Analyse du
cahier des charges
Spec. générales
Spec. détaillées
Stratégie de
tests
Comment valider
un logiciel
4cc-by-sa Jean-Paul Carmona
Déroulement d’un projet
a
b
c
d
e
f
g
h
Exigences
a
b
e
V1_rc1 V2_rc1
Dev. v1
v1
Bugfix v1 / Dev. v2
Valid. v1
2 itérations : V1 et V2
2 équipes : dev. & valid.
V1_rc2
bug
Prepa.
valid. v1
Prepa.
valid. v2
Valid. v2
Bugfix v2
V2_rc2
bug
Importance de la gestion de configuration
a
b
c
d
e
f
g
h
5cc-by-sa Jean-Paul Carmona
les responsabilités
du valideur
• Le développeur est responsable du
o développement des fonctionnalités
o du respect des exigences
o de la correction des anomalies
• Le validateur est responsable
o du bon fonctionnement du logiciel
o de la vérification de la correction des anomalies
• C'est le valideur qui est en faute si
le logiciel livré ne fonctionne pas correctement
• Le valideur doit préciser pour chaque version testée
o La liste des fonctionnalités et exigences non vérifiées
o La liste des anomalies connues et non corrigées
o L'infrastructure matérielle et système utilisée pour les tests
6cc-by-sa Jean-Paul Carmona
Exigences
• Définir les exigences à partir de l'expression de besoins
dans le cahier des charges
• Identifier chaque exigence avec un numéro unique.
• Exemple :
o Format “<categorie>_<numero>”
o Exemple de catégories:
• IHM Interface Homme Machine; FON Fonctionel
• PER Performance; DES Design; CU Cas d’Utilisation
• IMP Implementation; LIV Livraison; ORG Organisation projet
7cc-by-sa Jean-Paul Carmona
Une exigence doit être…
• Exprimée en une phrase :
o un sujet + « doit » + verbe + complément,
o avec utilisation de la formulation affirmative plutôt que négative,
• Mesurable : il doit y avoir un moyen de vérifier l'exigence
• Utile : ne porter que sur les éléments nécessaires au système
• Simple : une seule exigence à la fois
• Traçable : ne pas changer de numéro, historiser les modifications
• Non ambiguës : susceptible de n'avoir qu'une seule interprétation
• Cohérente : ne pas contredire une autre exigence, utiliser le
même vocabulaire
• Réalisable : réaliste quant aux moyens mis en œuvre pour le projet
• Justifiée et précisée par un narratif complémentaire
cc-by-sa Jean-Paul Carmona 8
Exemple d'exigences
• [IMP_33210] Le logiciel doit être performant
o Cette exigence n'est pas assez claire : Que veux dire performant ?
o Quel temps de réponse pour quelle fonctionnalité du logiciel ?
o Avec combien d'utilisateurs ? combien d'appels simultanées ?
o Sur quelles machines serveur, client, et quelle bande passante réseau ?
• [FON_33220] L'IHM du logiciel doit être en anglais et en
francais
o Cette exigence n'est pas simple. Elle est à remplacer par plusieurs exigences :
o [FON_33221] L'IHM du logiciel doit être disponible en anglais
o [FON_33222] L'IHM du logiciel doit être disponible en français
o [FON_33223] L'utilisateur peut changer de langue dans l'IHM, par défaut la langue
fournie par le navigateur web est utilisée
9cc-by-sa Jean-Paul Carmona
Description
d’un cas de test
• Titre du test
• Exigence vérifiée
• Etapes du test :
• Moyens nécessaires aux tests
o Compte utilisateur/mot de passe,
o données en base
o Systèmes externes,
o Bouchons ou simulateur
o Machines, réseaux/proxy
# Description Attendu
1
2
3
Au moins un cas de test par exigence
Cas nominal (normal)
Cas particuliers
10
cc-by-sa Jean-Paul Carmona
Préparer une validation
• Définir une stratégie de validation dans le
cadre du projet
o Moyens mis en œuvre (humain, outils, normes),
o Planning de développement du logiciel
o Définir le nombre de campagnes de test avec pour
chacune d’elle
• l’objectif de la campagne de test
• la version testée et son périmètre fonctionnel
• Identifier les moyens nécessaires aux tests
o Equipe de validation, de développement,
o Jeux de données,
o Simulateurs,
o Environnements
11cc-by-sa Jean-Paul Carmona
Environnements d’un
projet
• Développement(s)
• Intégration
• Validation
• Recette fonctionnelle
• Pré-Production
• Production
MOE
MOA
12cc-by-sa Jean-Paul Carmona
Déroulement d’une
campagne de tests
• Préparation
o Définir la liste des cas de tests
o Ordonner les cas de tests : priorités, dépendances
o Préparer l'environnement : serveur, jeux de données, simulateur
o Répartir des cas de tests entre testeurs : validation croisée
• Bilan quotidien
o Nouvelles anomalies trouvées : priorisation,
o Nouvelle version avec correctifs apportés
• Finir la campagne de tests
o Liste des cas de tests OK/KO/non passés
o Liste des anomalies non corrigées
o Décision de fin de campagne de tests
13cc-by-sa Jean-Paul Carmona
Description d’une
anomalie
Versions
• Bloquante : pas de livraison sans correction
• Majeure : fonctionnalité secondaire ou
solution de contournement
• Mineure : autres anomalies
14
cc-by-sa Jean-Paul Carmona
Cycle de vie d’une
anomalie
15
Types de validation
• Tests unitaires
o Plus une anomalie est découverte tard plus elle coute cher
• Validation fonctionnelle
o Vérification de chaque exigence du cahier des charges
o Ne revalider manuellement que les fonctions impactées par une
nouvelle version
• Tests automatiques
o Permet l’amélioration continue sans craindre les régressions
• Exploitabilité
o Arrêt, redémarrage, surveillance, sauvegarde
• Robustesse : purge, mode dégradé
• Sécurité : durcissement, intégrité, confidentialité
• Performances : nombre utilisateur maxi vs processeur/mémoire
• Migrations de données
• Bascule de système
16cc-by-sa Jean-Paul Carmona
Outils pour la validation
• de gestion des tests
o QualityCenter, SquashTM, Excel, Selenium,
• de gestion des anomalies
o JIRA, BugZilla, Mantis, QualityCenter, Trac, Redmine,
• de gestion de configuration
o Git, Subversion, CVS, SourceSafe
• de campagne de performance
o JMeter, the Grinder, commande linux: top, ps, etc.
• d’analyse de code
o qualité : PMD, Qa-C
o exécution : TPTP
17cc-by-sa Jean-Paul Carmona
Questions ?
18cc-by-sa Jean-Paul Carmona

Contenu connexe

Tendances

La spécification des besoins
La spécification des besoinsLa spécification des besoins
La spécification des besoins
Ismahen Traya
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logiciel
Rabia AZIZA
 

Tendances (20)

Automatisation des tests - objectifs et concepts - partie 1
Automatisation des tests  - objectifs et concepts - partie 1Automatisation des tests  - objectifs et concepts - partie 1
Automatisation des tests - objectifs et concepts - partie 1
 
Guide tests fonctionnels
Guide tests fonctionnelsGuide tests fonctionnels
Guide tests fonctionnels
 
Génie Logiciel : les tests
Génie Logiciel : les testsGénie Logiciel : les tests
Génie Logiciel : les tests
 
Qualité logiciel - Generalités
Qualité logiciel - GeneralitésQualité logiciel - Generalités
Qualité logiciel - Generalités
 
formation istqb.pdf
formation istqb.pdfformation istqb.pdf
formation istqb.pdf
 
Présentation Agile Testing
Présentation Agile TestingPrésentation Agile Testing
Présentation Agile Testing
 
Cours uml
Cours umlCours uml
Cours uml
 
réaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de testréaliser une plateforme d’automatisation et de génération des rapports de test
réaliser une plateforme d’automatisation et de génération des rapports de test
 
Présentation projet de fin d'étude
Présentation projet de fin d'étudePrésentation projet de fin d'étude
Présentation projet de fin d'étude
 
Procédure de contrôle qualité
Procédure de contrôle qualité Procédure de contrôle qualité
Procédure de contrôle qualité
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
 
Présentation PFE: Système de gestion des réclamations et interventions clients
Présentation PFE: Système de gestion des réclamations et interventions clientsPrésentation PFE: Système de gestion des réclamations et interventions clients
Présentation PFE: Système de gestion des réclamations et interventions clients
 
La spécification des besoins
La spécification des besoinsLa spécification des besoins
La spécification des besoins
 
Mémoire - L'automatisation des tests fonctionnels - Emeline Simon
Mémoire - L'automatisation des tests fonctionnels - Emeline SimonMémoire - L'automatisation des tests fonctionnels - Emeline Simon
Mémoire - L'automatisation des tests fonctionnels - Emeline Simon
 
Projet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiqueProjet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatique
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logiciel
 
Présentation PPT CARSELFCARE
 Présentation PPT  CARSELFCARE Présentation PPT  CARSELFCARE
Présentation PPT CARSELFCARE
 
Soutenance mémoire de fin d'études
Soutenance mémoire de fin d'étudesSoutenance mémoire de fin d'études
Soutenance mémoire de fin d'études
 
Rapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XPRapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XP
 
Présentation pfe esprit 2012
Présentation pfe esprit 2012Présentation pfe esprit 2012
Présentation pfe esprit 2012
 

Similaire à Introduction à la validation de logiciel

Université de la performance - Devoxx France
Université de la performance - Devoxx FranceUniversité de la performance - Devoxx France
Université de la performance - Devoxx France
Marc Bojoly
 

Similaire à Introduction à la validation de logiciel (20)

Université de la performance
Université de la performanceUniversité de la performance
Université de la performance
 
Performance ug#1
Performance ug#1Performance ug#1
Performance ug#1
 
Jenkins - Les jeudis de la découverte
Jenkins - Les jeudis de la découverteJenkins - Les jeudis de la découverte
Jenkins - Les jeudis de la découverte
 
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succèsDeux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
 
Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2
 
Test Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teamsTest Driven Development (aka TDD) for agile teams
Test Driven Development (aka TDD) for agile teams
 
Le rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingLe rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testing
 
Tests utilisateurs mon amour (a11y)
Tests utilisateurs mon amour (a11y)Tests utilisateurs mon amour (a11y)
Tests utilisateurs mon amour (a11y)
 
Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...
Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...
Capacity Planning : Pratiques et outils pour regarder la foudre tomber sans p...
 
Hands on Sonar
Hands on SonarHands on Sonar
Hands on Sonar
 
Load test & performance profiling
Load test & performance profilingLoad test & performance profiling
Load test & performance profiling
 
Confoo 2016: Initiation aux tests de charge
Confoo 2016: Initiation aux tests de chargeConfoo 2016: Initiation aux tests de charge
Confoo 2016: Initiation aux tests de charge
 
Université de la performance - Devoxx France
Université de la performance - Devoxx FranceUniversité de la performance - Devoxx France
Université de la performance - Devoxx France
 
Session #2 du workshop sur la performance en environnement de production
Session #2 du workshop sur la performance en environnement de productionSession #2 du workshop sur la performance en environnement de production
Session #2 du workshop sur la performance en environnement de production
 
Presentation test de_charge_jmeter
Presentation test de_charge_jmeterPresentation test de_charge_jmeter
Presentation test de_charge_jmeter
 
Perf university
Perf universityPerf university
Perf university
 
Agile tour 2015 alliés contre les défauts
Agile tour 2015   alliés contre les défautsAgile tour 2015   alliés contre les défauts
Agile tour 2015 alliés contre les défauts
 
Agile tour Lille 2015 allies ensemble contre les defauts
Agile tour Lille 2015 allies ensemble contre les defautsAgile tour Lille 2015 allies ensemble contre les defauts
Agile tour Lille 2015 allies ensemble contre les defauts
 
20151013 - Réduire les coûts des tests de performance ?
20151013 - Réduire les coûts des tests de performance ?20151013 - Réduire les coûts des tests de performance ?
20151013 - Réduire les coûts des tests de performance ?
 
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
 

Plus de Jean-Paul CARMONA (6)

Modèle cas d'utilisation
Modèle cas d'utilisationModèle cas d'utilisation
Modèle cas d'utilisation
 
Cartopartie de fuveau #1
Cartopartie de fuveau #1Cartopartie de fuveau #1
Cartopartie de fuveau #1
 
OpenStreetMap vs GoogleMaps pour développer des services sur Internet
OpenStreetMap vs GoogleMaps pour développer des services sur InternetOpenStreetMap vs GoogleMaps pour développer des services sur Internet
OpenStreetMap vs GoogleMaps pour développer des services sur Internet
 
Objets métier
Objets métierObjets métier
Objets métier
 
Elaborer un logiciel
Elaborer un logicielElaborer un logiciel
Elaborer un logiciel
 
5@7 AtoS Aix - Open Data en PACA
5@7 AtoS Aix - Open Data en PACA5@7 AtoS Aix - Open Data en PACA
5@7 AtoS Aix - Open Data en PACA
 

Dernier

ilide.info-cours-recherche-d-emploi-pr_aa839df7439dd234c803551c86e0197c.pdf
ilide.info-cours-recherche-d-emploi-pr_aa839df7439dd234c803551c86e0197c.pdfilide.info-cours-recherche-d-emploi-pr_aa839df7439dd234c803551c86e0197c.pdf
ilide.info-cours-recherche-d-emploi-pr_aa839df7439dd234c803551c86e0197c.pdf
ssuser6041d32
 

Dernier (16)

Texte avec différentes critiques positives, négatives ou mitigées
Texte avec différentes critiques positives, négatives ou mitigéesTexte avec différentes critiques positives, négatives ou mitigées
Texte avec différentes critiques positives, négatives ou mitigées
 
Chapitre3-Classififcation des structures de chaussu00E9e.pptx
Chapitre3-Classififcation des structures de  chaussu00E9e.pptxChapitre3-Classififcation des structures de  chaussu00E9e.pptx
Chapitre3-Classififcation des structures de chaussu00E9e.pptx
 
Echos libraries Burkina Faso newsletter 2024
Echos libraries Burkina Faso newsletter 2024Echos libraries Burkina Faso newsletter 2024
Echos libraries Burkina Faso newsletter 2024
 
GHASSOUB _Seance 4_ measurement and evaluation in education_-.pptx
GHASSOUB _Seance 4_ measurement and evaluation in education_-.pptxGHASSOUB _Seance 4_ measurement and evaluation in education_-.pptx
GHASSOUB _Seance 4_ measurement and evaluation in education_-.pptx
 
python-Cours Officiel POO Python-m103.pdf
python-Cours Officiel POO Python-m103.pdfpython-Cours Officiel POO Python-m103.pdf
python-Cours Officiel POO Python-m103.pdf
 
Télécommunication et transport .pdfcours
Télécommunication et transport .pdfcoursTélécommunication et transport .pdfcours
Télécommunication et transport .pdfcours
 
Neuvaine de la Pentecôte avec des textes de saint Jean Eudes
Neuvaine de la Pentecôte avec des textes de saint Jean EudesNeuvaine de la Pentecôte avec des textes de saint Jean Eudes
Neuvaine de la Pentecôte avec des textes de saint Jean Eudes
 
CALENDRIER ET COMPTE RENDU REUNION DIRECTION
CALENDRIER ET COMPTE RENDU REUNION DIRECTIONCALENDRIER ET COMPTE RENDU REUNION DIRECTION
CALENDRIER ET COMPTE RENDU REUNION DIRECTION
 
ilide.info-cours-recherche-d-emploi-pr_aa839df7439dd234c803551c86e0197c.pdf
ilide.info-cours-recherche-d-emploi-pr_aa839df7439dd234c803551c86e0197c.pdfilide.info-cours-recherche-d-emploi-pr_aa839df7439dd234c803551c86e0197c.pdf
ilide.info-cours-recherche-d-emploi-pr_aa839df7439dd234c803551c86e0197c.pdf
 
Réunion des directeurs de Jonzac - 15 mai 2024
Réunion des directeurs de Jonzac - 15 mai 2024Réunion des directeurs de Jonzac - 15 mai 2024
Réunion des directeurs de Jonzac - 15 mai 2024
 
Methode 5S - support de formation -.pdf
Methode 5S  - support de formation -.pdfMethode 5S  - support de formation -.pdf
Methode 5S - support de formation -.pdf
 
Fiche de vocabulaire pour faire une appréciation
Fiche de vocabulaire pour faire une appréciationFiche de vocabulaire pour faire une appréciation
Fiche de vocabulaire pour faire une appréciation
 
Les phases d'analyse des parties prenantes
Les phases d'analyse des parties prenantesLes phases d'analyse des parties prenantes
Les phases d'analyse des parties prenantes
 
Saint Damien, missionnaire auprès des lépreux de Molokai, Hawaï.pptx
Saint Damien, missionnaire auprès des lépreux de Molokai, Hawaï.pptxSaint Damien, missionnaire auprès des lépreux de Molokai, Hawaï.pptx
Saint Damien, missionnaire auprès des lépreux de Molokai, Hawaï.pptx
 
GHASSOUB _Seance 3_ measurement and evaluation in education.pptx
GHASSOUB _Seance 3_ measurement and evaluation in education.pptxGHASSOUB _Seance 3_ measurement and evaluation in education.pptx
GHASSOUB _Seance 3_ measurement and evaluation in education.pptx
 
Àma Gloria.pptx Un film tourné au Cap Vert et en France
Àma Gloria.pptx   Un film tourné au Cap Vert et en FranceÀma Gloria.pptx   Un film tourné au Cap Vert et en France
Àma Gloria.pptx Un film tourné au Cap Vert et en France
 

Introduction à la validation de logiciel

  • 1. Validation de logiciel Le contenu de ce document est mis à disposition selon les termes de la Licence Creative Commons Attribution - Partage dans les Mêmes Conditions 3.0 France. 1cc-by-sa Jean-Paul Carmona
  • 2. Sommaire • Pourquoi et comment valider un logiciel • Déroulement d’une campagne de test • Types de validation • Cycle de vie d’une anomalie • Outils pour la validation 2cc-by-sa Jean-Paul Carmona
  • 3. Pourquoi valider un logiciel • Vérifier le bon fonctionnement o Avant livraison au client, coté fournisseur ou MOE o Avant utilisation (ou mise en production), coté client ou MOA • Connaître techniquement le logiciel o Combien d’utilisateurs simultanés ? o Quel temps de réponse ? o Sur quelle configuration l’installer ? Maitrise d'OuvrAge ou client Cahier des charges Conception, Fabrication Maitrise d'OEuvre ou fournisseur ValidationRecette 3cc-by-sa Jean-Paul Carmona
  • 4. & techniques Exigences fonctionnelles & techniques Cas de tests Campagne de test #1 Anomalies Cahier des charges Campagne de testCampagnes de test #3 a b c d e f h i v1 aa bb cc dd ee ff gg hh v3v3 aa bb cc dd ee ff gg hh aa bb cc dd ee ff gg hh Analyse du cahier des charges Spec. générales Spec. détaillées Stratégie de tests Comment valider un logiciel 4cc-by-sa Jean-Paul Carmona
  • 5. Déroulement d’un projet a b c d e f g h Exigences a b e V1_rc1 V2_rc1 Dev. v1 v1 Bugfix v1 / Dev. v2 Valid. v1 2 itérations : V1 et V2 2 équipes : dev. & valid. V1_rc2 bug Prepa. valid. v1 Prepa. valid. v2 Valid. v2 Bugfix v2 V2_rc2 bug Importance de la gestion de configuration a b c d e f g h 5cc-by-sa Jean-Paul Carmona
  • 6. les responsabilités du valideur • Le développeur est responsable du o développement des fonctionnalités o du respect des exigences o de la correction des anomalies • Le validateur est responsable o du bon fonctionnement du logiciel o de la vérification de la correction des anomalies • C'est le valideur qui est en faute si le logiciel livré ne fonctionne pas correctement • Le valideur doit préciser pour chaque version testée o La liste des fonctionnalités et exigences non vérifiées o La liste des anomalies connues et non corrigées o L'infrastructure matérielle et système utilisée pour les tests 6cc-by-sa Jean-Paul Carmona
  • 7. Exigences • Définir les exigences à partir de l'expression de besoins dans le cahier des charges • Identifier chaque exigence avec un numéro unique. • Exemple : o Format “<categorie>_<numero>” o Exemple de catégories: • IHM Interface Homme Machine; FON Fonctionel • PER Performance; DES Design; CU Cas d’Utilisation • IMP Implementation; LIV Livraison; ORG Organisation projet 7cc-by-sa Jean-Paul Carmona
  • 8. Une exigence doit être… • Exprimée en une phrase : o un sujet + « doit » + verbe + complément, o avec utilisation de la formulation affirmative plutôt que négative, • Mesurable : il doit y avoir un moyen de vérifier l'exigence • Utile : ne porter que sur les éléments nécessaires au système • Simple : une seule exigence à la fois • Traçable : ne pas changer de numéro, historiser les modifications • Non ambiguës : susceptible de n'avoir qu'une seule interprétation • Cohérente : ne pas contredire une autre exigence, utiliser le même vocabulaire • Réalisable : réaliste quant aux moyens mis en œuvre pour le projet • Justifiée et précisée par un narratif complémentaire cc-by-sa Jean-Paul Carmona 8
  • 9. Exemple d'exigences • [IMP_33210] Le logiciel doit être performant o Cette exigence n'est pas assez claire : Que veux dire performant ? o Quel temps de réponse pour quelle fonctionnalité du logiciel ? o Avec combien d'utilisateurs ? combien d'appels simultanées ? o Sur quelles machines serveur, client, et quelle bande passante réseau ? • [FON_33220] L'IHM du logiciel doit être en anglais et en francais o Cette exigence n'est pas simple. Elle est à remplacer par plusieurs exigences : o [FON_33221] L'IHM du logiciel doit être disponible en anglais o [FON_33222] L'IHM du logiciel doit être disponible en français o [FON_33223] L'utilisateur peut changer de langue dans l'IHM, par défaut la langue fournie par le navigateur web est utilisée 9cc-by-sa Jean-Paul Carmona
  • 10. Description d’un cas de test • Titre du test • Exigence vérifiée • Etapes du test : • Moyens nécessaires aux tests o Compte utilisateur/mot de passe, o données en base o Systèmes externes, o Bouchons ou simulateur o Machines, réseaux/proxy # Description Attendu 1 2 3 Au moins un cas de test par exigence Cas nominal (normal) Cas particuliers 10 cc-by-sa Jean-Paul Carmona
  • 11. Préparer une validation • Définir une stratégie de validation dans le cadre du projet o Moyens mis en œuvre (humain, outils, normes), o Planning de développement du logiciel o Définir le nombre de campagnes de test avec pour chacune d’elle • l’objectif de la campagne de test • la version testée et son périmètre fonctionnel • Identifier les moyens nécessaires aux tests o Equipe de validation, de développement, o Jeux de données, o Simulateurs, o Environnements 11cc-by-sa Jean-Paul Carmona
  • 12. Environnements d’un projet • Développement(s) • Intégration • Validation • Recette fonctionnelle • Pré-Production • Production MOE MOA 12cc-by-sa Jean-Paul Carmona
  • 13. Déroulement d’une campagne de tests • Préparation o Définir la liste des cas de tests o Ordonner les cas de tests : priorités, dépendances o Préparer l'environnement : serveur, jeux de données, simulateur o Répartir des cas de tests entre testeurs : validation croisée • Bilan quotidien o Nouvelles anomalies trouvées : priorisation, o Nouvelle version avec correctifs apportés • Finir la campagne de tests o Liste des cas de tests OK/KO/non passés o Liste des anomalies non corrigées o Décision de fin de campagne de tests 13cc-by-sa Jean-Paul Carmona
  • 14. Description d’une anomalie Versions • Bloquante : pas de livraison sans correction • Majeure : fonctionnalité secondaire ou solution de contournement • Mineure : autres anomalies 14 cc-by-sa Jean-Paul Carmona
  • 15. Cycle de vie d’une anomalie 15
  • 16. Types de validation • Tests unitaires o Plus une anomalie est découverte tard plus elle coute cher • Validation fonctionnelle o Vérification de chaque exigence du cahier des charges o Ne revalider manuellement que les fonctions impactées par une nouvelle version • Tests automatiques o Permet l’amélioration continue sans craindre les régressions • Exploitabilité o Arrêt, redémarrage, surveillance, sauvegarde • Robustesse : purge, mode dégradé • Sécurité : durcissement, intégrité, confidentialité • Performances : nombre utilisateur maxi vs processeur/mémoire • Migrations de données • Bascule de système 16cc-by-sa Jean-Paul Carmona
  • 17. Outils pour la validation • de gestion des tests o QualityCenter, SquashTM, Excel, Selenium, • de gestion des anomalies o JIRA, BugZilla, Mantis, QualityCenter, Trac, Redmine, • de gestion de configuration o Git, Subversion, CVS, SourceSafe • de campagne de performance o JMeter, the Grinder, commande linux: top, ps, etc. • d’analyse de code o qualité : PMD, Qa-C o exécution : TPTP 17cc-by-sa Jean-Paul Carmona