14/10/2023

Introduction
Vérification &Test Logiciel
MP1 _ GL AU 2021 /2022

1 2

1 2

Vérification : Objectifs et Intérêt Vérification : Objectifs et Intérêt

Vérification et Validation ou V&V : ensemble d’activités
exécutées en parallèle du développement d’un système
logiciel afin de fournir l’assurance qu’il fonctionnera
conformément à un ensemble d’exigences / spécifications /
besoins utilisateur.
• Vérification : il s’agit de comparer certaines propriétés intrinsèques du logiciel à des standards, procédures,
politiques, process, exigences, spécifications : « am I building the product right ? »
• Validation : ici on compare le contenu informatif du produit à des propriétés extrinsèques : fait-il ce pour quoi il
a été conçu ? satisfait-il les besoins du client : « am I building the right product ? »

Le processus de V&V évalue le logiciel dans un contexte

système par une approche structurée : le logiciel est testé en
interaction avec les fonctionnalités du système, le contexte
d’utilisation (hardware, OS), les interfaces logicielles
(bibliothèques par exemple) et l’utilisateur. Il s’inscrit
naturellement dans le cycle en V classique de développement
de systèmes logiciels.

3 4

3 4
 14/10/2023

Objectifs de la vérification de logiciel Objectifs de la vérification de logiciel

La vérification a pour objectif principal de construire des systèmes ayant un minimum de défauts. La vérification a pour objectif principal de construire des systèmes ayant un minimum de défauts.
Les défauts interviennent typiquement à différents niveau dans le cycle en V : Les défauts interviennent typiquement à différents niveau dans le cycle en V :

• Défaut dans les spécifications (amont) : une fonctionnalité attendue a été oubliée ou mal spécifiée • Défaut dans les spécifications (amont) : une fonctionnalité attendue a été oubliée ou mal spécifiée
• Défaut dans la conception : la réalisation d’une fonctionnalité ne satisfait pas à ce qui a été spécifié • Défaut dans la conception : la réalisation d’une fonctionnalité ne satisfait pas à ce qui a été spécifié
• Défaut de codage (aval) : l’implantation de la fonctionnalité n’a pas été faite en accord avec sa conception • Défaut de codage (aval) : l’implantation de la fonctionnalité n’a pas été faite en accord avec sa conception

Remarque :

Plus le défaut est introduit en amont, plus son impact potentiel est grand et sa correction coûteuse. Il s’avère donc
indispensable d’adopter une méthodologie de vérification qui permette de détecter les défauts au plus tôt après leur
introduction, par exemple en vérifiant chaque étape du cycle en V avant de passer à l’étape suivante.

5 6

5 6

Quand vérifier ? Quand vérifier ?

La vérification fait partie intégrante du développement du logiciel, notamment parce que vérifier a posteriori qu’un
logiciel répond à certaines exigences est infiniment plus coûteux que de procéder de manière structurée et La vérification d’un niveau se fait conformément aux
incrémentale, et que la qualité d’un logiciel vérifié en parallèle de son développement est bien supérieure. exigences héritées du niveau supérieur, elles mêmes
issues au final des exigences systèmes initiales.
Lors de la descente du cycle en V (spécification, conception, développement), il s’agit de vérifier que les différents
modèles décrivant le système final et ses sous-systèmes satisfont bien aux exigences définies par le niveau de Lors de la phase remontante du cycle en V, les sous-
modélisation supérieur : systèmes sont intégrés de manière incrémentale pour
aboutir au système final. A chaque étape, les sous-
• les spécifications doivent répondre aux exigences systèmes systèmes sont supposés remplir correctement des sous-
• les modèles de conception doivent réaliser les fonctionnalités spécifiées fonctions, et l’on cherche à vérifier que leur combinaison
• le code doit fournir une implantation correcte des modèles de conception permet de réaliser les fonctionnalités de plus haut
niveau.

7 8

7 8
 14/10/2023

Comment vérifier ? Comment vérifier ?

La vérification se base sur des processus spécifiques tout au long du cycle de développement. La vérification se base sur des processus spécifiques tout au long du cycle de développement.
Il existe des technologies outillées qui ont pour objectif d’assurer formellement le développement et la vérification Il existe des technologies outillées qui ont pour objectif d’assurer formellement le développement et la vérification
parallèle de la partie logicielle d’un système. parallèle de la partie logicielle d’un système.

Il est cependant fréquent que les différentes étapes du développement soient chacune associée à un ensemble de
processus ad hoc pour vérifier leurs exigences : le test, la preuve de programme et le model checking en sont des
exemples. Une difficulté est alors d’assurer la cohérence entre les différents niveaux de description du système.
D’autre part, une grande part de la vérification est réalisée par l’utilisation de méthodologies que l’on peut qualifier
de transversales. En vrac on peut citer :

