Économie des tests    Stratégie de VVT (Validation Vérification & Test)    ROI de l’effort de test.

Présentation au sujet: "Économie des tests    Stratégie de VVT (Validation Vérification & Test)    ROI de l’effort de test."— Transcription de la présentation:

1 Économie des tests    Stratégie de VVT (Validation Vérification & Test)    ROI de l’effort de test

2 Introduction

3 Les acteurs de la VV&T Parmi les acteurs, il faut distinguer ceux qui introduisent les défauts, et ceux qui recherchent les défauts pour les corriger Le chef de projet Planification des tâches et assurance qualité (système qualité) – Organisation de l’équipe – Mise en œuvre de la stratégie et des méthodes L’architecte du projet (au sens large = expression de besoin, spécification fonctionnelle, conception – implique la MOA et/ou le client) Architecture testable Les programmeurs Conception détaillée et programmation – Composants logiciel {Données+Algorithmes +Contrôles} intégrables (i.e. documentés et testés) Le responsable de l’intégration et son équipe Le responsable de la qualification indépendante et son équipe (Assurance Qualité – Inspections et revues – Recette) Le support et/ou la maintenance de 1er niveau

4 Distribution des défauts
Modèle de données, en particulier interfaces entre les modules, Modèle d’enchaînement/contrôle des fonctions Conception détaillée Revues et Inspections Code source fabriqué par les programmeurs, compilé sans erreur + « debugging » Programmation VVT Tests de couverture et de contrôle 80 à 100 défauts par KLS à l’entrée du processus Le but de la VVT et de l’intégration est la réduction du nombre de défauts au minimum acceptable selon le contrat de service passé avec l’organisation cible Tests fonctionnel à partir des données Tests de performance 5 à 10 défauts par KLS Tests de robustesse Tests de pré-intégration 1 à 2 défauts par KLS à la sortie du processus INTÉGRATION  Si la stratégie VVT est correctement conduite (niveau de maturité élevé : CMM 4/5 + architecture testable + PSP) le nombre de défauts résiduels peut tomber à [ ] par KLS (Source SEI 2001) Installation

5 La chaîne de l’erreur (1/2)
Erreurs humaines Introduction des défauts dans les différentes phases du cycle BESOIN CONCEPTION PROGRAMMATION INSTALLATION MAINTENACE EXPLOITATION Défaillance +/- graves Manifestation d’une défaillance Éventualité d’une panne  grave Défaut dans le logiciel Erreur humaine

