Validation de logiciel

Présentation au sujet: "Validation de logiciel"— Transcription de la présentation:

1 Validation de logiciel

2 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 Exemples Il y aura une évaluation par QCM pour le cours "environnement informatique" La validation de logiciel est un secteur qui embauche

3 Pourquoi valider un logiciel
Vérifier le bon fonctionnement Avant livraison au client (coté MOE) Avant mise en production (coté MOA) Connaître techniquement le logiciel Combien d’utilisateurs simultanés ? Quel temps de réponse ? Sur quelle configuration l’installer ? Exemple de la livraison et de la réception d’une piscine

4 Exigences fonctionnelles & techniques
Du cahier des charges aux anomalies Cahier des charges Analyse du cahier des charges a b c d e f h i a b c d e f h i Exigences fonctionnelles & techniques Cas de tests Spec. générales Spec. détaillées Stratégie de tests Quel moyens (outils, personnes, environnements) planning de campagnes de tests (version testée, objectifs) Types de tests prévus Montrer un cahier des charges Montrer une spécification générale Montrer l’excel pour une campagne de test Montrer les écrans de Test Director et les documents générés : dossier de test, bilan de campagne Stratégie de tests a b c d e f h i v1 a b c d e f h i v3 Anomalies Campagne de test #1 Campagne de test Campagnes de test #3

5 Du cahier des charges à la validation
Ces slides expliquent pourquoi le valideur doit valider d'abord les spécifications et les exigences Ce que le client a expliqué Ce que l’architecte à conçu Ce que l’analyste à spécifié

6 Ce que le client va recetter
Ce que le développeur a fait Ce que le testeur va valider

7 Responsabilité Le développeur est responsable du
développement de la correction des anomalies Le validateur est responsable du bon fonctionnement du logiciel 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ée La liste des fonctionnalités non testées La liste des anomalies connues et non corrigées L'infrastructure matérielle et système utilisée pour les tests Il est utile de décrire l'infrastructure matérielle et logicielle pour indiquer qu'il ne s'agit pas de tests de performance

8 Démarches de projets Cycle en V Cycle en itérarif
Un cycle en V qui dure plus de 3 mois à un risque d’effet tunnel La validation se fait en interne par la maitrise d’oeuvre La recette se fait en externe par la maitrise d’ouvrage Question : quelle est la première chose que le testeur va valider ? Cycle en V Cycle en itérarif

9 Exigences Définir les exigences à partir du cahier des charges Identifier chaque exigence avec un numéro unique. Exemple : Format “<categorie>_<numero>” 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) Montrer un exemple de spécification générale avec des exigences Simple : une seul exigence à la fois Traçable : liens vers le cahier des charges, lien vers les cas de tests Conseils : Numéroter de 10 en 10 pour pouvoir en insérer ensuite Utiliser les numéros de chapitres / sous-chapire (§1.1.3 = ) Ne jamais changer l’id d’exigence même si la catégorie change ou l’ordre d’apparition change

10 Exemple d'exigences [IMP_33210] Le logiciel doit être performant
Cette éxigence n'est pas assez claire : Que veux dire performant ? quel temps de réponse pour quelle fonctionnalité du logiciel ? Avec combien d'utilisateurs et de transactions simultanées ? Sur quelles machines serveur, client, et quelle bande passante réseau ? [FON_33220] L'IHM du logiciel doit être en anglais et en francais Plusieurs exigences en une, à remplacer par : [FON_33221] L'IHM du logiciel doit être disponible en anglais [FON_33222] L'IHM du logiciel doit être disponible en français [FON_33223] L'utilisateur peut changer de langue dans l'IHM, par défaut la langue fournie par le navigateur web est utilisée

11 Description d’un cas de test
Titre du test Moyens nécessaires aux tests Compte utilisateur/mot de passe, données en base Systèmes externes, Bouchons ou simulateur Machines, réseaux/proxy Etapes du test : # Description Attendu 1 2

12 Organisation des cas de tests
Au moins un cas de test par exigence Cas nominal (normal) Cas particulier Cas aux limites Rattacher chaque cas de test à au moins une exigences Suivre le modèle de description des cas de test ci-avant Ajouter des étapes pour faciliter le déroulement de cas de test complexes

13 Préparer une validation
Définir une stratégie de validation dans le cadre du projet Moyens mis en oeuvre (humain, outils, normes), Planning de développement du logiciel 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 Equipe de validation, de développement, Environnements, Jeux de données, Simulateurs

14 Déroulement d’une campagne de tests
Préparation Définir la liste des cas de tests Ordonner les cas de tests : priorités, dépendances Préparer l'environnement : serveur, jeux de données, simulateur Répartir des cas de tests entre testeurs : validation croisée Bilan quotidien Nouvelles anomalies trouvées : priorisation, Nouvelle version avec correctifs apportés Finir la campagne de tests Liste des cas de tests OK/KO/non passés Liste des anomalies non corrigées Décision de fin de campagne de tests Finir avec "quelle stratégie de test ?" : combien de campagne de tests ? à partir de quelles exigences ?

15 Déroulement d’un projet
2 itérations : V1 et V2 2 équipes : dev. & valid. Importance de la gestion de configuration Exigences V2_rc1 V1_rc1 Dev. v1 Bugfix v1 / Dev. v2 Bugfix v2 v1 a a a V1_rc2 V2_rc2 b b b bug bug c c d Prepa. valid. v1 Valid. v1 d Prepa. valid. v2 Valid. v2 e e e f f h h i i

16 Environnements d’un projet
MOE Développement(s) Intégration Validation MOA Recette fonctionnelle Pré-Production Production Intégration : création de version Pré-production: Recette technique de performance Recette technique d’exploitation

17 Description d’une anomalie
Versions Bloquante : pas de livraison sans correction Majeure : fonctionnalité secondaire ou solution de contournement Mineure : autres anomalies

18 Cycle de vie d’une anomalie

19 Typologies de validation
Tests unitaires Plus une anomalie est découverte tard plus elle coute cher Validation fonctionnelle Vérification de chaque exigence du cahier des charges Ne revalider manuellement que les fonctions impactées par une nouvelle version Tests automatiques Permet l’amélioration continue sans craindre les régressions Exploitabilité 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 Preuve que c'est un secteur qui embauche Parler de OWASP pour la sécurité Démonstration de : Tests de performance avec Jmeter Bilan d’une campagne de performances Démonstration Selenium pour les tests de non régression Présentation d’Eclipse TPTP pour l’analyse de l’exécution du code

20 Outils pour la validation
de gestion des tests QualityCenter, SquashTM, Excel, Selenium, de gestion des anomalies JIRA, BugZilla, Mantis, QualityCenter, Trac, Redmine, de gestion de configuration Git, SubVersion, CVS, SourceSafe de campagne de performance JMeter, the Grinder, commande linux: top, ps, etc. d’analyse de code qualité : PMD, Qa-C exécution : TPTP

21 Questions ?