validation vÉrification & tests

©2001 Reproduction interdite J.Printz / CNAM - CMSL / VV&T dans le cycle système / Vers. 2.0 Page N° 1

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

VALIDATION VÉRIFICATION & TESTS

Place de la VVT dans le cycle système


Le cycle système et le cycle de développement


Cycle système - cycle de développement

Durée d’un cycle : > 15-20 ans, mais > 30 pour les grands systèmes technologiques

Faisabilité Définition Développement et MCO Retrait

Réalisation de maquettes

Version N°1

Version N°2 Exploitation

Version N°n Exploitation

Cycles de développement

A l’issue de ces deux phases, l’architecture/urbanisation du

système d’information doit être stabilisée

Le modèle de croissance est explicite

Exploitation

Nombre de RA/AC

Durée

Mesure de la qualité de service (QOS)

PrototypeExpérimentation

Réalisation de prototypes


Détail du cycle de développement (1/3)

Réalisation incrément N°3

Qualification


Qualification

CdCF-3

CdCF-2

Expression de besoin /Exigences

Expression de besoin /Exigences

CdCF-1


Conception

Développement

Intégration

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

Axe d’évolution

Axe d’évolution

Axe d’évolution

RETOUR D’EXPÉRIENCE

Déploiement, support et MCO

Déploiement, support et MCO

Processus de DEVELOPPEMENT


Détail du cycle de développement (2/3)

Expression de besoin et exigences

Exploitation et support

Processus de conception

Processus de développement

Assurance qualité et activités transverses AQ

EB/EC(Spécification

fonctionnelles)

CG

CD

P/TU

VVT

Mesure de la qualité de service

Mesure de la maturité de l’EB/EC

• Défauts détectés• Défauts propagés• Défauts ajoutés

Conception générale

Conception détaillée

Programmation et tests unitaires

Intégration (VV&T)

Implémentation

• Mesure du taux d’erreurs résiduelles

Nombre de RA/AC

Mesure de la maturité (i.e. contrat de service) en exploitation

Durée

Processus de spécification

QOS


Détail du cycle de développement (3/3)Système qualité - Assurance qualité

La recherche systématique des défauts se fait préventivement dans toutes les phases du cycle de développement

CCG, DCGCCD, DCD

CPTU, DPTU

CVVT, DVVT

AQ globale centralisée

CQFD global du projet

CQFD global du projet

CAQ = CAQ/GC + CAQ/CG + CAQ/CD + CAQ/PTU + CAQ/VVTCAQ = CAQ/GC + CAQ/CG + CAQ/CD + CAQ/PTU + CAQ/VVT

CD

P/TU

VVT

CG

CAQ/CG

CAQ/CD

CAQ/PTU

CAQ/VVT

DéléguerContrôlerMesurer

Agir

Effort

Nombre de RA/AC

Courbe de maturité


RecetteInstallation

RecetteInstallation

IntégrationIntégration

Cycle de vie VVT (Validation, Vérification, Test)

DéveloppementDéveloppement

ConceptionConception

BesoinBesoin

Plan et objectifs de tests• Système• Recette

Plan de tests• Modules• IntégrationConception des tests• Modules• Intégration• Système• Recette

Scénarios de tests• Modules• Intégration• SystèmeCas à tester• Modules• Intégration• Système• Recette

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é

Rés

ult

ats

des

ph

ases

co

nce

rnan

t l’

acti

vité

V&

V

des

ph

ases

su

ivan

tes

Cf. ANSI/IEEE Std 1012 Software verification and validation plans ; Std 1059 Guide VVT

TESTS ET VÉRIFICATIONS POUR LA NON RÉGRESSION

• L’activité de VVT débute dès la phase EB/EC


Les erreurs humaines et les sources des défauts logiciel


Origine des erreurs humaines

• Incompréhension du besoin et des exigences de l’organisation cible

En particulier les caractéristiques non fonctionnelles

• Incompréhension de l’environnement de développement et d’exécution

Complexité des plates-formes

• Erreurs inhérentes à l’activité psychocognitive Capacité intrinsèque des personnels Expérience et savoir faire

Cf. mon livre, Puissance et limites des systèmes informatisés, Chapitre 3, chez Hermès


Erreurs humaines - Psychologie de la programmation

Les défaillances du processus psychocognitif

D1 Erreur de perception, manque de discrimination, distinction fond/forme et/ou sémantique/syntaxe

