Master 1 - Sécurité des Systèmes Informatiques

Cours de Sûreté de Fonctionnement

et Fiabilité des Logiciels

Plan
1. Introduction
2. Défaillances, Erreurs et Fautes
• Elimination des fautes (Tests des Logiciels)
3. Evaluation quantitative (Fiabilité, Disponibilité,
Maintenabilité, …)
4. Méthodes d‘Analyse de Sûreté de Fonctionnement

1
 Tests des Logiciels
Vérification des Logiciels
(Elimination des fautes / Fault removal)

Test des Logiciels 2

La vérification du logiciel
• La vérification du logiciel a pour but de démontrer que les produits logiciels
issus d'une phase du cycle de développement sont conformes aux
spécifications (incluant les exigences légales et réglementaires) établies lors
des phases précédentes.
• Elle a également pour but de détecter et de rendre compte des fautes qui
peuvent avoir été introduites au cours des phases précédant la vérification.
• La vérification du logiciel est composée :
• des tests, partie prédominante pour les logiciels de faible taille,
• des activités de revues et d'analyse. Ces activités peuvent dans certains cas remplacer
certains tests (exemple : un test qui ne pourrait pas être réalisé sans détérioration d'un
composant matériel).

Test des Logiciels 3

Le test du logiciel

• Le test du logiciel est une approche dynamique de la vérification,

destinée à s'assurer que ce logiciel possède effectivement les
caractéristiques requises pour son contexte d'utilisation.
• La première action à entreprendre est donc de décrire avec précision
ce contexte, en particulier les fonctionnalités attendues, les
contraintes d'environnement, ou encore les situations dangereuses à
considérer.

Test des Logiciels 4

Principes de l’activité de tests
• Le test consiste à exécuter le logiciel avec l’intention de découvrir une
erreur.
• Un cas de test (jeu de test) définit un scénario d’exécution, incluant la
valeur des paramètres à fournir au logiciel.
• Un bon cas de test est un cas de test susceptible de déceler la présence
d’une nouvelle erreur.
• Un test est fructueux s’il permet de découvrir une nouvelle erreur.

Test des Logiciels 5

Objectifs de l’activité de tests
Cette activité vise à évaluer la qualité du produit logiciel développé :
• De détecter d'éventuels écarts entre le comportement attendu et le
comportement observé au cours des tests, ce qui élimine un grand
nombre de fautes présentes dans le logiciel.
• Est-il conforme aux résultats des phases d’analyse et de conception ?
• Satisfait-il au cahier des charges ?.
• D'obtenir la confiance nécessaire avant l'utilisation opérationnelle.

Test des Logiciels 6

Remarques :
• La phase de test est une activité essentielle. Il n’est pas rare d’allouer à
cette activité plus de 40 % des ressources totales d’un projet.
• Le test d’un système logiciel peut permettre d’y découvrir des erreurs.
• En revanche, le test est incapable d’établir l’absence de toute erreur !
• Le nombre de fautes détectées ne peut pas être considéré comme un
critère de réussite des tests.
• Le retour d'expérience montre en effet qu'à complexité technique et industrielle constante, un
grand nombre d'erreurs détectées par rapport à d’autres projets « de référence » peut seulement
être interprété comme l'indicateur d'un logiciel contenant un très grand nombre de fautes et non
comme l'atteinte d'un bon taux de détection des fautes présentes.
• Il est donc très difficile d'avoir confiance en un logiciel ayant un grand nombre de fautes détectées
par le test.

Test des Logiciels 7

Remarques :
• Il est illusoire de qualifier un système « complexe » à la seule
observation de son comportement sur un nombre limité de jeux de
tests. Les tests sont essentiels pour détecter des erreurs et améliorer
la confiance dans l'aptitude du système à accomplir sa mission, mais
insuffisants pour « qualifier » le comportement d'un système.
• La présence d’une phase de test au sein d’un cycle de développement
ne dispense pas de respecter les règles de bonne programmation lors
de l’implémentation :
• écriture de code lisible et commenté,
• relecture du code, . . .

Test des Logiciels 8

 Remarques :
