VALIDATION VÉRIFICATION & TESTS

VALIDATION VÉRIFICATION & TESTS DÉFINITIONS ET CONCEPTS DE BASE

ACTIVITÉ DE TESTS vs CYCLE DE VIE • LA RECHERCHE DES DÉFAUTS • Relectures et raisonnements sur les différents textes issus du cycle de développement au moyen de revues et d'inspections en vue d'en détecter les défauts. • LE TEST IMPLIQUE UNE EXECUTION SUR MACHINE • C’est un protocole expérimental au sens fort du terme • TESTS PREPARÉS A L'AVANCE • Scénarios construits puis exécutés permettant de vérifier ou valider une hypothèse de bon ou mauvais fonctionnement. • TESTS INOPINÉS • Exécutions défectueuses qui révèlent un défaut de fonctionnement

DONNÉES STATISTIQUES • Sources : • Classification et fréquence (Source B.Beizer, 1990) • Microsoft (étude M.Cusumano, R.Selby) • Productivité (B.Boehm)

Statistique B.Beizer • Source : B.Beizer, Software testing techniques (1990) 

Microsoft

Statistique B.Boehm

Découverte 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 Inspections • Code source fabriqué par les programmeurs, compilé sans erreur Programmation • Réduction du nombre de défauts au minimum acceptable selon le contrat de service VVT Tests de couverture et de contrôle • 80 à 100 défauts par KLS Tests fonctionnel à partir des données Tests de performance Tests de robustesse • 5 à 10 défauts par KLS Tests de pré-intégration • 1 à 2 défauts par KLS 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 à [0.5-0.3] par KLS (Source SEI 2001) Installation

QUELQUES DÉFINITIONS ET TERMES COURANTS • Tester • Preuve • Vérification • Validation • Certification • Mise au point (« Debugging ») • Tests unitaires • Tests de composants/éléments (fonction externe visible) • Tests de produits (ensemble de fonctions) • Tests de systèmes (ensemble de fonctions + un environnement réel) • Tests d'intégration (pour produits et/ou systèmes) • Tests d'acceptance ou de recette • Tests d'installation • Tests avec simulation • « Field » tests (tests sur sites clients)

CYCLE DE DÉVELOPPEMENT DES TESTS Objectif du test Spécification du programme à tester Spécification du test Scénario du test Chargement du programme et de son environnement Résultats et comportements attendus Exécution du test Analyse inductive (on vérifie une hypothèse à partir des résultats obtenus) Résultats effectifs Comparaison Exploitation Analyse des résultats Analyse déductive (on recherche les causes dans le programme) Modifications induites Correct Incorrect Archivage du test et des résultats Dans le test Dans le programme Gestion des configurations Sources +Tests Bibliothèque des tests

RAPPEL SUR LES RAISONNEMENTS INDUCTIFS ET DÉDUCTIFS • Exemple : démonstration de la formule • Méthode par récurrence • Méthode géométrique ou par détection de l’invariant

MISE AU POINT INDUCTIVE • Méthode expérimentale : on observe pour mieux caractériser la défaillance et localiser précisément le défaut et sa cause Rechercher les cas semblables qui ne présentent pas l'anomalie. Localiser toutes les données pertinentes On rassemble les cas particuliers pour généraliser et faire ressortir les contradictions. On passe d ’une représentation en extension à une représentation en intention. Organiser les données Etudier les relations et dépendances fonctionnelles entre les données Données insuffisantes On construit une mini-théorie qui explique complètement l'anomalie. Si plusieurs théories sont possibles, on commence par la plus simple. Formuler une hypothèse Inconsistance et/ou incomplétude Prouver/démontrer l'hypothèse On doit démontrer la consistance et la complétude de la théorie sélectionnée avant de se lancer dans une correction. Corriger le défaut

MISE AU POINT DÉDUCTIVE • Méthode logico-mathématique : on reconstruit la région de programme supposée contenir le défaut à partir de nouvelles hypothèses et on valide Les hypothèses et théories correspondantes vont permettre de structurer et analyser les données à partir desquelles on va reconstruire le code supposé fautif (i.e.une 2ème version). Enumérer toutes les causes possibles de l'anomalie Rassembler plus de données Si toutes les hypothèses et théories sont éliminées, il faut plus de données. Elimination progressive de toutes les causes sauf une A partir des renseignements et indices disponibles, on construit une mini-théorie. C’est une reconstruction de la partie du programme jugée fautive. Améliorer et affiner l'hypothèse Inconsistance et/ou incomplétude Prouver/démontrer l'hypothèse On doit démontrer la consistance et la complétude de la théorie sélectionnée avant de se lancer dans une correction. Corriger le défaut