• Règles de codage (par exemple MISRA 2 pour le monde automobile) : généralement pour interdire des
constructions jugées dangereuses pour des langages comme C ou C++
• Revue par les pairs : les autres concepteurs/développeurs effectuent des relectures critiques des modèles/codes,
dans un processus qui peut être formalisé
• Utilisation d’outils de génie logiciel : gestionnaire de versions, bug tracking systems , . . .
• Environnement d’automatisation des tests : faciliter leur écriture, automatiser leur exécution (non-régression) 10
9

9 10

Pourquoi vérifier ? Bonnes pratiques

• la vérification a avant tout un intérêt économique crucial pour l’industrie du logiciel. Des études ont chiffré les Pour un développement classique de logiciel, certaines pratiques de développement et de vérification sont
gains potentiels d’une activité de test bien menée à plusieurs milliards de dollars pour l’industrie du logiciel communément admises comme ayant fait leur preuve du point de vue du rapport entre leur coût et leur gain en
mondiale. terme de qualité. L’état de l’art prône principalement :

• Il existe donc un intérêt économique évident à la vérification, qui permet de produire plus rapidement des logiciels
de meilleure qualité.
• Certains domaines d’activité industrielle ayant une composante logicielle non négligeable (aéronautique,
ferroviaire, nucléaire civil et médical) voient leur processus de mise sur le marché de nouveaux produits soumis à
des autorités de certification.
• La vérification en profondeur de l’ensemble des exigences du logiciel
• La revue par des pairs (« peer-review ») des spécifications et des documents et modèles de conception
• La vérification en profondeur des implantations critiques, la revue pour le reste du code
• Le test unitaire (fonction par fonction) systématique avec une bonne qualité de couverture, et en général la
réalisation et l’exécution d’un plan de tests pertinent (pour les tests d’intégration, les tests du système . . . )

• Le logiciel de ces systèmes doit obligatoirement avoir été développé selon certaines normes et/ou satisfaire à une
certaine mesure de qualité. Certifier le logiciel de ces systèmes sans processus de vérification adapté est
généralement illusoire.

11 12

11 12
 14/10/2023

Bonnes pratiques Mesures de la qualité d’un logiciel

De bonnes pratiques de génie logiciel (Makefile, gestionnaire de version, bug-tracking, qualité de la documentation, La mesure de la qualité d’un logiciel peut se faire selon plusieurs dimensions, qui ne relèvent pas toutes de la
automatisation des tests de non-régression . . . ) contribuent également à la qualité du logiciel et facilitent sa vérification.
vérification.
En termes opérationnels, la qualité se mesure selon les axes suivants :
La mise en œuvre de telles pratiques permettrait de générer les performances théoriques suivantes (en partant d’une
situation sans systématisation du test, sans revue par les pairs, et à ne pas prendre trop au sérieux) : • Correction, fiabilité, sûreté : le logiciel réalise-t-il les fonctions demandées et à quel niveau ?
• Intégrité, sécurité : résiste-t-il aux attaques intentionnelles ou aux maladresses de l’utilisateur ?
• 70-90% des défauts détectés avant la phase de test • Efficacité, performance : quelles ressources le logiciel requiert-il (temps, mémoire) ?
• Ratio 7-12x de retour sur investissement • Facilité d’utilisation
• Réduction du time-to-market de 10-15% par an
• Productivité doublée en 5 ans La vérification se préoccupe principalement de la correction, fiabilité, sûreté voire sécurité du logiciel. Les aspects de
performance peuvent également être vérifiés (par exemple politique d’ordonnancement et analyse du pire temps
Ces bonnes pratiques contribuent globalement à la qualité d’un logiciel. d’exécution pour les logiciels temps-réel).

13 14

13 14

Mesures de la qualité d’un logiciel Mesures de la qualité d’un logiciel

La mesure de la qualité d’un logiciel peut se faire selon plusieurs dimensions, qui ne relèvent pas toutes de la La mesure de la qualité d’un logiciel peut se faire selon plusieurs dimensions, qui ne relèvent pas toutes de la
vérification. vérification.

La qualité du logiciel se mesure également en terme de facilité de développement et d’évolution, qui jouent un rôle
important du point de vue de l’aspect pratique de la vérification, et de la vérification des évolutions d’un logiciel :
• Maintenabilité : facilité à détecter et corriger des erreurs
• Flexibilité : facilité à faire évoluer le logiciel ou l’adapter
• Testabilité : facilité à dérouler une campagne de test
La qualité d’un logiciel peut également être évaluée sous l’angle de l’intégration :
• Interopérabilité : capacité à interagir avec d’autres systèmes
• Réutilisabilité de tout ou partie
• Portabilité vers d’autres plateformes (OS, application, micro-contrôleurs . . . )