D2 Erreur de codage/décodageD3 Erreur de représentation et/ou symbologie non adaptée (interopérabilité entre systèmes)D4 Représentation, compréhension et interprétation erronées de phénomènes dynamiques et/ou combinatoires (plusieurs

flots d’exécution en parallèle qui interfèrent, perception du temps vrai versus temps psychologique, synchronisation) ;modèle mental erroné du phénomène.

D5 Impasse, non-exhaustivité, oubli pur et simpleD6 Illusions (dans notre cas ce sont surtout les paradoxes de type logique ; non prédicativité)D7 Acceptation comme vraie d’une hypothèse fausseD8 Acceptation comme fausse d’une hypothèse vraieD9 Attribution de propriétés inutiles et/ou erronéesD10 Hypothèse superflue et/ou non appropriée (Exp. : tel événement se produit rarement alors qu’il est fréquent)D11 Erreur de communication homme - homme, de traduction lors d'un changement de code (contre sens, faux sens, etc.)D12 Non respect d'une procédure ou d'une règleD13 Non prise de décision en temps voulu (logiques temporelles)D14 Action non adaptée au contexte, action contradictoire et/ou antinomique vis à vis d’autres actionsD15 Itération, répétition inutile d’une action (i.e. propriété d’idempotence des actions)D16 Absence d’information qui entraîne une action par défaut non adaptée (non perception d’un manque ou d’une absence

de quelque chose)D17 Erreur de raisonnement, raisonnement circulaireD18 Défaut ou excès de généralité, abstraction mal construite, définition ambiguë (non prédicative)D19 Confusion langage / métalangage, concept / méta-concept (mélange de types au sens logique, ou équations de

dimensions incohérentes en physique)D20 Saturation de la bande passante (Exp. : trop de décisions simultanées, interruptions continuelles)D21 Saturation de la mémoire de travailD22 Analogies, associations erronées et/ou non adaptées au contexteD23 Confusion/Interférence proactive et/ou rétroactiveD24 Changement de tâche fréquent, « papillonnage » , toute perturbation qui augmente la probabilité de confusion et

d’interférence


Taux moyen de défauts

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


Si la stratégie de VVT est correctement conduite


La chaîne de l’erreur (1/2)

INSTALLATIONMAINTENACE

INSTALLATIONMAINTENACE

Erreurs humaines

Introduction desdéfauts dans lesdifférentes phases du cycle

Défaillance +/- graves

BESOINCONCEPTION

PROGRAMMATION

BESOINCONCEPTION

PROGRAMMATION EXPLOITATIONEXPLOITATION

Erreur humaineDéfaut dans le logiciel

Manifestation d’une défaillance

Éventualité d’une panne grave


La chaîne de l’erreur (2/2)

T0

Installationdu logiciel

Démarrage dulogiciel

(début de session)

TDébutT1 T2

TFin

nominal

Fault(exécution du défaut)

Failure(constatation de la

défaillance) Arrêt du logiciel

Période d'observationde la défaillance

Période d'introduction dedéfauts d'installation(Actions erronées de

l'administrateur)

Durée moyenne de bon fonctionnement du logiciel MTTF

Période d'introduction dedéfauts d'exploitation

(Actions erronées de l'usager)Temps de latence

Durée d’indisponibilité et réparation du logiciel MTTR

Période de très grand danger pour

l’intégrité du système


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


Espace méthodologique VV&T

Axe caractéristiques qualité produit (Cf. ISO/CEI 9126)

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

6 caractéristiques principales• FURPSECaractéristiques de l’environnement système• Sécurité, sûreté de fonctionnement, interopérabilité, etc.

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)


Rappel CMM : les 5 niveaux

InitialInitial

ReproduireReproduire

DéfinirDéfinir

PiloterPiloter

OptimiserOptimiser

« laissez faire »

• Gestion du besoin et des exigences• Assurance qualité (i.e. VV&T)• Gestion de projet ; contrats de sous-traitance• Gestion des configurations

• Définition des processus• Vision systémique « gagnant-gagnant » des acteurs ( formation)• Satisfaction du client final• Revues de projet, évaluation des risques

Pratique systématique de la mesure pour évaluer la performance :• Processus de développement• Produit logiciel réalisé

Régulation du processus sur les objectifs stratégiques de l’entreprise :• Prévention des défauts• Intégration des NTI ( architecture ouverte et testable) dans la stratégie• Optimisation CQFD


Les acteurs de la VV&T• Le chef de projet

Planification des tâches et assurance qualité (système qualité)

• L’architecte du projet Architecture testable

• Les programmeurs 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é ; Recette)

• Le support et/ou la maintenance de 1er niveau


Place des méthodes de validation

EB/EC

CG

CD

