RAPPELS SUR LES TESTS ET LA VALIDATION

Transcription

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
Page N° 2
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)
Page N° 3
Le constat et les causes
• PRESENCE DE NOMBREUX DÉFAUTS
DANS LES LOGICIELS
Cas de la navette spatiale :
logiciel embarqué :
logiciel sol :
0.11 par KLS (500)
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
Page N° 4
2
Données statistiques
• Sources :
Classification et fréquence (Source B. Beizer, 1990)
Microsoft (étude M. Cusumano, R. Selby)
Productivité (B. Boehm)
Page N° 5
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 :
catégorie et/ou phase
% erreurs
découvertes
Expression de besoin
Spécification fonctionnelle
Conception détaillée
8.12
16.19
25.18
Données
22.44
Programmation proprement
dite ; codage
Intégration
Appels système
Tests erronés
Divers
9.88
Total
8.98
1.74
2.76
4.71
Description et commentaires
Dont :
- 12.82 flot de contrôle, enchaînement
- 12.36 algorithmes de traitement
Dont :
- 11.14 valeurs initiales, duplication, etc.
- 12.36 typage, accès.
Interfaces entre les modules
100
• Source : B.Beizer, Software testing
techniques (1990)
Page N° 6
3
Microsoft
Testing technique
% of bugs detected
Usage tests
API tests
Ad hoc, other tests
Apps-16 tests
Gorilla tests
User interface tests
Stress tests
Apps-32 tests
NT verify tests
Applets tests
Non NT tests
Bug bash tests
SGA tests
RATS tests
Unspecified techniques
15.0
12.8
8.0
7.6
6.8
5.5
3.8
2.8
1.7
0.7
0.6
0.3
0.3
0.2
33.9
Total
Description
Bugs détectés par usage quotidien du système
Tests de validation des interfaces
Tests faits avec d’autres critères que ceux spécifiés
Tests de robustesse, tests aux limites
Scénarios fonctionnels
Tests de pré-intégration (construction d’incréments)
Tests faits à l’extérieur du groupe NT
100
Microsoft principle: Use metric data to determine milestone completion and
product release
Page N° 7
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
Conception générale et
Spécification fonctionnelle
Programmation proprement
dite ; codage et tests unitaires
Intégration
7
16
1.5
4.5
24
24
7
12
Total
29
19
100
44
Page N° 8
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.
Page N° 9
La chaîne de l'erreur (1/3)
Erreur
Défaut
ERROR
DEFECT
Est à l'origine
ACTION
ACTION
HUMAINE
HUMAINE
Défaillance Panne
FAULT
qui peut conduire
FAILURE
qui peut provoquer
DANS
DANSLE
LE
LOGICIEL
LOGICIEL
DANS
DANSLE
LE
PRODUIT
PRODUIT
Métrique:
•Densité d'erreurs
•Temps moyen de
diagnostic
•MTTR
Peut être masqué
par des dispositifs
de type tolérance
aux pannes
DE
DELA
LA
FONCTION
FONCTION
Métrique:
•MTTF
•MTBF
Page N° 10
5
La chaîne de l’erreur (2/3)
Erreurs humaines
BESOIN
BESOIN
CONCEPTION
CONCEPTION
PROGRAMMATION
PROGRAMMATION
INSTALLATION
INSTALLATION
MAINTENANCE
MAINTENANCE
Introduction des
défauts dans les
différentes phases
du cycle
EXPLOITATION
EXPLOITATION
Défaillance +/- graves
Manifestation
d’une
défaillance
Défaut dans le
logiciel
Erreur humaine
Éventualité
d’une panne
± grave
Page N° 11
La chaîne de l’erreur (3/3)
Période d'introduction de
défauts d'installation
(Actions erronées de
l'administrateur)
T0
Installation
du logiciel
Temps de latence
T1
TDébut
Démarrage du
logiciel
(début de session)
Fault
(exécution du défaut)
Durée moyenne de bon
fonctionnement du logiciel
MTTF
Période d'observation
de la défaillance
Période d'introduction de
défauts d'exploitation
(Actions erronées de l'usager)
Période de très
grand danger pour
l’intégrité du
système
T2
TFin
nominal
Failure
(constatation de la
défaillance)
→ Arrêt du logiciel
Durée de
dysfonctionnement,
d’indisponibilité et de
réparation du logiciel
MTTR
Page N° 12
6
TESTS
Terminologie
Page N° 13
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].
Page N° 14
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].
Page N° 15
• 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].
Page N° 16
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).
Page N° 17
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
Page N° 18
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
Page N° 19
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
Page N° 20
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 …
Page N° 21
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
Page N° 22
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
Page N° 23
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 »)
Page N° 24
12
Positionnement des types de tests
C o n c e p ti o n
d é ta illé e d u m o d u le
C o n c e p ti o n
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
C o n c e p tio n
d é ta illé e d u m o d u l e
T e s ts
u n ita ire s
•
•
•
M o d ule
te s té
T e sts
d 'i n t é g r a t i o n
M o d ule
te s té
L o g ic ie l
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
S p é c if ic a tio n s
s y s tè m e
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
T e s ts de
v a li d a tio n
L o g ic ie l
v ali dé
S y s tè m e o p é r a ti o n n e l
Page N° 25
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)
Page N° 26
13
Nature de l'information utilisée pour les tests
Élément ou Composant à Tester
m Paramètres
en entrée
Environnement
x1
n Résultats
y1
x2
y2
x3
•••
•••
yn
xm
Granularité de la description
Configuration externe
de l'élément à tester :
Ensembles
+
Relations
Configuration interne
de l'élément à tester :
Graphes de contrôle
+
Graphes de données
Bord de l'élément :
Pré-conditions
+
Post-conditions
Page N° 27
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)
Page N° 28
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,…)
Page N° 29
Aperçu sur la combinatoire (1/2)
Environnement
n Résultats
m Paramètres
en entrée
x1
x2
x3
•••
xm
Élément ou
Composant à
Tester
xi dénote la granularité
du paramètre i
Cardinalité : x1× x2× x3×…×
× xm = e
y1
y2
•••
yn
yj dénote la granularité
du résultat j
Cardinalité : y1× y2×…×
× yn = r
Page N° 30
15
Aperçu sur la combinatoire (2/2)
Entrées
Résultats
Tests de robustesse
+
+
*
Tests
fonctionnels
+
*
*
+
Cas possibles
Cas autorisés par
la spécification
*
Résultats
possibles
Résultats autorisés
par la spécification
Chaque → est un test, soit : ( Πyi ) ** ( Π xi ) tests possibles, i.e. exponentiel :
re
Page N° 31
TESTS
Place de la VVT dans le
cycle système
Page N° 32
16
Le cycle système et le cycle de
développement
Page N° 33
Cycle de vie système
Faisabilité
Développement et MCO
Définition
Prototype
Expérimentation
Version N°1
Réalisation de
Réalisation de
maquettes
prototypes
Retrait
Compatibilité ascendante des
versions successives
Exploitation
Version N°2
Exploitation
N Cycles de Développement – Exploitation - Maintenance
Validation fonctionnelle et
non fonctionnelle au sens
informatique
Version N°n
Exploitation
Dominante MCO
Validation fonctionnelle et
comportements exigés en
termes métier de la cible
Dominante développement
Vérification de la bonne prise en compte des règles
architecturales au sein des projets (Revues + Inspections)
Projet de migration
éventuelle
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
Page N° 34
17
Détail du cycle de développement (1/3)
RETOUR D’EXPÉRIENCE
Axe d’évolution
Expression de
Expression de
besoin
besoin/Exigences
/Exigences
Processus de DEVELOPPEMENT
Axe d’évolution
CdCF-3
Réalisation incrément N°3
CdCF-2
CdCF-1
Qualification
Conception
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)
Axe d’évolution
Qualification
Développement
Intégration
Fournitures contractuelles :
• Kit d’installation, paramétrage
et règle de calibrage, doc pour le
support, doc utilisateur, etc.
• Garantie Assurance Qualité et
contrat de service
Déploiement,
Déploiement,
support
supportetetMCO
MCO
Page N° 35
Mesure de la maturité de l’EB/EC
Processus de développement
Expression de
besoin et exigences
comportementales
EB/EC
• Défauts propagés
• Défauts ajoutés
• Défauts détectés
Conception
générale
CG
Conception
détaillée
CD
Processus de conception
Implémentation
• Taux d’erreurs résiduelles
acceptable par l’AQ
Programmation et
tests unitaires
P/TU
Intégration
(VV&T)
Recette
Assurance qualité et activités transverses AQ
VVT
Mesure de la maturité (i.e. contrat
de service) en exploitation
Nombre de RA/AC
Exploitation et
support
Durée
Mesure de la qualité de service
Page N° 36
18
Système qualité - Assurance qualité
CCG, DCG
CG
CAQ/CG
CQFDglobal
globaldudu
CQFD
projet
projet
CCD, DCD
CPTU, DPTU
CD
CAQ/CD
CVVT, DVVT
Nombre de RA/AC
P/TU
CAQ/PTU
CAQ/VVT
Courbe de maturité
VVT
AQ globale centralisée
Effort
Déléguer
Contrôler
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
Page N° 37
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].
Page N° 38
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.
Page N° 39
Cycle de vie VVT
• L’activité de VVT débute dès la phase
EB/EC
Besoin
Besoin
Résultats des phases
concernant l’activité V&V
des phases suivantes
Plan et objectifs de tests
• Système
• Recette
Conception
Conception
Plan de tests
• Modules
• Intégration
Conception des tests
• Modules
• Intégration
• Système
• Recette
Développement
Développement
Scénarios de tests
• Modules
• Intégration
• Système
Cas à tester
• Modules
• Intégration
• Système
• Recette
TESTS ET VÉRIFICATIONS
POUR LA NON RÉGRESSION
Intégration
Intégration
Scénario de tests
• Recette
Recette
Recette
Installation
Installation
Construction de la courbe de maturité
Pour toutes les phases : collecte des Rapports d’Anomalies (RA) et des Actions Correctrices (AC) ; traçabilité
Cf. ANSI/IEEE Std 1012 Software verification and validation plans ; Std 1059 Guide VVT
Page N° 40
20
Les erreurs humaines et les
sources des défauts logiciel
Page N° 41
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
Page N° 42
21
Erreurs humaines - Psychologie de la
programmation
D1
D2
D3
D4
D5
D6
D7
D8
D9
D10
D11
D12
D13
D14
D15
D16
D17
D18
D19
D20
D21
D22
D23
D24
Les défaillances du processus psychocognitif
Erreur de perception, manque de discrimination, distinction fond/forme et/ou sémantique/syntaxe
Erreur de codage/décodage
Erreur de représentation et/ou symbologie non adaptée (interopérabilité entre systèmes)
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.
Impasse, non-exhaustivité, oubli pur et simple
Illusions (dans notre cas ce sont surtout les paradoxes de type logique ; non prédicativité)
Acceptation comme vraie d’une hypothèse fausse
Acceptation comme fausse d’une hypothèse vraie
Attribution de propriétés inutiles et/ou erronées
Hypothèse superflue et/ou non appropriée (Exp. : tel événement se produit rarement alors qu’il est fréquent)
Erreur de communication homme - homme, de traduction lors d'un changement de code (contre sens, faux sens, etc.)
Non respect d'une procédure ou d'une règle
Non prise de décision en temps voulu (logiques temporelles)
Action non adaptée au contexte, action contradictoire et/ou antinomique vis à vis d’autres actions
Itération, répétition inutile d’une action (i.e. propriété d’idempotence des actions)
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)
Erreur de raisonnement, raisonnement circulaire
Défaut ou excès de généralité, abstraction mal construite, définition ambiguë (non prédicative)
Confusion langage / métalangage, concept / méta-concept (mélange de types au sens logique, ou équations de
dimensions incohérentes en physique)
Saturation de la bande passante (Exp. : trop de décisions simultanées, interruptions continuelles)
Saturation de la mémoire de travail
Analogies, associations erronées et/ou non adaptées au contexte
Confusion/Interférence proactive et/ou rétroactive
Changement de tâche fréquent, « papillonnage » , toute perturbation qui augmente la probabilité de confusion et
d’interférence
Page N° 43
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
Programmation
• Code source fabriqué par les
programmeurs, compilé sans erreur
• Réduction du nombre
de défauts au minimum
Tests de couverture et de
contrôle
Tests fonctionnel à partir
des données
• 80 à 100 défauts
par KLS
acceptable selon le
contrat de service
Tests de performance
VVT
Tests de robustesse
Tests de pré-intégration
• 5 à 10 défauts
par KLS
Si la stratégie de VVT est correctement conduite
INTÉGRATION
• 1 à 2 défauts
par KLS
Installation
Page N° 44
22
Espace méthodologique et
maturité de l’activité VVT
Page N° 45
Modèle qualité FURPSE – Coûts de mise
en oeuvre
F
U
Usability
(Facilités
d’emploi)
Reliability
(Fiabilité –
Sûreté)
Capacité et facilité
de :
• Compréhension
• Apprentissage
• Exploitation
• Ergonomie IHM
du point de vue
métier
• Maturité
• Tolérance aux
pannes
• Remise en état de
marche
Functionality
(Fonctionnalité)
• Adéquation des
fonctions
• Précision et
fidélité des
résultats
• Interopérabilité
• Sécurité
+
• Conformité aux
exigences
fonctionnelles
Caractéristiques qualité
Internes et Externes
R
P
Efficiency
(Performance)
• Temps de réponse
et comportement
dynamique
• Utilisation des
ressources
(mémoire, débit en
transactionnel, etc.)
S
Maintenability,
Serviceability
(Garantie de
service, MCO)
de :
• Analyse des
défaillances
• Modification
• Stabilité
(confinement des
défaillances)
• Test
(automaticité, non
régression, etc.)
E
Portability
(Évolutivité)
de :
• Adaptation et
évolution
• Installation des
modifications
• Remplacement
• Cohabitation
+ Conformité aux exigences non fonctionnelles (écart mesuré entre le besoin et ce qui est réalisé)
La prise en compte de chacune de ces caractéristiques implique du code à
développer ou à acquérir et/ou des tests (vérification et validation) à effectuer
Page N° 46
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,
interopérabilité, etc.
Axe méthodes VVT
Axe méthodologies Cycle système et cycle
de développement (Cf. ISO/CEI 12207)
• Chaque phase a des besoins et des
exigences qui lui sont propres
Espace de de choix possibles très grand donc risque d’inconsistance et
d’incomplétude si la maturité de l’équipe est faible (cf. CMM)
Page N° 47
Rappel CMMI : les 5 niveaux
Optimiser
Optimiser
Piloter
Piloter
Pratique systématique de la mesure pour évaluer
la performance :
• Processus de développement
• Produit logiciel réalisé
Définir
Définir
• Définition des processus
• Vision systémique « gagnant-gagnant »
des acteurs ( formation)
• Satisfaction du client final
• Revues de projet, évaluation des risques
Reproduire
Reproduire
Initial
Initial
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
• Gestion du besoin et des exigences
• Assurance qualité (i.e. VV&T)
• Gestion de projet ; contrats de sous-traitance
• Gestion des configurations
« laissez faire »
Page N° 48
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
Page N° 49
Place des méthodes de VVT
EB/EC
CG
CD
Codage
TU
IVVT
Modules
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éfauts
Par les techniques de tests traditionnelles
IVVT
Système
Recette
Ce flux permet la mesure du
taux d’erreurs résiduelles
Exploitation du logiciel
Fichier
des
incidents
Enregistrement systématique de tous
les incidents au moyen de fiches RA/AC
précises + Traces facilitant le diagnostic
Page N° 50
25
Stratégie coopérative MOA – MOE
Nécessité de mise en cohérence des systèmes qualité MOA
Organisation
cible
ET MOE
Organisation
cible
Pilote stratégique
MOA
Pilote
Pilote
Pilote
EB/EC
Intégration/
Recette
Suivi fournisseur
Système qualité MOA
Contrat
Interactions
Pilote
Contrat
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
Page N° 51
Méthodes agiles
cycle de vie XP
Software factory
Cas
d’emplois
Exploration
• Planning game
Planification
Architecture stabilisée
à la première itération
Durée de 2 à 6 mois
maximum
Mise en production
• The perfect time to tune
Maintenance
• The normal state of an XP
project
Terminaison
• The time to write a 5 to 10
pages tour of the system
Nominale
• Durée moyenne 1 à 4 semaines
• Tests fonctionnels de chaque
itération, faits par le client (TDD)
Itération
« mort »
Page N° 52
26
Schéma de communication entre les
acteurs SCRUM / XP
Management
Relation non explicite
Product Owner
SCRUM Master
Coach/Tracker XP
Relation non explicite
Usagers
Équipe
C’est, de fait, le chef de projet qui :
• Prend les décisions
• Lève les risques
• 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
Page N° 53
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.
Page N° 54
27
Stratégie de tests
Page N° 55
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
Page N° 56
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
Page N° 57
Le processus de test
Objectif du test
Spécification du programme
et/ou des interfaces à tester
Spécification du test
Chargement du programme
et de son environnement
Scénario du test
Exécution du test
Résultats et comportements
attendus
Résolution du problème
Analyse inductive
(on vérifie une hypothèse à
partir des résultats obtenus)
Résultats et comportements
observés
Diagnostic
Comparaison
Exploitation
Résultat
Correct
Résultat
Incorrect
Archivage du test et
des résultats
État d’avancement des
N scénarios de tests
Analyse des résultats
Modifications
induites
Analyse déductive
(on recherche les causes
dans le programme et/ou les
interfaces)
Diagnostic
Dans le test Dans le programme Gestion des configurations
Sources +Tests + Documentation
Modifs
Modifs
Page N° 58
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)
Page N° 59
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
Page N° 60
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
Page N° 61
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
Page N° 62
31
Équation générale de l’effort
• Peut-on justifier la forme de cette
équation ?
Effort = k × (KLS ) 1+α
Facteurs
d’influence
Terme linéaire
Dépend de la puissance expressive
et du « grain » sémantique du
langage
+ Expérience des acteurs
Facteurs de coût
Terme NON linéaire
Dépend de la complexité de
l’application et de la maturité du
processus de développement
• α est le facteur d’intégration
Facteurs d’échelle
Page N° 63
Interprétation des équations COCOMO
avec CQFD
C
Q
F
D
Effort = k × (KLS ) 1+α
D = (0,5 ± 0,04) × (Een HA ) 0,3±ε
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+α )
Page N° 64
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é
Page N° 65
La vision qualité : répartition de l’effort
Axe de progression de l’intégration
en minimisant les retours arrière
Équilibrage de l’effort de test
Objectifs de
test
Programmeur
Programmeurindividuel
individuel
Tests
Testsunitaires
unitaires
Test boîte
blanche
Équipe
Équipeprojet
projet
Intégration
Intégrationprojet
projet
Zone grise
Équipe
Équipesystème
système
Intégration
Intégrationsystème
système
Test boîte
noire
×α1
×α3
×α2
αi est un coefficient d’amplification
Page N° 66
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
projet
Effort
Page N° 67
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
Page N° 68
34
La détection précoce des défauts
Injection de
défauts
consécutive aux
erreurs des
acteurs de A
Découverte
tardive des
défauts de A par
les acteurs de B
Processus A
Processus B
Livrables de
A pour B
• Remède : Faire en sorte que les acteurs de A
découvrent leurs propres erreurs, ou à tout le
moins permettent à B de les découvrir plus vite
• Qualité des livrables
Page N° 69
Efficacité des revues et inspections (1/2)
Défaut introduits
Défauts résiduels
pouvant conduire à
des défaillances
Défauts cumulés
•
•
•
•
EB/EC CG
Défauts corrigés à l’aide
de tests
• Coût élevé
•
CD
P/TU
Intégration
Phases de développement
Page N° 70
35
Efficacité des revues et inspections (2/2)
Total des défauts
corrigés à l’aide des
revues et des tests
Moins de défauts
résiduels
• À effort constant la
qualité est améliorée
Défauts cumulés
•
•
•
Moins de défauts corrigés à
l’aide de tests, donc un gain
qui compense le coût des
revues et inspections
• Les tests passent plus vite
•
•
EB/EC CG
CD
P/TU
Intégration
Phases de développement
Page N° 71
Profils de maturité qualité produit
Nbre de RA-AC
Profil N°3
Profil N°1
Défauts résiduels
Profil N°2
En relatif, ces profils sont
indiscernables, mais les taux
d ’erreurs résiduelles sont
très différents
Effort VVT
Page N° 72
36
Principes de la VVT
Page N° 73
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é
Page N° 74
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
Page N° 75
• 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
Page N° 76
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 )
Page N° 77
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
Page N° 78
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.
Page N° 79
Influence de la VVT sur la
productivité et le rendement de
l’organisation de développement
Données économiques
Page N° 80
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
Page N° 81
Management qualité fondée sur la
métrologie des flux d’anomalies
INDICATEURS CARACTÉRISTIQUES
Développement
Maintenance
Flux de modifications
Flux de modifications
en cours de
en cours de
développement
développement
Durée du cycle
Besoin
Conception
RErr/ RA =
Flux d' Erreurs
<1
Flux de Rapports d' Anomalies
Age moyen des RA, Dispersion des RA
Disponibilité (i.e. MTTF, MTTR)
Temps de non régression
Programmation
Intégration
Rodage
Date début
d'exploitation
Relivraisons
Date fin
d'exploitation
Période d'exploitation d'une version du système
Courbe de maturité
Flux continu de défaillances découvertes en exploitation
Coûts chez le fournisseur:
Coûts chez le fournisseur:
• Constitution d'un dossier d'Erreur
• Constitution d'un dossier d'Erreur
(Action Correctrice).
(Action Correctrice).
• Coûts de réparation et de relivraison
• Coûts de réparation et de relivraison
de tout ou partie du système.
de tout ou partie du système.
Taux d’échecs
Filtrage
Deux modes d'exploitation :
Deux modes d'exploitation :
• 1 à qq. sites
• 1 à qq. sites
(i.e. clé en mains)
(i.e. clé en mains)
• Nombreux sites (progiciels)
• Nombreux sites (progiciels)
—> Doublons
—> Doublons
Coûts chez l'exploitant :
Coûts chez l'exploitant :
• Émission d'un Rapport d'Anomalie.
• Émission d'un Rapport d'Anomalie.
• Coûts d'arrêts de l'exploitation.
• Coûts d'arrêts de l'exploitation.
• Pertes d'équipements, humaines,…
• Pertes d'équipements, humaines,…
Bien distinguer dans le MTTR la part
due à la qualité du diagnostic
Page N° 82
41
Coût moyen des corrections
Conception
Programmation
Intégration
VVT
Coût moyen par
phase selon
vade-mecum
40%
20%
40%
Ce qui est
refait selon
vade-mecum
30%
50%
70%
12%
10%
28%
Coût moyen des
corrections
Taux
d’erreurs
acceptable
???
≈ 50%
Domaine de la prévention (amélioration de la productivité)
Page N° 83
Répartition des temps de correction par
défaut
1er Quartile : 8%
%
25%
50%
20%
4%
1%
100 erreurs
Effort moyen par
défaut (en heures)
2h
5h
10h
20h
50h
6.3h/err
Effort cumulé
(en heures)
50h
250h
200h
80h
50h
630h
2ème-3ème Quartile : 40%
4ème Quartile : 52%
Source : Hewlett-Packard
Page N° 84
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
logiciel
1ère mise en service
La différence est
supportée par l’usager du
logiciel et le MCO
Temps
Développement
Exploitation (et plus généralement MCO)
Page N° 85
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
Page N° 86
43
• Modèle d'amplification par phase du
• Prévoir le coût de
cycle de développement
cette détection dans les
ERREURS
COMMISES
DÉFAUTS
PROVENANT
Yi
DES PHASES
PRÉCÉDENTES
ERREURS PROPAGÉES EFFICACITÉ
DE LA
ERREURS AMPLIFIÉES DÉTECTION
DANS LA
PHASE
ERREURS NOUVELLES
xj
tâches du projet
• Identifier les modules
critiques (architecture)
DÉTECTION
DÉFAUTS TRANSMIS
À LA PHASE SUIVANTE
Yj
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)
Page N° 87
Conception
Préliminaire
Conception
Détaillée
Codage
Tests unitaires
Intégration
Modules
Validation
Modules
Intégration
Système
AMPLIFICATION SANS PROCESSUS DE REVUE
0
0
6
0%
10
27x3=81 20%
4x1,5=6 0%
10
25
10
93
0
0
25
37
50%
0
0
15
2
70%
1x1,5=2 50%
10
25
50%
24
0
0
93
AMPLIFICATION AVEC PROCESSUS DE REVUE
3
47
0
0
12
ERREURS RÉSIDUELLES
3
24
5
10x3=30 60%
25
50%
24
0
0
50%
12
0
0
50%
6
0
0
50%
Page N° 88
44
• Application du modèle VEST
Conformité de la
fourniture
Conformité de la
livraison
Pilote de
la tâche
T
Tâche projet à effectuer
E
Tâche(s) amont
S
Flux nominal
et anomalies
imputables à T
V
Validation, vérification,
test
Tâche(s) aval
Flux nominal et
demandes de
modifications
Bilan du processus en terme de
productivité - rendement (COQ et CONQ)
Par rapport à la FINALITÉ
Tâches d ’assurance qualité permettant de détecter
préventivement les défauts et d’éviter leur propagation
Page N° 89
Période de détection/correction
des défauts au moyen de tests
Période d’introduction des erreurs
x1
x2
x3
x4
EB/EC
CG
CD
Codage
Y1
Y2
Y3
Y4
TU
IVVT
Modules
IVVT
Système
Recette
Construction du référentiel de VVT
Scénarios
de tests
Statistique de répartition des défauts (selon B.Beizer,
Software testing techniques)
• EB/EC :
9%
• CG :
26%
• CD :
52% (dont 24% sur les données)
• Codage :
10%
• Tests :
3%
Potentiel de détection des
scénarios de tests fonction du
volume de scénarios (fonctionne
comme un filtre)
• Défaillances les + probables
• Absence de doublon
Page N° 90
45
> × 300
× 150 à 300
× 50 à 150
× 10 à 50
× 4à8
× 2à4
EB/EC
CdCF-1
Documents contractuels
Conception
Développement
Intégration
ORIGINE
= 1
Fournitures contractuelles
Déploiement,
support et MCO
Page N° 91
Coût pour l’usager (1/2)
• Coûts de gestion
Émission de RA, installation des corrections, relivraisons, tests de régression, etc.
• Coûts des interruptions de service
Systèmes « clé en main »
Possibilité d’impact « catastrophique » selon la criticité du système
Exemples : Infrastructures techniques (contrôle aérien,
énergie, communications, réseaux bancaires, défense, etc.)
Progiciels
Existence de contournement selon le niveau de maturité
Systèmes d’exploitation, progiciels système (SGBD, Réseaux,
etc.), progiciels applicatifs, etc.
Page N° 92
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)
Page N° 93
Élaboration et mise en œuvre
d’une stratégie de tests
Page N° 94
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
Page N° 95
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
e2
e3
•••
en
Contour flou si il y a des
progiciels dont le comportement
est mal connu
Fonction ou ensemble
de fonctions à tester
s1
s2
s3
•••
sm
La nomenclature de cet
ensemble est FONDAMENTALE
d1, d2, d3, ••• , dp
Ensemble des variables d’état dont
F hérite et qui influent sur F
Page N° 96
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
Page N° 97
• 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
Page N° 98
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
Page N° 99
• 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
Page N° 100
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)
Page N° 101
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)
Page N° 102
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
Page N° 103
Attributs indispensables d’un intégrat
Exigences fonctionnelles et
non fonctionnelles prises en
compte (FURPSE) + Traçabilité
des exigences
Est documenté
par :
• Documentation de maintenance
• Documentation d’exploitation
• Documentation de support
Est vérifié par :
• Liste des inspections et des
revues effectuées
• Liste des tests + modalités
Est validé par :
• Liste des inspections et des
revues effectuées
• Liste des tests+ modalités
Est géré par :
Rôle des acteurs selon modalités
CRUD étendues (modalités de
déploiement et d’exécution –
Ressources utilisées)
Intégrat
Demandes de modifications :
• Prises en compte
• En attente
• Refusées
Gestion des activités
• Traçabilité inverse
Page N° 104
52
Stratégie d’intégration
Construction d’une chaîne d’intégrats
satisfaisant VEST
Pré-intégration de I1 et I2 prédécesseurs
de I3, I4 et I5
Initialisation
Stimulus en
entrée
Intégrat-I1
Le système est initialisé
(éventuellement par simulation) pour
atteindre les intégrats I3, I4 et I5
Activation de I3
I1/I2
Intégrat-I2
Observation des états successifs des
transformations effectuées par les intégrats
I2/I3
Séparation défaut/défaillance
Intégrat-I3
Défaut diagnostiqué
dans I2
I3/I4
Intégrat-I4
Problème des défauts diffus
dans plusieurs intégrats
Terminaison selon
critères VEST
I4/I5
Intégrat-I5
Défaillance
constatée dans I4
Réponse en
sortie
Le système fournit les résultats
attendus (nominal ou non nominal)
Page N° 105
Stratégie de l’effort de test
• Construction de la matrice du jeu
Situations
possibles
Actions possibles
S1
S2
•••
Sn
A1
A2
A3
•••
Am
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é
Page N° 106
53
Aperçu sur l’intégration des systèmes
informatisés
Aspect logiciel de l’intégration
Page N° 107
Interactions dans le processus
d’intégration (Norme ISO 12207)
System requirements
analysis
Software
requirements analysis
Software detailed
design
System architecture
design
Software architecture
design
Software coding and
testing
Remontée de faits techniques et de rapports
d’anomalies à analyser par les acteurs de l’ingénierie
Conformité VEST
System integration
Software integration
Software installation
System qualification
testing
Software qualification
testing
Software acceptance
support
Conformité VEST
Livraison du système aux
Usagers cible + MCO
Ensemble d’activités IVVT
Intégration, Vérification, Validation et
Test
Page N° 108
54
Le procédé de construction
Livraison partielle pour
démarrer la recette finale
en parallèle
Intégrats rejetés
Flux d’intégrats
Intégration Système
et Logicielle
Test de Qualification
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
Page N° 109
La machine à intégrer (chaîne de
montage) – Assemblage des intégrats
Intégrat-1
Système satisfaisant aux critères
qualité spécifiés dans le cahier
des charges
Intégrat-1.1
...
...
Intégrats de rang 0
issu du
développement et
satisfaisant les
critères VEST
...
Intégrat-n
Étage
d’Intégration
N°1
Scénarios
étage N°1
Intégrats de rang 1
issu de l’étage N°1
et satisfaisant les
critères VEST
...
Intégrat-1.m
Étage
d’Intégration
N°2
Scénarios
étage N°2
Intégrat
Intégrat final
satisfaisant les
critères VEST
Étage
d’Intégration
final
Système
Scénarios
final
Anomalies
Anomalies
Anomalies
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
Page N° 110
55
Construction progressive de la
configuration livrée
Règles de recherche des éléments à intégrer
Livrables des
programmeurs
Éléments complets
vérifiés et validés
Livraisons de l’ingénierie
Éléments complets
partiellement vérifiés et
validés par l’intégration
Génération des
sources
Compilation
Édition de liens
Binaire
exécutable
Éléments complets livrés
par l’ingénierie
Éléments incomplets
livré par l’ingénierie
Bouchons +
Éléments temporaires
simulés
Essais avec les
scénarios de tests
Livrés par l’ingénierie ou
réalisé par l’intégration
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
Page N° 111
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
Page N° 112
56

RAPPELS SUR LES TESTS ET LA VALIDATION

Transcription

Documents pareils

Le squelette humain : les os

GE Capital Solutions, Fleet Services | Paperjam Guide

L`Abbé Joseph-Marie Trèves (1874

Chers participants, Une bonne et une mauvaise nouvelle: depuis

coloriages garcons_portrait.ai

flughafen hahn

Réglement d`accès au MAD

Flamme nue interdite et défense de fumer - E

Licence Commerce Amiens - Bienvenue au Cnam Picardie

Séjour linguistique et culturel à Trèves