15 16

15 16
 14/10/2023

Répartition des efforts dans le domaine logiciel Répartition des efforts dans le domaine logiciel

Le tableau qui suit décrit l’évolution de la répartition des efforts (pour chaque étape du cycle en V) dans l’industrie du
logiciel au cours du temps.
Quelques remarques concernant cette évolution :
• Il y a eu une prise de conscience par l’industrie du logiciel du coût élevé de la vérification tardive : l’effort global
s’est réparti plus amont
• Cette prise de conscience a favorisé l’émergence de modèles de conception et de langages de spécifications, qui en
retour a favorisé l’investissement dans l’effort de conception
• Les systèmes étant de plus en plus gros et intégrés, les phases de test d’intégration et de test systèmes sont
devenues plus coûteuses
• Le test est maintenant vu comme une activité à part entière, au coût toujours conséquent (un tiers du coût total)
• La phase de capture des exigences nécessite un effort important et souvent incompressible, notamment du fait de
la complexité des systèmes produits

17 18

17 18

Vérification Formelle : définition

C’est la vérification mathématique « exhaustive» de sa correction : On cherche à prouver au sens mathématique

que l’implantation (vue comme un modèle logique) satisfait à sa spécification (vue par exemple comme un ensemble
Vérification & de formules logiques).

La vérification formelle est une activité complexe.

méthodes formelles • La difficulté technique d’extraction d’un modèle depuis un programme ou de formules logiques depuis des
spécifications (souvent semi-formelles). Cette extraction doit se faire de manière sûre bien entendu.

• La difficulté d’arriver à faire la preuve que le modèle extrait satisfait bien aux formules qui correspondent à la
spécification requise.
Envisager une preuve manuelle complète est souvent tout à fait hors de question, la taille du modèle étant
rédhibitoire.
Envisager une preuve automatique à l’aide d’un ordinateur un problème tout à fait indécidable (il n’y a pas
de logiciel magique qui serait capable de prouver automatiquement la correction de tout logiciel).
19 20

19 20

Vérification Formelle : définition
La vérification formelle est une activité complexe.
• Le problème ne pouvant être résolu dans toute sa généralité.
• L’importance de combiner divers choix techniques
1. Vérification par la preuve assistée
2. Vérification par sur-approximation : techniques d’abstraction
3. Vérification par sous-approximation : le test
21
21
Vérification par sur-approximation : techniques d’abstraction
Il existe différentes techniques travaillant par sur-approximation :
Interprétation abstraite : il s’agit d’un cadre général qui permet d’associer une sémantique abstraite à un
programme qui soit une généralisation de sa sémantique concrète, ceci en fixant un domaine abstrait de
représentation des traces d’exécutions. On peut par exemple choisir un domaine abstrait de représentation des
variables (ex : intervalles), et choisir d’abstraire un chemin d’exécution par le point de contrôle qu’il atteint.
Il s’agit d’un cadre particulièrement adapté à la preuve automatique de l’absence de « runtime-errors » : division par
zéro, dépassement de capacité, accès hors bornes d’un tableau, déréférencement d’un pointeur invalide. Il permet en
effet de traquer avec une grande précision les valeurs potentielles qu’une variable peut prendre en chaque point du
graphe de contrôle. Dans les faits, une grande expertise est requise pour obtenir au final une abstraction fidèle du
programme initial, sans trop de faux positifs (valeurs du domaine abstrait posant problème et ne correspondant à
aucune exécution concrète), et sans utiliser dès les départ des domaines trop précis dont le coût lors de l’analyse
devient prohibitif (en temps et mémoire).
23
23
14/10/2023
Vérification par sur-approximation : techniques d’abstraction
La complexité d’un logiciel est liée à la complexité des comportements associés, généralement corrélés à sa taille,
mais pas uniquement. La présence de boucles, l’utilisation de structures de données ayant des invariants complexes,
le recours à des types de données flottants contribuent parmi d’autres à la complexité du logiciel. Cette complexité
se reflète dans ce qui est appelé la sémantique opérationnelle du programme, qui définit un système de transitions
généralement infini décrivant l’ensemble des traces d’exécution possibles (séquence des états mémoire). L’idée
générale est d’abstraire ce système de transition par un système « essentiellement fini », qui en soit une sur-
approximation (toutes les traces d’exécutions sont représentées). Il est alors possible d’essayer de prouver les
propriétés requises sur cette vue abstraite, simplifiée par rapport à la vue concrète de la sémantique opérationnelle.
Le point crucial est qu’une propriété prouvée sur la vue abstraite sera correcte sur la vue concrète. En revanche, une
propriété qu’on n’arrive pas à prouver sur l’abstraction ne sera pas forcément incorrecte sur la vue concrète, puisque
la sur-approximation a pu introduire des comportements illicites du point de vue de la propriété à prouver mais
qui n’existaient pas initialement.
Il existe différentes techniques travaillant par sur-approximation.
22
22
Vérification par sur-approximation : techniques d’abstraction
Il existe différentes techniques travaillant par sur-approximation :
Model checking : il s’agit cette fois de choisir un certain type de modèle (généralement à base d’automates finis
étendus avec des types de données simples) pour lequel il existe un algorithme permettant de vérifier la classe de
propriétés visées (souvent exprimées en terme de logique temporelles, décrivant des enchaînements complexes
d’actions). Une première difficulté est de parvenir à abstraire le logiciel vers ce type de modèle, automatiquement
dans l’idéal. Les limitations fortes sur le pouvoir d’expression des modèles obligent souvent à des abstractions
relativement grossières. Une autre difficulté majeure est le problème du passage à l’échelle en fonction de la taille
du modèle et de la complexité de la propriété à vérifier, les algorithmes de vérification étant en général exponentiels.
Les outils de model checking existant sont plutôt issus du monde académique.
De manière générale, toutes les techniques dites d’analyse statique (analyse d’un logiciel à partir de ses sources)
travaillent par sur-approximation. Par exemple : algorithmes de calcul de dépendances de données et autres
algorithmes dataflow utilisés dans les compilateurs.
24
24
 14/10/2023