Codage

TU

IVVTModules

IVVTSystème

Recette Exploitation du logiciel

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

Détection des défautsPar les techniques de tests traditionnelles

Fichier des

incidents

Enregistrement systématique de tous les incidents au moyen de fiches RA/AC précises + Traces facilitant le diagnosticCe flux permet la mesure du

taux d’erreurs résiduelles


Du besoin client au système installé

Expression de besoin - Exigences comportementales

Spécifications fonctionnelles

Conception système (Générale + Détaillée)

Intégration

Installation - Déploiement

Cycle de développement

système Chaîne de valeur

Assurance qualité système selon FURPSE appliquée à la chaîne de valeur

Les 3 NIVEAUX de modélisationF U R P S E

• Processus, Fonctions et Flux au sens métier• Ordonnancement et règles de gestion• Qualité de service (QOS) du point de vue « client »

• Processus, Fonctions et Flux au sens métier• Ordonnancement et règles de gestion• Qualité de service (QOS) du point de vue « client »

• Processus, Fonctions et Flux au sens informatique ; cartographie• Ordonnancement des travaux (workflow)• Contraintes d’exploitation (capacity planning ; system management)

• Processus, Fonctions et Flux au sens informatique ; cartographie• Ordonnancement des travaux (workflow)• Contraintes d’exploitation (capacity planning ; system management)

• Composants logiciel, transactions, COTS, « legacy » applications, etc.• Ordonnancement (client-serveur ; middleware ; OLTP ; etc.)• Maintenabilité ; diagnostics ; reprises incidents ; surveillance• Encapsulation des technologies et évolutivité

• Composants logiciel, transactions, COTS, « legacy » applications, etc.• Ordonnancement (client-serveur ; middleware ; OLTP ; etc.)• Maintenabilité ; diagnostics ; reprises incidents ; surveillance• Encapsulation des technologies et évolutivité

• Bilan VVT du développement; Tests de charge ; Robustesse ; Disponibilité ; etc.• QOS estimée au vue des résultats des tests d’intégration

• Bilan VVT du développement; Tests de charge ; Robustesse ; Disponibilité ; etc.• QOS estimée au vue des résultats des tests d’intégration

• VVT des paramétrages et des scripts d’installations ; MCO• QOS constatée sur les sites d’exploitation ; tableau de bord

• VVT des paramétrages et des scripts d’installations ; MCO• QOS constatée sur les sites d’exploitation ; tableau de bord

Assu

ran

ce q

ualité

Programmation

Bilan qualité et intégration

N1

N2

N3


Nécessité d’une méthode transverse cohérente

BesoinBesoin

ConceptionConception Développement SI-1Développement SI-1

Développement SI-2Développement SI-2

Développement SI-nDéveloppement SI-n IntégrationIntégration

RecetteInstallation

RecetteInstallation

Mettre en cohérence

Vérifierla cohérence

Validerl’interopérabilité

Méthodologie d’interopérabilité des SI selon MIND™

Prochain cycle

Structure d’un cycle d’acquisition de l’interopérabilité du SI global

MOE(s)

Nombre de RA/AC

Durée

Mesure de la qualité de service (QOS)

Construction systématique

multiprojet avec une garantie qualité

Référentiel(Modèles)


Mise en œuvre de la méthode

MOEDéveloppement

Pilote

MOEDéveloppement

Pilote

Pilote stratégique MOA

Suivi fournisseurSystème qualité MOA

Pilote

Interactions

Intégration/Recette

Pilote

EB/EC

Pilote

Contrat Contrat

Système qualité MOE

Nécessité de mise en cohérence des systèmes qualité MOA ET MOE

Plus les référentiels sont rigoureux et explicites, meilleures sont les chances de détecter les erreurs et de corriger les défauts


Stratégie de test


Stratégie de test : les objectifs (1/2)

• Un double objectif :– 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)

– 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


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

• Évaluation des caractéristiques non fonctionnelles des COTS (i.e. réduire le facteur d’incertitude)

Valider l’ergonomie avec les usagers REELS

• Équilibrer :– Techniques AQ : revues, inspections, audits,– tests Boîte Noire et tests Boîte Blanche – Tests de robustesse et tests d’innocuité/sûreté


La vision qualité : répartition de l’effort

Objectifs de test

Programmeur individuelTests unitaires

Programmeur individuelTests unitaires

Équipe projetIntégration projet

Équipe projetIntégration projet

Équipe systèmeIntégration système

Équipe systèmeIntégration système

Axe

de

prog

ress

ion

de l’

inté

grat

ion

en m

