VVT-rappels NT V3 PDF

RAPPELS SUR LES TESTS
ET LA VALIDATION
Développement piloté par
les tests – Coût des tests et
qualité FURPSE
©2012 Reproduction interdite /N. Trèves / CNAM - AISL / VV&T Introduction générale / Vers. 3.0 NFP209 Page N° 1
VALIDATION VÉRIFICATION &

TESTS
Introduction :
Le problème fondamental du génie
logiciel : le problème de l'erreur
1
Le problème de l'erreur
• COMMENT CONSTRUIRE DES

LOGICIELS QUI SOIENT :
ERGONOMIQUES
FIABLES
EVOLUTIFS
ECONOMIQUES
GARANTISSANT LE CONTRAT DE SERVICE REQUIS PAR

LES USAGERS (cf. caractéristiques FURPSE ISO/IEC 9126)
SATISFAISANT AUX CRITERES
Coût/Qualité/Fonctionnalités/Délais de réalisation (CQFD)
Le constat et les causes
• PRESENCE DE NOMBREUX DÉFAUTS

DANS LES LOGICIELS
Cas de la navette spatiale :
logiciel embarqué : 0.11 par KLS (500)
logiciel sol : 0.40 par KLS (1400)
Logiciels grand public : plutôt 5-10 voire plus par KLS
• EVOLUTIVITE DES LOGICIELS
PROBLEMATIQUE (Régression en
qualité)
Cas des grands systèmes
2
Données statistiques
• Sources :
Classification et fréquence (Source B. Beizer, 1990)
Microsoft (étude M. Cusumano, R. Selby)
Productivité (B. Boehm)
Statistique B.Beizer
Statistique portant sur 6.877 millions de LS (avec des commentaires)
Nombre de défaillances découvertes en exploitation : 16 209
Taux d’erreurs : 2.36 Err/KLS
Cause de la défaillance : % erreurs Description et commentaires

découvertes
catégorie et/ou phase
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 9.88
dite ; codage
Intégration 8.98 Interfaces entre les modules
Appels système 1.74
Tests erronés 2.76
Divers 4.71
Total 100
• Source : B.Beizer, Software testing

techniques (1990)
3
Microsoft
Testing technique % of bugs detected Description

Usage tests 15.0 Bugs détectés par usage quotidien du système
API tests 12.8 Tests de validation des interfaces
Ad hoc, other tests 8.0 Tests faits avec d’autres critères que ceux spécifiés
Apps-16 tests 7.6
Gorilla tests 6.8 Tests de robustesse, tests aux limites
User interface tests 5.5
Stress tests 3.8 Scénarios fonctionnels
Apps-32 tests 2.8
NT verify tests 1.7 Tests de pré-intégration (construction d’incréments)
Applets tests 0.7
Non NT tests 0.6 Tests faits à l’extérieur du groupe NT
Bug bash tests 0.3
SGA tests 0.3
RATS tests 0.2
Unspecified techniques 33.9
Total 100
Microsoft principle: Use metric data to determine milestone completion and

product 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.5
Conception générale et 16 4.5
Spécification fonctionnelle
Conception détaillée 24 7
Programmation proprement 24 12
dite ; codage et tests unitaires
Intégration 29 19
Total 100 44
4
Terminologie
• QUELQUES DEFINITIONS (IEEE STD 982 et 1044)

ERROR (Erreur) : Human action that results in software containing a
fault. E.g. omission or misinterpretation of user requirements in a software
specification, and incorrect translation or omission of a requirement in the
design specification.
DEFECT (Défaut) : A product anomaly; e.g. (1) omissions and
imperfections found during early life cycle phases and (2) faults contained
in software sufficiently mature for test or operation.
FAULT (Défaillance) : (1) An accidental condition that causes a
functional unit to fail to perform its required function. (2) A manifestation of
an error in software. A fault if encountered may cause a failure.
FAILURE (Panne) : The termination of the ability of a functional unit
to perform its required function. A failure may be produced when a fault is
encountered.
La chaîne de l'erreur (1/3)
Erreur Défaut Défaillance Panne
ERROR DEFECT FAULT FAILURE
Est à l'origine qui peut conduire qui peut provoquer
ACTION
ACTION DANS
DANSLE
LE DANS
DANSLE
LE DE
DELA
LA
HUMAINE
HUMAINE LOGICIEL
LOGICIEL PRODUIT
PRODUIT FONCTION
FONCTION
Métrique: Peut être masqué Métrique:

•Densité d'erreurs par des dispositifs •MTTF
•Temps moyen de de type tolérance •MTBF
diagnostic aux pannes
•MTTR
5
La chaîne de l’erreur (2/3)
Erreurs humaines
BESOIN
BESOIN INSTALLATION
Introduction des
CONCEPTION INSTALLATION EXPLOITATION
CONCEPTION
PROGRAMMATION
MAINTENANCE
MAINTENANCE
EXPLOITATION défauts dans les
PROGRAMMATION
différentes phases
du cycle
Défaillance +/- graves
Manifestation Éventualité
Défaut dans le
Erreur humaine d’une d’une panne
logiciel
défaillance ± grave
La chaîne de l’erreur (3/3)
Période de très
grand danger pour
Période d'introduction de
Période d'observation
l’intégrité du
défauts d'installation Période d'introduction de
(Actions erronées de défauts d'exploitation
de la défaillance système
l'administrateur) (Actions erronées de l'usager)
Temps de latence
TFin
T0 TDébut T1 T2
nominal
Fault Failure
Installation Démarrage du (exécution du défaut) (constatation de la
du logiciel logiciel défaillance)
(début de session) → Arrêt du logiciel
Durée moyenne de bon Durée de

fonctionnement du logiciel dysfonctionnement,
MTTF d’indisponibilité et de
réparation du logiciel
MTTR
6
TESTS
Terminologie
Quelques définitions (1/4)
• Vérification : confirmation par l’examen et la

fourniture de preuves objectives que des
exigences spécifiées ont été remplies [ISO
9000].
• Validation : confirmation par l’examen et la

fourniture de preuves objectives que les
exigences, pour un usage ou une application
voulue, ont été remplies [ISO 9000].
7
• Processus de test (testing) : processus

consistant en toutes les activités du cycle de
vie, statiques et dynamiques, concernant la
planification et l’évaluation de produits logiciels,
pour déterminer s’ils satisfont aux exigences,
pour démontrer qu’ils sont aptes aux objectifs et
pour en détecter des anomalies [CFTL].
• Test : un ensemble d’un ou plusieurs cas de

tests [IEEE 829].
• Cas de test : un ensemble de valeurs

d’entrée (données de tests), de pré conditions
d’exécution, de résultats attendus et de post
conditions d’exécution, développées pour un
objectif ou une condition de tests particulière,
tel qu’exécuter un chemin particulier d’un
programme ou vérifier le respect d’une
exigence spécifique [IEEE 610].
• Objectif de test : une raison ou un but pour
la conception et l’exécution d’un test [CFTL].
8
• Condition de test : un article ou événement

d’un composant ou système qui pourrait être
vérifié par un ou plusieurs cas de tests; par
exemple une fonction, une transaction, un
attribut qualité ou un élément de structure
[CFTL].
• Stratégie de test : un document de haut
niveau définissant, pour un programme, les
niveaux de tests à exécuter et les tests dans
chacun de ces niveaux (pour un ou plusieurs
projets).
Tests et systèmes
• Un système
Est constitué d’éléments / composants échangeant de
l’information par des interfaces (cf. découpage
architectural)
Est exécutable à partir de stimuli / données provenant de
l’environnement
• Test d’un système
SYSTEME
DONNEES DE TEST RESULTAT
9
Activité de tests
• UN TEST IMPLIQUE UNE EXECUTION SUR
MACHINE
Du système ou d’un composant du système (nœud/feuille de l’arbre produit)
C’est un protocole expérimental au sens fort du terme
TESTS PREPARÉS A L'AVANCE

Cas de tests 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 non planifiées qui révèlent un défaut de fonctionnement
• L’ACTIVITÉ DE TEST S’INSCRIT DANS CELLE PLUS

GENERALE DE RECHERCHE DES DÉFAUTS
Qui inclut relectures et raisonnements sur les différents textes issus du
cycle de développement au moyen de revues et d'inspections
Du point de vue intuitif
• Activité aussi vieille que le

développement
• Souvent négligée et peu formalisée
• Considérée (à tort) comme moins
« noble » que le développement
• Coût souvent > 50% du coût total d’un
logiciel
• Très peu enseignée
10
Idées fausses sur les tests (1/2)
• Il faut éliminer tous les défauts

Doit-on tester le cas où l’automobile roule à 500 km/h ?
• L’amélioration de la fiabilité est

proportionnelle au nombre de défauts
corrigés
Il reste un défaut dans une fonction toujours utilisée …
• Je programme sans erreur, ce n’est pas la

peine de tester …
Idées fausses sur les tests (2/2)
• L’amélioration de la fiabilité est

proportionnelle au taux de couverture
du code par les tests
• Évaluer la qualité d’un logiciel, c’est
estimer le nombre de défauts
résiduels
• Croire que c’est simple et facile
• Croire que cela n’exige ni expérience,
ni savoir-faire, ni méthodes
11
Juste un exemple
232
+
232
Faire tous les tests 0,5 milliard d’années !

(pour toutes les valeurs)
En phase de test, nous sommes toujours face à