Vérification par sous-approximation : le test logiciel Vérification par sous-approximation : le test logiciel

• Ne pas faire une vérification exhaustive du logiciel. Difficulté & Mesures de qualité

• Essayer de mettre le modèle en défaut par rapport à une propriété de la spécification.
• Effectuer le test sur le logiciel final, ou des sous-parties du logiciel (modules, fonctions), ou sur des modèles du
logiciel. La qualité première du test est de permettre de révéler des défauts avec une grande précision et à
moindre coût, mais jamais de garantir qu’il n’y ait aucun défaut.
• Parvenir à identifier un ensemble de tests (ou suite de tests) suffisamment pertinent pour se convaincre de la
correction du logiciel.
• Impossible de prouver qu’un programme est correct en n’utilisant que des techniques de test, puisqu’il s’agit d’une
technique qui explore seulement une sous-approximation des comportements.

• Mesurer la qualité d’une suite de tests, ce qui se fait généralement en terme de couverture d’un certain critère.

• Les critères les plus courants au niveau du test de code sont le taux de couverture des instructions ou
• des branches (décisions).

25 26

25 26

Vérification par sous-approximation : le test logiciel

Attention

Le test n’est pas une technique de vérification formelle à proprement dit : Il ne permet pas à lui seul de conclure.

La technique de vérification
• la plus universellement adoptée,
• la moins coûteuse en terme de défauts trouvés par rapport à l’effort investi Test de Logiciel
• la mieux outillée (environnement de tests comme JUnit, automatisation des tests).

27 28

27 28
 14/10/2023

Le test logiciel Le test logiciel

Importance Importance

Le test est une activité cruciale dans le monde du logiciel, comme l’attestent les données chiffrées suivantes :
– le poids de l’activité du test dans l’industrie du logiciel aux USA s’élève à plusieurs dizaines de milliards de
dollars par an
– en moyenne, le test représente 30%du coût de développement d’un logiciel standard
– pour un logiciel critique (avionique, nucléaire, médical, transport), cette part moyenne monte à 50 %
Le test est l’activité de V&V dominante, la phase remontante du cycle en V correspond principale à l’exécution
de tests. Même si un code a été prouvé formellement, le tester reste indispensable : notamment car on teste
l’implantation alors qu’on ne prouve que des modèles.
Citation de Donald Knuth : « Beware of bugs in the above code ; I have only proved it correct, not tried it ».
Le test est la technique la moins coûteuse et la plus efficace pour capturer une grande partie des défauts
d’implantation (bugs) et on ne peut donc pas s’en priver.

29 30

29 30

Le test logiciel Le test logiciel

Définitions Définitions