6 La chaîne de l’erreur (2/2)
Période de très grand danger pour l’intégrité du système Période d'introduction de défauts d'installation (Actions erronées de l'administrateur) Période d'observation de la défaillance Période d'introduction de défauts d'exploitation (Actions erronées de l'usager) Temps de latence TFin nominal T0 TDébut T1 T2 Fault (exécution du défaut) Failure (constatation de la défaillance) Arrêt du logiciel Installation du logiciel Démarrage du logiciel (début de session) Durée moyenne de bon fonctionnement du logiciel MTTF Durée d’indisponibilité et réparation du logiciel MTTR

7 Caractéristiques de l’activité de test
Spécifier et développer les « bons » tests – élaborer les résultats attendus Classer, organiser et gérer les tests (gestion de configuration) Exécuter les tests dans un environnement ad hoc – Localiser les défauts Analyser les résultats obtenus et diagnostiquer les erreurs commises Rédaction des rapports d’anomalies RA et envoi des RA aux acteurs impliqués

8 Le processus de test Objectif du test
Spécification du programme et/ou des interfaces à tester Spécification du test Résultats et comportements attendus Chargement du programme et de son environnement Scénario du test Résolution du problème Exécution du test Analyse inductive (on vérifie une hypothèse à partir des résultats obtenus) Résultats et comportements observés Diagnostic Comparaison Exploitation Analyse des résultats Analyse déductive (on recherche les causes dans le programme et/ou les interfaces) Résultat Correct Résultat Incorrect Modifications induites Diagnostic Archivage du test et des résultats Dans le test Dans le programme Gestion des configurations Sources +Tests + Documentation État d’avancement des N scénarios de tests Modifs Modifs

9 Objectif de l’effort de tests
Parmi tous les tests possibles, identifier ceux qui sont véritablement pertinents pour le système à tester Objectif et critère de test explicite Pour un coût donné, trouver le maximum de défauts (rentabilité, rendement) NB : Coût = effort humain + outillages + plates-formes Capitaliser ce qui est répétitif et automatiser si le coût de l’automatisation est compatible avec l’économie du système Coût de l’automatisation << Coût humain (projet et/ou coût complet)

10 Considération MOA, MOE, Projet
Pour le maître d’ouvrage qui représente le client, il faut toujours raisonner en coût complet Le MOA doit intégrer dans son analyse économique l’exploitation, le support et la maintenance, en plus du développement – l’investissement test doit être géré comme un livrable du projet Pour le maître d’œuvre et a fortiori le chef de projet, la tendance sera de raisonner en coût projet sur une version du système La vision du MOE est bornée à celle de son projet – Son action s’arrête dès que la recette est prononcée Quand faut-il arrêter les tests Mesure et/ou estimation de la maturité du point de vue de l’usager

11 La perception de l’usager
Défaillances et pannes perturbent plus ou moins fortement le fonctionnement de l’organisation cible Il faut soigneusement distinguer : Le coût de la réparation du point de vue du fournisseur, tel que vu par le chef de projet Le coût de l’interruption de service tel que perçu par l’usager du système Un cas extrême : ARIANE 501 Le rapport de ces deux coûts peut être de plusieurs ordres de grandeur Il est prudent de considérer le début de l’exploitation comme la fin de la VVT projet

12 Estimation de l’effort de test
Le nombre de défauts introduits est une fonction croissante de la taille du référentiel de programmation Documents de conception et volume de code réellement écrit par les programmeurs L’effort de VVT est une fonction croissante de la taille du référentiel de programmation ET du degré d’organisation de ce référentiel, i.e. l’architecture Dans le modèle d’estimation COCOMO, la forme de cette fonction est polynomiale si l’architecture est en couche Cf. J.Printz, Productivité des programmeurs, chez Hermès

13 Équation générale de l’effort
Peut-on justifier la forme de cette équation ? Terme linéaire Terme NON linéaire Dépend de la puissance expressive et du « grain » sémantique du langage + Expérience des acteurs Dépend de la complexité de l’application et de la maturité du processus de développement  est le facteur d’intégration Facteurs d’influences Facteurs de coût Facteurs d’échelle

14 Interprétation des équations COCOMO avec CQFD
Rendement de l’effort VVT exprimé en termes de : Taux de défauts résiduels Disponibilité de l’application ou du système

15 Principes de la VVT

16 Quelques principes VV&T (1/3)
Principe N°1 Tester exhaustivement un logiciel est généralement impossible Phénomènes combinatoires et coûts exponentiels Principe N°2 Tester correctement un logiciel est une tâche difficile qui requiert intelligence, créativité et savoir-faire Choix de stratégies, critères d’arrêt + Connaissance indispensable du contexte d’emploi réel Pièges : croire que c’est simple et facile par rapport à la programmation jugée plus « noble » croire que cela n’exige ni expérience, ni savoir-faire, ni méthodes et qu’il est inutile de planifier cette activité

17 Quelques principes VV&T (2/3)
Principe N°3 L’essence de l’activité de test est la prévention Elle s’applique à toutes les phases du cycle Il est futile de concevoir ce que l’on ne saura pas tester Concept de testabilité à tous les niveaux Principe N°4 Le volume et la nature des tests à effectuer (i.e. l’effort VVT en terme de CQFD) doit s’apprécier en terme de risques que l’emploi du logiciel fait courir à l’organisation cible

18 Quelques principes VV&T (3/3)
Principe N°5 La planification sérieuse de la VVT est indispensable à la maîtrise du projet Chaque tâche du projet a sa propre VVT afin d’éviter l’effet d’avalanche lors de l’intégration Piège : considérer que l’effort de test est une marge de manœuvre Principe N°6 L’évaluation honnête de la qualité exige la présence d’un tiers de confiance (AQ logiciel) indépendant du développement Pièges : 1) croire que le développement est seul juge de son activité ou 2) croire que le jugement de l’AQ est suffisant

19 VV&T et QUALITÉ Qualité VVT
Conformité aux exigences du contrat de service défini par l’organisation cible La qualité est une notion relative (Appréciation du risque  Notion de qualité de service QOS) – Ce qui est acceptable du point de vue usagers VVT Le but des tests est de rendre la qualité « visible » Le ratio de l’effort de VVT est un indicateur de la qualité du logiciel

20 Le cycle système et le cycle de développement
Place de la VVT dans le cycle système