l’explosion combinatoire
Les différentes sortes de tests
• Tests unitaires
On teste chaque fonction de chaque module (tests « boîte
blanche » sur les instructions)
• Tests d’intégration
On teste les interfaces entre modules (tests « boîte blanche » sur
les interfaces, tests « boîte noire » sur les instructions)
• Tests de validation
On teste les fonctionnalités du logiciel (tests « boîte noire »)
12
Positionnement des types de tests
C o n c e p ti o n C o n c e p ti o n
d é ta illé e d u m o d u le p ré li m i n a i r e
T e sts
u n itaire s
M o d ule
te s té
C o n c e p tio n
d é ta illé e d u m o d u l e
T e s ts T e sts
u n ita ire s M o d ule d 'i n t é g r a t i o n
te s té
•
•
• M o d ule
C o n c e p tio n te s té L o g ic ie l
d é ta illé e d u m o d u l e as se m b lé
T e s ts
u n ita ire s
S p é c if ic a tio n s
f o n c tio n n e lle s T e s ts de
v a li d a tio n
S p é c if ic a tio n s
L o g ic ie l
s y s tè m e
v ali dé
A u t re s é lé m e n ts
s y s tè m e T e s ts S y s tè m e o p é r a ti o n n e l
s y s tè m e
Quelques termes courants

Tester
Preuve
Vérification
Validation
Qualification
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)
13
Nature de l'information utilisée pour les tests
Élément ou Composant à Tester
m Paramètres Environnement n Résultats

en entrée
x1 y1
x2
y2
x3
•••
•••
yn
xm
Granularité de la description
Configuration externe Configuration interne Bord de l'élément :

de l'élément à tester : de l'élément à tester : Pré-conditions
Ensembles Graphes de contrôle +
+ + Post-conditions
Relations Graphes de données
Objectif de tests et ensemble générateur
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'une

dé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)
14
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» (i.e. contraintes) 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,…)
Aperçu sur la combinatoire (1/2)
Environnement
m Paramètres n Résultats
en entrée
x1 y1
x2 Élément ou y2
x3 Composant à •••
••• Tester yn
xm
xi dénote la granularité yj dénote la granularité

du paramètre i du résultat j
Cardinalité : x1× x2× x3×…×

× xm = e Cardinalité : y1× y2×…×
× yn = r
15
Aperçu sur la combinatoire (2/2)
Entrées Résultats
Tests de robustesse
+
+
*
Tests
fonctionnels
*
+ *
*
+
Cas autorisés par Résultats Résultats autorisés

Cas possibles la spécification possibles par la spécification
Chaque → est un test, soit : ( Πyi ) ** ( Π xi ) tests possibles, i.e. exponentiel : re


TESTS
Place de la VVT dans le

cycle système
16
Le cycle système et le cycle de
développement
Cycle de vie système

Faisabilité Définition Développement et MCO Retrait
Prototype
Expérimentation Compatibilité ascendante des
versions successives
Version N°1 Exploitation
Réalisation de Réalisation de
maquettes prototypes Version N°2 Exploitation
N Cycles de Développement – Exploitation - Maintenance
Validation fonctionnelle et Version N°n Exploitation

non fonctionnelle au sens
informatique
Dominante MCO
Validation fonctionnelle et
comportements exigés en
termes métier de la cible Dominante développement
Projet de migration
Vérification de la bonne prise en compte des règles éventuelle
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 : > 15-20 ans, mais > 30 pour les grands systèmes technologiques
17
Détail du cycle de développement (1/3)
RETOUR D’EXPÉRIENCE
Expression de Axe d’évolution

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