inim

isan

t le

s re

tour

s ar

rière

1

3

2

i est un coefficient d’amplification

Équilibrage de l’effort de test

Test boîte noire

Test boîte blanche

Zone grise


Productivité de l’effort VVT

Temps/Effort

Nombre de défauts détectés

Techniques REVUES + INSPECTIONS(Détection des défauts peu coûteuse)

Techniques de TEST(Détection des défauts coûteuse)

PERTE


En relatif, ces profils sont indiscernables, mais les taux

d ’erreurs résiduelles sont très différents

Profils de maturité qualité produit

Effort VVT

Défauts résiduels

Nbre de RA-AC

Profil N°1

Profil N°2

Profil N°3


Principes de la VVT


Quelques principes VV&T (1/3)

• Principe N°1– Tester exhaustivement un logiciel est généralement

impossiblePhénomènes combinatoires et coûts exponentiels

• Principe N°2– Tester correctement un logiciel est une tâche difficile qui

requiert intelligence et créativité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é



• 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



• Principe N°5– La planification sérieuse de la VVT est indispensable à la

maîtrise du projetChaque 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ège : croire que le développement est seul juge


VV&T et QUALITÉ

• Qualité 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)

• 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

)(

KLSsourcelignesdeNbre

découvertsdéfautsdeNbreDensité

découvertsdéfautsdeNbre

testdeEffortEfficacité

totalEffort

testdeEffortr


Influence de la VVT sur la productivité et le rendement de

l’organisation de développement


Données économiques

• Métriques qualité

• Coût des corrections

• Courbes de maturité

• Facteurs d’amplification des coûts

• Coûts pour l’usager


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éveloppementMaintenance

Date débutd'exploitation

Date find'exploitation

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

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

Deux modes d'exploitation :

• 1 à qq. sites(i.e. clé en mains)

• Nombreux sites (progiciels)—> Doublons

RErr/ RA Flux d' Erreurs

Flux de Rapports d' Anomalies 1

Flux de modifications en cours de développement

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é


Coût moyen des corrections

40% 20% 40%

Conception Programmation Intégration VVT

Coût moyen par phase selon

vade-mecum

Ce qui est refait selon

vade-mecum

Coût moyen des corrections

30% 50% 70%

12% 10% 28% = 50%

Taux d’erreurs

acceptable ???

Domaine de la prévention (amélioration de la productivité)


Courbes de maturité - Transfert de coût

Palier de maturité acceptable(dépend du taux d’erreurs non reproductibles)

Temps

1 à 5 Err/KLS selon exigence

Développement Exploitation

1ère mise en service

La différence est supportée par l’usager du logiciel

La différence est supportée par l’éditeur du logiciel

Pente résiduelle


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


ERREURS PROPAGÉES

ERREURS AMPLIFIÉES

ERREURS NOUVELLES

EFFICACITÉDE LA

DÉTECTION DANS LA PHASE

ERREURS COMMISES DÉTECTION

DÉFAUTSPROVENANTDES PHASES

PRÉCÉDENTESDÉFAUTS TRANSMISÀ LA PHASE SUIVANTE

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)


• Modèle d'amplification par phase du cycle de développement

YiYj

xj

YixjYj


TTâche projet à effectuer

E S

VValidation,

vérification, test

Tâche(s) amont Tâche(s) aval

Pilote de la tâche

Flux nominal et anomalies imputables à T

Flux nominal et demandes de

modifications


Tâches d ’assurance qualité permettant de détecter préventivement les défauts et d’éviter leur propagation

• Application du modèle VEST



EB/EC CG CD Codage TUIVVT

ModulesIVVT

SystèmeRecette

Période d’introduction des erreurs

x1 x2 x3 x4

Y1 Y2 Y3 Y4

Période de détection/correction des défauts au moyen de tests

Construction du référentiel de VVT

Scénarios de tests

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

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%


EB/EC

CdCF-1

Réalisation incrément N°1 Déploiement, support et MCO

Développement

Intégration

2 à 4

4 à 8

ORIGINE= 1

10 à 50

50 à 150

150 à 300

> 300

Fournitures contractuelles

Documents contractuels

Conception



Coût pour l’usager (1/2)

• Coûts de gestion– Emission 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èmeExemples : Infrastructures techniques (contrôle aérien, énergie,

communications, réseaux bancaires, défense, etc.)

– ProgicielsExistence de contournement selon le niveau de maturité

Systèmes d’exploitation, progiciels système (SGBD, Réseaux, etc.), progiciels applicatifs, etc.


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 dictionnaire de données/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)