Validation de
logiciel
Le contenu de ce document est mis à disposition selon les termes de la
Licence Creative Commons Att...
Sommaire
• Pourquoi et comment valider un logiciel
• Déroulement d’une campagne de test
• Types de validation
• Cycle de v...
Pourquoi valider un
logiciel
• Vérifier le bon fonctionnement
o Avant livraison au client, coté fournisseur ou MOE
o Avant...
& techniques
Exigences
fonctionnelles
& techniques
Cas de tests
Campagne de
test #1
Anomalies
Cahier des
charges
Campagne ...
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ération...
les responsabilités
du valideur
• Le développeur est responsable du
o développement des fonctionnalités
o du respect des e...
Exigences
• Définir les exigences à partir de l'expression de besoins
dans le cahier des charges
• Identifier chaque exige...
Une exigence doit être…
• Exprimée en une phrase :
o un sujet + « doit » + verbe + complément,
o avec utilisation de la fo...
Exemple d'exigences
• [IMP_33210] Le logiciel doit être performant
o Cette exigence n'est pas assez claire : Que veux dire...
Description
d’un cas de test
• Titre du test
• Exigence vérifiée
• Etapes du test :
• Moyens nécessaires aux tests
o Compt...
Préparer une validation
• Définir une stratégie de validation dans le
cadre du projet
o Moyens mis en œuvre (humain, outil...
Environnements d’un
projet
• Développement(s)
• Intégration
• Validation
• Recette fonctionnelle
• Pré-Production
• Produc...
Déroulement d’une
campagne de tests
• Préparation
o Définir la liste des cas de tests
o Ordonner les cas de tests : priori...
Description d’une
anomalie
Versions
• Bloquante : pas de livraison sans correction
• Majeure : fonctionnalité secondaire o...
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 fonctionne...
Outils pour la validation
• de gestion des tests
o QualityCenter, SquashTM, Excel, Selenium,
• de gestion des anomalies
o ...
Questions ?
18cc-by-sa Jean-Paul Carmona
Prochain SlideShare
Chargement dans…5
×

Introduction à la validation de logiciel

9 374 vues

Publié le

introduction à la validation de logiciel,
comment valider un logiciel,
les types de validation,
la gestion d'anomalies

Publié dans : Formation
0 commentaire
5 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
9 374
Sur SlideShare
0
Issues des intégrations
0
Intégrations
26
Actions
Partages
0
Téléchargements
287
Commentaires
0
J’aime
5
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Introduction à la validation de logiciel

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. Cycle de vie d’une anomalie 15
  16. 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. 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
  18. 18. Questions ? 18cc-by-sa Jean-Paul Carmona

×