• Il existe un risque pour le concepteur de faire définir par une même entité
(individu, équipe), la spécification, la conception, la stratégie de tests et les
cas de tests.
• Deux raisons au moins justifient le recours à un tiers pour tester un logiciel :
• le but des tests est d’exécuter un programme avec l’intention de trouver ses erreurs, ce qui constitue
un processus mental non naturel, difficile à mener par une même entité ;
• le programme peut contenir des erreurs dues à la non compréhension de l’implémentation ou des
spécifications par le développeur. Dans ce cas, il est probable que celui-ci aura ces mêmes « non-
compréhensions» quand il testera son propre programme (mode commun de défaillance).

• La correction des fautes logicielles peut :

• injecter de nouvelles fautes et perturber des parties correctes déjà testées ;
• rendre active une partie du logiciel jusqu'alors inaccessible et donc révéler un grand nombre de
nouvelles fautes, qui ne pouvaient être constatées avant cette correction.

Test des Logiciels 9

Formalisation des tests
• Les documents de test définissent les tests et leur mise en œuvre,
rendent compte des résultats des tests. La formalisation facilite la
vérification de la non régression.
• Le plan de test du logiciel définit l’organisation et l’environnement de
mise en œuvre des tests, décrit la prévision et la planification des
tests.
• Le document de description des tests du logiciel sert de support à
l’exécution des tests. Il décrit les procédures et les outils à mettre en
œuvre. Il définit les jeux d’essais.
• Le rapport des tests du logiciel enregistre, pour chaque jeu d’essai,
les résultats des tests : test OK ou not OK, observations en cours de
tests.
Test des Logiciels 10
Plan du test: Les principales étapes de la démarche
de construction des tests du logiciel
1) Définition préalable des tests à réaliser / Choix des jeux de tests :
conditions initiales, entrées à injecter au logiciel
2) Exécution du logiciel à tester avec les jeux de tests
3) Capture des résultats, des sorties
4) Vérifications / Appréciation des résultats
5) Notification des résultats, conclusions du test dans le rapport de
test.

Test des Logiciels 11

Types de Tests
• Tests statiques : (vérification sans exécution effective)
o Revues logicielles,
o Analyse statique du code
o Simulation (exécution symbolique)
• Tests Dynamiques : basée sur un exécution réelle, mais différèrent par
la technique de choix des jeux de tests
• Tests fonctionnels (de boite noire): tests de cas nominaux, cas aux limites…
• Tests structurels (de boite blanche)
• Tests statistiques : évaluation de la fiabilité
• Tests de surcharge, performance, stress, volume
• Tests de robustesse

Test des Logiciels 12

 Phases des Tests
• Tests Unitaires :
• Tests des unités du logiciel (procédures,
classes)
• Tests d’intégration :
• Tests des composants assemblés à
partir des unités logicielles
• Tests d’interface des unités logicielles
• Tests de compatibilité/d’interopérabilité
entre unités logicielles
• Tests de validation Système :
• Tests du système complet vis-à-vis de
ses spécifications (cahier des charges)
• Tests d’acceptation
Test des Logiciels 13
 Tests unitaires
