validation vÉrification & tests

©2000 Reproduction interdite J.Printz / CNAM - CMSL / VVT Chapitre 1 : Définitions et concepts de base / Vers. 4.4

VALIDATION VÉRIFICATION & TESTS

DÉFINITIONS ET CONCEPTS DE BASE

C E N T R E D E

M A I T R I S E D E S

S Y S T E M E S E T

D U L O G I C I E L


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)

Statistique portant sur 6.877 millions de LS (avec des commentaires) Nombre d’erreurs : 16 209 Taux d’erreurs : 2.36 Err/KLS

Catégorie et/ou phase % erreurs découvertes

Description et commentaires

Expression de besoin 8.12 Spécification fonctionnelle 16.19 Conception détaillée 25.18 Dont :

- 12.82 flot de contrôle, enchaînement - 12.36 algorithmes de traitement

Données 22.44 Dont : - 11.14 valeurs initiales, duplication, etc. - 12.36 typage, accès.

Programmation proprement dite ; codage

9.88

Intégration 8.98 Interfaces entre les modules Appels système 1.74 Tests erronés 2.76 Divers 4.71

Total 100


Microsoft

Testing technique % of bugs detected Description

Usage tests 15.0 Bugs détectés par usage quotidien du systèmeAPI tests 12.8 Tests de validation des interfacesAd hoc, other tests 8.0 Tests faits avec d’autres critères que ceux spécifiésApps-16 tests 7.6Gorilla tests 6.8 Tests de robustesse, tests aux limitesUser interface tests 5.5Stress tests 3.8 Scénarios fonctionnelsApps-32 tests 2.8NT verify tests 1.7 Tests de pré-intégration (construction d’incréments)Applets tests 0.7Non NT tests 0.6 Tests faits à l’extérieur du groupe NTBug bash tests 0.3SGA tests 0.3RATS tests 0.2Unspecified techniques 33.9

Total 100

Microsoft principle: Use metric data to determine milestone completion andproduct release


Statistique B.Boehm

Source : Improving software productivity, Computer September 1987 et COCOMO

Phase Poids en % de la phase Dont refait suite à la découverte d’erreurs

Expression de besoin 7 1.5Conception générale etSpécification fonctionnelle

16 4.5

Conception détaillée 24 7Programmation proprementdite ; codage et tests unitaires

24 12

Intégration 29 19

Total 100 44


VVT

Conception détaillée

Programmation

Tests de couverture et de contrôle

Tests fonctionnel à partir des données

Tests de performance

Tests de robustesse

Tests de pré-intégration

• Modèle de données, en particulier interfaces entre les modules,• Modèle d’enchaînement/contrôle des fonctions

INTÉGRATION

• Code source fabriqué par les programmeurs, compilé sans erreur

• Réduction du nombre de défauts au minimum acceptable selon le contrat de service

• 80 à 100 défauts par KLS


Installation


Découverte des défauts

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)

Revues

Insp

ect

ions


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

Spécification du testSpécification du test

Exécution du testExécution du test

ComparaisonExploitation

ComparaisonExploitation

Archivage du test etdes résultats

Archivage du test etdes résultats

Modificationsinduites

Modificationsinduites

Analyse des résultatsAnalyse des résultats

Objectif du testSpécification duprogramme à tester

Chargement du programme et de son environnement

Scénario du test Résultats et comportementsattendus

Résultats effectifs

Correct Incorrect

Analyse inductive(on vérifie une hypothèse à partir des résultats obtenus)

Analyse déductive(on recherche les causes

dans le programme)

Bibliothèque des tests

Dans le test Dans le programmeGestion des configurationsSources +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

2

)1(321

nnnSn


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

Localiser toutes les données pertinentes

Organiser les données

Etudier les relations et dépendancesfonctionnelles entre les données

Formuler une hypothèse

Prouver/démontrer l'hypothèse

Corriger le défaut

Données insuffisantes

Inconsistance et/ouincomplétude

Rechercher les cas semblables qui neprésentent pas l'anomalie.

On rassemble les cas particulierspour généraliser et faire ressortir lescontradictions.On passe d ’une représentation en extension à une représentation en intention.

On construit une mini-théorie quiexplique complètement l'anomalie.Si plusieurs théories sont possibles,on commence par la plus simple.

On doit démontrer la consistance et lacomplétude de la théorie sélectionnéeavant de se lancer dans une correction.


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

Enumérer toutes les causespossibles de l'anomalie

Rassembler plus de données

Elimination progressive de toutes lescauses sauf une

Améliorer et affiner l'hypothèse

Prouver/démontrer l'hypothèse

Corriger le défaut

Inconsistance et/ouincomplétude

Les hypothèses et théories correspondantesvont permettre de structurer et analyser lesdonnées à partir desquelles on va reconstruire le code supposé fautif (i.e.une 2ème version).

Si toutes les hypothèses et théories sontéliminées, il faut plus de données.

A partir des renseignements et indicesdisponibles, on construit une mini-théorie.C’est une reconstruction de la partie du programme jugée fautive.

On doit démontrer la consistance et lacomplétude de la théorie sélectionnéeavant de se lancer dans une correction.


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

Programmesource

Résultats

Tests

Profils

Métrologie

Compilateur

Surveillance(en ligne)

Analyseurstatique

Analyseurdynamique

Exécution

Programmebinaire

VALIDATION

VERIFICATION


NATURE DE L'INFORMATION UTILISÉE POUR LES TESTS

Élément ou Composant à Tester

x1

x2

x3

xm

• • •

y1

y2

yn

• • •

m Paramètresen entrée

n Résultats

Configuration externede l'élément à tester :Ensembles+Relations

Configuration internede l'élément à tester :Graphes de contrôle+Graphes de données

Granularité de la description

Bord de l'élément :Pré-conditions+Post-conditions

Environnement


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

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)

ON RECHERCHE L'EXHAUSTIVITÉ DANS UNE CLASSE DE TEST DONNÉE QUI CONSTITUE L’OBJECTIF DE TEST


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)

Élément ou Composant à Tester

x1

x2

x3

xm

• • •

y1

y2

yn

• • •

m Paramètresen entrée

n Résultats

xi dénote la granularitédu paramètre i

yj dénote la granularitédu résultat j

Cardinalité : x1x2x3…xm = e Cardinalité : y1y2…yn = r

Environnement


APERÇU SUR LA COMBINATOIRE (2/2)

Tests de robustesse

Tests fonctionnels

+

**+

+

*

*

Cas autorisés parla spécificationCas possibles

Résultats autoriséspar la spécification

Résultats possibles

Chaque est un test, soit : ( yi ) ** ( xi ) tests possibles, i.e. exponentiel :

Entrées Résultats

+

er


Aperçu statistique

Espace des cas à tester

Testeur N°1

Testeur N°2 Testeur N°3

Pour éviter les redondances et/ou les lacunes les testeurs doivent disposer d’une information parfaite

Espace du système réel

Espace échantillon du système réel

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 ?


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)

• É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

URNES DES ERREURS

2

Np


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

Documents