Upload
catherine-delannoy
View
144
Download
9
Embed Size (px)
Citation preview
Validation de logiciel
Sommaire• Pourquoi et comment valider un logiciel• Déroulement d’une campagne de test• Typologies de validation• Cycle de vie d’une anomalie• Outils pour la validation
Exe
mp
les
Pourquoi valider un logiciel
• Vérifier le bon fonctionnemento Avant livraison au client (coté MOE)o Avant mise en production (coté MOA)
• Connaître techniquement le logicielo Combien d’utilisateurs simultanés ?o Quel temps de réponse ?o Sur quelle configuration l’installer ?
Exigencesfonctionnelles& techniques
Cas de tests
Campagne detest #1
Anomalies
Cahier des charges
Du cahier des chargesaux anomalies
Campagne detestCampagnes detest #3
abcdefhi
v1 abcdefhi
v3
abcdefhi
abcdefhi
Analyse du cahier des charges
Spec. générales
Spec. détaillées
Stratégie detests
Du cahier des charges à la validation
Ce que le client a expliqué
Ce que l’analyste à spécifié
Ce que l’architecte à conçu
Ce que le développeur a fait Ce que le client va recetter
Ce que le testeur va valider
Responsabilité• Le développeur est responsable du
o développemento de la correction des anomalies
• Le validateur est responsable o du bon fonctionnement du logicielo de la vérification de la correction des anomalies
• C'est le valideur qui est en faute si le logiciel livré ne fonctionne pas
• Il doit préciser pour chaque version testéeo La liste des fonctionnalités non testéeso La liste des anomalies connues et non corrigéeso L'infrastructure matérielle et système utilisée pour les tests
Démarches de projets
8
Cycle en V
Cycle en itérarif
Exigences• Définir les exigences à partir du cahier des charges • Identifier chaque exigence avec un numéro unique.
• Exemple :o Format “<categorie>_<numero>”o Exemple de catégories:
• IHM Interface Home Machine; FON Fonctionel• PER Performance; DES Design; CU Cas d’Utilisation• IMP Implementation; LIV Livraison; ORG Organisation projet
• Les exigences doivent être MUST (Mesurable, Utile, Simple, Traçable)
Exemple d'exigences• [IMP_33210] Le logiciel doit être performant
o Cette éxigence 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 et de transactions 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 francaiso Plusieurs exigences en une, à remplacer par :o [FON_33221] L'IHM du logiciel doit être disponible en anglaiso [FON_33222] L'IHM du logiciel doit être disponible en françaiso [FON_33223] L'utilisateur peut changer de langue dans l'IHM, par
défaut la langue fournie par le navigateur web est utilisée
Description d’un cas de test
• Titre du test• Moyens nécessaires aux tests
o Compte utilisateur/mot de passe, o données en baseo Systèmes externes, o Bouchons ou simulateuro Machines, réseaux/proxy
• Etapes du test :
# Description Attendu
1
2
Organisation des cas de tests
o Au moins un cas de test par exigence• Cas nominal (normal)• Cas particulier• Cas aux limites
o Rattacher chaque cas de test à au moins une exigences
o Suivre le modèle de description des cas de test ci-avant
o Ajouter des étapes pour faciliter le déroulement de cas de test complexes
Préparer une validation
• Définir une stratégie de validation dans le cadre du projeto Moyens mis en oeuvre (humain, outils, normes), o Planning de développement du logicielo Définir le nombre de campagnes de test avec pour
chacune d’elles• 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 Environnements, o Jeux de données,o Simulateurs
Déroulement d’une campagne de tests
• Préparationo Définir la liste des cas de testso Ordonner les cas de tests : priorités, dépendanceso Préparer l'environnement : serveur, jeux de données,
simulateuro Répartir des cas de tests entre testeurs : validation croisée
• Bilan quotidieno Nouvelles anomalies trouvées : priorisation, o Nouvelle version avec correctifs apportés
• Finir la campagne de testso Liste des cas de tests OK/KO/non passéso Liste des anomalies non corrigéeso Décision de fin de campagne de tests
Déroulement d’un projet
abcdefhi
Exigences
ab
e
V1_rc1 V2_rc1Dev. v1
v1
Bugfix v1 / Dev. v2
Valid. v1
2 itérations : V1 et V22 équipes : dev. & valid.
V1_rc2bug
Prepa.valid. v1
Prepa.valid. v2
Valid. v2
Bugfix v2
V2_rc2bug
Importance de la gestion de configuration
abcdefhi
Environnements d’un projet
• Développement(s)
• Intégration• Validation
• Recette fonctionnelle
• Pré-Production• Production
MOE
MOA
Description d’une anomalie
Versions• Bloquante : pas de livraison sans
correction• Majeure : fonctionnalité secondaire
ou solution de contournement• Mineure : autres anomalies
Cycle de vie d’une anomalie
Typologies de validation
• Tests unitaireso Plus une anomalie est découverte tard plus elle coute cher
• Validation fonctionnelleo Vérification de chaque exigence du cahier des chargeso 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
Outils pour la validation
• de gestion des testso QualityCenter, SquashTM, Excel, Selenium,
• de gestion des anomalieso 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-Co exécution : TPTP
Questions ?