Mesure de la maturité de l’EB/EC Processus de développement
Expression de
besoin et exigences
comportementales
• Défauts propagés
EB/EC
Conception • Défauts ajoutés
générale • Défauts détectés
CG
Conception
détaillée
Implémentation
CD Programmation et • Taux d’erreurs résiduelles
tests unitaires acceptable par l’AQ
P/TU Intégration
Processus de conception (VV&T) Mesure de la maturité (i.e. contrat
Recette
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
18
Système qualité - Assurance qualité
CCD, DCD CQFDglobal

CQFD globaldudu
CCG, DCG
projet
projet
CG CPTU, DPTU
CAQ/CG
CD Nombre de RA/AC
CVVT, DVVT
CAQ/CD
P/TU
CAQ/PTU Courbe de maturité
VVT
Déléguer
CAQ/VVT Contrôler
AQ globale centralisée Effort Mesurer
Agir
CC
AQ ==CC
AQ/GC ++CC
AQ/CG ++CC
AQ/CD ++CC
AQ/PTU ++CC
AQ/VVT
AQ AQ/GC AQ/CG AQ/CD AQ/PTU AQ/VVT
La recherche systématique des défauts se fait préventivement

dans toutes les phases du cycle de développement
Des définitions complémentaires (1/2)
• Plan de tests : un document décrivant l’étendue,

l’approche, les ressources et le planning des activités
de test prévues. Il identifie entre autres les éléments et
caractéristiques à tester, qui fera chaque tâche, le
degré d’indépendance des testeurs, l’environnement
de test, les techniques de conception des tests et les
techniques de mesure des tests à utiliser, et tout
risque nécessitant des plans de contingence. C’est un
document reprenant les processus de planification des
tests [IEEE 829].
19
Des définitions complémentaires (2/2)
• Scénarios de tests : une technique de conception

de tests boîte noire dans laquelle les cas de tests sont
conçus pour exécuter des scénarios de cas
d’utilisation.
• Conception de tests : Conditions de tests pour
l’approche détaillée d’un test et l’identification des cas
de tests de haut niveau associés [d’après IEEE 829]
• Condition de test : un article ou événement d’un
composant ou système qui pourrait être vérifié par un
ou plusieurs cas de tests; p.ex. une fonction, une
transaction, un attribut qualité ou un élément de
structure.
Cycle de vie VVT

• L’activité de VVT débute dès la phase
EB/EC
Besoin
Besoin
Plan et objectifs de tests Conception
Conception
• Système TESTS ET VÉRIFICATIONS
• Recette
Développement POUR LA NON RÉGRESSION
Plan de tests Développement
concernant l’activité V&V
• Modules
• Intégration
Résultats des phases
des phases suivantes
Conception des tests Scénarios de tests Intégration

Intégration
• Modules
• Modules
• Intégration • Intégration Recette
Recette
• Système Scénario de tests
• Système
Cas à tester • Recette Installation
Installation
• Recette
• Modules
• Intégration
• Système Construction de la courbe de maturité
• Recette
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
20
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é psycho
cognitive
Capacité intrinsèque des personnels
Expérience et savoir faire
cf. J. Printz, Puissance et limites des systèmes informatisés, Chapitre

3, chez Hermès
21
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écodage
D3 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 simple
D6 Illusions (dans notre cas ce sont surtout les paradoxes de type logique ; non prédicativité)
D7 Acceptation comme vraie d’une hypothèse fausse
D8 Acceptation comme fausse d’une hypothèse vraie
D9 Attribution de propriétés inutiles et/ou erronées
D10 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ègle
D13 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 actions
D15 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 circulaire
D18 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 travail
D22 Analogies, associations erronées et/ou non adaptées au contexte
D23 Confusion/Interférence proactive et/ou rétroactive
D24 Changement de tâche fréquent, « papillonnage » , toute perturbation qui augmente la probabilité de confusion et
d’interférence
Taux moyen de 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
• Code source fabriqué par les

Programmation programmeurs, compilé sans erreur
• Réduction du nombre
Tests de couverture et de de défauts au minimum
contrôle acceptable selon le
Tests fonctionnel à partir contrat de service
des données
• 80 à 100 défauts
par KLS Tests de performance
VVT Tests de robustesse
Tests de pré-intégration
• 5 à 10 défauts
par KLS
INTÉGRATION
Si la stratégie de VVT est correctement conduite
• 1 à 2 défauts
par KLS
Installation
22
Espace méthodologique et
maturité de l’activité VVT
Modèle qualité FURPSE – Coûts de mise

en oeuvre
Caractéristiques qualité
Internes et Externes
F U R P S E
Maintenability,
Usability Reliability
Functionality Efficiency Serviceability Portability
(Facilités (Fiabilité –
(Fonctionnalité) (Performance) (Garantie de (Évolutivité)
d’emploi) Sûreté)
service, MCO)
• Adéquation des Capacité et facilité • Maturité • Temps de réponse Capacité et facilité Capacité et facilité
fonctions de : • Tolérance aux et comportement de : de :
• Précision et • Compréhension pannes dynamique • Analyse des • Adaptation et
fidélité des • Apprentissage • Remise en état de • Utilisation des défaillances évolution
résultats • Exploitation marche ressources • Modification • Installation des
• Interopérabilité • Ergonomie IHM (mémoire, débit en • Stabilité modifications
• Sécurité du point de vue transactionnel, etc.) (confinement des • Remplacement
+ métier défaillances) • Cohabitation
• Conformité aux • Test
exigences (automaticité, non
fonctionnelles régression, etc.)
+ 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
23
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, Axe méthodes VVT
interopérabilité, etc.
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)
Rappel CMMI : les 5 niveaux
Optimiser
Optimiser 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
Piloter
Piloter
• Optimisation CQFD
Pratique systématique de la mesure pour évaluer

la performance :
• Processus de développement
Définir
Définir • Produit logiciel réalisé
• Définition des processus

• Vision systémique « gagnant-gagnant »
des acteurs ( formation)
Reproduire
Reproduire
• Satisfaction du client final
• Revues de projet, évaluation des risques
• Gestion du besoin et des exigences