21 Cycle de vie système Faisabilité Définition Développement et MCO
Retrait Prototype Compatibilité ascendante des versions successives Expérimentation Version N°1 Exploitation Réalisation de maquettes Réalisation de prototypes Version N°2 Exploitation N Cycles de Développement – Exploitation - Maintenance Validation fonctionnelle et non fonctionnelle au sens informatique Version N°n Exploitation Dominante MCO Validation fonctionnelle et comportements exigés en termes métier de la cible Dominante développement Projet de migration éventuelle Vérification de la bonne prise en compte des règles architecturales au sein des projets (Revues + Inspections) Grande variété de types de projets selon la nature des activités et « l’age » du système Durée d’un cycle : > ans, mais > 30 pour les grands systèmes technologiques

22 Détail du cycle de développement (1/3)
RETOUR D’EXPÉRIENCE Expression de besoin /Exigences Axe d’évolution Processus de DEVELOPPEMENT Axe d’évolution CdCF-3 Réalisation incrément N°3 CdCF-2 CdCF-1 Réalisation incrément N°2 Réalisation incrément N°1 Qualification Conception Axe d’évolution Documents contractuels : Spécifications techniques de besoin et exigences (fonctionnel et non fonctionnel, en particulier contrat de service pour les usagers en terme d’exigences) Développement Qualification Intégration Fournitures contractuelles : Kit d’installation, paramétrage et règle de calibrage, doc pour le support, doc utilisateur, etc. Garantie Assurance Qualité et contrat de service Déploiement, support et MCO

23 Détail du cycle de développement (2/3)
Mesure de la maturité de l’EB/EC Processus de développement Expression de besoin et exigences comportementales Défauts propagés Défauts ajoutés Défauts détectés EB/EC Conception générale CG Conception détaillée Implémentation CD Programmation et tests unitaires Taux d’erreurs résiduelles acceptable par l’AQ Processus de conception P/TU Intégration (VV&T) Recette Mesure de la maturité (i.e. contrat de service) en exploitation Assurance qualité et activités transverses AQ Nombre de RA/AC VVT Exploitation et support Durée Mesure de la qualité de service

24 Détail du cycle de développement (3/3) Système qualité - Assurance qualité
CCG, DCG CCD, DCD CPTU, DPTU CVVT, DVVT AQ globale centralisée CQFD global du projet CAQ = CAQ/GC + CAQ/CG + CAQ/CD + CAQ/PTU + CAQ/VVT CD P/TU VVT CG CAQ/CG CAQ/CD CAQ/PTU CAQ/VVT Nombre de RA/AC Courbe de maturité Déléguer Contrôler Mesurer Agir Effort La recherche systématique des défauts se fait préventivement dans toutes les phases du cycle de développement

25 Cycle de vie VVT L’activité de VVT débute dès la phase EB/EC Besoin
Conception Plan et objectifs de tests Système Recette TESTS ET VÉRIFICATIONS POUR LA NON RÉGRESSION Développement Plan de tests Modules Intégration Conception des tests Système Recette Intégration Scénarios de tests Modules Intégration Système Cas à tester Recette Résultats des phases concernant l’activité V&V des phases suivantes Recette Installation Scénario de tests Recette Construction de la courbe de maturité Pour toutes les phases : collecte des Rapports d’Anomalies (RA) et des Actions Correctrices (AC) ; traçabilité Cf. ANSI/IEEE Std 1012 Software verification and validation plans ; Std 1059 Guide VVT

26 Métrologie de l’effort de tests
 Amélioration de la qualité d’une version à la suivante Nombre de défauts détectés Maturité potentielle Garantir la non régression lors du passage d’un cycle au suivant Cycle N°3 Maturité réelle Cycle N°2 Cycle N°1  Le « gap » s ’accroît : régression inexorable de la qualité lors du passage d’un cycle au suivant effort de test

27 La vision qualité : impact de la non régression
Scénario N°1 Nombre d’exécution pour N scénarios (1 par module) : Scénario N°2 • • • Axe de progression du passage des scénarios de test Scénario N°i Critère d’arrêt : Tous les scénarios ont été exécutés avec toutes les modifications • • • Scénario N°n Attention aux doublons : plusieurs scénarios détectent le même défaut 

28 Espace méthodologique et maturité de l’activité VVT