« Le test est l’exécution ou l’évaluation d’un système ou d’un composant par des moyens automatiques ou
manuels, pour vérifier qu’il répond à ses spécifications ou identifier les différences entre les résultats attendus
et les résultats obtenus » IEEE
« Tester, c’est exécuter le programme dans l’intention d’y trouver des anomalies ou des défauts » G. Myers
Le test est une méthode de vérification partielle : le test exhaustif d’un programme en injectant toutes les
entrées possibles n’est en général pas possible. On ne prouve pas qu’un programme est correct par le test seul.
« Testing can only reveal the presence of errors but never their absence » E. W. Dikjstra
Tester sert avant tout à améliorer la qualité du logiciel, ce qui permet de réduire les coûts de développement et
de maintenance

31 32

31 32

Le test logiciel
Propriétés
Tester consiste à stimuler un maximum des comportements d’un logiciel, en gardant à l’esprit qu’on cherche à
minimiser le nombre de tests (et surtout leur redondance) et à maximiser leur pertinence (en exécutant des
tests révélant des défauts réellement impactant).
Le test est une méthode dynamique, dans la mesure où l’on exécute réellement le programme, contrairement
aux techniques par analyse statique, où seul le source est examiné pour déterminer la correction du
programme.
33
33
Le test logiciel
Perspectives du test
Le test comme technique permettant de trouver des défauts a déjà beaucoup été évoqué.
Idéalement, cette recherche de défauts se fait au plus tôt, en parallèle du développement. C’est
particulièrement aisé et conseillé à un niveau « test unitaire », le développeur écrivant les tests en
parallèle de la fonction qu’il code, et s’aidant de ces tests pour corriger les bugs rencontrés jusqu’à
satisfaction. Le test est donc vu comme un moyen de mettre le programme en défaut (test-to-fail) et
l’on aboutit naturellement à l’obtention d’une suite de tests de non-régression.
35
35
14/10/2023
Le test logiciel
Infrastructure de test
L’infrastructure de test est l’ensemble des outils et processus permettant de mettre en oeuvre une politique de
test.
La qualité d’une infrastructure de test se mesure selon les critères suivants :
– Temps de détection des défauts après leur introduction (le plus court étant le mieux).
Des tests pertinents doivent être écrits et exécutés dans un délai très court après l’introduction de nouveau
code .
–Précision sur la détermination de l’origine d’un défaut. L’échec d’un test doit fournir un retour suffisant pour
que l’origine du problème puisse être tracée précisément.
–Capacité à caractériser l’impact système d’un défaut. Celà permet de classifier la correction des défauts par
ordre de priorité. Le coût induit par des infrastructures de test inadéquates du point de vue de ces critères est
estimé à plusieurs dizaines de milliards de dollars par an.
34
34
Le test logiciel
Perspectives du test
Les suites de tests étant écrites par le développeur, on parle aussi de test « boîte blanche » car le développeur à
non seulement connaissance de la spécification de la fonction mais également de son implantation. On peut
jauger la qualité de cette suite par sa capacité à capturer des défauts lors des évolutions du code, lorsque
l’implantation évolue mais que les interfaces et spécifications restent les mêmes.
Le test peut également être vu comme un processus d’assurance qualité (validation testing) voire comme
participant à la certification du logiciel. L’idée est de contrôler la qualité d’un logiciel, pour soi ou un tiers
(autorité de certification), dans la phase ascendante du cycle en V, généralement en boîte noire (connaissance
des spécifications mais pas de l’implantation du logiciel), et par des équipes dédiées.
Cette utilisation du test est typique dans les industries développement des systèmes embarqués critiques. Le
test est alors vu comme un moyen de confirmer le bon fonctionnement du logiciel (test-to-pass).
36
36
 14/10/2023

Le test logiciel Le test logiciel

Processus de test Processus de test

Un scénario de test correspond à un chemin fonctionnel (issu des spécifications) que l’on cherche à exercer. Il
s’agit de définir une suite d’actions (les entrées du test) ainsi que l’ensemble des réponses censées être
déclenchées en retour.
Le domaine des entrées d’un programme est l’ensemble de ses entrées possibles : variables globales,
paramètres de fonctions, actions venues de l’extérieur . . . Chaque entrée est associée à un domaine de valeurs
possibles (domaine de définition), qui est un sous-ensemble du domaine de valeurs que définit le type de
l’entrée.
Un cas de test est l’association d’un scénario de test, des données de test le déclenchant et d’un oracle décidant
de sa réussite. Il s’agit donc d’une étape dans la concrétisation d’un scénario de test.
Un script de test est un mécanisme (en général un programme dédié ou un script shell) en charge d’exécuter les
cas de tests qui ont été définis pour le logiciel sous test, et de recueillir les résultats (on parle aussi de verdict de
test, suivant que l’oracle soit satisfait ou non pour chaque cas de test).