• Assurance qualité (i.e. VV&T)
• Gestion de projet ; contrats de sous-traitance
Initial
Initial • Gestion des configurations
« laissez faire »
24
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
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é)
EB/EC
Relectures formelles
• Preuves par simulation sur la base de modèles explicites
CG
Simulation partielles
Simulations exhaustives
CD
• Preuves « mathématiques » par raisonnements explicites
Par construction (via des langages ad hoc)
Codage
Par induction (démonstrations ± automatiques
Compilation des langages
TU
IVVT Détection des défauts

Modules
Par les techniques de tests traditionnelles
IVVT
Système
Recette Exploitation du logiciel
Fichier Enregistrement systématique de tous

des les incidents au moyen de fiches RA/AC
Ce flux permet la mesure du incidents précises + Traces facilitant le diagnostic
taux d’erreurs résiduelles
25
Stratégie coopérative MOA – MOE
Nécessité de mise en cohérence des systèmes qualité MOA ET MOE
Organisation Organisation
cible Pilote stratégique cible
MOA
Pilote
Pilote
Pilote
Intégration/
EB/EC Suivi fournisseur Recette
Système qualité MOA
Contrat Interactions Contrat
Pilote
Pilote
MOEMOE
Développement
Développement
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
Méthodes agiles
cycle de vie XP
Software factory
Cas
d’emplois Exploration
Planification • Planning game
Architecture stabilisée • Durée moyenne 1 à 4 semaines

Itération
à la première itération • Tests fonctionnels de chaque
itération, faits par le client (TDD)
Durée de 2 à 6 mois Mise en production • The perfect time to tune

maximum
Maintenance • The normal state of an XP

project
• The time to write a 5 to 10

Terminaison
pages tour of the system
Nominale « mort »
26
Schéma de communication entre les
acteurs SCRUM / XP
Management
Relation non explicite
SCRUM Master
Product Owner Équipe
Coach/Tracker XP
C’est, de fait, le chef de projet qui :

Relation non explicite • Prend les décisions
• Lève les risques
Usagers • Suit les actions
Les interactions correspondent aux processus de livraison, ainsi que

de fourniture des besoins et de validation (cf. TDD : test driven development)
Forte cohésion entre les équipes
La place des tests dans les 12 règles de

l’XP-programming
• R1 : Whole Team - All the contributors to an XP project – developers , business analysts, testers, etc. –
work together in an open space, members of one team. The walls of this space are littered with big
visible charts and other evidences of their progress.
• R2 : Planning Game - Planning is continuous and progressive. Every two weeks, for the next two
weeks, developers estimate the cost of the candidate features, and customers select those features
to be implemented based upon cost and business value.
• R3 : Customer Tests - As part of selecting each desired feature, the customers define automated
acceptance tests to show that the feature is working.
• R4 : Simple Design - The team keeps the design exactly suited for the current functionality of the
system. It passes all the tests, contains no duplication, expresses every thing the authors want
expressed, and contains as little code as possible.
• R5 : Pair Programming - All production software is built by two programmers, sitting side by side, at
the same machine. – 1 testeur 1 développeur, les roles sont interchangeables.
• R6 : Test-Driven Development - The programmers work in very short cycles, adding a failing test, then
making it work.
• R7 : Design Improvement - Don’t let the sun set on bad code. Keep the code as clean and expressive as
possible.
• R8 : Continuous Integration - The team keeps the system fully integrated at all times.
• R9 : Collective Code Ownership - Any pair of programmers can improve any code at any time.
• R10 : Coding Standard - All the code in the system looks as if it was written by a single–very
competent–individual.
• R11 : Metaphor - The team develops a common vision of how the program works.
• R12 : Sustainable Pace - The team is in it for the long term. They work hard, at a pace that can be
sustained indefinitely. They conserve their energy, treating the project as a marathon rather than a
sprint.
27
Stratégie de tests
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
28
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
Le processus de test
Objectif du test
Spécification du programme
et/ou des interfaces à tester
Spécification du test
Résultats et comportements
Chargement du programme Scénario du test attendus
et de son environnement
Résolution du problème
Exécution du test
Analyse inductive
(on vérifie une hypothèse à
Résultats et comportements partir des résultats obtenus)
observés
Diagnostic
Analyse déductive
Comparaison Analyse des résultats (on recherche les causes
Exploitation dans le programme et/ou les
interfaces)
Résultat Résultat Modifications Diagnostic
Correct Incorrect induites
Archivage du test et
Dans le test Dans le programme Gestion des configurations
des résultats
Sources +Tests + Documentation
État d’avancement des Modifs Modifs
N scénarios de tests
29
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)
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
30
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
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
31
Équation générale de l’effort
• Peut-on justifier la forme de cette

équation ?
Effort = k × (KLS ) 1+α

Terme linéaire Terme NON linéaire
d’influence
Facteurs
Dépend de la puissance expressive Dépend de la complexité de

et du « grain » sémantique du l’application et de la maturité du
langage processus de développement
+ Expérience des acteurs • α est le facteur d’intégration
Facteurs de coût Facteurs d’échelle
Interprétation des équations COCOMO

avec CQFD
C
Effort = k × (KLS ) 1+α
Q
F
D = (0,5 ± 0,04) × (Een HA ) 0,3±ε
D Rendement de l’effort VVT exprimé en termes de :
• Taux de défauts résiduels
• Disponibilité de l’application ou du système
Effort [Q ] = C × (k × (KLS ) 1+α )

