Introduction à la validation de logiciel

Validation de logiciel

Le contenu de ce document est mis à disposition selon les termes de laLicence 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


Pourquoi valider un logiciel

• Vérifier le bon fonctionnemento Avant livraison au client, coté fournisseur ou MOE

o Avant utilisation (ou mise en production), coté client ou MOA

• Connaître techniquement le logicielo Combien d’utilisateurs simultanés ?

o Quel temps de réponse ?

o Sur quelle configuration l’installer ? Maitrise d'OuvrAgeou client

Cahier descharges

Conception,Fabrication

Maitrise d'OEuvreou fournisseur

ValidationRecette


& techniques

Exigencesfonctionnelles& techniques

Cas de tests

Campagne detest #1

Anomalies

Cahier des charges

Campagne detestCampagnes detest #3

abcdefhi

v1 aabbccddeeffgghh

v3v3

aabbccddeeffgghh

aabbccddeeffgghh

Analyse du cahier des charges

Spec. générales

Spec. détaillées

Stratégie detests

Comment validerun logiciel


Déroulement d’un projet

abcdefgh

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. v2Valid. v2

Bugfix v2

V2_rc2bug

Importance de la gestion de configuration

abcdefgh


les responsabilités du valideur

• Le développeur est responsable duo 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 sile logiciel livré ne fonctionne pas correctement

• Le valideur doit préciser pour chaque version testéeo 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


Exigences• Définir les exigences à partir de l'expression de besoinsdans 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


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 francaiso 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


Description d’un cas de test

• Titre du test• Exigence vérifiée• Etapes du test :

• Moyens nécessaires aux testso Compte utilisateur/mot de passe, o données en baseo Systèmes externes, o Bouchons ou simulateuro Machines, réseaux/proxy

# Description Attendu

1

2

3

Au moins un cas de test par exigenceCas nominal (normal)Cas particuliers


Préparer une validation• Définir une stratégie de validation dans le cadre du projeto 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


Environnements d’un projet

• Développement(s) • Intégration• Validation

• Recette fonctionnelle• Pré-Production• Production

MOE

MOA


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


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 chargeso Ne revalider manuellement que les fonctions impactées par une nouvelle version

• Tests automatiqueso 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 tests

o QualityCenter, SquashTM, Excel, Selenium,

• de gestion des anomalieso JIRA, BugZilla, Mantis, QualityCenter, Trac, Redmine,

• de gestion de configurationo Git, Subversion, CVS, SourceSafe

• de campagne de performanceo JMeter, the Grinder, commande linux: top, ps, etc.

• d’analyse de codeo qualité : PMD, Qa-C

o exécution : TPTP


Questions ?


Education

Introduction à la validation de logiciel