29 Modèle qualité FURPSE – Coûts de mise en oeuvre
Caractéristiques qualité Internes et Externes F U R P S E Functionality (Fonctionnalité) Usability (Facilités d’emploi) Reliability (Fiabilité – Sûreté) Efficiency (Performance) Maintenability, Serviceability (Garantie de service, MCO) Portability (Évolutivité) Adéquation des fonctions Précision et fidélité des résultats Interopérabilité Sécurité + Conformité aux exigences fonctionnelles Capacité et facilité de : Compréhension Apprentissage Exploitation Ergonomie IHM du point de vue métier Maturité Tolérance aux pannes Remise en état de marche Temps de réponse et comportement dynamique Utilisation des ressources (mémoire, débit en transactionnel, etc.) Capacité et facilité de : Analyse des défaillances Modification Stabilité (confinement des défaillances) Test (automaticité, non régression, etc.) Capacité et facilité de : Adaptation et évolution Installation des modifications Remplacement Cohabitation + Conformité aux exigences non fonctionnelles (écart mesuré entre le besoin et ce qui est réalisé)  La prise en compte de chacune de ces caractéristiques implique du code à développer ou à acquérir et/ou des tests (vérification et validation) à effectuer

30 Espace méthodologique VV&T
Axe caractéristiques qualité produit (Cf. ISO/CEI 9126) 6 caractéristiques principales FURPSE Caractéristiques de l’environnement système Sécurité, sûreté de fonctionnement, interopérabilité, etc. Axe méthodes VVT Axe méthodologies Cycle système et cycle de développement (Cf. ISO/CEI 12207) Chaque phase a des besoins et des exigences qui lui sont propres Espace de de choix possibles très grand donc risque d’inconsistance et d’incomplétude si la maturité de l’équipe est faible (cf. CMM)