32
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é
La vision qualité : répartition de l’effort
Objectifs de
Équilibrage de l’effort de test
test
Axe de progression de l’intégration
en minimisant les retours arrière
Programmeur
Programmeurindividuel
individuel Test boîte
Tests
Testsunitaires
unitaires blanche
×α1
Équipe
Équipeprojet
projet
×α3 Intégration
Intégrationprojet
projet
Zone grise
×α2
Équipe
Équipesystème
système Test boîte
Intégration
Intégrationsystème
système noire
αi est un coefficient d’amplification
33
Maturité de développement d’un système
Indicateur d’avancement du processus de test

(+ critère de terminaison)
Système « idéal », sans défaut résiduel
Défauts résiduels
Fin de Effort
projet
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
34
La détection précoce des défauts
Injection de
Découverte
défauts
tardive des
consécutive aux
défauts de A par
erreurs des
les acteurs de B
acteurs de A
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
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
35
Efficacité des revues et inspections (2/2)
Total des défauts Moins de défauts

corrigés à l’aide des résiduels
revues et des tests • À 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
Profils de maturité qualité produit
Nbre de RA-AC
Profil N°3
Profil N°1
Défauts résiduels
Profil N°2
Effort VVT
En relatif, ces profils sont
indiscernables, mais les taux
d ’erreurs résiduelles sont
très différents
36
Principes de la VVT
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 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é
37
• 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 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ège : croire que le développement est seul juge
38
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 Effort de test Effort de test
r= Efficacité =
Effort total Nbre de défauts découverts
Nbre de défauts découverts
Densité =
Nbre de lignes source ( KLS )
Maturité
NIVEAU 1 : mise au point et tests ne sont pas
différenciés.
NIVEAU 2 : le but des tests est de montrer que
le système fonctionne.
NIVEAU 3 : le but des tests est de montrer que
le système ne fonctionne pas.
NIVEAU 4 : le but des tests est de réduire le
risque de non fonctionnement tel que perçu par
l’usager à une valeur compatible avec la mission
du système.
NIVEAU 5 : 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
39
Lois 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 et stratégie 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.
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.
LOI 4 : la topologie des défauts passe progressivement
de l'état « dense » à l'état « diffus » ; l’analyse locale
devient globale. Les « heisenbugs » deviennent
prépondérants.
Influence de la VVT sur la

productivité et le rendement de
l’organisation de développement
Données économiques
40
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
Management qualité fondée sur la

métrologie des flux d’anomalies
INDICATEURS CARACTÉRISTIQUES
Flux d' Erreurs
Développement
RErr/ RA = <1
Flux de Rapports d' Anomalies
Maintenance Age moyen des RA, Dispersion des RA
Durée du cycle Disponibilité (i.e. MTTF, MTTR)
Besoin
Flux de modifications Temps de non régression
Flux de modifications Conception
en cours de
en cours de Programmation
développement
développement Intégration
Date début Relivraisons Date fin

Rodage d'exploitation d'exploitation
Deux modes d'exploitation :
Deux modes d'exploitation :
• 1 à qq. sites
Période d'exploitation d'une version du système • 1 à qq. sites
Courbe de maturité (i.e. clé en mains)
(i.e. clé en mains)
Flux continu de défaillances découvertes en exploitation • Nombreux sites (progiciels)
• Nombreux sites (progiciels)
—> Doublons
—> Doublons
Coûts chez le fournisseur: Coûts chez l'exploitant :

Coûts chez le fournisseur: Coûts chez l'exploitant :
• Constitution d'un dossier d'Erreur • Émission d'un Rapport d'Anomalie.
• Constitution d'un dossier d'Erreur • Émission d'un Rapport d'Anomalie.
(Action Correctrice).
(Action Correctrice). • Coûts d'arrêts de l'exploitation.
• Coûts de réparation et de relivraison
Filtrage • Coûts d'arrêts de l'exploitation.
• Coûts de réparation et de relivraison • Pertes d'équipements, humaines,…
de tout ou partie du système. • Pertes d'équipements, humaines,…
de tout ou partie du système.
Taux d’échecs Bien distinguer dans le MTTR la part

due à la qualité du diagnostic
41
Coût moyen des corrections
Conception Programmation Intégration

VVT
Coût moyen par Taux
d’erreurs
phase selon 40% 20% 40% acceptable
vade-mecum
???
Ce qui est
refait selon 30% 50% 70%
vade-mecum
Coût moyen des

corrections 12% 10% 28% ≈ 50%
Domaine de la prévention (amélioration de la productivité)
Répartition des temps de correction par

défaut
1er Quartile : 8%
% Effort moyen par Effort cumulé
défaut (en heures) (en heures)
25% 2h 50h
50% 5h 250h
20% 10h 200h 2ème-3ème Quartile : 40%
4% 20h 80h
1% 50h 50h
100 erreurs 6.3h/err 630h
4ème Quartile : 52%
Source : Hewlett-Packard
42
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
La différence est
logiciel
supportée par l’usager du
1ère mise en service logiciel et le MCO
Temps
Développement Exploitation (et plus généralement MCO)
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
43
• Modèle d'amplification par phase du