Les données de test associent à chaque entrée d’un programme une valeur choisie dans son domaine de
définition, ceci dans l’optique d’exercer un scénario de test.

Un oracle est un mécanisme permettant de décider la réussite d’un scénario de test, c’est à dire de déterminer
si les réponses obtenues à l’exécution du test correspondent bien à ce que requiert le scénario.
37 38

37 38

Le test logiciel Le test logiciel

Process simplifié du test Process simplifié du test

Le processus de test suit les étapes suivantes :

1. identification des scénarios à tester

2. détermination des oracles de chaque scénario
3. génération (manuelle ou automatique) des données de test de chaque scénario :
on dispose alors d’une suite de cas de test couvrant tous les scénarios
4. création et exécution d’un script de test évaluant le programme sur l’ensemble des cas de tests
5. comparaison des résultats obtenus aux oracles
6. émission d’un rapport de test décrivant les cas de tests ayant réussis et ceux ayant échoués

39 40

39 40

Le test logiciel
Process simplifié du test
L’identification des scénarios à tester s’effectue lors de l’élaboration des plans de test, en parallèle des phases
de conception et de codage correspondantes.
La détermination des sorties attendues se fait de manière conjointe, mais les oracles utilisés au final nécessitent
généralement d’être concrétisés de manière plus précise que cela n’est possible en conception. Il faut en
particulier être capable de traduire les entrées, sorties et observables tels que définis au niveau des
spécifications en tant qu’éléments concrets de l’implantation finale.
41
41
Le test logiciel
Scripts de test
Un script de test peut schématiquement être décomposé de la manière suivante :
–Préambule : le programme est amené dans la configuration voulue pour un ou plusieurs cas de test, ceci en
appelant un certain nombre de fonctions d’initialisations et de constructeurs. Il peut par exemple s’agir
d’allouer un certain nombre d’objets ayant certaines dépendances, d’initialiser les tables d’une base de données
avec certaines entrées, d’émettre ou de recevoir un ensemble de messages dans le cadre d’un protocole . . .
–Corps : le script exécute les fonctions sous test avec les données de test qui ont été
générées.
43
43
14/10/2023
Le test logiciel
Process simplifié du test
La génération des données de test, qu’elle soit manuelle ou automatique, constitue une activité à part entière
du test.
L’activité d’exécution des tests prend place lors de la phase remontante du cycle en V, au contraire des activités
précédentes. Evidemment un constat d’échec à ce niveau implique des corrections sur le code, la conception ou
les spécifications du système suivant la phase de test où l’on se trouve alors. La conception des tests eux-
mêmes peut bien évidemment être en cause. La capacité à émettre des rapports de test informatifs est cruciale
afin de pouvoir détecter le plus précisément possible l’origine de la divergence constatée.
42
42
Le test logiciel
Scripts de test
Un script de test peut schématiquement être décomposé de la manière suivante :
–Identification (facultatif) : le script peut effectuer un certain nombre d’opérations d’observation qui vont
permettre de faciler l’évaluation de l’oracle. Le scénario de test peut en effet nécessiter d’observer des actions
effectuées en cours d’exécution du test, et non pas simplement le résultat final. Le script de test doit donc
permettre de tracer les actions requises, ou de voir l’évolution des valeurs de certaines variables globales. Cela
n’est possible que si le programme sous test rend ces données effectivement observables.
–Postambule : le script réinitialise le programme dans un état initial, par exemple l’état obtenu juste après
exécution du préambule, ceci afin de permettre d’enchaîner avec les tests restant. Il peut par exemple s’agir
d’effectuer un rollback des requêtes émises par le corps du test dans le cadre du test d’une base de données.
44
44