31 Place des méthodes de VVT
Détection des défauts au moyen de : Relectures informelles sur la base de standards Inspections et revues (cf. système qualité) Relectures formelles Preuves par simulation sur la base de modèles explicites Simulation partielles Simulations exhaustives Preuves « mathématiques » par raisonnements explicites Par construction (via des langages ad hoc) Par induction (démonstrations  automatiques Compilation des langages EB/EC CG CD Codage TU IVVT Modules Détection des défauts Par les techniques de tests traditionnelles IVVT Système Recette Exploitation du logiciel Fichier des incidents Enregistrement systématique de tous les incidents au moyen de fiches RA/AC précises + Traces facilitant le diagnostic Ce flux permet la mesure du taux d’erreurs résiduelles

32 Stratégie coopérative MOA – MOE
Nécessité de mise en cohérence des systèmes qualité MOA ET MOE Organisation cible Organisation cible Pilote stratégique MOA Intégration/Recette Pilote EB/EC Pilote Pilote Suivi fournisseur Système qualité MOA Interactions Contrat Contrat MOE Développement Pilote MOE Développement Pilote Système qualité MOE Système qualité MOE La mise en œuvre d’une stratégie gagnant-gagnant dépend de la qualité de la spécification de réalisation ET de la méthodologie d’accompagnement Plus les référentiels sont rigoureux et explicites, meilleures sont les chances de détecter les erreurs et de corriger les défauts

33 Pourquoi une stratégie de test est indispensable
Espace des choix possibles

34 Stratégie de test : les objectifs (1/2)
Un double objectif : Choix N°1 : Augmenter le MTTF  Réduire au maximum le taux d’erreurs résiduelles  Reconfigurer dynamiquement le système sur des états cohérents malgré le non-déterminisme (c’est une compensation des effets de certaines défaillances connues) Choix N°2 : Diminuer le MTTR  Se donner les moyens d’observation des états déterministe du système (élimination systématique des erreurs reproductibles)  Réserver des ressources en quantité suffisante pour les tests « en ligne » En respectant les contraintes de Coût-Délai du projet Comment répartir et organiser l’effort de VVT – Comment choisir

35 Stratégie de test : les moyens (2/2)
Architecture testable Créer les conditions d’observation des états du système que l’on saura interpréter et reproduire pour améliorer le diagnostic Évaluation des caractéristiques non fonctionnelles (i.e. réduire le facteur d’incertitude) Exemples : Déterminer les performances et la fiabilité véritablement souhaitables ; Valider l’ergonomie avec les usagers REELS ; etc. Équilibrage entre : Techniques AQ : revues, inspections, audits, Tests Boîte Noire et tests Boîte Blanche Tests de robustesse et tests d’innocuité/sûreté

36 La vision qualité : répartition de l’effort
Objectifs de test Équilibrage de l’effort de test Programmeur individuel Tests unitaires Test boîte blanche 1 Axe de progression de l’intégration en minimisant les retours arrière Équipe projet Intégration projet 3 Zone grise 2 Équipe système Intégration système Test boîte noire i est un coefficient d’amplification

37 Productivité de l’effort VVT
Nombre de défauts détectés Techniques de TEST (Détection des défauts coûteuse) Techniques REVUES + INSPECTIONS (Détection des défauts peu coûteuse) PERTE Temps / Effort

38 La détection précoce des défauts
Injection de défauts consécutive aux erreurs des acteurs de A Découverte tardive des défauts de A par les acteurs de B Processus A Processus B Livrables de A pour B Remède : Faire en sorte que les acteurs de A découvrent leurs propres erreurs, ou à tout le moins permettent à B de les découvrir plus vite Qualité des livrables

39 Efficacité des revues et inspections (1/2)
Défaut introduits Défauts résiduels pouvant conduire à des défaillances Défauts cumulés • • • • Défauts corrigés à l’aide de tests Coût élevé • EB/EC CG CD P/TU Intégration Phases de développement

40 Efficacité des revues et inspections (2/2)
Total des défauts corrigés à l’aide des revues et des tests Moins de défauts résiduels À effort constant la qualité est améliorée Défauts cumulés • • • Moins de défauts corrigés à l’aide de tests, donc un gain qui compense le coût des revues et inspections Les tests passent plus vite • • EB/EC CG CD P/TU Intégration Phases de développement

41 Influence de la VVT sur la productivité et le rendement de l’organisation de développement
Données économiques

42 L’analyse des données économiques à l’aide de métriques et d’indicateurs
Métriques qualité Coût des corrections Courbes de maturité Facteurs d’amplification des coûts Coûts pour l’usager

43 Management qualité fondée sur la métrologie des flux d’anomalies
INDICATEURS CARACTÉRISTIQUES   Age moyen des RA, Dispersion des RA  Disponibilité (i.e. MTTF, MTTR)  Temps de non régression Rodage Période d'exploitation d'une version du système Besoin Conception Programmation Intégration Développement Maintenance Date début d'exploitation Date fin Flux continu de défaillances découvertes en exploitation Coûts chez l'exploitant : Émission d'un Rapport d'Anomalie. Coûts d'arrêts de l'exploitation. Pertes d'équipements, humaines,… Coûts chez le fournisseur: Constitution d'un dossier d'Erreur (Action Correctrice). Coûts de réparation et de relivraison de tout ou partie du système. Relivraisons Deux modes d'exploitation : 1 à qq. sites (i.e. clé en mains) Nombreux sites (progiciels) —> Doublons Flux de modifications en cours de développement Filtrage  Durée du cycle  Bien distinguer dans le MTTR la part due à la qualité du diagnostic  Taux d’échecs  Courbe de maturité

44 Coût moyen des corrections
Conception Programmation Intégration VVT Coût moyen par phase selon vade-mecum Taux d’erreurs acceptable ??? 40% 20% 40% Ce qui est refait selon vade-mecum 30% 50% 70% Coût moyen des corrections 12% 10% 28%  50%  Domaine de la prévention (amélioration de la productivité)

45 Répartition des temps de correction par défaut
1er Quartile : 8% 2ème-3ème Quartile : 40% 4ème Quartile : 52% Source : Hewlett-Packard

46 Courbes de maturité - Transfert de coût entre les processus
Palier de maturité acceptable (dépend du taux d’erreurs non reproductibles) 1 à 5 Err/KLS selon exigence Pente résiduelle La différence est supportée par l’éditeur du logiciel La différence est supportée par l’usager du logiciel et le MCO 1ère mise en service Temps Développement Exploitation (et plus généralement MCO)

47 Amplification du coût de correction (1/5)
Le coût de traitement d’une erreur dépend fortement du temps de latence (Introduction/Découverte) : Erreur humaine/défaut  Défaillance reproductible Plus le temps de latence est long, plus le coût de la correction est élevé Toute erreur non détectée peut occasionner d’autres erreurs (amplification)  Avec l’augmentation de complexité, seule une stratégie préventive est gagnante

48 Amplification du coût de correction (2/5)
Modèle d'amplification par phase du cycle de développement Prévoir le coût de cette détection dans les tâches du projet Identifier les modules critiques (architecture) ERREURS COMMISES DÉTECTION ERREURS PROPAGÉES EFFICACITÉ DE LA DÉTECTION DANS LA PHASE DÉFAUTS PROVENANT DES PHASES PRÉCÉDENTES Yi ERREURS AMPLIFIÉES DÉFAUTS TRANSMIS À LA PHASE SUIVANTE Yj ERREURS NOUVELLES xj COËFFICIENT D'AMPLIFICATION : #ERR   dépend fortement de l'architecture (interfaces, modularité) l'efficacité de la détection dépend de la documentation, des standards, de l'organisation qualité et de l’expérience de l’équipe de revue (cf. facteurs AEXP et ACAP de COCOMO)

49 Amplification du coût de correction (3/5)
Application du modèle VEST Conformité de la fourniture Conformité de la livraison Pilote de la tâche E T Tâche projet à effectuer S Tâche(s) amont Tâche(s) aval Flux nominal et anomalies imputables à T Flux nominal et demandes de modifications V Validation, vérification, test Par rapport à la FINALITÉ Bilan du processus en terme de productivité - rendement (COQ et CONQ) Tâches d ’assurance qualité permettant de détecter préventivement les défauts et d’éviter leur propagation

50 Amplification du coût de correction (4/5)
Période d’introduction des erreurs Période de détection/correction des défauts au moyen de tests x1 x2 x3 x4 EB/EC CG CD Codage TU IVVT Modules IVVT Système Recette Y1 Y2 Y3 Y4 Construction du référentiel de VVT Scénarios de tests Statistique de répartition des défauts (selon B.Beizer, Software testing techniques) EB/EC : 9% CG : 26% CD : 52% (dont 24% sur les données) Codage : 10% Tests : 3% Potentiel de détection des scénarios de tests fonction du volume de scénarios (fonctionne comme un filtre) Défaillances les + probables Absence de doublon

51 Amplification du coût de correction (5/5)
>  300  150 à 300  50 à 150  10 à 50  4 à 8  2 à 4 EB/EC CdCF-1 Réalisation incrément N°1 Conception Développement Documents contractuels Intégration Déploiement, support et MCO ORIGINE = 1 Fournitures contractuelles

52 Coût pour l’usager (1/2) Coûts de gestion
Émission de RA, installation des corrections, relivraisons, tests de régression, etc. Coûts des interruptions de service Systèmes « clé en main » Possibilité d’impact « catastrophique » selon la criticité du système Exemples : Infrastructures techniques (contrôle aérien, énergie, communications, réseaux bancaires, défense, etc.) Progiciels Existence de contournement selon le niveau de maturité Systèmes d’exploitation, progiciels système (SGBD, Réseaux, etc.), progiciels applicatifs, etc.

53 Coût pour l’usager (2/2) Impact des défaillances en terme de coût
Le coût induit par une erreur est fonction : FRÉQUENCE DE LA DÈFAILLANCE : liée au taux d'erreurs résiduelles, effet de parc (variété/nombre des configurations installées) COÛT DE LA RÉPARATION : dépend de l’architecture du système (par exemple : avec ou sans dispositif de journalisation, avec ou sans gestion de configuration, etc.) COÛT DE LA CORRECTION : très dépendant de l’automatisation des tests (cf. caractéristique de maintenabilité du logiciel) COÛT DE L’INSTALLATION : dépend de l’architecture du système (par exemple : avec ou sans édition de liens dynamique, avec ou sans moniteur de machines virtuelles, etc.) + effet de parc COÛT DE L’INTERRUPTION DE SERVICE : la non disponibilité du système peut induire des pertes qui doivent être comptabilisées (dommages et intérêts)

54 Élaboration et mise en œuvre d’une stratégie de tests

55 Définition Stratégie de VV&T : le problème Techniques de tests
Rentabiliser REVUES et INSPECTIONS Comment produire et ordonnancer les tests de façon à Maximiser la probabilité de découverte d’erreurs intéressantes du point de vue de l’utilisateur Satisfaire au mieux le contrat de service Minimiser la composante CQFD de l’ensemble des activités de VV&T sur l’ensemble du cycle de développement Garantir la qualité de l’assemblage En terme de Disponibilité Capacity Planning et de System Management Rendement du système, COST/EFFECTIVENESS du point de vue du contrat de service Techniques de tests Boite noire Boite blanche

56 Le contexte système du test
Contour flou, surtout si il y a des humains dans la périphérie du système Modalités d’emploi du système Fonction ou ensemble de fonctions à tester e1 e2 e3 • • • en s1 s2 s3 • • • sm La nomenclature de cet ensemble est FONDAMENTALE Contour flou si il y a des progiciels dont le comportement est mal connu d1, d2, d3, ••• , dp Ensemble des variables d’état dont F hérite et qui influent sur F

57 Les objectifs de tests (1/5)
N°1 : Couverture du domaine FONCTION Toutes les fonctions sont exécutées au moins une fois Toutes les régions de code (selon granularité) sont visitées au moins une fois N°2 : Couverture du domaine données ENTRÉES Toutes les entrées sont sollicitées au moins une fois, y compris les limites N°3 : Couverture du domaine données SORTIE Toutes les sorties attendues sont produites au moins une fois N°4 : Couverture du domaine CONTRÔLE et des ENCHAÎNEMENTS Les comportements les plus fréquents sont sollicités au moins une fois Implique une excellente connaissance du contexte d’emploi du système Toutes les exceptions et les messages d’erreurs sont levés au moins une fois

58 Les objectifs de tests (2/5)
FONCTION Échantillonnage raisonnable de la transformation {ei}{sj} Tests de couvertures Influence des variables d’état héritées sur la transformation {ei}{sj} Prise en compte du contexte d ’exécution de la fonction Échantillonnage raisonnable des cas invalides {ei et dk} Valeurs particulières Dépendances fonctionnelles et/ou contraintes sur les {ei et dk} Erreurs spécifiques à la fonction Erreurs fonctionnelles

59 Les objectifs de tests (3/5)
ENTRÉE Analyse systématique de tous les types possibles en entrée MCD, états logiques et/ou physiques des données en entrée Analyse systématique de toutes les bornes des domaines de validité des données 3 valeurs par borne : =, > et < (y compris les combinaisons) Analyse systématique de toutes les situations conduisant à un overflow Dépassement de capacité des ressources allouées à la fonction compte tenu des données en entrée Impact des interruptions possibles File d ’attente d ’événements pris en compte par la fonction ; saturation des files, etc. Effet « cache » ; saturation du cache, etc. Robustesse (Données incomplètes et/ou fausses) Innocuité : la réponse fausse ne dégrade pas l’environnement de F

60 Les objectifs de tests (4/5)
SORTIE Analyse systématique de tous les types possibles en sortie MCD, états logiques et/ou physiques des données en SORTIE Édition de tous les diagnostics, de tous les message d’erreurs Analyse systématique de tous les types possibles de rapports et/ou fichiers créés par la fonction Y compris les états incomplets et/ou faux Non altération des données qui ne font que transiter par la fonction Non propagation des contaminations (confinement et latence) Analyse systématique de tous les modes de terminaison possibles et des cas de reprises qui leur sont associés Cas des arrêts sur événements inopinés et/ou générés par l’opérateur ou l’environnement

61 Les objectifs de tests (5/5)
CONTRÔLE et ENCHAINEMENTS Analyse systématique de scénarios d’emploi de la fonction jugés significatifs pour le contrat de service Tests de chemins Analyse raisonnable de scénarios catastrophes Prévention des risques décrits dans le contrat de service Non propagation des défaillances Analyse raisonnable de combinatoires {ei et dk} du point de vue contrôle Chemins anormaux devant conduire à une erreur, latence, etc. Erreurs dues aux conditions d’entrée Analyse raisonnable de combinatoires {sj et dk} du point de vue contrôle Erreurs dues à l’environnement (matérialisée par dk)

62 Logique d’intégration et ingénierie système (1/2)
Identifier le(s) chemin(s) d’intégration optimum de l’application selon le critère CQFD Maturité des composants élémentaires et des interfaces critiques (à intégrer le plus tôt possible) Les plus fréquemment utilisés du point de vue du contrat de service Identification des chaînes fonctionnelles longues i.e. ossature du système Croissance incrémentale par ajouts successifs pour les composants basiques des chaînes longues Construire des « intégrats » permettant d’éviter le recours trop systématique à la simulation équilibrage entre simulation vs contexte et environnement de tests La simulation est remplacée par un contexte spécifique ad hoc (jeté en fin de test)

63 Logique d’intégration et ingénierie système (2/2)
Répertorier les dépendances fonctionnelles de l’application vis à vis des COTS et de l’environnement système Encapsulation systématique et/ou homologation préalable des COTS IHM interactive et/ou disposant d ’un mode commande Prise en compte des coûts de non régression Mise en œuvre des 4 principes d’intégration Activation, Séparation, Observation, Terminaison

64 Attributs indispensables d’un intégrat
Exigences fonctionnelles et non fonctionnelles prises en compte (FURPSE) + Traçabilité des exigences Documentation de maintenance Documentation d’exploitation Documentation de support Est documenté par : Liste des inspections et des revues effectuées Liste des tests + modalités Est vérifié par : Intégrat Liste des inspections et des revues effectuées Liste des tests+ modalités Est validé par : Demandes de modifications : Prises en compte En attente Refusées Gestion des activités Traçabilité inverse Rôle des acteurs selon modalités CRUD étendues (modalités de déploiement et d’exécution – Ressources utilisées) Est géré par :

65 Stratégie d’intégration Construction d’une chaîne d’intégrats satisfaisant VEST
Initialisation Pré-intégration de I1 et I2 prédécesseurs de I3, I4 et I5 Stimulus en entrée Intégrat-I1 Activation de I3 Le système est initialisé (éventuellement par simulation) pour atteindre les intégrats I3, I4 et I5 I1/I2 Intégrat-I2 Observation des états successifs des transformations effectuées par les intégrats I2/I3 Séparation défaut/défaillance Intégrat-I3 Défaut diagnostiqué dans I2 I3/I4 Intégrat-I4 Problème des défauts diffus dans plusieurs intégrats Terminaison selon critères VEST I4/I5 Intégrat-I5 Réponse en sortie Défaillance constatée dans I4 Le système fournit les résultats attendus (nominal ou non nominal)

66 Stratégie de l’effort de test
Construction de la matrice du jeu Actions possibles Situations possibles  L’analyse des situations se fait par rapport au but fixé dans le contrat de service, en fonction de l’évolution des courbes de maturité

67 Aperçu sur l’intégration des systèmes informatisés
Aspect logiciel de l’intégration

68 Interactions dans le processus d’intégration (Norme ISO 12207)
System requirements analysis Software requirements analysis Software detailed design System architecture design Software architecture design Software coding and testing Remontée de faits techniques et de rapports d’anomalies à analyser par les acteurs de l’ingénierie Conformité VEST System integration Software integration Software installation System qualification testing Software qualification testing Software acceptance support Conformité VEST Livraison du système aux Usagers cible + MCO Ensemble d’activités IVVT Intégration, Vérification, Validation et Test

69 Le procédé de construction
Intégrats rejetés Livraison partielle pour démarrer la recette finale en parallèle Flux d’intégrats Satisfaisant les critères VEST Intégration Système et Logicielle Test de Qualification et Acceptance Exécution des tests avec des intégrats bouchonnés Identifications des acteurs concernés par le RA RA et FT Flux de rapports d’anomalie RA (+ faits techniques irréfutables) concernant les intégrats sous test

70 La machine à intégrer (chaîne de montage) – Assemblage des intégrats
Système satisfaisant aux critères qualité spécifiés dans le cahier des charges Intégrat-1.1 . . . . . . Intégrats de rang 0 issu du développement et satisfaisant les critères VEST Intégrats de rang 1 issu de l’étage N°1 et satisfaisant les critères VEST Étage d’Intégration N°1 Étage d’Intégration N°2 Étage d’Intégration final Intégrat Système Intégrat final satisfaisant les critères VEST . . . Scénarios étage N°1 Scénarios étage N°2 Scénarios final . . . Intégrat-1.m Anomalies Anomalies Anomalies Intégrat-n Diagnostic Diagnostic Diagnostic Retour arrière si les critères ne sont pas satisfaits et/ou découvertes d’anomalies nécessitant une correction dans un intégrat de rang 0 ; re-examens des différents scénarios qui on laissé passer l’erreur

71 Construction progressive de la configuration livrée
Règles de recherche des éléments à intégrer Livrables des programmeurs Éléments complets vérifiés et validés Génération des sources Compilation Édition de liens Éléments complets partiellement vérifiés et validés par l’intégration Éléments complets livrés par l’ingénierie Binaire exécutable Essais avec les scénarios de tests Éléments incomplets livré par l’ingénierie Livraisons de l’ingénierie Livrés par l’ingénierie ou réalisé par l’intégration Bouchons + Éléments temporaires simulés L’organisation de la bibliothèque est en relation duale avec l’organisation du projet ; c’est un aspect fondamental de l’ingénierie projet