cycle de développement • Prévoir le coût de
cette détection dans les
ERREURS tâches du projet
DÉTECTION • Identifier les modules
COMMISES critiques (architecture)
DÉFAUTS ERREURS PROPAGÉES EFFICACITÉ
PROVENANT
DES PHASES
Yi DE LA
DÉFAUTS TRANSMIS
PRÉCÉDENTES ERREURS AMPLIFIÉES DÉTECTION Yj
À LA PHASE SUIVANTE
DANS LA
xj ERREURS NOUVELLES PHASE
Yj = xj + α × Yi
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)

Conception Conception Codage Intégration Validation Intégration
Préliminaire Détaillée Tests unitaires Modules Modules Système
AMPLIFICATION SANS PROCESSUS DE REVUE
0 6 10 93 47 24
0 0% 4x1,5=6 0% 27x3=81 20% 0 50% 0 50% 0 50%
10 25 25 0 0 0
10 37 93
12
AMPLIFICATION AVEC PROCESSUS DE REVUE ERREURS RÉSIDUELLES
3
3 15 24
0 2 5 24 12 6
0 70% 1x1,5=2 50% 10x3=30 60% 0 50% 0 50% 0 50%
10 25 25 0 0 0
44
• Application du modèle VEST

Conformité de la Conformité de la
fourniture livraison
Pilote de
la tâche
T
Tâche projet à effectuer
Tâche(s) amont E S Tâche(s) aval
Flux nominal Flux nominal et

et anomalies V demandes de
imputables à T Validation, vérification, modifications
test
Bilan du processus en terme de

Par rapport à la FINALITÉ
productivité - rendement (COQ et CONQ)
Tâches d ’assurance qualité permettant de détecter

préventivement les défauts et d’éviter leur propagation
Période d’introduction des erreurs Période de détection/correction

des défauts au moyen de tests
x1 x2 x3 x4
IVVT IVVT
EB/EC CG CD Codage TU Recette
Modules Système
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,

Potentiel de détection des
Software testing techniques)
scénarios de tests fonction du
• EB/EC : 9%
volume de scénarios (fonctionne
• CG : 26%
comme un filtre)
• CD : 52% (dont 24% sur les données)
• Défaillances les + probables
• Codage : 10%
• Absence de doublon
• Tests : 3%
45
> × 300
× 150 à 300
× 50 à 150
× 10 à 50
× 4à8
× 2à4
EB/EC
CdCF-1 Conception
Développement
Documents contractuels
Intégration

Déploiement,
ORIGINE support et MCO
= 1 Fournitures contractuelles
Coût pour l’usager (1/2)
• Coûts de gestion
Émission de RA, installation des corrections, re-
livraisons, 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.
46
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)
Élaboration et mise en œuvre

d’une stratégie de tests
47
Définition
• Stratégie de VV&T : le problème
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
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
e1 s1
e2 s2
Fonction ou ensemble
e3 s3
de fonctions à tester •••
•••
en sm
La nomenclature de cet
Contour flou si il y a des ensemble est FONDAMENTALE
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
48
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
• 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
49
• 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
• 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
50
• 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)
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)
51
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
Attributs indispensables d’un intégrat
Exigences fonctionnelles et
• Documentation de maintenance
non fonctionnelles prises en Est documenté • Documentation d’exploitation
compte (FURPSE) + Traçabilité par :
• Documentation de support
des exigences
• Liste des inspections et des

Est vérifié par : revues effectuées
• Liste des tests + modalités
Intégrat
• Liste des inspections et des
Est validé par : revues effectuées
• Liste des tests+ modalités
Demandes de modifications : Rôle des acteurs selon modalités

• Prises en compte CRUD étendues (modalités de
Est géré par :
• En attente déploiement et d’exécution –
• Refusées Ressources utilisées)
Gestion des activités
• Traçabilité inverse
52
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é I1/I2
(éventuellement par simulation) pour Intégrat-I2

atteindre les intégrats I3, I4 et I5 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é I3/I4

dans I2
Intégrat-I4
Problème des défauts diffus
dans plusieurs intégrats Terminaison selon
I4/I5 critères VEST
Réponse en
Intégrat-I5
Défaillance sortie
constatée dans I4
Le système fournit les résultats
attendus (nominal ou non nominal)
Stratégie de l’effort de test
• Construction de la matrice du jeu

Actions possibles
A1 A2 A3 ••• Am
S1
Situations
possibles
S2
•••
Sn
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é
53
Aperçu sur l’intégration des systèmes
informatisés
Aspect logiciel de l’intégration
Interactions dans le processus

d’intégration (Norme ISO 12207)
System requirements Software Software detailed
analysis requirements analysis design
System architecture Software architecture Software coding and

design design testing
Remontée de faits techniques et de rapports