Le test logiciel
Environnement de test unitaire
Les caractéristiques principales d’un environnement de test unitaire sont :
– le code de test est développé dans des fichiers distincts du code de développement, qui n’est donc en aucun
cas modifié par l’ajout de tests (requis pour les systèmes critiques)
–les préambules, corps et postambules sont des fonctions virtuelles à définir dans les classes implantant
effectivement les cas de test (généricité)
– l’oracle est implanté par l’utilisateur en utilisant tout la puissance du langage de base, ainsi que des facilités
offertes par l’environnement de test
–l’environnement de test peut proposer un environnement d’exécution facilitant la mesure de la qualité des
tests (sous forme de couverture atteinte).
45
45
Le test logiciel
Mesure de la qualité d’une suite de tests
On peut également baser la mesure de couverture sur le taux de détection de mutants du logiciel sous test. Un
mutant est un quasi-clone du programme, dans lequel seul un petit nombre d’instructions (souvent une seule)
a été modifié.
On peut par exemple choisir de remplacer un opérateur de comparaison < par <= ou un = par un !=.
Les transformations effectuées pour obtenir les mutants se basent sur un modèle des fautes les plus probables
commises par le programmeur, fautes qui devraient être à même d’être capturées par les cas de tests.
Outre la qualité de couverture obtenue, une deuxième caractéristique importante est de disposer d’une suite
de tests de taille raisonnable et comportant peu de tests redondants (c’est à dire des paires de cas de test dont
l’apport en terme de couverture est équivalent).
Réduire le nombre de tests permet de réduire le coût d’écriture, d’exécution et de maintenance des tests.
Les critères de couverture principaux seront détaillés dans le chapitre suivant.
47
47
14/10/2023
Le test logiciel
Mesure de la qualité d’une suite de tests
Une infrastructure de test adéquate doit permettre de pouvoir aboutir à l’obtention de suites de tests
pertinentes. L’objectif principal est d’obtenir une suite de tests dont le taux de couverture est élevé, ce qui
indique qu’une bonne proportion des comportements du logiciel est testée.
La couverture se mesure souvent sur la base de critères liés à la structure du programme (flot de contrôle et de
données), comme par exemple le taux d’instructions, de branches ou de paires définition-utilisation
effectivement exécutées.
46
46
Le test logiciel
Caractérisations de l’activité de test / Typologie
Afin de caractériser l’activité de test, diverses dimensions sont à prendre en compte :
A partir de quoi les tests sont-ils générés ?
Les cas de test peuvent être issus de la spécification seule : on parle alors d’approche « boîte noire », car
l’implantation est vue comme une boîte noire dont seules les entrées et les sorties sont connues. Lorsque les
cas de test sont déterminés en s’aidant du code source et la connaissance de la mécanique interne du logiciel,
on parle au contraire d’approche « boîte blanche ».
Un test issu des spécifications est aussi appelé un test fonctionnel : le but du cas de test est de mettre en avant
de manière explicite une fonctionnalité du système apparaissant dans la spécification. Un test issu du code
source est le plus souvent un test structurel, puisque la création du cas de test se fait sur la base des chemins
d’exécution associés au code (ou d’autres éléments structurels, comme le fait de chercher à atteindre une
instruction particulière dans un état-mémoire donné). On associe généralement le test boîte noire avec le test
48
fonctionnel, et le test boîte blanche avec le test structurel.
48
 14/10/2023

Le test logiciel Le test logiciel

A quel niveau du cycle de développement se trouve-t-on ? Quel est l’objectif du test ?

Les cas de tests sont élaborés (plans de test) lors de la
L’activité de test est principalement vue comme une façon d’améliorer la correction fonctionnelle et la sûreté
partie descendante d’un cycle en V typique, en parallèle
d’un logiciel, en parallèle d’activités de vérification formelle.
des phases de spécification, conception, et de codage.
Mais le test est également le principal moyen pour évaluer un système du point de vue de sa résistance aux
L’exécution des tests se fera dans chacune des phases de la
attaques (sécurité), au stress ou à la charge, et du point de vue de sa performance (temps de réponse) et de son
partie remontante du cycle, sur la base des cas de tests
ergonomie.
élaborés dans la phase jumelle de la partie descendante.
Certains types de test ont pour objectif de fournir une aide au développement.
=> Test unitaire, de test d’intégration, de test système (ou
Le test de non-régression est un process facilitant l’écriture et l’exécution de tests unitaires à des fins de
de test de conformité).
détection rapide de défauts logiciels introduits en cours de développement.
Le test-driven development est une technique de développement agile qui utilise les tests unitaires comme
guide du développement.

49 50

49 50

Le test logiciel Le test logiciel

Quelle est la technologie de génération des données de test ? Teste-t-on le code ou un modèle du code ?

La réalisation concrète des cas de test nécessite de créer des données de test à même de solliciter les scénarios La communauté du model-based testing focalise son
de test correspondants. Différentes techniques manuelles ou automatiques coexistent pour sélectionner les attention sur le test de modèles de conception,
données de test, suivant la nature du logiciel à tester et le fait que la sélection des tests se fasse en boîte généralement à base d’automates finis, qui se prêtent bien
blanche (test mutationnel, test « symbolique ») ou noire (test combinatoire, test aux limites, test aux techniques de génération automatique de tests
mutationnel). structurels par des méthodes symboliques.

=> Ces technologies seront décrites plus en détail dans le chapitre suivant.

51 52

51 52
 14/10/2023

Le test logiciel Le test logiciel