• Tests unitaires, pour démontrer que chaque module effectue toute la
fonction prévue et seulement cette fonction.
• On peut distinguer dans ces tests unitaires :
• les tests de logique (recherche d'erreur, vérification de l'enchaînement
correct des branches parcourues) ;
• les tests de calcul (vérification des résultats des calculs, des performances,
de l'exactitude des algorithmes).
• Typiquement, les tests de calcul comprennent les tests de données dans
les limites des spécifications (état normal), aux limites spécifiées et en
dehors de ces limites (état anormal).
• Les tests de comportements anormaux (hors limites, erreurs) sont
généralement appelés tests de robustesse.
Test des Logiciels 14
Tests d’intégration

• Tests d’intégration du logiciel, pour démontrer le bon fonctionnement

d'unités fonctionnelles constituées d'un assemblage de modules.
• Ils portent principalement sur la vérification des enchaînements entre
modules, la circulation des données, les aspects dynamiques, les
séquences d'événements prévus et les reprises en cas d'interruption.

Test des Logiciels 15

Tests de validation

• Tests de validation, pour s’assurer que le logiciel implanté dans le matériel

répond aux spécifications fonctionnelles, en vérifiant plus particulièrement
les fonctions générales, les interfaces matériel / logiciel, le fonctionnement
temps réel, les performances, l'utilisation et l'allocation des ressources.
• Cette décomposition du test, reliée au cycle de vie, distingue les tests de
validation du logiciel de ceux du système. Elle montre ainsi clairement qu’il
est nécessaire de vérifier d’une part, la conformité du logiciel à ses
exigences propres et d’autre part, la conformité du système à ses exigences
(les premières étant déduites des secondes).
• Cette distinction ne doit cependant pas conduire à valider le logiciel
indépendamment du matériel sur lequel il est implanté.

Test des Logiciels 16

Test structurel : test en boîte blanche (whitebox
testing)
• Le test en boîte blanche est un procédé qui consiste à construire un
ensemble de cas de test sur base de la structure interne du code à tester.
Principes : Les cas de test sont calculés de façon à :
• garantir que tous les chemins indépendants du code seront exécutés au
moins une fois;
• conduire à des évaluations aussi bien positives que négatives de chaque
condition logique présente dans les instructions de décision du programme.
• exécuter chaque boucle dont l’itération est contrôlée par l’environnement
du programme un nombre de fois correspondant
– aux conditions limites imposées par le logiciel;
– à des valeurs opérationnelles typiques.
• tester l’ensemble des fonctionnalités de chaque structure de données
interne.
Test des Logiciels 17
L’analyse des chemins
• On souhaite construire un ensemble de cas de test garantissant que
chaque instruction d’un module (i.e., méthode, constructeur,
procédure, sous-routine, . . . ) soit au moins exécutée une fois.
• Ce problème se résout de la façon suivante :
1. On dessine le graphe de contrôle G du module à tester;
2. On calcule la complexité cyclomatique V (G) de ce graphe, qui en donne le
nombre maximum de chemins indépendants.
3. On construit une base de G, c’est-à-dire un ensemble de V (G) chemins
indépendants en fonction desquels tout chemin de G peut s’exprimer. Cette
base caractérise les cas de test à choisir.

Test des Logiciels 18

Le graphe de contrôle d’un programme
Ce graphe se construit de la façon suivante :
• Les nœuds du graphe correspondent aux instructions du programme;
• Un arc dirigé relie le nœud n1 au nœud n2 s’il est possible d’exécuter
l’instruction correspondant à n2 immédiatement après celle associée
à n 1;
• Deux arcs distincts ne peuvent pas posséder la même origine et la
même destination.
• Le graphe possède un nœud d’entrée et un nœud de sortie uniques et
distincts.
• Tous les nœuds doivent être accessibles depuis le nœud d’entrée.
• Le nœud de sortie doit être accessible à partir de tous les nœuds.
Test des Logiciels 19
• Un chemin du graphe est une séquence d’arcs permettant de le
traverser depuis son nœud d’entrée jusqu’à son nœud de sortie.
• Un chemin peut également être décrit par la suite de nœuds qu’il
visite.
• Les chemins admettent une représentation vectorielle : Chaque arc du
graphe de contrôle est associé à la valeur unitaire d’une composante
vectorielle qui lui est propre, et le vecteur représentant un chemin
s’obtient par addition de tous les arcs composant le chemin.

Test des Logiciels 20

Exemple :

Test des Logiciels 21

Les chemins indépendants
• La représentation vectorielle des chemins nous permet de définir
formellement une notion d’indépendance entre chemins :
• Un ensemble de chemins est indépendant si leurs représentations vectorielles
sont linéairement indépendantes.
• Exemple : Dans la figure précédente, les chemins 1 = (a; b; c; g), 2 =
(a; b; c; b; c; g) et 3 = (a; b; e; f; g) sont indépendants.
• En revanche, les chemins 1, 2, 3 et 4 = (a; b; c; b; e; f; g) ne sont pas
indépendants. En effet,
4 = 2 + 3 − 1.

Test des Logiciels 22

La complexité cyclomatique
• La complexité cyclomatique V (G) d’un graphe de contrôle G est
définie comme suit : V (G) = E − N +2,
où
- E est le nombre d’arcs du graphe,
- N est le nombre de nœuds du graphe.
• Théorème : La complexité cyclomatique d’un graphe de contrôle est
égale au nombre maximum de chemins indépendants dans ce graphe.
• Exemple :
• Pour le graphe de contrôle de la figure précédente, on a N = 7 et E = 10.
• La complexité cyclomatique de ce graphe est donc égale à 5.

Test des Logiciels 23

Remarques :
• La complexité cyclomatique est souvent utilisée comme métrique
permettant d’évaluer la complexité d’une partie de code.
• Il est généralement admis qu’un module possédant une complexité
cyclomatique supérieure à 10 doit être réécrit (sauf dans le cas d’une
décision simple possédant un grand nombre de branches).
• La complexité cyclomatique d’un graphe de contrôle G ne
comprenant que des décisions binaires obéit à la relation :
V (G) = D +1,
où D est le nombre de nœuds de décision.

Test des Logiciels 24

• La complexité cyclomatique d’un graphe planaire (i.e., pouvant être
dessiné dans un plan sans que ses arcs ne se croisent) est égale aux
nombre de régions délimitées par les arcs dans un dessin plan du graphe.
• Exemple :

Test des Logiciels 25

Les bases d’un graphe de contrôle
• Etant donné un graphe de contrôle G, il est toujours possible d’en
extraire V(G) chemins tels que l’ensemble de leurs combinaisons
linéaires couvre l’ensemble des chemins de G.
• Un tel ensemble de V (G) chemins est appelé base du graphe.
• Exemple : Le graphe de contrôle du premier exemple possède la base
{(a; b; c; g), (a; b; c; b; c; g), (a; b; e; f; g), (a; d; e; f; g), (a; d; f; g)}.
• Si on connait la complexité cyclomatique d’un graphe de contrôle,
alors une base de ce graphe peut être obtenue incrémentalement : Il
suffit de rechercher successivement 1, 2, . . . , V(G) tels que pour
tout i{2, 3, …, V (G)}, les chemins 1, 2, . . . , i soient indépendants.

Test des Logiciels 26

L’analyse des boucles
• Si le graphe de contrôle du module à tester possède des boucles dont
le nombre d’itérations peut être contrôlé par l’environnement, alors
on construit un certain nombre de cas de test visant à évaluer la
validité de ces boucles.
• Le procédé utilisé dépend de la nature des boucles :
• Boucle simple pouvant être exécutée jusqu’à n fois :
– On ne passe pas dans la boucle.
– On passe une seule fois dans la boucle.
– On passe m fois dans la boucle, avec m fixé tel que 1< m < n.
– On passe n − 1, n et n+1 fois dans la boucle.

Test des Logiciels 27

Boucles imbriquées :
1. On teste la boucle la plus interne (en la considérant comme une
boucle simple), tout en effectuant le nombre minimal d’itérations
des autres boucles.
2. On teste ensuite la boucle suivante (en procédant de l’intérieur de
l’imbrication vers l’extérieur). A chaque étape, on exécute un
nombre minimal de fois les boucles extérieures à la boucle testée,
et un nombre typique de fois les boucles intérieures.
3. On répète le point précédent jusqu’à avoir testé l’ensemble des
boucles.
• Boucles concaténées : Si les boucles sont indépendantes (i.e., si leurs
nombres d’itérations ne sont pas corrélés), on teste séparément
chaque boucle comme une boucle simple. Dans le cas contraire, on
procède comme pour les boucles imbriquées.
Test des Logiciels 28
Test Fonctionnel : Test en boîte noire (blackbox
testing)
• Le test en boîte noire consiste à analyser un système logiciel à travers
son interface. L’objectif de ce test est de déterminer si le système
satisfait ou non à ses exigences fonctionnelles.
• Note : Le test en boîte noire est complémentaire au test en boîte
blanche et ne le remplace pas !
• Les erreurs que le test en boîte noire vise à déceler, appartiennent
aux catégories suivantes :
les fonctionnalités absentes ou incorrectement implémentées,
les erreurs d’interface,
les erreurs dans les structures de données,
les défauts de performance,
les erreurs d’initialisation ou de terminaison.

Test des Logiciels 29

• Le test en boite noire s’effectue en construisant un ensemble de cas
de test représentatif des différentes possibilités d’utilisation. Les cas
de test peuvent se déterminer sur base des indications suivantes :
• Chaque fonctionnalité définie dans le cahier des charges ou dans le
modèle logiciel doit être couverte par au moins un cas de test.
• Si les données d’entrée du logiciel conduisent à plusieurs
comportements différents (perceptibles par l’environnement), alors
chacun de ces comportements doit faire l’objet d’au moins un cas de
test.
• Si certaines données d’entrée du logiciel sont accompagnées d’un
intervalle de validité, alors des cas de test doivent être créés pour les
valeurs immédiatement inferieures, égales et immédiatement
supérieures à chaque borne de l’intervalle.

Test des Logiciels 30

La régression
• Les tests effectués au sein d’un cycle de développement ne se
limitent pas uniquement aux fonctions du système qui ont été
ajoutées ou adaptées au cours de ce cycle.
• En effet, il est fréquent que des modifications, des ajouts de code ou
des corrections d’erreurs introduisent à leur tour de nouvelles
erreurs.
• Le test de régression consiste à vérifier lors de la phase de test de
chaque cycle que l’ensemble des tests effectués depuis le début du
processus de développement restent valides.
• Une façon simple de réaliser ce test de régression consiste à
maintenir une bibliothèque de tous les cas de test utilisés, et à les
valider grâce à un outil automatique.

Test des Logiciels 31

La régression modulaire
• Si le système développé est complexe ou de grande taille, la validation
directe de l’ensemble des cas de test appartenant à la bibliothèque de
régression peut nécessiter des ressources trop importantes.
• Une solution consiste alors à effectuer un test de régression modulaire,
qui permet de limiter le nombre de tests inutiles.
• Principe : On analyse séparément chaque module du système, en ne
testant que ceux dont le comportement a pu être affecté par une
modification survenue après leur dernier test.
• Supposons que le système contienne un composant logiciel P dont le
comportement est entièrement déterminé par les échanges
d’information effectués à son interface (i.e., la même séquence de
données d’entrée conduit toujours aux mêmes valeurs de sortie).

Test des Logiciels 32

• Si un cycle de développement conduit à modifier P, on effectue les
opérations suivantes :
1. Avant la modification. On enregistre l’ensemble des données
fournies à P ou consultées par celui-ci au cours des tests déjà
effectués, ainsi que les données produites en retour par P.
2. Après la modification. On exécute la nouvelle implémentation de P
en lui fournissant les données d’entrée précédemment enregistrées.
On vérifie que les données produites sont identiques à celles
observées avant la modification.
En cas de différence, l’ensemble des composants dépendant directement ou
transitivement de P doivent être retestées.

Test des Logiciels 33

 Remarque : Tolérance aux Fautes
• Contrairement aux tests qui visent à éliminer les fautes, les techniques de tolérance aux
fautes visent à faire fonctionner le système même en présence des erreurs :
• Traitement des Erreurs (Error Processing) : Elimination des états d’exécution erronés
• Détection des erreurs et recouvrement (Error detection and recovery) : recouvrement de l’état
correct à partir de l’état erroné
• Arrière (Backward) : retour à un état sauvegardé antérieurement (Recovery points)
• Avant (Forward) : génération d’un nouvel état à partir duquel le système pourrait opérer (mode dégradé)
• Compensation des Erreurs (Error compensation) :
• Redondance permet la délivrance d’un service correct
• Fault masking : vote de majorité
• Traitement des Fautes (Fault Treatment)
• Diagnostic des fautes (Fault diagnosis) : déterminer la cause de l’erreur
• Déterminer la localisation de la faute et de sa nature
• Passivation des fautes (Fault passivation) : prévenir la faute d’être réactivée
• enlever les composants fautifs
• Sinon, reconfiguration du système

Test des Logiciels 34