Conformité VEST d’anomalies à analyser par les acteurs de l’ingénierie
System integration Software integration Software installation
System qualification Software qualification Software acceptance

testing testing support
Conformité VEST
Ensemble d’activités IVVT

Livraison du système aux
Intégration, Vérification, Validation et
Usagers cible + MCO
Test
54
Le procédé de construction
Intégrats rejetés Livraison partielle pour

démarrer la recette finale
en parallèle
Flux d’intégrats
Intégration Système Test de Qualification
et Logicielle et Acceptance
Satisfaisant
les critères VEST
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
La machine à intégrer (chaîne de

montage) – Assemblage des intégrats
Intégrat-1
Système satisfaisant aux critères
Intégrat-1.1 qualité spécifiés dans le cahier
... des charges
...
Intégrats de rang 0
Intégrats de rang 1
issu du Étage Étage Étage
issu de l’étage N°1
développement et d’Intégration d’Intégration Intégrat d’Intégration Système
N°1 et satisfaisant les N°2 final
satisfaisant les Intégrat final
critères VEST
critères VEST satisfaisant les
... critères VEST
Scénarios Scénarios Scénarios
... étage N°1 étage N°2 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
55
Construction progressive de la
configuration livrée
Règles de recherche des éléments à intégrer
Livrables des
Éléments complets programmeurs
vérifiés et validés
Génération des
sources
Éléments complets
partiellement vérifiés et
validés par l’intégration Compilation
Édition de liens
Livraisons de l’ingénierie
Éléments complets livrés Binaire

par l’ingénierie exécutable
Essais avec les

scénarios de tests
Éléments incomplets
livré par l’ingénierie
Livrés par l’ingénierie ou

Bouchons + réalisé par l’intégration
É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
Bibliographie
• Glossaire CFTL/ISTQB des termes

utilisés en tests de logiciels
• IEEE SW standards collection
• J. Printz, JF. Peyre, Pratique des tests
logiciels, 2009
56

VVT-rappels NT V3 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

VVT-rappels NT V3 PDF

Transféré par

Droits d'auteur :

Formats disponibles

RAPPELS SUR LES TESTS

VALIDATION VÉRIFICATION &

• COMMENT CONSTRUIRE DES

GARANTISSANT LE CONTRAT DE SERVICE REQUIS PAR

Le constat et les causes

• PRESENCE DE NOMBREUX DÉFAUTS

Cause de la défaillance : % erreurs Description et commentaires

• Source : B.Beizer, Software testing

Testing technique % of bugs detected Description

Microsoft principle: Use metric data to determine milestone completion and

Source : Improving software productivity, Computer September 1987 et COCOMO

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

• QUELQUES DEFINITIONS (IEEE STD 982 et 1044)

La chaîne de l'erreur (1/3)

Erreur Défaut Défaillance Panne

ERROR DEFECT FAULT FAILURE

Est à l'origine qui peut conduire qui peut provoquer

Métrique: Peut être masqué Métrique:

Défaillance +/- graves

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

Durée moyenne de bon Durée de

Quelques définitions (1/4)

• Vérification : confirmation par l’examen et la

• Validation : confirmation par l’examen et la

• Processus de test (testing) : processus

• Test : un ensemble d’un ou plusieurs cas de

Quelques définitions (3/4)

• Cas de test : un ensemble de valeurs

• Condition de test : un article ou événement

DONNEES DE TEST RESULTAT

TESTS PREPARÉS A L'AVANCE

• L’ACTIVITÉ DE TEST S’INSCRIT DANS CELLE PLUS

Du point de vue intuitif

• Activité aussi vieille que le

• Il faut éliminer tous les défauts

• L’amélioration de la fiabilité est

• Je programme sans erreur, ce n’est pas la

Idées fausses sur les tests (2/2)

• L’amélioration de la fiabilité est

Faire tous les tests 0,5 milliard d’années !

En phase de test, nous sommes toujours face à

Les différentes sortes de tests

Quelques termes courants

Élément ou Composant à Tester

m Paramètres Environnement n Résultats

Configuration externe Configuration interne Bord de l'élément :

Objectif de tests et ensemble générateur

 ON RECHERCHE L'EXHAUSTIVITÉ DANS UNE CLASSE DE TEST DONNÉE

Propriété recherchée : SI Eg est couvert ALORS la probabilité d'une

Difficulté : Faire que Eg soit à la fois :

Aperçu sur la combinatoire (1/2)

xi dénote la granularité yj dénote la granularité

Cardinalité : x1× x2× x3×…×

Cas autorisés par Résultats Résultats autorisés

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

VALIDATION VÉRIFICATION &

Place de la VVT dans le

Cycle de vie système

N Cycles de Développement – Exploitation - Maintenance

Validation fonctionnelle et Version N°n Exploitation

Expression de Axe d’évolution

Réalisation incrément N°1

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

ON RECHERCHE L'EXHAUSTIVITÉ DANS UNE CLASSE DE TEST DONNÉE