TYPOLOGIE DES TESTS • TESTS BOITE NOIRE • On ignore volontairement les détails de l'implémentation • Validation par rapport aux spécifications • TESTS BOITE BLANCHE • On prend en compte les détails de l'implémentation • Vérification de la logique d'une implémentation

PROCESSUS DE TESTS D’UN PROGRAMME VERIFICATION Programme source Analyseur statique Compilateur Profils Tests VALIDATION Programme binaire Exécution Métrologie Analyseur dynamique Résultats Surveillance (en ligne)

NATURE DE L'INFORMATION UTILISÉE POUR LES TESTS Élément ou Composant à Tester n Résultats m Paramètres en entrée Environnement x1 y1 x2 y2 • • • x3 • • • yn xm Granularité de la description Bord de l'élément : Pré-conditions + Post-conditions Configuration externe de l'élément à tester : Ensembles + Relations Configuration interne de l'élément à tester : Graphes de contrôle + Graphes de données

OBJECTIF DE L'EFFORT DE TESTS • SUR UN GRAND PROJET OU SUR DES PROJETS SYSTÈMES (Contrôle, Concurrence, Communication) LES TESTS REPRÉSENTENT SOUVENT > 50% DE L'EFFORT.IL FAUT RENDRE CET EFFORT LE PLUS PRODUCTIF POSSIBLE. • TROUVER LE PLUS D'ERREURS PERTINENTES • DIAGNOSTIQUER LES ERREURS RAPIDEMENT • CORRIGER LES PROGRAMMES ET/OU LES TESTS • SANS DEPLACER LES ERREURS • S'ASSURER DES TESTS DEJA EFFECTUES • DEFINIR UN CRITÈRE D'ARRET SUR DES BASES ÉCONOMIQUES • COÛT DES TESTS vs COÛT DES DÉFAILLANCES SYSTÈMES (Évaluation des risques)

OBJECTIF DE TESTS et ENSEMBLE GENERATEUR  ON RECHERCHE L'EXHAUSTIVITÉ DANS UNE CLASSE DE TEST DONNÉE QUI CONSTITUE L’OBJECTIF DE TEST • Espace des cas possibles : Ecp • TOUS LES CHEMINS possibles induits par la combinatoire des paramètres d'entrée et le mode de construction du système • Espace générateur : Eg • CERTAINS CHEMINS convenablement sélectionnés • Propriété recherchée : SI Eg est couvert ALORS la probabilité d'unedéfaillance dans Ecp (mesurée par un MTTF) est < à une limite fixéeà l'avance. • Difficulté : Faire que Eg soit à la fois : • Pertinent  Identification d'une classe de tests «intéressante» • Consistant et Complet  par rapport à la réalité (sémantique)

CONSTRUCTION DE L'ENSEMBLE GÉNÉRATEUR • CRITÈRES DE CONSTRUCTION • DIFFÉRENTS NIVEAUX DE COUVERTURES SELON LA FRÉQUENCE D'EMPLOI ET/OU LA CRITICITÉ DE L'ÉLÉMENT • CONDITIONS DE «BORD» SUR LES DONNÉES DES DOMAINES D'ENTRÈES ET/OU DE SORTIES • NOTION DE CONTRAINTES PERTINENTES PERMETTANT DE DÉTERMINER L'ENSEMBLE DES DONNÉES QUI SONT AU VOISINAGE DU BORD • CONDITIONS D'OBSERVATION DU COMPORTEMENT DE L'ÉLÉMENT • RÉSULTATS INTERMÉDIAIRES INTÉRESSANTS • CONSOMMATION DES RESSOURCES CRITIQUES (TEMPS, MÉMOIRE, I/O,…)

MÉTROLOGIE • FICHES D'ENREGISTREMENT POUR TOUTES LES ERREURS ET LES CORRECTIONS CORRESPONDANTES • SURVEILLANCE DU NOMBRE ET DE LA RÉPARTITION DES ERREURS A PARTIR DE L'INTÉGRATION • MTTF • MTTR • DISPONIBILITÉ • NOMBRE D'ERREURS CUMULÉES ET DENSITÉ D'ERREURS • COUT MOYEN PAR ERREUR EXTRAITE • NORMALISATION DES MESURES

CINÉMATIQUE ET DYNAMIQUE DE L'EFFORT • CINÉMATIQUE • VITESSE D'ÉCRITURE DES TESTS • Documentation, "driver", "stub' • VITESSE D'EXÉCUTION DES TESTS • Temps machine, puissance des matériels, niveau d'automatisme • VITESSE D'OBTENTION DES CORRECTIONS • Pertinence des données associées à l'anomalie, gestion des configurations • Organisation (Support, Maintenance, Qualification) • DYNAMIQUE • CE QUI FAIT VARIER LA VITESSE • Suite de tests: T1, T2, ..., Tx, Tn Pour vérifier la progression avec Tx il faut repasser les lots T1, T2, ..., Tx-1 • Archiver tests et résultats + comparaison automatique • Décélération inéluctable • Effort réparti entre: Ecriture des tests et Analyse des résultats des tests • Courbes d'effort en S • Age du système IMPORTANCE DES PARAMÈTRES INDIVIDUELS ET ORGANISATIONNELS