Test Fonctionnel & Test Structurel Test Fonctionnel & Test Structurel
La détermination des cas de test est une part essentielle du test. On parle également de génération, ou sélection, La détermination des cas de test est une part essentielle du test. On parle également de génération, ou sélection,
de cas de test. On peut classifier les différentes techniques permettant de déterminer les cas de test en deux de cas de test. On peut classifier les différentes techniques permettant de déterminer les cas de test en deux
grandes familles : grandes familles :
• Le test fonctionnel • Le test fonctionnel
• Le test structurel. • Le test structurel.

Test fonctionnel : On parle de test fonctionnel lorsque le cas de test est conçu à partir des spécifications du
logiciel. Le concepteur du test n’a pas accès au code source ou a choisi de ne pas regarder la façon dont le logiciel a
été écrit : c’est pour celà qu’on parle également de test en boîte noire. Il s’agit principalement d’évaluer dans quelle
mesure les fonctionnalités que les spécifications requièrent du système sont réalisées.
Le Test structurel : le cas de test est conçu en partant du code source (on parle également de test en boîte
blanche). Le testeur essaie de mettre en évidence la façon dont l’implantation a réalisé la fonctionnalité requise en
terme d’éléments de programmation (structures de contrôle notamment), et écrit les tests en fonction des chemins
d’exécution qu’il veut voir sollicités. Il est évidemment nécessaire d’avoir accès au code source et d’être capable de
le comprendre de manière détaillée.

53 54

53 54

Le test logiciel Le test logiciel

Attention Attention

Le test fonctionnel ne se basant que sur les spécifications, normalement plus directement compréhensibles
que le code, l’écriture de cas de test s’en trouve facilitée, et ils ont un sens fonctionnel généralement assez évident.
De même, la détermination des oracles est en général simple car explicite dans la spécification.
En revanche, les spécifications n’étant pas toujours formelles ou très précises, il peut être difficile de concrétiser les
données de test ou de réaliser effectivement l’oracle sans passer par une analyse approfondie des documents de
conception. En essence, on ne teste que les fonctionnalités attendues du programme, et il est peu probable de
mettre à jour des fonctionnalités cachées ou des erreurs à l’exécution non triviales sans les rechercher
explicitement.
Le test structurel étant déterminé à partir du code source, la réalisation du script de test s’en trouve facilitée. En
revanche la détermination de l’oracle peut poser des difficultés : un test sollicite un chemin dont la sémantique en
termes fonctionnels demande potentiellement beaucoup d’investissement de la part du testeur. De plus, des
fonctionnalités de haut niveau relativement claires au niveau des spécifications peuvent être difficiles à retrouver
au niveau de l’implantation.
=> Le test fonctionnel et le test structurel sont ainsi complémentaires

55 56

55 56
 14/10/2023

Le test logiciel Le test logiciel

Phases du test Pièges du test

Le test unitaire a pour objectif de tester les procédures, modules, ou autres composants (classes dans un contexte Par rapport au rôle du test
orienté object) en isolation. La plus grande partie des techniques de détermination des cas de tests seront décrites – ne pas chercher à trouver les défauts importants,
dans le cadre des tests unitaires. – ne pas estimer la qualité des tests, ni la qualité de l’estimation,
– ne se soucier de la qualité du logiciel que lors de la phase de test,
Les tests d’intégration servent à tester le comportement obtenu lors de la composition de procédures et modules – se fier uniquement au test pour vérifier un logiciel.
pour former des sous-systèmes, qui réalisent des fonctionnalités de plus haut niveau.
Par rapport au processus de test
Les tests système / d’acceptation / de conformité permettent de valider le comportement fonctionnel du – ne pas budgétiser ou planifier l’activité de test,
code par rapport aux spécifications générales du système, ainsi que sa conformité aux exigences. – se baser principalement sur du test fonctionnel,
– ne pas faire de revue de conception des tests,
– produire des rapports de test peu informatifs,
– ne pas faire de test de configuration, charge, stress, procédure d’installation,
– commencer les tests trop tard,
– ne se fier qu’au taux de couverture comme mesure de qualité des tests ou des testeurs.
57 58

57 58

Le test logiciel

Conclusion

Le test reste une technique permettant avant tout de révéler les défauts d’un logiciel, plutôt que de prouver sa
correction, du simple fait qu’il s’agit d’une technique travaillant par sous-approximation.

Il ne faut néanmoins pas minimiser son intérêt :

la plupart des systèmes industriels classiques sont validés principalement à travers du test, souvent parce qu’il s’agit
de la seule technologie efficace pour un coût restant raisonnable.

59

59