FONDEMENTS THÉORIQUES • COMBINATOIRE • PROBABILITES ET STATISTIQUES • FONCTIONS BOOLÉENNES • GRAPHES • AUTOMATES ET GRAMMAIRES

APERÇU SUR LA COMBINATOIRE (1/2) Environnement n Résultats m Paramètres en entrée Élément ou Composant à Tester x1 y1 x2 y2 x3 • • • • • • yn xm xi dénote la granularité du paramètre i yj dénote la granularité du résultat j Cardinalité : x1 x2 x3… xm = e Cardinalité : y1 y2… yn = r

APERÇU SUR LA COMBINATOIRE (2/2) Entrées Résultats Tests de robustesse + Tests fonctionnels + * * + * * + Cas autorisés par la spécification Résultats autorisés par la spécification Résultats possibles Cas possibles Chaque  est un test, soit : ( yi ) ** ( xi ) tests possibles, i.e. exponentiel :

Aperçu statistique Espace du système réel Espace des cas à tester Espace échantillon du système réel Testeur N°1 Testeur N°3 Testeur N°2 • Qq. problèmes statistiques intéressants : • Représentativité de l’échantillon ? • Est-ce que ce qui est vrai dans l’échantillon l’est encore dans le système réel ? • Est-ce que ce qui est faux dans l’échantillon est faux dans le système réel ? • Peut-on calculer/estimer un intervalle de confiance ? • Quelle confiance peut-on avoir dans les scénarios de tests ? Pour éviter les redondances et/ou les lacunes les testeurs doivent disposer d’une information parfaite

APERÇU PROBABILISTE (1/2) • UN CHEMIN BIEN IDENTIFIÉ : • PLUSIEURS / NOMBREUX CAS EXTERNES POSSIBLES • UNE ERREUR BIEN IDENTIFIÉE (SYMPTÔMES IDENTIQUES) : • PLUSIEURS CHEMINS POSSIBLES PEUVENT MENER À LA MÊME ERREUR

APERÇU PROBABILISTE (2/2) URNES DES ERREURS • ÉVITER LES CAS DOUBLONS • IL FAUT ÉVALUER LES PROBABILITÉS POUR QUE : • 1 TIRAGE DONNE UNE ERREUR • IDENTIFIER LES COMBINAISONS DE PARAMÈTRES QUI ONT LE PLUS DE CHANCE DE TROUVER DES ERREURS • 2 TIRAGES D'ERREURS SUCCESSIFS TROUVENT DEUX ERREURS DIFFÉRENTES • TROUVER LES CHEMINS FAUTIFS • IDENTIFIER LE PLUS COURT CHEMIN QUI REPRODUIT LES MÊMES SYMPTÔMES • PROBABILITÉ DES DOUBLONS : • Pour une urne contenant N types de boules

MATURITÉ • NIVEAU 0 : mise au point et tests ne sont pas différenciés • NIVEAU 1 : le but des tests est de montrer que le système fonctionne • NIVEAU 2 : le but des tests est de montrer que le système ne fonctionne pas • NIVEAU 3 : le but des tests est de réduire le risque de non fonctionnement tel que perçu par l’usager à une valeur acceptable ( implique une mesure) • NIVEAU 4 : la testabilité du système est complètement intégrée au processus de conception • Il est futile de « concevoir » ce que l'on ne saura pas tester.

LOIS EMPIRIQUES DE LA TESTABILITÉ • LOI 1 : toute méthode de tests laisse un résidu d'erreurs contre lesquelles la méthode adoptée est inefficace • Corollaire : Le potentiel de détection des défauts d’une suite de test s’épuise  Il faut constamment renouveler les tests en changeant de point de vue (objectif de test). • LOI 2 : l'accroissement de complexité des systèmes dépasse très facilement le niveau de complexité que l'on sait raisonnablement valider, vérifier et tester compte tenu des contraintes économiques (cf. modèle CQFD) • LOI 3 : code et données entretiennent des relations de dualité ; le code se transforme facilement en données. Les données sont une source d'erreurs aussi importante que le code (cf. statistique B.Beizer) • LOI 4 : la topologie des défauts passe progressivement de l'état « dense » à l'état « diffus » ; l’analyse locale devient globale, le défaut résulte d’interactions imprévues entre différentes régions. Les « heisenbugs » deviennent prépondérants (le non déterminisme latent rend les pannes non reproductibles)

VALIDATION VÉRIFICATION & TESTS