Les Tests du Logiciel [été 2022 ed.]

Citation preview

Les Tests du Logiciel

3 Prof. Alain April, ing.

Yves Lionel Kemmogne

et Prof. Alain Abran

édition été 2022

Table

des

1 Les connaissances fondamentales

matieres en tests du logiciel

11

INTRODUCTION vrs ccssisvsnsismnenassnsnenisnnsnnonmasisssssssninsnensssasansssises

1.2

UNE VUE D'ENSEMBLE DU CONTRÔLE DE LA QUALITÉ DU LOGICIEL …

13

LES CONNAISSANCES FONDAMENTALES DE TEST …

14

BUTS ET OBJECTIFS DE TESTS (LES NIVEAUX ET TYPES DE TESTS)...

15

LES TECHNIQUES DE TEST ..….....….ccsscccsssrsrssseses area esscassasennaseens

1.6

LES MESURES DE TEST ..…...….......…ecccccaseensercrrsranenrrscrsnnnnaraceennne

1.7

TESTS APPLICATIFS ET DE DOMAINES D'APPLICATIONS SPECIFIQUES............

18

OUTS DEMEST LOGIC ELcucaccurensemersierane ermerssrenmenarenecs seras

1.9

SOMMAIRE DES APPRENTISSAGE DU CHAPITRE 1 ..…...……uccsccscsccsscsccccces

2 Les tests boite noire ere

21

INTRODUCTION buse

22

LES APPROCHES DE TESTS are

rame

wa rem area

mere

23

STRATEGIES ET TECHNIQUES DE CONCEPTION DE TESTS.

24

SOMMAIRE DES APPRENTISSAGE DU CHAPITRE 2...

EEE

3 Les tests boîte blanche ere 31

INTRODUCTION ss cscerenemensenesen ecrans tienne déteste sosie ae ques

32

LES TECHNIQUES DE TESTS UTILISANT LE GRAPHE DE FLOT DE CONTRÔLE .....

33

TECHNIQUES DE TESTS UTILISANT LE GRAPHE DE FLOT DE DONNÉES ...........

34

LES REVUES DE CODE ET DE DOCUMENTS

35

SOMMAIRE DES APPRENTISSAGE DU CHAPITRE 3

4 Le processus de test ... 41

ÉTABLIR LA MATURITÉ EN TEST DE VOTRE ORGANISATION …..…..…..…..…..……cunrscesserescenuse 90

42

LE CENTRE D'EXPERTISE DE TEST ..........…..…..……ssessssseneassansanensensansanaanaananeanan0 92

43

LA VUE D'ENSEMBLE DES ACTIVITES DE TEST DANS LE CYCLE DE VIE DU LOGICIEL ................. 96

44

L'ESTIMATION DE L'EFFORT DÉTES Ts ssvusasnssvssnsssssonsssssnssssssvsvossovivesosssorsossonss 105

45

LE PROCESSUS DE CLASSIFICATION DES DÉFAUTS ..……...….….…..ccssccccassecssssacessascansances 107

46

LA DOCUMENTATION DES TESTS ses mea

47

SOMMAIRE DES APPRENTISSAGES DU CHAPITRE 4 8.....……uucccccccssessersascessssasecssace0e 113

AE

110

5 Les tosts automatiséS..:.……00imnenennnn nn seresenssen srrrioncs sans 114 5.1

INTRODUCTION...

.115

52

LES LANGAGES DE SPECIFICATIONS AUTOMATISABLES .

.117

53

PREOCCUPATIONS POUR BIEN REUSSIR EN TESTS AUTOMATISES

54

DES OUTILS POUR LES TESTS AUTOMATISES .

5.5

A1

SOMMAIRE DES APPRENTISSAGES DU CHAPITRE 5 ..….…....………ucsserrsrersansnsscercasaa unes

Bibliographie

Les tests du logiciel

Les

connaissances

fondamentales

en tests

du

logiciel

A la suite de la lecture de ce chapitre, vous serez capable :

—

D'avoir une vue d'ensemble des connaissances fondamentales nécessaires en test logiciel pour un ingénieur logiciel et TI. Ces connaissances, publiées par le SWEBOK, sont enseignées dans tous les programmes de génie logiciel en Amérique,

—

De comprendre la notion de niveaux de test,

—

De connaître la liste des techniques de tests,

—

De comprendre les mesures utilisées pour les tests,

—

D'avoir une vue d'ensemble des processus de tests,

—

De comprendre les défis des tests applicatifs et pour certains domaines d’affaires,

—

De discuter des tests pour les technologies émergentes,

—

De connaître les différentes catégories d'outils de tests.

1 Les connaissances fondamentales en tests du logiciel

1.1

INTRODUCTION Ce chapitre est consacré à vous présenter les connaissances fondamentales des tests logiciels pour l’ingénieur logiciel, une composante importante du contrôle de la qualité (CQ) d’un logiciel. Le CQ est défini comme : les activités

et les techniques opérationnelles de la gestion de la qualité axées sur l’atteinte des exigences qualité une fois le produit terminé (après-coup). Le CQ vise principalement à détecter les défauts du logiciel avant sa mise en service. Par exemple, les activités de contrôle de qualité sont : la revue des documents d’exigences et de spécifications, la revue du code source, les tests et parfois des techniques de vérification et validation plus poussées, par exemple :

l’analyse du flôt de contrôle pour des artéfacts et du code source pour des systèmes plus critiques. Ainsi, le contrôle de qualité permet d’évaluer la qualité d’un artéfact logiciel. Les tests sont reconnus comme étant la pierre angulaire du contrôle de la qualité du logiciel par un grand nombre d'ingénieurs logiciels. Effectuer des revues au bon moment et concevoir un plan de test logiciel bien planifié peut permettre à une organisation d’économiser du temps, des efforts et du budget lors des étapes de la validation et de l’acceptation d’un logiciel par le client. Ce chapitre permet aux ingénieurs logiciels d’acquérir des connaissances générales enseignées dans toutes les universités américaines de génie logiciel qui utilisent le guide SWEBOK comme référence pour leur programme

universitaire d’enseignement et de certification. C’est donc un survol de tous les sujets, défis et préoccupations qui surviennent dans le domaine des tests logiciels.

1.2

UNE VUE D’ENSEMBLE DU CONTRÔLE DE LA QUALITÉ DU LOGICIEL L’ingénieur logiciel doit se soucier de la qualité de ses livrables. Pour être une

profession reconnue, le génie logiciel s’est doté d’un corpus de connaissances qui fait l’objet de consensus et est devenu une norme internationale. Comme la plupart des autres disciplines de l’ingénierie, il est nécessaire de connaître et d’utiliser ces connaissances, méthodes et techniques reconnues pour le développement, la maintenance/l’évolution et l’infrastructure/l’opération des logiciels.

Génie logiciel: L'application d’une approche systématique, disciplinée, quantifiable au développement, à l'opération et à la maintenance du logiciel. Ainsi c'est l'application du génie au domaine du logiciel. (IEEE) Le Contrôle

qualité de logiciel (CQL),

qui fait l’objet de ce livre, fait partie du

domaine de l’assurance qualité logicielle (AQL).

© Alain April, 2022

- Tous droits réservés

5

Les tests du logiciel

Assurance qualité (AQ): 1.

2.

La planification systématique de toutes les actions nécessaires pour fournir une assurance suffisante qu'un élément produit est conforme aux exigences techniques établies; Un ensemble d'activités destinées a évaluer le processus par lequel les produits sont développés ou fabriquées;

Contrôle de la qualité (CQ):

2.

1.

Un ensemble d'activités visant à évaluer la qualité des produits développés fabriqués; Le processus de vérification de son propre travail ou de celui d'un collègue.

Le

terme

‘assurance-qualité’,

comme

le terme

« assurance-vie

» est

un

ou

peu

trompeur, car la mise en place de pratiques de génie logiciel ne peut pas « assurer » la qualité d’un projet. Car, le terme « assurer » signifie donner la certitude. En fait, l’assurance qualité est mise en place pour réduire les risques de développer un logiciel de faible qualité. Cette qualité (AQ) implique, pour le développement suivants :

perspective de l’assurance du logiciel, les éléments

-

La nécessité de planifier les aspects qualité d'un produit ou d’un service,

-

des activités systématiques qui indiquent que, tout au long du cycle de vie du logiciel, certaines corrections sont requises,

=

Que

le système qualité est un dispositif complet qui doit permettre, dans le

cadre de la gestion de la qualité, la mise en œuvre de la politique qualité et l'amélioration continue,

-

L’'exécution de techniques d’assurance qualité qui ont pour objectif de démontrer le niveau de qualité atteint de manière à donner confiance aux utilisateurs et clients, et

-

La démonstration de la satisfaction des exigences qualité qui ont été définies pour le projet, la modification ou le service TI.

En plus du développement logiciel, l’assurance qualité peut aussi porter sur la maintenance/l’évolution ainsi que l'infrastructure et les opérations des logiciels. Les activités de qualité qui sont effectuées tout au long d’un projet sont de deux types : 1) la vérification et 2) la validation. Comme illustré à la figure 1.1, le développement logiciel utilise un cycle de développement où ces activités de vérification et de validation (V&V)

sont planifiées et effectuées. Les

tests ont une importance capitale entourant l’activité de codage. Mais il y a aussi beaucoup d’autres techniques qui sont disponibles à l’ingénieur logiciel pour s’assurer la qualité de son logiciel.

1 Les connaissances fondamentales en tests du logiciel

Besoi

Validation

du client

kd

|

'

H

I

1

1

1

Exigences système

Erreurs logiciel

1

Conception

Vérification

Code

Vérification

Produit

Vérification

| Vérification

Figure 1.1 — Illustration d'activités de vérification et validation d’un logiciel La vérification a pour but de montrer que l’activité effectuée a été bien réalisée, en conformité à son plan de réalisation et qu’elle n’a pas introduit de défaut dans le résultat. Elle peut se faire notamment sur les états intermédiaires successifs du produit de l’activité. Les objectifs de la vérification visent : —

a assurer que le logiciel (ou une partie de celui-ci) arrivé a une fin de phase du cycle de développement remplit bien les conditions requises pour passer

à la phase suivante, —

a vérifier que les exigences logicielles sont correctes, complètes, traçables et testables vis-à-vis des besoins identifiés,

—

a vérifier que

les plans

de

test

sont

suffisants

vis-à-vis

des

exigences

fonctionnelles et opérationnelles,

—

à vérifier que l’architecture et la conception détaillée ne vont pas à l’encontre des exigences de développement et d’interface,

—

à s'assurer que les techniques de tests mises en œuvre sont suffisantes pour vérifier et valider les exigences.

La validation est une série d’activités, qui commencent au tout début du cycle de développement par la validation des exigences, où les utilisateurs finaux ou leurs représentants évaluent le comportement du produit logiciel dans son

environnement ciblé, qu’il soit réel ou simulé. Les objectifs de la validation sont principalement : —

de valider de façon exhaustive que les fonctionnalités logicielles soient disponibles conformément aux spécifications, contrôlées complètement et que l’ensemble implémenté,

—

des

comportements

opérationnels

est

correctement

de valider de façon exhaustive les exigences de performance.

La validation permet aussi de minimiser les risques du développement en s’assurant que les exigences sont adéquates et complètes. Par la suite, on s’assure que ces exigences validées sont développées lors des phases de conception et de

codage. La validation permet aussi de s'assurer que le produit logiciel ne fait pas ce qu’il ne devrait pas faire.

© Alain April, 2022 - Tous droits réservés

7

Les tests du logiciel

Les techniques de V&V aident : —

à prévenir les erreurs, les localiser et les corriger,

—

à valider les artéfacts tout au long du développement,

—

à déterminer si les produits d’une activité donnée du développement ou de la maintenance sont conformes aux exigences de cette activité et à celles qui

ont été imposées par les activités précédentes, —

à déterminer si le produit logiciel final satisfait aux exigences et aux besoins des utilisateurs dans un environnement de production spécifié.

Des outils ou techniques peuvent être utilisés afin d’exécuter ces activités de V&V. L'utilisation de ces outils est hautement dépendante de la criticité de l’application, de la maturité du logiciel, de la culture organisationnelle et du cycle de vie développement, du type programmer le logiciel.

de modélisation

et de simulation

nécessaire

avant

de

Le degré auquel les activités de vérification de V&V peuvent être automatisées influence directement l’efficacité générale des efforts de V&V. Comme il n'y a pas de processus formel de sélection des outils, il est important de sélectionner le bon outil.

Idéalement,

les outils de modélisation

et de

simulation

utilisés lors

des

phases de conception et développement doivent être intégrés avec les outils de vérification et des tests. Le marché des outils de V&V est un marché commercial possédant une offre bien fournie. Il est facile d’obtenir une liste d’au moins une centaine de vendeurs sur Internet. On retrouve parmi ces outils les deux catégories suivantes : —

—

les outils génériques appuyant les données des résultats de validation : o

Systèmes de bases de données,

o

Outils de manipulation de données,

o

Outils de modélisation de données.

les outils pour les méthodes formelles : o

Les langages formels,

o

Les outils de preuves de théorèmes/algorithmes automatisés,

o

Les vérificateurs de modèles.

Dolores Wallace (Wallace, 1996) et quelques collègues ont rédigé un rapport technique pour le département de commerce américain qui explique les différentes techniques de V&V. Dans un premier temps, il faut savoir qu’il y a

trois types de techniques, ensuite un tableau présente des exemples de ces techniques : l’analyse statique, l’analyse dynamique et l’analyse formelle : —

les techniques d’analyse statique sont celles qui analysent directement la forme et la structure d’un produit sans exécuter le produit. Les revues, les inspections, les audits et les analyses de flux de données sont des exemples de techniques d’analyse statique,

-

les techniques d'analyse dynamique impliquent l’exécution ou la simulation, d’un produit de l’activité de développement pour détecter des erreurs en analysant la réponse d’un produit à des ensembles de données d’entrée. Pour

1 Les connaissances fondamentales en tests du logiciel

ces techniques, les valeurs de sortie, ou les gammes

de valeurs doivent étre

connues. Le test est la technique la plus fréquente d’analyse dynamique, —

lanalyse

formelle

est

l'utilisation

de

techniques

mathématiques

pour

analyser les algorithmes d’une solution. Parfois, les exigences logicielles peuvent être rédigées dans un langage de spécification formelle (par exemple, VDM, Z et B) qui peut être vérifié en utilisant une technique d’analyse formelle.

Tableau 1.1 — Exemples de techniques de vérification et validation du logiciel

Revue au bureau

Semer des erreurs

Tests dos a dos

Tables de décision

Modélisation analytique de la

Analyse de la complexité des

Test de mutation | Test de performance

Preuve de correction Tranches de code

Analyse de l'arbre des évènements

Analyse des modes de défaillances

performance

algorithmes

Analyse des valeurs frontalières

Analyse du flot de données

Analyse de Dimensionnement

Arbres de défaillances

(AMDEC)

Revue avec liste de vérification

Réseau de Pétri

Prototypage pour valider le logiciel

Test de stress

Lire le code source

Automate fini

Test de régression

Tests structurels

Analyse de sensibilité

Test d'accessibilité

Analyse d'exigences

Analyse de traçabilité

Couverture de code

Inspection de code

Revue de code

Certification logicielle

Analyse critique de coordination et flot

Analyse d'interface utilisateur

Analyse du flot de contrôle

Exécution symbolique

Analyse de BD

Test d'utilisabilité

Simulation

Walkthrough

Les techniques utilisées pour la walkthrough, les inspections et validation sont les tests en boite non fonctionnels. Ils vérifient

vérification sont : la revue par les pairs, le les audits. Les méthodes utilisées pour la noire, les tests en boite blanche et les tests que le logiciel est conforme ou non aux

spécifications. Ce livre n’explorera pas toutes les techniques de vérification et validation. Il se concentre seulement sur les tests logiciels. Les tests logiciels consistent en : 1) la validation dynamique d’un logiciel qui fait l’objet de test, qui, en s’exécutant, rencontre les attentes lors de l’utilisation d’un nombre déterminé de cas de test, adéquatement sélectionnés, dans un domaine d’exécution généralement infini, 2) la validation statique d’un artéfact ou d'un code source qui consiste à l’analyse du texte de l’artéfact dans le but d’identifier des défauts. Dans cette définition,

certains mots, en italique, correspondent à des problèmes-clés du domaine de connaissances des tests logiciel: —

Dynamique : ce terme signifie que les tests impliquent toujours l’exécution du logiciel qui fait l’objet de test sur un ensemble de cas de tests (c.-à-d. une suite de test),

—

Logiciel qui fait l’objet de test : ce terme peut faire référence à l’objet du test qui peut être un programme, un produit logiciel, une application, une

© Alain April, 2022

- Tous droits réservés

9

Les tests du logiciel

application orientée services microservices), un système,

(par exemple, des services Web et un système composé de systèmes,

des un

écosystème, un intergiciel et une composition de services, —

attentes lors de l’utilisation : pour chaque cas de test exécuté, il doit être possible, bien que pas toujours facile, de décider si les résultats observés correspondent à ceux attendus. En effet, le comportement observé peut être vérifié par rapport aux besoins de l'utilisateur (c.-à-d. communément appelés tests de validation), par rapport à une spécification (c.-à-d. tests de vérification) ou, peut-être, par rapport au comportement anticipé à partir d’exigences ou d’attentes implicites,

—

Nombre déterminé : même dans un logiciel simple, l’exécution de tous les cas de test possibles (c’est-à-dire des tests exhaustifs) peut nécessiter des semaines ou des mois. Par conséquent, dans la pratique, les scénarios de tests ciblent un sous-ensemble de tous les cas de test possibles, qui est déterminé par différents critères (nommé la suite de tests). Les tests impliquent toujours un compromis entre les ressources disponibles et les

échéanciers de livraison d’une part et des exigences de test intrinsèquement illimitées d’autre part,

—

Cas de test : un cas de test est la spécification de tout ce qui est essentiel à l'exécution, telle que les valeurs d’entrée, les conditions d’exécution et de synchronisation, la procédure de test et les résultats attendus (par exemple, les valeurs produites, les changements d’état, les messages de sortie). Les valeurs d’entrées seules ne suffisent pas toujours à spécifier un cas de test,

car un logiciel qui fait l’objet de test peut réagir à la même entrée avec des comportements différents, en fonction, par exemple, de l’état du logiciel ou des conditions environnementales. Un ensemble de cas de test est généralement appelé une suite de tests.

—

Adéquatement sélectionnés : comment identifier le critère de sélection le plus approprié dans des conditions données est un problème complexe. En pratique, différentes techniques peuvent être envisagées et combinées, telles que l'analyse des risques, les exigences logicielles, la réduction des coûts, la

satisfaction des attributs de qualité ou la hiérarchisation et la détection des défauts. Les nombreuses techniques de test proposées diffèrent essentiellement dans la manière dont la suite de tests est sélectionnée, et les ingénieurs logiciels doivent être conscients que différents critères de sélection peuvent donner des degrés d’efficacité très le profil d'utilisation réelle du logiciel,

—

—

généralement infini : la difficulté des tests logiciels vient de la complexité des logiciels : on ne peut pas tester complètement un logiciel qui a une complexité modérée, car le nombre de cas de tests requis pour couvrir l’ensemble des cas grandit exponentiellement et rapidement, Statique : ce terme signifie une approche

d’analyse de texte utilisé pour

évaluer la qualité d’un artéfact par rapport à une norme et le comportement d’un code source sans réellement l’exécuter, —

Artéfact (logiciel) : d'une manière générale et en génie logiciel, un artéfact désigne toute sorte d’information créée, produite, modifiée ou utilisée lors du

développement, de la maintenance ou de l’opération d’un logiciel. Tout ce qui est produit durant le cycle de vie d’un logiciel peut être considéré comme un

1 Les connaissances fondamentales en tests du logiciel

artéfact. L’artéfact peut être créé directement ou indirectement (par exemple un récit d’exigences, un échéancier, du code source...).

:

Le test logiciel est donc une activité omniprésente et holistique impliquant tous les artéfacts à toutes les étapes de tout type de cycle de vie de développement de processus (par exemple, développement traditionnel ou agile/DevOps (DevOps,

2021)).

Bien

sûr

si

on

veut

tester

un

récit

d’exigences

ou

un

échéancier il va falloir en faire la revue (seul ou en équipe). Pour le code source il est possible d’en faire la revue, par exemple à l’aide d’une pull request, mais aussi de le tester à l’aide de techniques qui seront décrites dans ce livre. Dans le reste de ce chapitre, les connaissances de base des tests ainsi que leurs

défis, problèmes, pratiques et solutions communément acceptées sont synthétisées pour offrir une vue d’ensemble. Notez que les connaissances qu’un ingénieur logiciel devrait posséder sont décrites dans le corpus de connaissances des ingénieurs logiciels spécialisés en tests logiciels (SWEBOK,

2022). Les tests logiciels est un des quinze grands domaines de connaissance reconnus comme faisant partie de la discipline de l’ingénierie du logiciel, tel que cela est présenté dans la version 4 du guide au corpus des connaissances en génie logiciel

(Software Engineering Body of Knowledge - SWEBOK) (nouvelle version qui sera publiée bientôt).

présenté à la figure 1.2

togad

=Connaessances de test 1 pl | pro

Nova detest

Techniques detest

1 1ebut ™ date

Techs utilisant les specications

vobyecat » detest

sme.

Mesures de Test

]

Techrmques utdsant structure du lool

bvalsation du opel qu fat l'objet du Rest , Évahsationdes Tests effectués

» Techniques selon

| + tes Tests et bes astres

Processus de Test

Test apphcatifs ] et du Domane ||

Outs. detest

, Comsdérations Pratiques

est Apphcad

Chom et support des cuts de test

Sous processus et acti de Test

et du Domame

… Catégories outs detest

+ Dotationdu

» Test de technologes

Pre

é

|

sl

» Vechaiques à base de

défauts et de mutations … Techniques en fonction de Putisation du lope LT adaptées Aa nature du loppoel |, Tenues wiiisant des , Sélection et combinaton de techniques Figure 1.2 — Taxonomie des tests du logiciel selon le Guide SWEBOK (version 2022 bientôt disponible)

Le

premier

sujet

abordé

par

le

SWEBOK

présente

les

connaissances

fondamentales de test. Il couvre les définitions de base du domaine des tests de logiciels, la terminologie à connaître, les problèmes-clés du domaine, ainsi que la relation entre les activités de tests et les autres activités du cycle de vie

d’un logiciel.

© Alain April, 2022

- Tous droits réservés

11

Les tests du logiciel

Le deuxiéme sujet abordé dans le chapitre du guide traite des niveaux de test. Les niveaux de tests sont découpés en deux sous-sujets (dits orthogonaux) : 1) le premier sous-sujet répertorie les niveaux dans lesquels le test est traditionnellement

subdivisé,

et 2) le deuxième

sous-sujet considère le test de

conditions ou de propriétés spécifiques et qui est le concept d’objectif d’un test. Le but et l’objectif d’un test (c.-a-d. son critère d’arrét) déterminent ensemble comment

une suite de tests finie est identifiée, à la fois en ce qui concerne

sa

cohérence : —

Combien de tests sont suffisants pour atteindre l’objectif déclaré ? appelés les critères d’adéquation du test

—

Quels cas de test doivent être sélectionnés pour atteindre cet objectif ? appelés les critères de sélection du test.

Ensuite, le guide s’attarde sur plusieurs techniques de développées au cours des dernières décennies. Ces

test qui ont été techniques sont

généralement connues, acceptées et utilisées par les ingénieurs logiciels dans toutes sortes de domaines d’affaires et de types de logiciels (c.-à-d. embarqué, gestion, scientifique...). Le guide poursuit avec la présentation des mesures de tests, tandis que les préoccupations et connaissances relatives au processus de tests viennent par la suite. Ensuite les différents tests de logiciels que l’on retrouve selon différents domaines d’application sont décrits, et aussi des nouvelles

techniques de tests qui sont développées à l’aide de technologies émergentes comme l’intelligence artificielle. Finalement, le sujet des outils de test de logiciels est survolé dans la dernière section du chapitre des tests du SWEBOK.

1.3

LES CONNAISSANCES FONDAMENTALES DE TEST Dans cette section, un aperçu des et à la relation entre les tests et présenté. La terminologie correcte à est également introduite. Un aperçu

principales problématiques liées aux tests les autres activités de génie logiciel est utiliser dans le domaine des tests logiciels plus complet des tests et de la terminologie

liée aux tests peut être trouvé dans les autres chapitres du livre.

1.3.1 DÉFAUTS VERSUS DÉFAILLANCES De

nombreux

décrire

un

termes

sont

utilisés

dysfonctionnement

dans

la littérature

: notamment

défaut,

du

génie

panne,

ou

logiciel pour erreur,

entre

autres. Il est essentiel de bien distinguer la cause d’un dysfonctionnement du logiciel en production (pour laquelle le terme défaillance sera utilisé ici) qui est un effet indésirable observé dans le service rendu du système en production. Écoutez bien lors des différentes rencontres que vous avez avec vos collègues et vous découvrirez un nombre important de termes qui décrivent les

problèmes avec un système comprenant du logiciel, par exemple : —

Le système a planté en production,

x

Le concepteur

a commis

une

erreur,

1 Les connaissances fondamentales en tests du logiciel

—

Ala suite d’une revue, on a trouvé un défaut dans les données,

—

J'’ai trouvé un bogue,

— —

Leclient se plaint qu’il y a une faute dans le calcul du rapport de paiement, On rapporte une défaillance en production.

Tous ces termes réfèrent-ils au même concept ou a des concepts différents? Il est important d’utiliser une terminologie claire et précise si nous voulons éviter de donner un sens différent à chacun de ces termes et de confondre tout le monde lors de discussions. La figure pour l'ingénieur logiciel et TI.

1.3 décrit l’utilisation correcte des termes

Terminologie des défauts du logiciel

Pendant la conception

Pendant les essais

SE CS

Erreurs

En production

a E

î

p=

Faute

7)

1

Ÿ

=«

Défaillance /-

dusystème

Figure 1.3 — Terminologie des problèmes du logiciel

Une défaillance (synonyme de panne) est l’exécution (ou la manifestation) d’une faute dans l’environnement opérationnel. Une défaillance se définit comme la fin de l’aptitude d’un composant à exécuter une fonction dont il est totalement ou partiellement responsable. L'origine d’une défaillance repose dans une faute qui est tapie dans le système opérationnel. Tant que le système en production n’exécute pas l'instruction (ou traite une donnée) fautive, il fonctionne

normalement. Il est donc plausible que vos systèmes opérationnels comportent des fautes qui n’ont pas encore été exécutées. Les fautes (synonyme de défauts) sont issues d’erreurs humaines qui n’ont pas été détectées lors du développement ou de la modification grammaticale, de logique ou de données.

du

logiciel.

Une

erreur

peut

être

Erreur (Error) : une action humaine qui produit un résultat incorrect (ISO 24765, 2017). Faute (Defect) : 1) une faute (synonyme de défaut) qui, si elle n'est pas corrigée, pourra causer une défaillance (Failure) ou produire des résultats incorrects (ISO 24765, 2017); 2) Une faute dans un composant logiciel ou un système peut conduire à ce qu'un

composant ou un système n’exécute pas les fonctions requises, par exemple une instruction ou une définition de données incorrecte. Un défaut, si rencontré lors de l'exécution, peut causer la défaillance d'un composant ou d'un système (ISTQB, 2022). Défaillance (Failure) : cessation de l'aptitude d'un produit à accomplir une fonction

requise ou de son

incapacité à s'en acquitter à l’intérieur des limites spécifiées

précédemment (ISO 25010, 2011). La figure 1.4 présente la relation entre les erreurs, les fautes et les défaillances avec le cycle de vie d’un logiciel. On peut voir l’apparition d’erreurs dès les

© Alain April, 2022 - Tous droits réservés

13

Les tests du logiciel

premières étapes d’exploration et de planification d’un nouveau logiciel. Ces erreurs deviennent des fautes quand les documents sont approuvés et que les erreurs sont passées inapercues. Puis, progressivement, les fautes sont

observées autant dans les produits intermédiaires (comme les exigences, les spécifications et la conception) que dans le code source lui-même. Ces défaillances apparaissent quand on utilise un produit intermédiaire ou un

G

Erreur

Jd mise

Q

Faute

A

—>d—>Io—>¢

VERSION n

—>

—>Jd—> 9

4

logiciel fautif.

Défaillance

Figure 1.4 — Représentation des erreurs, fautes et défaillances dans le cycle de vie

Lors du déroulement des processus de développement du logiciel, les défauts sont continuellement introduits et doivent être localisés et éliminés le plus tôt possible. Il est donc utile de recueillir et d’analyser les données sur les défauts observés. De cette manière, nous pourrons tenter d’améliorer nos processus

afin de minimiser l’introduction de défauts dans les produits logiciels. Selon votre domaine d’affaires, vous devrez travailler plus ou moins fort pour identifier les défauts. Il y a actuellement une certaine culture de tolérance aux défauts

dans

le domaine

du

logiciel.

Il est

clair que

nous

souhaitons

tous

qu’Airbus et Boeing aient identifié et corrigé tous les défauts des logiciels de leurs avions avant que nous montions à bord! En effet, il peut bien y avoir des

défauts

latents

dans

le logiciel qui

ne

se manifestent jamais

défaillances. Ainsi, les tests peuvent révéler des défaillances,

comme

des

mais ce sont les

défauts qui peuvent et doivent être supprimés avant que le client utilisateur

14

1 Les connaissances fondamentales en tests du logiciel

soit impacté. Cependant, il faut reconnaître que la cause d’une défaillance ne peut pas toujours étre identifiée sans équivoque. Aucun critére théorique n’existe pour déterminer de manière définitive, de manière générale, le défaut

qui a provoqué une défaillance constatée. On pourrait dire que c’est ce défaut qui a dû être modifié pour supprimer la défaillance, mais d’autres modifications auraient pu tout aussi bien résoudre la défaillance. Pour éviter toute ambigüité, on peut se référer aux entrées provoquant une défaillance au lieu des défauts, c’est-à-dire aux ensembles d’entrées qui provoquent l'apparition d’une défaillance.

1.3.2 LES QUESTIONS CLÉS QUE SE POSENT LES TESTEURS Cette sous-section

présente un aperçu

des préoccupations centrales que tout

ingénieur logiciel rencontre lors des tests d’un logiciel. Création de cas de test : La création ou la génération de cas de test fait référence au processus de création de la suite de tests nécessaire pour tester

le logiciel selon les objectifs spécifiques fixés (par exemple, adéquation et précision (de l’anglais accuracy)). Parce que la conception de cas de test est l’une des activités les plus importantes et les plus intensives des tests de logiciels, elle est généralement soutenue par des approches, des outils pour automatiser le plus possible ce processus.

Critères

de

sélection

(ou d’adéquation)

des

tests : Un

des techniques et

critère

de sélection

de

tests est un moyen de sélectionner des cas de test ou de déterminer qu’une suite de tests est suffisante pour un

objectif spécifié.

La sélection des cas de

test vise à réduire le nombre de suites de tests tout en conservant la même efficacité en termes

défauts peuvent réalisés.

de couverture

qui se cachent dans être

utilisés

pour

ou

de taux

de détection

de fautes

(c.-à-d.

le logiciel). Les critères de sélection des tests

décider

quand

assez

de

tests

seront

ou

ont

été

Hiérarchisation /Minimisation des tests : Afin d’améliorer l’efficacité des tests, et une sélection appropriée, une approche de priorisation des cas de test doit être

adoptée.

d’exécution

La

des

hiérarchisation

tests

en

des

fonction

cas

de

de

test

certains

vise

critères

à

définir

(par

un

ordre

exemple,

la

couverture du code, le taux de détection des défauts, la similarité et le risque),

de sorte que les tests qui ont une priorité plus élevée soient exécutés avant ceux qui ont une priorité moins élevée. Cette minimisation des cas de test vise généralement la réduction d’une suite de tests. Par exemple si les tests automatisés complets d’une application prennent 45 minutes à s’exécuter, alors vous voudrez peut-être seulement prendre un sous ensemble plus important lors de tests sommaires quand un petit changement a été effectué (aussi nommé smoke/ sanity tests). Bien sûr il y a des ac de recherche, à l’aide d’intelligence artificielle, dans ce domaine.

© Alain April, 2022

- Tous droits réservés

15

Les tests du logiciel

But et objectif du test : L’activité de test peut être guidée par différents buts et objectifs bien définis : ce n’est qu’à la lumière de ces informations qu’une suite de tests peut être conçue/générée (c.-à-d. sélectionnée), exécutée et évaluée.

Évaluation

et certification : Les

tests

qui

visent

à obtenir

une

certification

doivent être axés sur un ensemble spécifique de buts/objectifs, tels que les exigences, les obligations et les normes. Les cas de test doivent être générés et exécutés de manière à fournir des preuves utiles pour évaluer et/ou certifier le respect des exigences/obligations initiales. Habituellement, l’évaluation et la certification des résultats de test incluent la vérification que les cas de test ont été conçus et générés en utilisant les exigences du logiciel (autant fonctionnelles que non fonctionnelles), en utilisant un processus de contrôle

de la gestion de la configuration logicielle (GCL) et en utilisant des processus de tests reproductibles. Tests pour l’amélioration/l’assurance de la qualité : Nous avons vu que les tests peuvent porter sur de nombreuses perspectives. Dans ce cas-ci, c’est un but d’amélioration et d’assurance de la qualité du logiciel (AQL). Dans ce cas, les caractéristiques principales de ces tests impliquent processus et d’activités d’AQL planifié et systématique d’augmenter la confiance que le logiciel répond aux exigences techniques (c.-à-d. fonctionnelles que non fonctionnelles) projet ou le contrat.

Ainsi,

ces tests nécessitent

un ensemble de ayant pour but fonctionnelles et établies dans le

l’identification de méthodes,

d'outils, de compétences et de pratiques ayant pour but de rencontrer un certain niveau ainsi que des objectifs qualité spécifiques définis au projet. Le problème de l’Oracle de test : L’Oracle de test est un mécanisme important des tests qui permet de décider si un test est réussi avec succès ou est en échec. En effet, un test n’a de sens que s’il est possible de décider de son résultat observé. Un Oracle peut être n’importe quel agent humain ou automatisé qui décide si un logiciel s’est comporté correctement dans un test

donné et selon les résultats attendus. Par conséquent, l’Oracle de test doit fournir un verdict «réussite» ou «échec». Si l’Oracle de test ne peut pas prendre cette décision, dans ce cas, le résultat du test est classé comme non concluant. Il existe de nombreux types d’Oracles de test; par exemple, les spécifications d’exigences sont les plus utilisées. Mais dans certains domaines d’affaires, des langages de spécifications formelles non ambigües, des conceptions par modèles et des annotations de code. L’automatisation des oracles de tests peut

être difficile et parfois coûteuse. Limites

théoriques

et pratiques : La

théorie

des

tests

met

en

garde

contre

l’attribution d’un niveau de confiance injustifié à une suite de tests réussie. Malheureusement, la plupart des résultats publiés concernant la théorie des tests sont négatifs, en ce sens qu’ils indiquent ce que les tests ne peuvent jamais réaliser par opposition à ce qu’il est réellement possible de tester dans un logiciel. La citation la plus célèbre à cet égard est l’aphorisme de Dijkstra selon lequel « les tests de programmes peuvent être utilisés pour montrer la

présence

de défauts,

mais jamais

pour montrer

leur absence

». La raison

1 Les connaissances fondamentales en tests du logiciel

évidente en est que des tests complets ne sont pas réalisables dans un logiciel complexe pour les raisons suivantes : le domaine des entrées possibles d’un

logiciel est trop grand pour être complètement utilisé dans le test du logiciel. Il existe à la fois des entrées valides et des entrées non valides. Le logiciel moderne peut avoir un grand nombre d’états (voir le texte d'introduction de la section 2.3).

Le problème

des chemins

inatteignables : Ces

chemins,

dans

le code

source,

qui sont inatteignables, sont des chemins du flot de contrôle du logiciel qui ne peut être exercé par aucune donnée d’entrée (c’est-à-dire des cas de tests). L’élimination des chemins inatteignables peut aider à réduire le temps et les ressources consacrés aux tests, car ils constituent un problème important

dans les tests basés sur des chemins, en particulier dans la dérivation automatisée de cas de test qui vise à exercer tous les chemins de flot de contrôle d’un logiciel. La testabilité : Le terme « testabilité logicielle » a deux significations interreliées, mais qui ont un sens différent : d’une part, il fait référence à la facilité avec laquelle un critère de il est défini comme qu’une suite de tests le logiciel. Les deux

couverture de test donné peut être satisfait, d’autre part, la probabilité, éventuellement mesurée statistiquement, expose une faute quand il y a présence d’un défaut dans sens sont importants à prendre en compte lors de la

conception des tests. L’exécution et l’automatisation des tests : Un défi important des tests est d’améliorer le degré d’automatisation atteignable, soit en développant des techniques avancées pour générer les entrées de test, soit, au-delà de la génération de tests, en mettant en place des scripts et outils de support pour automatiser (au maximum) les différentes activités de test. Cette approche permet d’augmenter graduellement le nombre de cas de test conçus, générés et exécutés.

L'efficacité des tests : L'efficacité c’est « la capacité de produire le maximum de résultats avec le minimum d’effort, de dépense ». Évaluer le logiciel qui fait

l’objet de test et mesurer l’efficacité d’une technique de test ou juger quand le test peut être arrêté (c.-à-d. est suffisant) sont des questions importantes du domaine du test logiciel, qui peuvent nécessiter de définir et de sélectionner des mesures d’efficacité de test qui pourraient être associée à chaque suite ou cas de test.

Contrôlabilité, réplication et généralisation : Une autre préoccupation est : i) la contrôlabilité, qui fait référence à la transition des activités de test du laboratoire (c’est-à-dire de l’environnement de test) à la réalité (c’est-à-dire l’environnement de production), ii) la réplication qui fait référence à la

réalisation des mêmes activités de test par différentes personnes. Le but est de vérifier si une suite de test donnée peut être considérée comme fonctionnant au moins

en pratique, et iii) la généralisation des tests qui est liée à la validité

© Alain April, 2022 - Tous droits réservés

17:

Les tests du logiciel

externe, c’est-à-dire la mesure dans laquelle l’approche de test peut être appliquée à des contextes plus larges ou à des logiciels utilisés dans plusieurs

environnements opérationnels différents. La généralisabilité des tests de logiciels peut être une notion importante pour la gestion des activités de test (en termes de coût et d’effort) ainsi que pour accroître la confiance des résultats des tests pour les logiciels grand public. Le test hors ligne versus en ligne : Dans ce cas de figure, un processus de test peut être exécuté en tenant compte de deux paramètres : 1) hors ligne (dans un environnement de test simulant la réalité); et 2) en ligne (dans l’environnement réel de production). Habituellement, dans les tests hors ligne, le logiciel qui fait l’objet de test est validé dans un environnement sans

interaction externe. Alors que, dans les tests en production, le logiciel interagit avec l’environnement d’application réel. Dans les deux cas, les cas de test sont conçus/dérivés manuellement ou automatiquement et les résultats attendus sont utilisés pour évaluer le logiciel qui fait l’objet de test.

En conclusion, il y a un bon nombre de défis, de préoccupations et concepts à prendre en compte lors de la planification des tests dans vos projets logiciels. Bien que ces sujets puissent être planifiés informellement, il serait sage d’en dresser une liste de vérification et de formaliser un peu ces perspectives avant de débuter l’itération de développement.

1.3.3 LES RELATIONS ENTRE LES TESTS ET LES AUTRES ACTIVITÉS DE DÉVELOPPEMENT LOGICIEL Les tests, dans

un

projet

de développement

logiciel, d’une

manière

générale,

sont semblables, mais diffèrent des tests effectués pour certains objectifs bien précis et qui peuvent nécessiter l’implication de spécialistes (par exemple un test

d’intrusion).

Le

guide

SWEBOK

a

documenté,

dans

chacun

de

ses

chapitres les activités spécialisées de tests qui sont effectuées à chaque étape du cycle de vie de développement. Vous voudrez bien vous y référer pour comprendre ces cas de figure qui sont précisés pour chaque étape spécifique du cycle de vie d’un logiciel : —

Les exigences sont la référence des tests,

—

Tests dans les projets vs techniques statiques et tests d’exigences qualité pour rencontrer les exigences d’un groupe d’Assurance Qualité Logicielle

—

Tests dans les projets vs preuves d’exactitude et de vérification formelle de

(AQU), Vérification

et Validation

(V&V) requises

pour

les systèmes

embarqués,

—

Test dans les projets vs tests spécialisés en sécurité et intrusion,

—

Le rôle de test manager a l’échelle avec Safe,

—

Test dans les projets versus aspects légaux des tests.

critiques

et

1 Les connaissances fondamentales en tests du logiciel

La prochaine

1.4

section introduit la notion de niveaux et de types de test.

BUTS ET OBJECTIFS DE TESTS (LES NIVEAUX ET TYPES DE TESTS) L’exécution de tests d’un logiciel, spécialement pour les grands logiciels, est typiquement effectuée par niveaux. Dans la plupart des organisations il y aura quatre à cinq niveaux de tests : unitaire, intégration, opérationnel.

système,

acceptation et

Au niveau unitaire, les tests visent à identifier des défauts fonctionnels et structurels. Au niveau de l’intégration, les tests visent à découvrir les problèmes de communication entre les unités et s’assurer du bon

fonctionnement

et de

la structure

du

groupe.

Au

niveau

du

système,

la

fonctionnalité est encore une fois testée, mais ce niveau de test va contenir des

types

de

tests

variés

avec

des

objectifs

spécifiques

au

logiciel

testé.

L’acceptation vise l’autorisation du client de la mise en production et opérationnel s’assurer que le logiciel en production effectue bien son travail.

Aujourd’hui de plus en plus d'outils peuvent aider à produire, supporter et même enregistrer les cas de tests dans un but de les rejouer automatiquement sans intervention humaine. Nous allons les aborder plus tard. Ceci devient intéressant pour l’ingénieur logiciel qui ne modifie qu’une infime partie d’un logiciel et qui désire rejouer les tests sur l’ensemble du logiciel. Il est clair que

l’industrie a tout intérêt à proposer des solutions pour cet aspect du logiciel qui demande beaucoup d’effort.

1.4.1 LE BUT DU TEST Les niveaux de tests peuvent être distingués en fonction de l’objectif du niveau de test, parfois aussi appelé la cible, ou le but du test. Test unitaire: Les tests unitaires vérifient le fonctionnement de chaque composant du logiciel d’une manière isolée. L'objectif principal du test unitaire est de s’assurer que chaque unité de code effectue bel et bien les fonctionnalités spécifiées. Chaque composant fait donc l’objet de test

séparément. Selon le contexte, il peut s’agir de sous-programmes ou composants individuels, d’un sous-système ou d’une composition de composants du logiciel qui fait l’objet de test. De manière générale, mais pas toujours, celui qui a conçu et écrit le code effectue ses tests unitaires.

Nous savons qu’une unité de code est le plus petit composant de logiciel qui peut être testé. Il peut être décrit comme

—

:

Une procédure ou fonction qui effectue une fonction unique et cohésive,

—

Une procédure ou fonction qui peut être compilée séparément,

—

Une unité de code qui tient sur une seule page ou écran. une procédure

ou

une fonction développée dans un langage de programmation procédural.

Historiquement,

la notion d’unité de code était vue comme

En

© Alain April, 2022 - Tous droits réservés

19

Les tests du logiciel

orienté objet, autant la classe que la méthode code.

a été identifiée comme

unité de

Les pratiques exemplaires requiérent que le test unitaire soit planifié et spécifié avant son exécution. La planification du test unitaire a pour objectif la conception de cas de tests et des données qui vont soulever des défauts en fonction d’objectifs spécifiques, tels que : la fonctionnalité, l’algorithme, les données,

les

contrôles

et

la

séquence.

Pour

y

arriver,

nous

verrons

des

techniques (boite blanche et boite noire) dans les prochains chapitres. Pour les logiciels critiques, il est préférable d’impliquer un testeur indépendant, car c’est souvent requis par la règlementation. Le testeur indépendant n’a pas de préjudice ou connaissance préalable et du fait assure une intégrité supérieure lors de ces travaux. De manière courante, pour la plupart des logiciels il est très fréquent de voir ces tests effectués par l’auteur du code source avant ou

dès que l'unité de code est créée. Cette technique de test unitaire est ad hoc ou exploratoire. Dans cette situation les défauts sont rarement documentés. Dans les logiciels qui utilisent des langages orientés objet, on doit décider si l'unité est la classe ou la méthode. Dans le cas où la méthode est choisie, on doit traiter le cas où la méthode en appelle une autre. Il est donc nécessaire de développer du code additionnel (de test) pour traiter cet appel. Dans un projet de développement, le développement de ce code additionnel sera très similaire au code

existant dans

la classe.

Ce travail peut être couteux,

mais

il assure

que tous les énoncés et chemins du code source seront exécutés au moins une fois

et que

la fonctionnalité

de

base

est

vérifiée.

ingénieurs logiciels choisiront la classe comme

Alternativement,

certains

unité de code. Un terme est

employé pour ce type de test, le test de composant. Une classe, bien construite, encapsule plusieurs méthodes qui interagissent sur des données communes. Le test de composant permet non seulement de tester les énoncés, chemins et données,

mais

aussi

les caractéristiques

conceptuelles

du

paradigme

orienté

objet : encapsulation, héritage et polymorphisme. Il y a, cependant, un certain nombre de questions qui doivent être étudiées pour évaluer si ce choix d’unité de code est adapté à une situation spécifique : Question 1 - Justifier le choix d'unité de code : Le cout élevé de test de chaque méthode dans une classe est apparent quand il y a beaucoup de méthodes dans une classe. Si la classe est choisie, il est possible de réduire ce cout du code supplémentaire d’appel. Dans certains cas, il faudra développer du code source supplémentaire nécessaire pour exécuter les appels de l’externe,

actuellement absents. En plus, l’ingénieur logiciel doit voir s’il sera possible de tester adéquatement chaque méthode, Question 2 - Observer les changements d’état : Une méthode ne retourne pas toujours une valeur lorsqu'elle est appelée. Parfois, elle modifie seulement l’état d’un objet. L'état d’un objet se représente dans la valeur de ses variables. Dans ce cas, il sera nécessaire d’utiliser une technique une séquence à respecter lors des tests,

de test d’états.

Il y a donc

Question 3 - Retester les classes : Un des bénéfices de l’encapsulation est de cacher l’information. Une classe peut permettre une interface publique qui publie ses services. Dans ce cas, l’implantation des services est privée. Le

mainteneur ne doit pas statuer sur le fait que seulement les classes dont les

20

1 Les connaissances fondamentales en tests du logiciel

méthodes ont été modifiées doivent être testées. Lors d’un changement a une classe, toutes les classes en dépendent. Il en va de même pour s’assurer que

l’héritage n’est pas affecté lors d’un changement à une classe. Test d’intégration : Le nom intégration vient du fait que nous intégrons une unité à la fois. Le test d’intégration doit être réalisé avec des unités de code

préalablement testées (c.-à-d. unitairement). Les unités de code étant testées, la prochaine étape de tests consiste à intégrer ces unités au niveau du système existant. Il a comme objectif de détecter les défauts aux interfaces des unités et d’assembler les composants pour préparer à faire un test de système. Le test d’intégration est une activité continue qui peut être effectuée à chaque étape du développement. Le test d'intégration vérifie les interactions entre les composants du logiciel qui fait l’objet de test (par exemple, les méthodes, les modules ou les sous-systèmes). Les stratégies d’intégration impliquent l’intégration incrémentielle (et systématique) des éléments du logiciel qui fait

l’objet de test en tenant compte soit des fils d’exécution «threads» fonctionnels identifiés, soit de la spécification de l'architecture. Les stratégies de test d’intégration typiques sont : descendantes, ascendantes, mixtes (ou mixtes) et « big bang ». À chaque ajout, nous effectuons l’ensemble des tests. Cette manière de procéder un système complet.

nous

assure

un contrôle

parfait sur la progression

vers

Dans un logiciel orienté objet, l’intégration s’effectue en ajoutant un groupe (ou grappe) de classes. Typiquement, un groupe simple de classes sont intégrées et testées et ensuite on y ajoute des groupes d’une manière logique et structurée.

Historiquement, dans les logiciels procéduraux, l'intégration se faisait soit de bas en haut ou de haut en bas (ou une combinaison des deux approches). Les unités de code étaient ajoutées une à une jusqu’à l’obtention de l’ensemble des unités. L’approche de bas en haut a l’avantage d’utiliser les unités de codes les plus petits et bien stables. Ce sont souvent des unités de codes qui sont réutilisées partout dans le logiciel. Pour les logiciels orientés objet, la stratégie de test d’intégration tend à utiliser une approche de grappe d’objets. Une grappe d'objets est un ensemble de classes interreliées qui coopèrent afin d’exécuter une fonctionnalité du logiciel. Effectuer

un

test d’intégration

en utilisant le concept

d’ajout

de grappes

est

similaire à identifier un sous-système logique à l’intérieur du système à tester. Il sera nécessaire ici aussi de concevoir du code de test pour les interactions externes au sous-système choisi. Le test d'intégration peut aussi se concentrer sur différentes perspectives du niveau auquel les composants du logiciel sont intégrés. Il peut cibler différents aspects tels que l’interopérabilité (par exemple la compatibilité ou la

configuration) des éléments du logiciel ou avec l’environnement externe. Des interfaces externes vers d’autres applications, utilitaires, périphériques matériels ou environnements d’exploitation peuvent également être testés. Bien que les interfaces aient été exercées durant les tests unitaires, nous n’étions pas certains que le code additionnel de test soit tout à fait une image de la réalité. Il est donc nécessaire d’utiliser les vrais appels ou de se faire des appels fictifs similaires à la réalité.

© Alain April, 2022

- Tous droits réservés

21

Les tests du logiciel

Test système: Le test d’intégration étant maintenant terminé, nous passons au test de système. Ce test nécessite beaucoup d’efforts, car il doit simuler la réalité telle qu’elle sera perçue par la clientèle, c.-à-d. rencontre-t-il les

exigences? Autant les exigences qualité que fonctionnelles doivent faire l’objet de tests. Il sera donc nécessaire d’expérimenter

données

réelles,

une

charge

réelle.

Le

test

dans un

système

environnement,

consiste

à tester

des

le

comportement du logiciel qui fait l’objet de test dans son environnement de production. Des tests unitaires et d'intégration efficace auraient dû identifier de nombreux défauts préalablement. Le test système évalue principalement les exigences qualité (c.-à-d. non fonctionnelles) du système, telles que la sécurité, la confidentialité, la performance,

la précision et la fiabilité. Voici une liste de

types de tests système (aussi nommés objectifs de tests système) typiques, qui sont choisis et effectués au cas par cas selon le besoin : Test d’acceptation/Fonctionnel — Ce type de tests vise à s’assurer que toutes

les fonctions attendues du logiciel sont implémentées et fonctionnent correctement (du point de vue des utilisateurs finaux). Son objectif principal est de vérifier que le logiciel répond aux exigences et aux attentes des utilisateurs finaux. Ce test cible aussi l’autorisation finale de déployer le logiciel en production. Généralement, il est exécuté par ou avec les utilisateurs finaux pour exécuter les fonctions et les tâches pour lesquelles le logiciel a été

conçu. Ce test peut aussi cibler l’utilisabilité et l’acceptation opérationnelle. Un genre spécifique de tests fonctionnel est le test d’exactitude. Test opérationnel — Ce test vise à s’assurer que toutes les étapes de mise en production et de retrait en cas de problème fonctionnent correctement. C’est une préparation consciencieuse afin de s’assurer que le déploiement en production fonctionnera sans problèmes. C’est un test qui peut nécessiter des essais sur différentes plateformes cibles, qui vise à s’assurer qu’il s’installe, fonctionne et se désinstalle de façon satisfaisante. Au niveau opérationnel, les

tests visent à identifier s’il n’y a pas dégradation des services à la suite de sa mise en service, ce qui implicitement nécessitera de surveiller et diagnostiquer le logiciel de près dès sa mise en production. Chaque niveau et type de tests découvrira des défauts. Dans la prochaine section, nous présenterons les différents objectifs de tests possibles.

1.4.2 L’OBJECTIF DE TEST Les tests sont conduits en vue d’objectifs précis, plus ou moins explicites et plus ou moins précis. Énoncer les objectifs des tests en termes précis et quantitatifs permet de mesurer et de contrôler le processus de test. Nous avons

vu que les tests peuvent porter sur différents niveaux. Les cas de test peuvent être conçus pour vérifier que les spécifications fonctionnelles sont correctement mises en œuvre, ce qui est aussi appelé dans la littérature un test fonctionnel. Aussi, plusieurs autres propriétés non fonctionnelles peuvent également être testées, notamment les performances, la fiabilité et la convivialité, pour ne nommer que celles-ci. D’autres objectifs importants comprennent, mais sans s’y limiter, la mesure de la fiabilité, l’identification des vulnérabilités en matière de sécurité et de

22

1 Les connaissances fondamentales en tests du logiciel

confidentialité et l’évaluation de la convivialité des interfaces différentes approches seraient adoptées. Notez qu’en général,

pour lesquelles les objectifs du

test varient selon la cible du test, ainsi différents objectifs sont abordés à différents niveaux de test. Les sous-thèmes listés ci-dessous sont ceux les plus souvent cités dans la littérature. Test

alpha

et bêta:

Avant

qu’un

logiciel de masse

soit commercialisé,

il est

parfois distribué à un ensemble restreint et représentatif d’utilisateurs potentiels pour des essais préliminaires, soit une première fois en interne (test alpha) ou à l’externe pour utilisation restreinte (test béta). Ces utilisateurs signaleront des défauts avec le produit. Test bout en bout — Dans ce type de tests, les transactions d’affaires sont initiées et suivies tout au long de leurs transformations jusqu’à complétude. Par exemple, dans un dossier d’historique de l’employé, un employé se joint à

l’entreprise; est ensuite promu; est ensuite rétrogradé, des augmentations de salaire sont accordées, quelquefois des diminutions de salaire peuvent être effectuées; un dossier peut être gardé en suspens; un employé transféré, puis partir à la retraite, mis à pied ou décéder. Ce type de test s’assure que la transaction d’affaires est fonctionnelle. Test de charge — Test de simulation de comportement du logiciel à sa charge maximale (tel que spécifié lors de sa construction), ainsi qu’au-delà de cette charge. Dans certains cas, ce type de tests cherchera à rendre certaines ressources non disponibles pour voir le comportement du logiciel. C’est un type de tests populaire pour les applications Web et les applications

multiutilisateurs. Un grand nombre d'utilisateurs sont connectés et essaient d’utiliser le logiciel d’une manière aléatoire. L'objectif est de voir si le logiciel permet de bien gérer plusieurs demandes de toutes sortes. Ce type de test fait ressortir des problématiques liées à la bande passante, les bases de données, la suffisance de mémoire, les accès aux disques, tests de charge est le test de concurrence.

Test de cohérence survol

rapide

de

etc. Un

genre

spécifique

de

(de l’anglais smoke test) — Ce type de tests effectue un

l’ensemble

des

composants

pour

s’assurer

que

le « build

»

contiendra les versions appropriées et complètes des composants appropriés pour la version désirée. C’est un test rapide, de quelques minutes, quand il est passé

avec

succès,

qui

signifie

qu’on

peut

procéder

avec

des

tests

plus

détaillés. Test de confidentialité : Les tests de confidentialité sont consacrés à l’évaluation de la sécurité et de la confidentialité des données personnelles des utilisateurs afin de prévenir les attaques locales et respecter les lois. Il vise spécifiquement l’évaluation des politiques de confidentialité et de partage d'informations ainsi que la validation de la gestion décentralisée des profils sociaux des utilisateurs et des solutions de stockage de données.

adopté la loi 64 récemment concernant la confidentialité devient une préoccupation légale pour l'ingénieur logiciel.

Le Québec

des données

a

qui

Test de configuration: Le test de configuration analyse le logiciel sous diverses configurations spécifiées lorsque le logiciel qui fait l’objet de test est

© Alain April, 2022

- Tous droits réservés

23

Les tests du logiciel

conçu pour servir différents utilisateurs. Il vérifie le logiciel selon les différentes configurations spécifiées.

Test de conformité: Le test de conformité vise à vérifier que le logiciel, qui fait l’objet de test, est conforme aux normes, règlements, spécifications, exigences,

conceptions, processus ou pratiques. Test de la documentation

utilisateur — Ce type de tests vise à s’assurer que

les messages d’erreurs et la documentation comportement du logiciel.

s’arriment parfaitement avec le

Test dos à dos — Dans ce type de tests, le même jeu d’essais est effectué sur deux versions différentes d’un même produit logiciel, et les résultats sont comparés. Test de fiabilité — Ce type de test évalue les endroits critiques qui peuvent influencer son bon fonctionnement (le temps de service entre deux pannes). Test

d’interfaces

et

d’API:

Les

défauts

d'interface

sont

courants

dans

les

systèmes complexes. Le test d’interface vise à vérifier si l’interface entre les composants permet l’échange correct de données et d’informations de contrôle. Habituellement, les cas de test sont générés à partir de la spécification d’interface. Un objectif spécifique du test d'interface est de simuler l’utilisation des API par les applications des utilisateurs finaux. Cela implique la génération de paramètres des appels d’API, la définition de conditions d’environnement

externes et la définition de données internes qui affectent l’API. Test d’installation : Souvent effectué à la suite des tests de système et d’acceptation, ce test vérifie l’installation dans l’environnement de production. Les tests d’installation peuvent être considérés comme des tests système

effectués dans l’environnement opérationnel avec les configurations matérielles et les autres contraintes opérationnelles. Les procédures d’installation peuvent également être vérifiées pendant ce test. Test de maintenabilité — Type de tests du logiciel pour s’assurer que sa maintenance sera efficace. La maintenabilité dans ce contexte signifie : 1) qu’il est facile d'identifier l’endroit ou faire une modification; 2) effectuer une modification se fait facilement; 3) il est simple de tester la modification et

d’effectuer le test de régression sur le reste du logiciel et 4) de faciliter son déploiement à la suite d’une modification. Test non fonctionnel (qualité): Les tests non fonctionnels ciblent la validation

des aspects non fonctionnels (tels que : les performances, l’utilisabilité ou la fiabilité) et sont effectués à tous les niveaux de test. En pratique, plusieurs tests non fonctionnels sont effectués avant la mise en production comme les tests d’utilisabilité, de sécurité, de performance et de maintenabilité.

Test en parallèle — Ce type de tests permet de reproduire exactement les résultats d’un autre logiciel similaire qui fait l’objet de remplacement. Le test parallèle est utile, car il permet de comparer exactement ce qui va se passe en production si on mettait le composant en service.

Test de performance — La performance est la capacité d’un logiciel à continuer à donner un service efficace quand l’une de ses exigences non fonctionnelles

24

1 Les connaissances fondamentales en tests du logiciel

(synonyme d’exigence qualité) telles que la charge, c’est-a-dire quand le nombre de transactions et le volume de données augmentent, continue d’opérer correctement. Ce test est lié à la capacité d’adaptation autant du logiciel que

de la plateforme et de l’environnement

(c.-à-d. l'infrastructure) sur lequel le

logiciel s’exécute, telle que les environnements

et virtualisés,

les grappes

de

serveurs

et les

distribués,

services

les réseaux sans fil

infonuagiques.

Par

exemple, un type de tests de performance s’assure que le temps de réponse d’une transaction, telle que perçue par l’utilisateur final, reste à l’intérieur de limites spécifiées acceptables. Ce test est spécifiquement destiné à vérifier que le logiciel répond aux exigences spécifiques de performance, par exemple, la

capacité et le temps de réponse. Selon Google c’est le facteur le plus important pour les utilisateurs de votre logiciel. Si le temps réponse passe d’une (1) seconde à trois (3) secondes, la probabilité que l'utilisateur quitte votre site Web augmente de 32%. Si c’est d’une (1) seconde à cinq (5) secondes, cette probabilité passe à 90%. Évaluez la performance avec des outils comme : PageSpeed de Lighthouse, GTmetrix et Google Search Console, Gatling et

Jmeter pour n’en nommer que quelques-uns. Test de priorisation: La hiérarchisation des cas de test vise à planifier les cas de test pour augmenter : 1) le taux de détection des défauts ; 2) la probabilité de trouver des défauts ; 3) la couverture du code testé ; et 4) la fiabilité du

logiciel qui fait l’objet de test. Généralement, les tests de priorisation reposent sur des euristiques et leurs performances peuvent varier en fonction du logiciel qui fait l’objet de test, de l’environnement et des cas de test disponibles. Parmi les différentes propositions de priorisation, la _priorisation basée sur la similarité est l’une des plus couramment adoptées. Dans ce cas, les cas de test

sont priorisés à partir de ceux qui sont les plus

dissemblables

selon une

fonction de distance prédéfinie.

Test de recouvrement (aussi nommé test de reprise) — l’objectif de ce type de tests est de s’assurer que le logiciel peut récupérer facilement et rapidement a la suite d’une défaillance. Test de régression (aussi appelé TNR ou Test de Non-Régression): le test de régression consiste à tester le logiciel pour vérifier que les modifications n’ont pas causé d’effets secondaires ailleurs et que le logiciel est toujours conforme à ses exigences spécifiées. La définition officielle est : « Des tests sélectifs d’un système ou composants pour vérifier que les modifications n’ont pas entrainé des effets inattendus ».

En pratique, l’approche consiste à démontrer que le logiciel réussit toujours les tests précédemment réussis dans une suite de tests (souvent automatisés). Dans certains cas, un compromis doit être fait entre l’assurance donnée par

les tests de régression à chaque fois qu’un changement est effectué et les ressources nécessaires pour effectuer ces tests, car ils peuvent prendre beaucoup de temps en raison du grand nombre de cas de tests à être exécutés. Les tests de régression peuvent être effectués à chacun des niveaux de test décrits dans la section précédente et peuvent impliquer des tests fonctionnels et non fonctionnels, tels que des tests de fiabilité, d’accessibilité, d’utilisabilité, de maintenabilité, de conversion, de migration et de compatibilité. Pour réduire

l'effort

du

© Alain April, 2022

test

de

régression,

- Tous droits réservés

ils

peuvent

nécessiter

la

sélection

et

la

25

Les tests du logiciel

minimisation des cas de test ainsi que l’adoption d’approches de hiérarchisation des suites de tests existantes (souvent nommée « smoke test ».

Le test de régression est un test fondamental dans l’approche Agile, le développement piloté par les tests et le développement continu en général (le DevOps). Ce test est généralement effectué après le test d’intégration et avant le déploiement en production. Test de sécurité:

Les tests de sécurité se concentrent

sur l’assurance que le

logiciel est protégé contre les attaques externes. Il vérifie notamment la confidentialité, l’intégrité et la vulnérabilité du système et de ses données. Il s’assure aussi d’identifier des vulnérabilités contre les accès accidentels, non autorisés, les menaces des virus et les logiciels espions. Habituellement, les tests de sécurité incluent la validation contre l’utilisation abusive (tests

d’intrusion et de vulnérabilité). Test d’utilisabilité et d’interaction personne-machine: La tâche principale du test d’utilisabilité et d’interaction personne-machine est d’évaluer la facilité d’apprentissage et d'utilisation des interfaces utilisateurs du logiciel par les utilisateurs finaux. En logicielles qui prennent qui aide les utilisateurs erreurs d'utilisation. Le

général, cela peut impliquer de tester les fonctions en charge les tâches de l’utilisateur, la documentation et la capacité du système à soulever et renseigner les test d’utilisabilité devra prendre en compte différents

types d'utilisation, et s’assurer que l'interface utilisateur s’acquitte, de manière satisfaisante, des exigences d'utilisabilité spécifiées. On vise ici à évaluer si l’utilisateur peut effectuer son travail efficacement en suivant la séquence des opérations dans l’interface. Ce test a pour objectif d’évaluer la facilité pour les utilisateurs finaux à utiliser et à apprendre le logiciel et d’évaluer l’efficacité des fonctions à soutenir les tâches des utilisateurs. Un genre spécifique de

tests d’utilisabilité est le test de la documentation des utilisateurs. La prochaine section présente une synthèse des techniques utilisées pour concevoir ou sélectionner des cas de tests qui sont utilisés à tous les niveaux et pour tous les objectifs de tests présentés.

1.5

LES TECHNIQUES DE TEST Au fil des ans, différentes techniques de test ont été développées dans le but d'augmenter la qualité globale des logiciels. Ces techniques tentent de proposer des procédures et des approches systématiques pour concevoir ou sélectionner les suites de tests les plus appropriées qui vont détecter le plus de défauts et de défaillances possible. La classification des techniques de test peut être effectuée en tenant compte de différentes perspectives des exigences telles que

la spécification du logiciel, la structure du code et l’expérience des développeurs. Dans certains cas, des sources d’information supplémentaires peuvent être utiles pour trouver des failles additionnelles telles que : l’utilisation prévue du logiciel, la nature de l’application ou des connaissances dérivées. Dans cette classification, le chevauchement est possible et une catégorie peut traiter de l’utilisation combinée de deux ou plusieurs techniques.

26

1 Les connaissances fondamentales en tests du logiciel

Des classifications alternatives sont actuellement disponibles dans littérature qui repose sur le degré d’information disponible concernant

la le

logiciel qui fait l’objet de test. En effet, dans les techniques basées sur spécifications, appelées techniques boite noire, la génération des cas de repose uniquement sur le comportement d’entrée/sortie du logiciel qui l’objet de test, tandis que les techniques basées sur la structure interne

les test fait du

logiciel, appelées boite blanche, les cas de test sont informations sur les énoncés et les variables du code que certaines techniques de test sont plus utilisées cette section présente les techniques de test les plus

générés en utilisant des source exécuté. Sachant que d’autres, la suite de couramment adoptées en

entreprise.

1.5.1 LES TECHNIQUES DE TEST QUI UTILISENT LES SPECIFICATIONS DU LOGICIEL L'idée sous-jacente des techniques de test basées sur les spécifications est de sélectionner quelques cas de test dans le domaine d’entrée capables de détecter des catégories spécifiques de défauts. Ces techniques vérifient que le logiciel qui fait l’objet de test peut gérer les entrées dans un certain intervalle de valeurs et renvoyer la sortie requise ou donner un message d’erreur précis et compréhensible. Tests exploratoires

(ad hoc) : Avec cette technique, les cas de test sont générés

de manière à l’aide de l’expérience ou d’une manière purement aléatoire. Cette forme de test identifie des cas de tests avec le domaine d’entrée puisque le domaine d’entrée doit être connu afin de pouvoir choisir des données a l’intérieur de celui-ci. Les tests aléatoires offrent une approche relativement simple pour l’automatisation des tests, récemment, des formes améliorées de tests aléatoires (comme les tests aléatoires adaptatifs) ont été proposées dans

lesquelles l’échantillonnage aléatoire des entrées est dirigé par d’autres critères de sélection

des entrées.

Actuellement,

sous

le nom

de test flou, la sélection

aléatoire d’entrées et de données invalides et inattendues est largement utilisée dans le contexte de la cyber sécurité pour trouver des erreurs de code et des failles de sécurité. Classes

d’équivalence : Le partitionnement

en classes

d’équivalence

implique

le partitionnement de l’ensemble des données d’entrée en une collection de sous-ensembles (ou de classes équivalentes) en fonction d’un critère ou d’une relation spécifiée. Ce critère ou cette relation peut être différents résultats de calcul, une relation basée sur le flot de contrôle ou le flot de données, ou une

distinction faite entre des entrées valides qui sont acceptées et traitées par le logiciel et des entrées invalides, tel que des valeurs hors plage, qui ne sont pas

acceptées et qui doivent générer un message d’erreur significatif ou lancer le traitement d’erreur prévu. Une suite de tests représentative est généralement obtenue de chaque classe d’équivalence. Analyse

des valeurs frontalières : Les cas de test sont choisis sur ou près des

limites du domaine d’entrée des variables, avec la logique sous-jacente que de nombreux défauts ont tendance à se concentrer près des valeurs extrêmes des entrées. Une extension de cette technique est le test de robustesse, dans lequel les cas

de

© Alain April, 2022

test

sont

également

- Tous droits réservés

choisis

en

dehors

du

domaine

d’entrée

des

27

Les tests du logiciel

variables pour tester la robustesse entrées inattendues ou erronées.

du

programme

dans

le traitement

des

Test de syntaxe : Les techniques de test de syntaxe, également connues sous le nom de techniques basées sur les spécifications formelles, reposent sur les spécifications du logiciel qui fait l’objet de test dans un langage formel. Cette représentation permet la dérivation automatique des cas de test fonctionnels

et, en même temps, fournit un oracle pour vérifier les résultats des tests. Techniques

de

test

combinatoire

:

Les

techniques

de

test

combinatoires

dérivent systématiquement le cas de test de manière couvrir des paramètres spécifiques des conditions de valeurs. Les techniques de tests combinatoires couramment utilisées sont : Test de toutes les combinaisons, Tests par paire, Chaque test de choix, Test de choix de base, Parmi eux, le test entièrement combinatoire se concentre sur toutes les combinaisons possibles d’entrées, tandis que son sous-ensemble, également appelé test t-wise, considère toutes les combinaisons possibles d’entrées t. Dans ce cas, plus d’une paire est dérivée, c’est-à-dire en incluant des combinaisons de niveau supérieur. Le test

par paires est une technique de test combinatoire spécifique où les cas de test sont dérivés en combinant les valeurs de chaque paire d’un ensemble d’entrées. Ces techniques Array Testing (OAT) ».

sont également

connues

sous

le nom

« Orthogonal

Table de décision : Les tables de décision (ou arbres de décisions) représentent les relations logiques entre les conditions (en gros, les entrées) et les actions (en gros, les sorties). Habituellement, ils sont largement adoptés pour la représentation des connaissances (par exemple dans l’apprentissage

automatique). Les cas de test sont systématiquement dérivés en considérant toutes les combinaisons possibles de conditions et leurs actions résultantes correspondantes. Une technique connexe est la représentation graphique de cause à effet. Actuellement, les processus de développement décalés à gauche tirent parti de ce type de techniques de test, car elles sont utiles pour documenter les résultats des tests et les facteurs qui peuvent les affecter. Graphe de cause à effet : Les techniques de représentation graphique de cause à effet reposent sur des réseaux logiques qui mappent un ensemble de causes à un ensemble d’effets en explorant systématiquement les combinaisons possibles de conditions d’entrée. En particulier, ils identifient les effets et

relient les effets à leurs causes grâce à des modèles de graphes. Les techniques de représentation graphique de cause à effet sont utilisées dans les tests, car elles permettent l’analyse de la spécification, l’identification des conditions ou causes d’entrée pertinentes, conditions de sortie.

les

transformations

qui

en

résultent

et

les

Test de transition d’état : Les techniques basées sur les machines à états finis, également appelées techniques de test de transition d’état dans se concentrent sur la représentation du logiciel qui fait l’objet de test au moyen d’une machine

28

1 Les connaissances fondamentales en tests du logiciel

a états finis. Dans ce cas, la suite de tests est dérivée afin de couvrir les états et les transitions selon un niveau de couverture spécifique. Test a partir de scénarios : Un modéle est utilisé qui une représentation abstraite (formelle) du logiciel qui fait l’objet de test ou de ses exigences logicielles. Les tests basés sur des scénarios sont utilisés pour valider les

exigences, vérifier leur cohérence et générer des cas de test axés sur les aspects comportementaux du logiciel qui fait l’objet de test. Les composants clés des tests basés sur des scénarios sont : la notation utilisée pour représenter le modèle du logiciel ou ses exigences, modèles de flot de travail ou modèles similaires, la stratégie de test ou l’algorithme utilisé pour la génération de cas de test, l’infrastructure de support pour l’exécution des tests, et l’évaluation des résultats des tests par rapport aux résultats attendus. En raison de la complexité des techniques, les approches de test basées sur des scénarios sont

souvent utilisées conjointement avec des harnais d’automatisation des tests. Parmi les tests basés sur des scénarios, des modèles de flot de travail peuvent

également être utilisés pour la représentation graphique de la séquence d'activités effectuées par des humains et/ou des applications logicielles. Dans ce cas, chaque séquence d’actions constitue un workflow (aussi appelé scénario). En règle générale, il est important de s’assurer que les workflows typiques et alternatifs sont également testés. Les tests de processus métier font partie de ces techniques basées sur des scénarios. Dans ce cas, l’accent est mis sur les rôles dans une spécification de workflow.

Test fondé sur des preuves : En génie logiciel, pour les logiciels embarqués, tests basés sur des preuves représentent la meilleure solution pour

problème comprend

les un

pratique suivant une approche de recherche rigoureuse qui i) l’identification des preuves et la formulation d’une question, ii)

rechercher les meilleures preuves pour répondre à la question, iii) réfléchir de manière critique les preuves sur le problème et le contexte que les preuves devraient aider à résoudre. Les principes d’ingénierie logicielle basés sur des preuves peuvent également être appliqués au processus de test. Dans ce cas,

les approches largement utilisées qui permettent d’identifier et d’agréger les preuves sont : les études cartographiques systématiques et les revues systématiques. Test de mutation : Cette technique vise à concevoir des cas de test qui sont spécifiquement conçus pour vérifier si logiciel qui fait l’objet de test peut gérer un ensemble prédéfini d’exceptions/erreurs, telles que l’exception de données, l’exception d’opération, l’exception de débordement, l’exception de protection ou l’exception de sous-dépassement. Les techniques de test se concentraient

généralement sur des scénarios de test négatifs, c’est-à-dire des cas de test capables de forcer la génération de messages d’erreur.

1.5.2 LES TECHNIQUES QUI UTILISENT LA STRUCTURE DU LOGICIEL Les techniques de test basées sur la structure (parfois appelées techniques de test basées sur le code) se concentrent sur le code et sa structure. Les

© Alain April, 2022

- Tous droits réservés

29

Les tests du logiciel

techniques de test basées sur la structure peuvent étre effectuées a différents niveaux (tels que le développement de code, l’inspection de code ou les tests unitaires) et peuvent inclure : des tests statiques (tels que l’inspection de code,

la procédure pas-à-pas de code, la révision de code), des tests dynamiques (comme

la couverture

de

déclaration,

couverture

de branche,

couverture

de

chemin) ou mesures de la complexité du code (par exemple en utilisant des techniques comme

la complexité cyclomatique).

Tests utilisant le flot de contrôle : Les tests de flot de contrôle visent à couvrir toutes les instructions, branches, décisions, conditions de branche, couverture de Condition Modifiée/Décision Modifiée (MC/DC), blocs d’instructions ou combinaisons spécifiques d'instructions dans un logiciel qui fait l’objet de test. Le plus fort des critères basés sur le flot de contrôle est le test des chemins,

qui vise à exécuter tous les chemins de flot de contrôle d’entrée à sortie dans le graphe de flot de contrôle d’un logiciel qui fait l’objet de test. Étant donné que les tests de chemin exhaustifs ne sont généralement pas réalisables en raison des boucles, d’autres critères moins stricts se concentrent sur la couverture des chemins qui limitent les itérations de boucle, telles que la couverture des instructions, la couverture des branches et les tests de condition/décision. L’adéquation de ces tests est mesurée en pourcentages, par exemple, lorsque toutes les branches ont été exécutées au moins une fois par les tests, une couverture de branche de 100 % a été atteinte. Test utilisant le flot de données : Dans les tests de flot de données, le graphique de flot de contrôle est annoté avec des informations sur la façon dont les

variables sont définies, utilisées et supprimées. Les techniques de test de flot de données généralement adoptées sont les suivantes : test (d-define) de toutes définitions création et initialisation, test toutes les initialisations de données, test (k-kill) de toutes destruction de valeur, test (u-util) toutes utilisations de données, test (c-calcul) d’utilisation dans un calcul et test (p-prédicat) d'utilisation dans une instruction. Le critère le plus fort est le dernier où tous

les chemins d'utilisation de définition doivent être couverts. Il nécessite que, pour chaque variable, chaque segment de chemin de flot de contrôle d'une définition de cette variable à une utilisation de cette définition soit exécuté. Afin de réduire le nombre de chemins nécessaires, des stratégies plus faibles telles que toutes les définitions et toutes les utilisations sont employées.

Revues d’artéfacts

: Les techniques

de revue d’artéfacts et de code (parfois

appelées « pull requests » et revues/inspections) se concentrent à regarder l’artéfact en groupe et tenter de trouver des défauts. Ces tests peuvent être effectuées à différents niveaux (tels qu’au niveau des exigences, de la

conception, développement du code ou même au niveau des tests eux-mêmes) et peuvent inclure : des tests statiques (tels que l'inspection de code, la procédure d’exécution pas-à-pas et la révision de code).

1.5.3 LES TECHNIQUES DE TESTS SELON L'EXPÉRIENCE La génération de la suite de tests la plus appropriée peut dépendre de différents facteurs, tels que la connaissance de l’ingénieur logiciel envers le logiciel qui fait l’objet de test et de son contexte, ainsi que de son expérience et de son

30

1 Les connaissances fondamentales en tests du logiciel

intuition. Dans ce qui suit, les techniques basées sur l’expérience couramment adoptée sont brièvement présentées.

Tests exploratoires (ad hoc): Les tests exploratoires sont définis comme l’apprentissage simultané, la conception des tests et l’exécution des tests. Les cas de test ne sont pas définis à l’avance, mais sont conçus, exécutés et

modifiés de manière dynamique en fonction des preuves collectées et des résultats de test tels que: le comportement observé du logiciel, les particularités du logiciel qui fait l’objet de test, le domaine et l’environnement, le processus de défaillance, le type de défauts et de pannes possibles, le risque associé à un logiciel particulier. Habituellement, l’intuition, les connaissances et l’expertise de l’ingénieur logiciel chargé d’effectuer les tests exploratoires

peuvent avoir un impact sur l’efficacité de ces tests. Les tests exploratoires sont actuellement largement utilisés dans le développement agile.

1.5.4 LES TECHNIQUES DE TEST DE MUTATION Le test de mutation est conçu à l’origine comme une technique d’évaluation des suites de tests, dans laquelle un mutant est une version légèrement modifiée du logiciel qui fait l’objet de test, qui s’en différencie par un petit changement syntaxique. Chaque cas de test teste à la fois la version originale et tous les mutants générés : si un cas de test réussit à identifier la différence entre la version de référence et un mutant, ce dernier est dit « tué ». L'hypothèse sous-jacente du test de mutation, l’effet de couplage, est qu’en recherchant des

défauts syntaxiques simples, des défauts plus complexes, mais réels seront trouvés. Pour que la technique soit efficace, un grand nombre de mutants doivent être automatiquement générés et exécutés de manière systématique. Les tests de mutation sont également un critère de test en soi : soit les tests sont générés de manière aléatoire jusqu’à ce que suffisamment de mutants aient été tués, soit les tests sont spécifiquement conçus pour tuer les mutants survivants.

Dans ce dernier cas, les tests de mutation peuvent également être

classés comme une technique de test basée sur la structure du code source. Les tests de mutation sont récemment utilisés comme un moyen efficace de génération de tests flous. Une application plus récente du processus de mutation est le test métamorphique, qui est une technique qui est devenue de plus en plus populaire pour relever certains des défis de test pour des logiciels en intelligence artificielle et d’apprentissage machine. Dans ce cas, les modifications (morphing) sont appliquées aux entrées afin qu’une relation

puisse tenir de l’entrée précédente (et sa sortie) à la nouvelle entrée morphée (et sa sortie).

1.5.5 LES TECHNIQUES DE TESTS SELON L'UTILISATION DU LOGICIEL Ces cas de tests sont basés sur l’utilisation du logiciel réel. Les tests basés sur

des profils opérationnels visent à cibler les cas de test utilisateurs utilisent le plus le logiciel. Cette technique l’utilisation des fonctionnalités par les utilisateurs afin sur l’utilisation de chaque fonctionnalité. Ainsi

© Alain April, 2022 - Tous droits réservés

vers les endroits où les de test nécessite d’épier d’avoir des statistiques le testeur aura plus

31

Les tests du logiciel

d’information ou c’est plus utile de tester le logiciel. Ce dernier test nécessite de collecter des mesures.

1.5.6 LES TECHNIQUES DE TESTS SELON LA NATURE DU LOGICIEL Cette approche vise à comprendre quelles techniques sont préférées pour certains types de logiciels. Les techniques s'appliquent à tous les types de

logiciels qui font partie du groupe. Des techniques supplémentaires pour la dérivation et l’exécution des tests sont basées sur la nature du logiciel testé. Par exemple : —

Logiciel orienté-objet,

—

Logiciel à base de composant,

—

Logiciel Web,

—

Logiciel temps réel,

—

Logiciel orienté service

—

Logiciel infonuagique,

—

Logiciel libre,

—

Logiciel embarqué,

—

Logiciel d’intelligence artificielle, et

—

Logiciel orienté service.

Dans

certains

fournissent

des

cas,

des

normes

exemples

et

un

telles

quTSO

support

29119-1

pour

(ISO29119-1,

spécifier

des

cas

de

2022) test,

automatiser leur exécution et maintenir les suites de tests.

1.5.7 LES TECHNIQUES DE TESTS QUI UTILISENT DES COMBINAISONS DE TECHNIQUES La combinaison de différentes techniques de test a toujours été un moyen valable pour assurer le niveau requis de qualité. Actuellement, en particulier dans le développement agile, les méthodologies des techniques de test dès le début du développement font partie de l’état de la pratique. L'objectif est d’améliorer l’efficacité des processus de test, en apprenant de l’expérience passée et, en même temps, en adaptant la sélection de la technique à la session

de test en cours à l’aide de rétroactions rapides avec la clientèle.

1.6

LES MESURES DE TEST Les techniques de test aident à garantir la réalisation des objectifs de test spécifiques. Pour évaluer si un objectif de test est atteint, il faut des mesures bien définies. La mesure est généralement considérée comme fondamentale pour l’analyse de la qualité. La mesure peut également être utilisée pour optimiser la planification et l’exécution des tests. La gestion des tests peut utiliser plusieurs mesures de processus différentes pour surveiller les progrès. Les techniques de test peuvent être classées en tenant compte des degrés de couverture qui peuvent être atteints en les utilisant. La couverture peut varier de 0 % a 100 %, à l’exclusion des tests irréalisables éventuels, c’est-à-dire des

32

1 Les connaissances fondamentales en tests du logiciel

tests qui ne peuvent pas étre exécutés ou impossibles a exécuter. Ainsi, pour chacune des techniques de test basées sur les spécifications, basées sur la structure et basées sur l’expérience, la définition des mesures de couverture

associées ainsi que la procédure pour l’évaluer est présentée. Des exemples de mesures de couverture pourraient être le pourcentage de directions couvertes dans le graphique de déroulement du programme ou le pourcentage d’exigences fonctionnelles exercées parmi celles énumérées de spécifications.

dans le document

Il est important de considérer que des outils de mesure capables de calculer dynamiquement le ratio entre les composants testés par rapport au nombre total de composants peuvent être très utiles. De plus, en particulier dans le cas des techniques de test basées sur la structure, un outil de mesure appropriée peut également être nécessaire pour aider l’effort de test. Cependant, d’un point de vue pratique, l’ensemble de mesures de tests proposés peut également être classé en considérant un point de vue différent :

ceux qui fournissent et permettent une évaluation du logiciel qui fait l’objet de test, sur la base des résultats de test observés, et ceux qui évaluent la rigueur

ou l’efficacité des suites de tests exécutées. Voici quelques mesures de tests populaires : —

JL

_

Nb tests passés avec succès

% tests passés avec succès= —————————————————— Nb total des tests exécutés

Nb total de tests exécutés -

—

Durée des tests=

—

Efficacité des tests= ÿ Nb total défauts durant les tests ‘Total aéfauts+(Nb total défauts durant les tests+Nb défauts trouvés en production)

Temps total exécution

—

La couverture des tests=

—

La couverture du code=

—

La

densité

des

) + 100

Nb total des tests exécutés

7

Nb de tests possibles Nb total des tests unitaires exécutés

défaut:

—

=

Nb de tests unitaires possibles Nb total défauts durant les tests

"Nb total de lignes de code testées *

Explication :

Supposez que vous avez 5 modules en tests. Les défauts trouvés sont (5,10,20,15 et 5) et ces modules avaient (500,1000,1500,1500 et 1000) lignes de code. Alors la densité des défauts sera = 55/5500 = .01défaut/ligne de code.

1.6.1 L’EVALUATION DU LOGICIEL QUI FAIT L'OBJET DU TEST Habituellement,

peuvent

des

indicateurs,

être utilisés pour

c’est-à-dire

déterminer

des

informations

mesurables,

si le logiciel qui fait l’objet du

test

fonctionne comme prévu et atteint les résultats escomptés. Ces mesures, parfois connues sous le nom d’indicateurs de performance clé (KPI), sont étroitement liées aux mesures d’évaluation, aux méthodes, à l’analyse des données et aux rapports adoptés.

© Alain April, 2022

- Tous droits réservés

33

Les tests du logiciel

Mesures du logiciel qui fait l’objet de test qui facilite la planification et la conception de tests : La mesure de couverture des tests peut être utilisées pour planifier et guider l’arrêt de l’activité de test. ISO 29119-4 (ISO29119-4, 2021)

décrit

cette

mesure

de

présentées précédemment

—

couverture mesures

pour

toutes

les

de tests suivants

techniques

de

tests

:

La couverture des partitions d’équivalences,

— La couverture de l’arbre de classification : Cette méthode de mesure de la couverture de l’arbre de classification se compose de deux étapes principales : o

L'identification des aspects pertinents pour le test (appelés classifications) et leurs valeurs correspondantes (appelées classes), ainsi que

o

La combinaison de différentes classes de toutes les classifications en cas de test.

—

La couverture de l’analyse des valeurs frontalières,

—

La couverture du test de syntaxe,

—

La couverture de la combinaison des techniques de tests,

—

La couverture de l’analyse des valeurs frontalières, et

—

La couverture du test de syntaxe.

La classification des défauts et leurs statistiques : La littérature sur les tests est riche en classifications et taxonomies de défauts qui peuvent être génériques ou spécifiques d’un contexte ou d’attributs de qualité (comme la classification des défauts d’utilisabilité, la taxonomie des vulnérabilités et des attaques de sécurité et de confidentialité sur le matériel et sur le logiciel, la classification des risques de cyber sécurité). Pour rendre les tests plus

efficaces, il est important de savoir quels types de défauts peuvent être trouvés dans le logiciel testé et la fréquence relative avec laquelle ces défauts se sont produits dans le passé. Ces informations peuvent être utiles pour faire des prédictions de qualité ainsi que pour l’amélioration des processus.

Mesure de la densité des défauts : Traditionnellement, un logiciel qui fait l’objet de test peut être évalué en comptant les défauts découverts, par exemple le ratio entre le nombre de défauts trouvés et la taille du logiciel. Par exemple pour un module de 1,000 lignes codes qui contiens 10 défauts alors 10/1000

= .01 = 1 défaut per Kloc. Actuellement, grâce à la définition sémantique des défauts, des mesures supplémentaires peuvent être envisagées telles que la profondeur du défaut (le nombre minimal de suppressions de défauts nécessaires pour rendre un logiciel qui fait l’objet multiplicité des défauts (le nombre de changements pour réparer un seul défaut).

de test correct) et la atomiques nécessaires

Mesure de la fiabilité : Une estimation statistique de la fiabilité du logiciel, qui peut être obtenue en observant la fiabilité atteinte, peut être utilisée pour

évaluer un logiciel qui fait l’objet de test et décider si les tests peuvent ou non être arrêtés ou s’ils sont suffisamment matures pour être candidats à la prochaine itération agile.

34

1 Les connaissances fondamentales en tests du logiciel

Récemment, l’évaluation de la fiabilité prend un rôle important dans le contexte infonuagique : d’une part, les propositions de validation et de vérification se

concentrent sur la garantie du niveau (généralement élevé) de fiabilité et de disponibilité requis des applications infonuagiques. Finalement,

des

mesures

spécifiques

du

processus

de

développement

agile,

telles que la fréquence de déploiement, le délai d’exécution, le temps moyen de récupération après panne et le taux de défaillance en production sont également des mesures couramment adoptées pour planifier et gérer les activités et les résultats des tests.

1.6.2 L’EVALUATION DES TESTS EFFECTUÉS Le comportement du logiciel qui fait l’objet de test est généralement vérifié en exécutant des suites de tests, qui sont essentielles pour trouver des défauts.

Une question fondamentale dans les tests de logiciels, tant du point de vue des chercheurs

que des praticiens,

est de savoir comment

comparer

les suites de

tests. Habituellement, évaluer les suites de tests signifie comparer les techniques de génération de cas de test qui produisent les cas de test. Plusieurs critères sont utilisés à cette fin, tels que les critères de couverture ou l’analyse des mutations.

L’injection de défauts : Dans l'injection de fautes, certaines fautes sont artificiellement introduites dans le logiciel qui fait l’objet de test avant le test. Lorsqu’une suite de tests est exécutée, certaines de ces fautes injectées seront révélées ainsi que, éventuellement, certaines fautes qui étaient déjà présentes. En théorie, en fonction du nombre et du nombre de défauts artificiels découverts, l’efficacité des tests peut être évaluée et le nombre restant de

défauts réels peut être estimé. En pratique, les statisticiens s’interrogent sur la distribution et la représentativité des fautes injectées par rapport aux fautes réelles et sur la petite taille de l’échantillon sur lequel reposent les éventuelles

extrapolations. Certains soutiennent également que cette technique doit être utilisée avec beaucoup de précautions, car l'insertion de défauts dans le logiciel

qui fait l’objet de test comporte le risque évident de les y laisser. Le compte

de mutation

: Dans

les tests de mutation,

la mesure

de l’efficacité

de la suite de tests est calculée comme le rapport des mutants tués au nombre total de mutants générés. Plus l’efficacité de la suite de tests est élevée, mieux c’est, en raison de la capacité des tests exécutés à découvrir les fautes injectées les plus réelles.

Comparaison relative permet propriété

et efficacité de comparer

spécifique,

relative

des

différentes

telle que le nombre

différentes techniques

techniques : L'efficacité de test par rapport

de tests nécessaires

à une

pour trouver la

première défaillance, le rapport entre le nombre de défauts trouvés lors des tests et tous les défauts trouvés pendant et après les tests, et le degré d’amélioration de la fiabilité du logiciel. Plusieurs études ont déjà été menées

© Alain April, 2022

- Tous droits réservés

35

Les tests du logiciel

pour comparer analytiquement et empiriquement différentes techniques chacune des notions de propriété (ou d’efficacité) qui y sont définies.

1.7

selon

TESTS APPLICATIFS ET DE DOMAINES D’APPLICATIONS SPECIFIQUES Quel que soit le processus de développement adopté, le test reste une activité fondamentale. Cependant, dans certains cas, tels que le cycle de vie de développement adopté et/ou le domaine d’application, des activités de test ou des terminologies spécifiques pourraient être utilisées. Dans le reste de cette section, les particularités des tests dans les différents processus de

développement logiciel ainsi que dans les principaux domaines d’application sont brièvement introduites. 1.7.1 LES TESTS PENDANT LE PROCESSUS DE DÉVELOPPEMENT Il existe une variété de processus logiciels traditionnels qui peuvent être adoptés au sein de l’organisation et qui sont essentiellement basés sur les principes de cycles de vie de développement connus. Le cycle de vie en cascade et agile n’est que quelques-uns des modèles couramment appliqués.

Cependant, dans tous ces processus, le test n’est qu’une des activités effectuées, elle est parfois réalisée à la fin du processus, avec un risque tangible d’échec du projet de développement en cas de déviation des besoins de l’utilisateur final ou de problèmes de tests. Au cours des dernières années, afin d’évaluer et de contrôler la qualité globale du logiciel, des initiatives d’amélioration des processus logiciels ont été mises en place. En conséquence, différents modèles d’amélioration ont été proposés à cet effet, par exemple le

CMMI (SEI, 2018) est l’un des modèles les plus référencés, capable de guider les principales parties prenantes dans l’amélioration de leurs processus de développement. Dans le cas des tests c’est le modèle TMMI qui est composé d’un ensemble bien défini des meilleures pratiques en matière de test logiciel, qui améliore la qualité des activités de tests en augmentant la satisfaction client. Au niveau initial du TMMI, l’organisme laisse typiquement chaque ingénieur logiciel effectuer les tests du logiciel par lui-même. Les résultats varient selon

l’expérience de chacun et sa capacité à bien comprendre la vue d’ensemble des interactions des systèmes de l’entreprise. Au niveau deux de maturité du TMMI l’étape des tests est reconnue dans une politique dont l’objectif principal est de s’assurer que le logiciel rencontre les spécifications du client et sera testé selon une approche commune à tous les ingénieurs logiciels de l’organisation. Au niveau trois du TMMI, des objectifs de tests sont établis lors de la stratégie de tests. Les tests sont contrôlés et vérifiés avant la mise en production finale du

logiciel. Un centre d’expertise de test, indépendant des ingénieurs logiciel et localisé au niveau de l’organisation, démarre ses activités. Au niveau quatre du TMM], on se préoccupe de la mesure du processus de test et des résultats des tests. Les projets de développement et les logiciels maintenus font l’objet de types de tests additionnels : de performance, de fiabilité, d’utilisabilité et de maintenabilité. Finalement au niveau cinq du TMMI, l’accent de tous est

36

1 Les connaissances fondamentales en tests du logiciel

principalement sur la prévention des défauts. Un processus de rétroaction, des mesures et des activités d’inspections, est instauré. Les outils de création/modification et réutilisation de cas de tests sont déployés et utilisés. Le mouvement de test agile promeut la réalisation des tests aux premières étapes du développement logiciel. L'objectif est d’anticiper au plus tôt la

détection des défauts et leur élimination afin : d’augmenter la qualité globale du logiciel qui fait l’objet de test et de réduire le coût et les risques liés aux activités de test. Dans le développement agile, différents aspects de test doivent être pris en compte

:

La qualité du code interne : les tests de régression, la priorisation des tests, les tests de sécurité et confidentialité pourraient être les principaux objectifs de la qualité du code pour cette approche. Habituellement, les tests unitaires et d'intégration sont automatisés, tandis que l’application du langage de définition des exigences BDD est utilisée pour faciliter les tests. En ce qui concerne les tests d’acceptation, ils se concentrent davantage sur le système

et les attentes des utilisateurs finaux. Dans le développement agile, les activités de test impliquent toutes les parties prenantes (telles que les clients et les membres de l’équipe) et tous visent à identifier les domaines où des améliorations pourraient être apportées dans les interactions futures. Généralement, l’automatisation des tests est utilisée pour gérer le risque de régression et les tests exploratoires peuvent être utilisés pour gérer l’impact d’un manque d’exigences détaillées. Dans le développement piloté par les tests,

les cas de test ciblent principalement la spécification et l’acceptation des exigences logicielles et ils sont générés avant l’écriture du code. Pour cela, les tests sont basés sur les récits utilisateurs et implémentés à l’aide d’outils de tests de composants automatisés. En effet, le TDD est une pratique qui nécessite la définition et la maintenance de tests unitaires et peut également avoir un impact positif sur l’élaboration des besoins utilisateurs et des

spécifications des exigences logicielles. Lors des tests de « build » automatisés et d'intégration continue (par exemple à l’aide d’approche DevOps (DevOps, 2021)), le logiciel qui fait l’objet de test est

continuellement développé, intégré, livré et surveillé. Dans ce processus, des tests de régression sont effectués en continu afin d’identifier et de corriger en temps opportun les problèmes de développement et d'intégration. De plus, des techniques de test rapide, telles que les tests de fumée, sont couramment utilisées lors de l’intégration continue pour garantir que le logiciel qui l’objet de test est testable avant qu’il ne soit mis en service.

fait

1.7.2 LES TESTS POUR DES DOMAINES D’APPLICATIONS SPÉCIFIQUES Habituellement,

un

domaine

d’application

est strictement

lié à une

certaine

réalité ou métier et, par conséquent, les approches de test doivent parfois être adaptées aux besoins du domaine et adaptées aux technologies adoptées par

ce domaine d’affaires. Pour les systèmes logiciels critiques ou la vie où l’environnement est en danger quand le système a une défaillance, certaines normes

s’imposent,

comme

MISRA,

© Alain April, 2022 - Tous droits réservés

ou

la

planification

des

tests

doit

être

37

Les tests du logiciel

effectuée dès la définition du besoin, associée a l'utilisation du logiciel :

elle

repose

sur

l’analyse

des

risques

identifier les risques propres a aux actions effectuées par le logiciel (ex. : risque de perdre la traçabilité d’un dispositif), identifier les risques induits par l’utilisation du logiciel (ex. d’intrusion et accès à une base de données confidentielle), et

: risque

évaluer le niveau de risques et en fonction du niveau de risque : planifier

les types et plus ou moins de tests. Il n’est pas toujours nécessairement question de faire des tests techniques très poussés du logiciel, mais de tester et démontrer l’atteinte des objectifs d'utilisation, en testant des scénarios d'utilisation avec des utilisateurs

représentatifs pour le niveau de sécurité requis. Ainsi, dans les items qui sont présentés dans la liste suivante, je présente un aperçu des différentes considérations et solutions que l'ingénieur logiciel doit prendre en compte pour les tests de logiciels appliqués dans plusieurs environnements domaine :

spécifiques à un

Tests dans le domaine automobile et véhicules routiers : en raison de la complexité croissante des systèmes automobiles et de transport qui ajoutent

des technologies comportant du logiciel constamment, les tests impliquent différents aspects qui incluent presque tous les composants logiciels ainsi que leur interaction avec le matériel. Ce qui préoccupe ce domaine c’est l'intégration de composants, provenant de toutes sortes de fournisseurs, et qui comportent du matériel et du logiciel. L'interaction défectueuse entre ces systèmes peut créer des dangers possibles. Ainsi dans ce secteur il n’est pas rare de voir l’utilisation de modélisation/simulation pour générer des cas de

tests : de sécurité, de fiabilité/cycle de vie, de systèmes intégrés. Plusieurs normes sont actuellement disponibles pour guider et gérer les essais de logiciels pour automobiles en fonction de la particularité, du composant ou de l’aspect qualitatif à évaluer : ISO26262, sont que quelques exemples,

IATF 16949,

Autosar et OSEK

ne

Test dans le domaine avionique/aérospatiale/ferroviaire : généralement, les systèmes avioniques comprennent plusieurs composants indépendants ou faiblement couplés et des produits commerciaux prêts à l’emploi. Cela oblige

les tests à inclure des processus et des approches très généraux applicables à la fois au niveau du système et au niveau des processus. Fonctionnels et non fonctionnels, intégration, tests opérationnels de communication, tests de résistance, tests de sûreté et de sécurité ne sont que quelques exemples d’approches possibles. Comme dans d’autres domaines, les normes de support telles que les normes ARINC et ASTM F3153-15 peuvent être utilisées comme référence, Tests dans le domaine

de la santé et machine

médicales : les tests dans le

domaine des dispositifs et des données médicales sont décrits dans la norme 1SO13485 (ISO13486, 2016) et doivent garantir différents aspects de qualité tels que l’échange de données sécurisé et fiable, des performances stables, la confidentialité et la sécurité, l’interopérabilité, la convivialité, la performance et la conformité aux règlementations du secteur ainsi qu’aux normes de sécurité et de sûreté (telles que Health Level Seven (HL7), Fast Healthcare

38

1 Les connaissances fondamentales en tests du logiciel

Interoperability Resources

(FHIR) et Digital Imaging

and

Communications

in

Medicine (DICOM), HIPAA et le RGPD) doivent également étre pris en compte, —

Test dans le domaine juridique : l’un des aspects les plus importants du domaine juridique est la gestion des utilisateurs et des données hautement sensibles. Par conséquent, la sécurité, la confidentialité et la confiance sont

les attributs les plus courants à garantir. De plus, en raison de la grande quantité de données collectées et échangées, des tests de performance du référentiel de données, des approches de test de communication et d’intégration précises, ainsi qu’une méthodologie de test de cohérence et de conformité doivent également être adoptés. Enfin, parce que le domaine juridique est caractérisé par des nomenclatures et un jargon spécifique,

l'implication d’experts du domaine juridique dans le processus de génération de cas de test est également une pratique courante pour se concentrer sur les caractéristiques et la qualité souhaitables, —

Tests du domaine financier : ils couvrent un large éventail d’aspects allant de la gestion des besoins financiers à l’évaluation des applications financières et des logiciels. Comme dans d’autres domaines spécifiques, la connaissance du domaine financier (comme les banques, les coopératives de crédit, les compagnies d'assurance, les sociétés de cartes de crédit, les entreprises de crédit à la consommation, les fonds d’investissement et les courtiers en

valeurs mobilières) pourrait être nécessaire pour une application efficace et efficiente du processus de test. La satisfaction client, la convivialité, la sécurité, la confidentialité, les intégrations de composants et d'applications tiers, le temps réel et les performances sont quelques-uns des défis les plus importants de ce domaine, —

Test du domaine de l'Informatique des Objets (IOT): ils impliquent des aspects tels que le développement d’applications, la gestion des appareils, la gestion

du système, la gestion de l’hétérogénéité, la gestion des données, les outils d’analyse, le déploiement, la surveillance, la visualisation et la recherche. De plus, la sécurité, la confidentialité, les communications ainsi que l’interaction (utilisateurs/composants) doivent également être prises en compte dans l’évaluation de la qualité. À titre d’exemple, les lignes directrices et les suites de tests de conformité spécifiques pour l’évaluation de la cybersécurité du SUT IoT sont détaillées dans les normes ETSI,

—

Tests du domaine des jeux vidéos : Les applications et logiciels de jeux sont actuellement un domaine très actif provoquant une demande croissante de nouvelles approches et moyens pour leur qualité et leur sécurité. Parmi les techniques de test spécifiques, le « playtesting » (qui est un test alpha) est l’une des plus couramment adoptées : un processus par lequel un concepteur de jeu rend disponible un nouveau jeu pour que les joueurs détectent les défauts de conception avant de le commercialiser. Dans ce cas, les vrais joueurs répètent les méthodes de contrôle qualité à de nombreux points de

l'exécution

du jeu

ou

du

processus

de

conception.

De

plus,

les tests

d’interface graphique, les tests de fonctionnalité, les tests de sécurité, les tests

de console,

les tests de conformité

et les tests de performance

peuvent

également être pris en compte.

© Alain April, 2022

- Tous droits réservés

39

Les tests du logiciel

1.7.3 LES TESTS DE TECHNOLOGIES EMERGENTES Au cours des derniéres décennies, le développement de logiciels est stimulé par des tendances émergentes telles que la diffusion généralisée de la technologie mobile, l’adoption d’infrastructures infonuagiques ainsi que l’analyse de données volumineuses et le logiciel en tant que paradigme de souligne de nouvelles contraintes et défis pour l’activité de test. Tests

d'applications

du

domaine

de

l’intelligence

l’intelligence artificielle (IA) est appliquée

service

qui

artificielle : Récemment,

avec succès

dans

la pratique,

et tôt

ou tard, la plupart des applications commerciales auront une forme d’IA en production. En raison de leurs particularités, tester de telles applications peut être plus difficile et peut être plus coûteux. Les tests d’IA, font référence a toute activité conçue pour révéler des défauts. Trois aspects principaux doivent être pris en compte lors de la définition des défauts et des tests dans ce scénario :

les conditions requises, telles que l’exactitude, la robustesse, la sécurité et la confidentialité. Un défaut peut exister dans les données, l’algorithme ou l’approche d’apprentissage ou le modèle utilisé, et les activités de test impliquées, telles que la génération de cas de test, l’identification et la définition d’oracle de test, et les critères d’adéquation des cas de test. Dans toutes ces applications, un prototype est d’abord généré sur la base de données historiques. Ensuite, des tests hors ligne, tels que la validation croisée, sont effectués pour vérifier que le modèle généré satisfait aux conditions requises. Habituellement, après prédiction en générant

données

le déploiement, le modèle est utilisé à des fins de de nouvelles données. Grâce à des tests en ligne, les

générées sont analysées pour évaluer comment

avec les comportements

le modèle interagit

des utilisateurs,

Tests d’application de chaîne de blocs : En général, les techniques de test couramment utilisées pour valider les chaînes de blocs et les applications associées telles que les contrats intelligents sont les tests de performance, pénétration et les tests de sécurité.

de

Cependant, en fonction de la situation spécifique, différents aspects doivent être pris en compte lors du test du logiciel qui fait l’objet de test basé sur la chaîne de blocs, tel que :

—

Le niveau publique

de validation ou

privée.

Ce

dépend dernier

de l'implémentation nécessite

beaucoup

de la plateforme

plus

:

d’efforts lors des

tests,

—

La

connexion

connectée

à

avec

d’autres

d’autres

applications : lorsque

applications,

des

tests

la chaîne

d’intégration

de

blocs

doivent

est être

effectués à des fins de contrôle de cohérence, —

Les problèmes de performances : dans ce cas, des tests de performance doivent être effectués. Dans ce cas, des stratégies spécifiques capables de

traiter un grand nombre de transactions doivent être conçues afin de garantir un niveau de performance satisfaisant. Des mesures qualitatives et quantitatives doivent également être prises en compte, moyenne de validation des transactions et la sécurité.

telles que la latence

40

1 Les connaissances fondamentales en tests du logiciel

Test d’applications infonuagiques : Les tests sur l’infonuagique visent à valider la qualité des applications et des infrastructures déployées en tenant compte a la fois des propriétés fonctionnelles et non fonctionnelles. L’accent est alors

mis sur identification des problèmes posés par les systèmes résidant dans le nuage. Par conséquent, les activités de test utilisent des techniques visant à valider les performances, l’évolutivité, l’élasticité et la sécurité des services fonctionnels basés sur le cloud. De plus, ces tests doivent également être axés sur la compatibilité et l’interopérabilité entre les ressourcesinfonuagiques hétérogènes, lorsque différents modèles de déploiement sont utilisés (par exemple, privé, public ou hybride), et finalement Tests d’applications concurrentes et distribuées : L’un des aspects importants des tests dynamiques, complexes, distribués ou simultanés est la nécessité de

gérer plusieurs systèmes d’exploitation et mises à jour, plusieurs plateformes et versions de navigateur, différents types de matériel et un grand nombre d'utilisateurs simultanés. Cela empêche presque la possibilité d’appliquer des approches de test basées sur la hiérarchie classique entre composants ou systèmes au profit de solutions basées sur les entrées/sorties, les fils de dépendance ou les relations dynamiques. De plus, la possibilité d’une intégration et d’un déploiement continus des différents composants oblige le

processus de test à inclure des approches de gestion du fonctionnement, de l’injection, de la surveillance et du rapportage des tests en continu, en fonction des

contraintes

de

d’adaptabilité.

temps,

Enfin,

des

d'utilisation

solutions

de

la bande

passante,

permettant

la

de

débit

réutilisation

et

des

connaissances, des architectures et du code de test, pour rendre l’activité de test plus efficace et moins coûteuse doivent également être envisagées.

1.8

OUTILS DE TEST LOGICIEL Actuellement,

il

existe

plusieurs

outils

de

test

axés

sur

les

différentes

particularités et besoins du logiciel qui fait objet de test. Dans cette section, les principaux problèmes et défis liés aux outils de test sont présentés.

1.8.1 LA SÉLECTION ET PRISE EN CHARGE DES OUTILS DE TEST Les tests nécessitent de nombreuses tâches beaucoup d’effort de maind’œuvre, l’exécution de nombreux scripts et programmes et la gestion d’une grande quantité d'informations. Des outils appropriés peuvent alléger le fardeau manuel et rendre les tests moins sujets aux erreurs. Des outils sophistiqués peuvent prendre en charge la conception de tests et la génération de cas de test, ce qui les rend plus efficaces. Les conseils aux gestionnaires et aux testeurs sur la manière de sélectionner les outils de test qui seront les plus utiles à leur organisation et à leurs processus sont un sujet très important, car la sélection des outils affecte

grandement l’efficacité et l’efficience des tests. La sélection des outils dépend de divers facteurs, telles que le but du test, les langages/cadriciels de programmation impliqués, les objectifs du test, les environnements de test, etc.

© Alain April, 2022 - Tous droits réservés

41

Les tests du logiciel

En général, il se peut qu’il n'y ait pas un outil unique qui réponde a des besoins particuliers, donc une suite d’outils pourrait être un choix plus approprié.

1.8.2 LES CATEGORIES D’OUTILS DE TEST Il

existe

plusieurs

classifications

d'outils

de

test

logiciel

qui

reposent

principalement sur leurs fonctionnalités, telles que : Les harnais de test fournissent un environnement contrôlé dans lequel les tests peuvent être lancés et les sorties de test peuvent être enregistrées. Afin

d’exécuter des parties d'un programme, des pilotes et des stubs sont fournis pour simuler respectivement les modules appelants et appelés, Les générateurs de tests fournissent une assistance dans la génération des cas de test. La génération peut être aléatoire, basée sur un chemin, basée sur un modèle ou une combinaison de ces éléments, Les outils de capture/relecture réexécutent ou rejouent automatiquement les tests précédemment exécutés qui ont enregistré des entrées et des sorties (par exemple, des écrans), Les

outils d’Oracle

de

test/comparateurs

de fichiers/outils

de vérification

d’assertion aident à décider si un résultat de test est réussi ou non, Les analyseurs de couverture de test évaluent lesquelles et combien d’entités du graphe de flot de programmes ont été testées parmi toutes celles requises par le critère de couverture de test sélectionné,

Les traceurs programme,

enregistrent

l'historique

des

chemins

d’exécution

d’un

Les outils de test de régression prennent en charge la réexécution d’une suite de tests après la modification d’une section de logiciel. Ils peuvent également aider à sélectionner un sous-ensemble de test en fonction du changement effectué,

Les outils de test de la fiabilité prennent en charge l’analyse des résultats des tests et la visualisation graphique afin d’évaluer les mesures liées à la fiabilité

selon des modèles sélectionnés, Les outils basés sur l'injection se concentrent sur lintroduction ou la reproduction de problèmes spécifiques afin de confirmer que le système faisant objet de test se comporte

de manière

appropriée

dans

la condition

correspondante. Cela peut impliquer la gestion d’un certain type d’entrée ou le déclenchement

d’évènements.

Habituellement,

deux

types d'outils basés

sur l'injection sont considérés : l’injection d'attaques et l’injection de fautes, Des outils basés sur la simulation sont utilisés pour la vérification et la validation des propriétés sélectionnées. Ils exploitent généralement des modèles spécifiques pour permettre l’exécution automatisée de scénarios afin d’évaluer si le logiciel qui fait l’objet de tests fonctionne comme prévu ou de prédire comment il répondrait à des entrées définies. Les outils typiques basés sur la simulation sont : les outils de vérification, outils de collaboration, outils d’optimisation, outils de test de système automatisé, outils d’évaluation

de concepts logiciels, Les outils de tests de sécurité. Il existe actuellement différents outils de test axés

sur

des

vulnérabilités

de

sécurité

spécifiques.

Parmi

les

plus

42

1 Les connaissances fondamentales en tests du logiciel

couramment adoptés, il y a des outils pour : l’injection d’attaque, les tests de pénétration et les tests flous, —

Les outils de gestion des tests incluent tous les outils de support capables

d’assurer une gestion des tests et une collecte de données

efficientes et

efficaces,

—

Les outils de test multinavigateurs permettent de créer et d’exécuter rapidement des cas de test d’interface utilisateur sur des applications de bureau, mobiles et Web dans le but de vérifier si le logiciel qui fait l’objet de test ressemble et fonctionne comme

—

prévu sur chaque appareil et navigateur,

Les outils de test de charge sont spécifiquement conçus pour collecter des données et des preuves utiles logiciel qui fait l’objet du test,

pour

les

évaluations

de

performances

du

—

Les outils de suivi des défauts aident à suivre les défauts détectés au cours des projets de développement d’un logiciel. Ces outils se comportent comme des systèmes de suivi et permettent généralement aux utilisateurs finaux de

—

Les outils de test mobile prennent en charge la mise en œuvre et le test des applications mobiles en permettant : plusieurs tests d’interface utilisateur répétés sur la plateforme d’application, la mise en œuvre sur de vrais appareils mobiles ou émulateurs, tester les applications mobiles sur des

saisir directement les rapports défaillances/défauts,

implémentations en temps réel, la collecte d’assurance qualité spécifiques,

de données

pour

des

mesures

—

Les outils de test d’API vérifient si les applications répondent aux attentes en matière de fonctionnalités, de performances, de fiabilité et de sécurité grâce

—

Les outils de validation du CSS permettent de valider le code des feuilles de

à l’automatisation de tests d’API spécifiques, style en cascade (CSS) et de découvrir les défauts, les problèmes et les avertissements qui peuvent être corrigés. L'un des valideurs les plus utilisés dans la pratique est celui fourni par le W3C qui est un service de validation gratuit visant à aider les concepteurs Web et les développeurs Web à vérifier CSS, et —

Les outils de test d’applications Web, également appelés simplement outils de test Web, sont utilisés pour valider les fonctionnalités et les performances des logiciels Web, avant leur déploiement en production. Ces outils fournissent des informations et des données importantes aux différentes

parties prenantes du logiciel qui fait l’objet de test, telles que les développeurs, les administrateurs de serveurs et d’infrastructures. Dans une perspective DevOps (DevOps, 2021), ces outils de test permettent de résoudre les problèmes ou les défauts avant de rendre utilisateurs finaux.

le logiciel disponible pour les

Ceci met fin à l’introduction au corpus des connaissances en tests logiciels que l'ingénieur logiciel devrait connaître. Ainsi vous avez maintenant une connaissance générale et une vue d’ensemble des enjeux et des défis du domaine des tests logiciels. Certains de ces sujets seront repris dans ce livre avec un peu plus de détail afin de mieux comprendre comment mettre en œuvre

certaines

© Alain April, 2022

techniques

et

connaissances.

- Tous droits réservés

Le

prochain

chapitre

décrit

les

43

Les tests du logiciel

approches de tests, les stratégies et techniques à l’aide de techniques de test boite noire.

1.9

de conception

de cas de tests

SOMMAIRE DES APPRENTISSAGES DU CHAPITRE 1 Voici

les connaissances

à bien

réviser

pour

avoir

les meilleures

chances

de

succès à l’examen : -

Quelle est la différence entre l’AQL et le CQL? Expliquez en quoi consistent la vérification et la différence avec les activités

de validation? -

-

A quoi servent les activités de V&V? Quelles sont les deux catégories d’outils de V&V?

Mme Wallace a pris le temps d’expliquer en détail en quoi consiste la V&V d’une manière pratique. elle?

-

Quels sont les 3 types de techniques de V&V selon

Donnez des exemples de techniques statiques de V&V? Donnez des exemples de techniques dynamiques de V&V?

-

Donnez des exemples de techniques formelles de V&V?

-

En quoi consistent les tests logiciels? Pourquoi doit-il y avoir un nombre limité de cas de tests?

-

Quelle est la notion de ‘généralement infinie’ de cas de tests?

-

Comment tester un artéfact logiciel papier/document?

-

Décrivez le concept de critère d’adéquation d’un test?

-

En quoi consiste un critère de sélection d’un test?

-

Décrivez la différence entre une erreur, un défaut et une défaillance? A quel endroit est-ce que les erreurs sont insérées dans les artéfacts

logiciels lors d’un projet de développement d’un nouveau logiciel? -

Comment

-

Quelles sont les questions que se posent les testeurs concernant la priorité,

peut-on identifier les défauts dans les artéfacts logiciels?

les critères de sélection et la création de cas de tests?

-

En quoi consiste un Oracle de test?

-

Est-ce possible de tester entièrement un logiciel? Quel est le nom du chercheur qui a dit ‘les tests de programmes peuvent être utilisés pour

montrer la présence de défauts, mais jamais pour montrer leur absence”? -

Expliquez chaque niveau de test?

-

Comment décider de l’unité de test dans un logiciel orienté-objet? Comment effectuer un test d'intégration?

-

Quel

test vise a s’assurer

sont

implémentées

que

toutes

et fonctionnent

les fonctions

correctement

attendues

(du

point

du

logiciel

de vue

des

utilisateurs finaux)?

-

En quoi consiste l’objectif de test?

-

Expliquez en quoi consiste un test de performance?

-

Expliquez en quoi consiste un test de régression? Nommez les techniques de tests qui utilisent les spécifications du logiciel?

-

Nommez les techniques qui utilisent la structure du logiciel? Nommez les techniques de tests selon l’expérience? Expliquez comment mesurer l’activité de test et listez les mesures

les plus

populaires? -

Identifiez

un

domaine

d’affaires

particulier

(par

exemple

: automobile,

avionique, machine médicale...) et expliquez les particularités pour tester ces applications? -

Listez les catégories d’outils de tests?

44

2 Les tests boite noire

Les tests

boite

noire

À la suite de la lecture de ce chapitre, vous serez capable de comprendre et utiliser : —

Les approches de tests,

—

Des stratégies et techniques de conception de tests boite noire : La technique des tests exploratoires (ad hoc), La technique de séparation en classe d'équivalence, La technique d'analyse des valeurs frontalières, La technique des graphes cause à effet, La technique des tables de décision.

© Alain April, 2022

- Tous droits réservés

45

Les tests du logiciel

2.1

INTRODUCTION Nous avons vu au chapitre précédent que le guide recommande qu'un objectif de test (c’est-à-dire déterminé avant l’exécution des tests. Ce critère est objectif de test. Ce critère limite la portée des tests mesures

SWEBOK (version 2022) un critère d’arrét) soit aussi parfois nommé un qui seront exécutés. Des

de couvertures de tests et de densité des défauts peuvent aussi aider

l’ingénieur logiciel à prendre la décision couts/bénéfices/risques de continuer ou d’arréter de tester. La section suivante présente les approches de tests. Attention, certains prétendent qu’il dans certains cas la différence test boite noire

vs

boite

blanche

n’est

pas

si clair.

Faites

la lecture

de

cet

article

de

StackOvervflow. En général la règle est simple. Si votre test parcourt tous les branchements d’exécution et les structures de données du code que vous testez, il s’agit alors d’un test en boite blanche. Cependant, si votre test n’utilise pas les divers branchements et les structures de données du code, il ne peut pas prétendre

être un test boite blanche.

2.2

LES APPROCHES DE TESTS Etant donné les contraintes de ressources

et de temps

imposées aux activités

de développement logiciel, il est probable que le personnel ne pourra pas effectuer des tests complets et exhaustifs de toutes les conditions et ainsi identifier tous les défauts présents. Décider de poursuivre les tests alors qu’ils auraient pu être arrêtés, prolonge la durée et le coût inutilement. Arrêter trop tôt, contribuera à livrer un changement qui a des défauts.

46

2 Les tests boite noire

Onze Principes de tests :

1. Le test est un processus consistant a solliciter un composant logiciel en utilisant un ensemble choisi de cas de tests avec intention de (i) révéler des défauts et (ii) d’évaluer sa qualité, 2. Quand l'objectif du test est de détecter des défauts, un bon cas de test est celui qui a une probabilité élevée de révéler un défaut encore non détecté, 3. Les résultats de tests devraient assurer l’exactitude, 4.

être inspectés

pour

en

Un cas de test doit spécifier la sortie ou le résultat attendu,

5. Des cas de tests devraient être développés aussi pour des entrées invalides, 6.

méticuleusement

La

probabilité

logiciel est composant,

qu’il

existe

proportionnelle

des

au

défauts

nombre

pour des entrées valides, mais

additionnels

de

défauts

dans

un

composant

dans

ce

7. Les tests devraient être réalisés par un groupe qui est indépendant groupe de développement ou de maintenance (quand c’est possible),

du

8.

Les tests doivent être répétables et réutilisables,

9.

Les tests devraient être planifiés,

déjà

détectés

10. Les activités associées aux tests devraient être intégrées dans le cycle de vie du projet, 11. Les tests forment une tache créative accompagnée défi.

d’un haut niveau de

Il est donc nécessaire d’établir un objectif de test avant d’effectuer les tests. L'objectif de test varie, par exemple selon trois perspectives :

© Alain April, 2022

- Tous droits réservés

47

Les tests du logiciel

1)

La qualité - éliminer le plus grand nombre

de défauts possible, allant de :

o

Tous les défauts indépendamment

o

Presque tous les défauts possibles dans le temps (le cout et le temps sont le critère de sortie), Tous les défauts possibles avec temps est le critère principal.

du temps ou des coûts,

le

temps

alloué,

disponible quand

le

2)

L’acceptation du client — l’objectif principal des tests est d’obtenir l’approbation du client de telle sorte qu’il accepte la modification au logiciel,

3)

La certification du produit - une tierce partie effectue les tests afin de certifier que le logiciel a été testé par un organisme indépendant. Ces tests visent

typiquement: oO

L’élimination de virus et logiciels espions,

oO

La fonctionnalité,

o

L’utilisabilité,

o

La comparaison et la position relative du logiciel par rapport à un autre logiciel, L'évaluation indépendante de la qualité du logiciel.

En plus d'établir un objectif général de test, les deux considérations font également partie d’une bonne stratégie de test : 1)

Quels niveaux et quels général de test ?

2)

Comment

suivantes

types de tests seront exécutés pour atteindre l’objectif

faire ces tests — choisir les techniques de test : o

Boite noire : exploratoires, classes d’équivalence, analyse des valeurs frontalières, graphes causes à effets, table de décision,

etc, Boite blanche : test d’énoncé, test de décision, test de branche, test de chemins, test de définition d'utilisation d’une variable, etc,

d’une

variable,

test

Tests de mutation, Test

de

régression

: si nous

faisons

ces

tests,

quel

sera

le

nombre d’itérations pour s’assurer de sa qualité? Une seule

48

2 Les tests boite noire

fois où réitérons-nous jusqu’à ce que clos ? o

tous les défauts

soient

Critères de réussite du test : prenons-nous une durée fixe, un

budget fixe ou bien une fonction des défauts découverts et qui subsistent ? o

Quels sont les mécanismes de résolution d’un défaut qui est découvert lors de tests et qui doit faire l’objet d’une correction et d’un test subséquent ?

o

Quels seront les itérations de tests et les rapports requis au cours de l’exécution des activités ?

o

d’étape

Qui effectuera l’analyse des défauts et catégorisera les défauts ?

Pour répondre à ces préoccupations, les chercheurs sont toujours à la recherche du critère de sortie optimal. Tous sont d’accord qu’il faut tenter d’éviter d’abandonner les tests à cause de : l’obligation de livrer, l’expiration des délais, l'épuisement du budget, la perte de ressources ou l’explosion de défauts imprévus. Différentes approches de tests ont été conçues, étudiées et utilisées pour essayer d’optimiser l’effort de test tout en obtenant une qualité satisfaisante. Les approches de tests les plus populaires sont : —

Le suivi du plan initial,

—

La tendance des défauts résiduels,

—

La couverture du code,

— —

L'estimation de la présence de défauts, Le profil d'utilisation réelle du logiciel.

L’approche fondée sur l’effort prévu vise à l’achèvement du plan de test approuvé. Donc le critère de sortie, dans ce cas, est que tous les tests prévus et planifiés ont été effectués. Cette approche repose sur la prémisse que le plan initial était de bonnes qualités. La seconde approche, la densité des défauts, évalue le nombre de défauts identifiés par unité de temps. Si ce taux augmente, on continue les tests. Le critère de sortie est : quand ce nombre diminue en deçà d’un seuil établi, on arrête les tests. Cette approche est valable si la cueillette des données est effectuée sérieusement. La couverture de code est une approche qui tente de mesurer la quantité de code source qui a été testé. Un programme avec une couverture de code élevée a été plus testé et a moins de chances de contenir des défauts qu’un

programme avec une couverture de code faible. Différentes méthodes peuvent être utilisées pour calculer la couverture de code; parmi les plus populaires est le pourcentage du code testé. La mesure de ce taux implique souvent l’utilisation de tests unitaires.

© Alain April, 2022

- Tous droits réservés

49

Les tests du logiciel

La quatrième approche reproche aux trois premières de ne pas considérer l’importance relative des différentes fonctions du logiciel dans l’établissement du critère d’arrêt. L’approche fondée sur le risque tente d’associer l’effort de

test dans les endroits les plus critiques du logiciel. Ici, critique signifie que la présence de défauts dans certaines fonctions causerait un impact négatif plus important sur les affaires de l’organisme. Cette approche nécessite que les utilisateurs et ingénieurs logiciels établissent préalablement l’ordre de la criticité des fonctions du logiciel. On effectuera donc plus de tests dans les endroits critiques. On effectuera des tests dans les autres endroits, mais le critère de sortie sera principalement influencé par l’achèvement des tests de

fonctions critiques. La dernière approche présentée est celle du profil d’utilisation réel du logiciel. Cette approche n’impose pas la nécessité de tester avec autant de rigueur les

parties garder d’effort quand tester.

d’un logiciel qui sont utilisées peu fréquemment. On propose donc de des statistiques d'utilisation de chaque fonctionnalité et de mettre plus sur les fonctions à utilisation fréquente. Le critère de sortie est donc : les fonctions les plus utilisées toutes couvertes, on pourra arrêter de

En fait, il n'y a pas de solution magique et chaque approche possède ses forces et ses faiblesses. Nous sommes ici dans un équilibre fragile entre la présence de défauts résiduels et la décision de continuer à les chercher. Dans ce contexte il est assez difficile de prévoir l’effort des tests au début du projet, la prochaine

section discute de ce sujet, et présente ces concepts en détail.

2.3

STRATEGIES ET TECHNIQUES DE CONCEPTION DE TESTS Un logiciel moindrement complexe, c’est-à-dire pour un logiciel comportant un grand nombre de branchements et décisions, il est presque impossible de tester toutes les combinaisons possibles. Par exemple, pour un logiciel comportant seize branchements, il y a 70 chemins possibles. Le nombre de chemins d’exécution possibles progresse rapidement; en utilisant cent branchements, il

y a 184 756 chemins et en ayant 400 branchements, il y a 1.38E+11 chemins possibles. Les développeurs de logiciels auront donc développé un certain nombre de jeux de tests qui permettront de détecter le plus d’erreurs possible tout en sachant qu’il sera impossible de tout tester. Voilà tout le défi du bon choix de cas de tests. De plus, nous avons vu au chapitre précédent qu’il n’existe aucun moyen connu de prouver l’absence de défauts dans un logiciel raisonnablement complexe, en particulier l’absence de défauts de spécification

et de conception. Cette section introduit les stratégies et techniques de conception de cas de test les plus populaires. Un cas de test efficace démontrera les propriétés suivantes : —

La probabilité plus élevée de trouver des défauts,

—

L'utilisation plus efficace des ressources,

—

Une probabilité plus élevée de pouvoir réutiliser les tests,

50

2 Les tests boite noire

—

Une meilleure productivité, et

—

Une possibilité de livrer un service de meilleure qualité.

Il y a deux grandes familles de techniques de tests :

1)

Tests dynamiques : tests qui nécessitent l’exécution du logiciel,

2)

Tests statiques : tests qui ne nécessitent pas l’exécution du logiciel: analyse statique des exigences, des artéfacts documents de tests, du code source, etc.

de

conception,

des

Les deux stratégies les plus populaires de conception de tests sont : 1)

Boite noire (aussi nommés «tests basés sur les spécifications» ou «tests fonctionnels») : le logiciel à tester est considéré comme une boite opaque. Le testeur sait ce que fait le logiciel, à partir de sa description

dans les spécifications (formelles ou non). Ces tests définissent les pré conditions et post conditions afin de révéler des défauts au niveau des fonctionnalités telles que spécifiées, 2)

Boite blanche

(aussi nommés

«tests structurels»,

«boite transparente»

ou »boite de verre») : se concentre sur la structure interne du code source (ou un pseudocode

Les

cas

de

tests

sont

«fidéle») qui doit être disponible au testeur.

conçus

pour

exercer

certaines

structures

spécifiques du code source. Appliqués à des «petits» éléments logiciels, ces tests sont utiles pour révéler des défauts reliés à la conception ou au code (c.-à-d. données).

contrôle,

logique,

séquences,

initialisation,

flot

des

Pour chacune de ces deux stratégies, il y a un certain nombre de techniques qui ont été développées au fil des années (voir figure 2.1).

Stratégie de test

Point de vue

Sources

entrée

-Exigences

Boîte noire

-Données

-Cas d'utilisation -Table de décision

sortie \

-Analyse cause à effet

-Archi

-Test d'énoncé

-Conception

-Test de branche

-Graphes du code source

-Test de chemin

-Structures internes Le i

-Test de flot de données -Test de structure

\ AA

-Classes d'équivalence Analyse des valeurs frontalières Transition d'états

-Analyse des défauts

pese

-Exploratoire

Spécifications -Expertise du domaine

A

Boîte blanche

Techniques/Approche

du testeur

Figure 2.1 — Les stratégies de test boite noire et boite blanche (Burnstein, 2003 Fig.

4.1) Les sections suivantes présentent les techniques pour ces deux stratégies.

© Alain April, 2022 - Tous droits réservés

51

Les tests du logiciel

2.3.1 LA TECHNIQUE BOITE NOIRE POUR LA CONCEPTION DE CAS DE TESTS La stratégie boite noire de conception

de cas de tests considére

le logiciel

comme une boite noire, soit du point de vue entré/sorti, sans aucune considération de sa structure interne (c.-a-d. comment il est mis en œuvre).

Les cas de tests sont conçus a partir d’une spécification (c.-a-d. sans égard au code source, si celui-ci est disponible). Le

défi repose

sur le choix

des

données

d’entrée

qui auront

une

probabilité

élevée de révéler des défauts fonctionnels. Bien qu’il y ait un grand nombre d’approches, nous présentons seulement les cinq approches principales : 1)

Tests exploratoires (aussi nommée

2)

Séparation en partitionnelle»),

3)

Analyse des valeurs frontalières (aussi nommée «tests aux limites»),

classes

4)

Graphes

5)

Tables de décision.

«aléatoire» ou «ad hoc»),

d’équivalence

(aussi

nommée

«analyse

cause a effets,

2.3.2 LES TESTS EXPLORATOIRES (AD HOC) C’est probablement la technique la plus largement pratiquée encore aujourd’hui. C’est donc une des techniques basées sur l’expérience. Les cas de tests sont dérivés en s’appuyant sur les compétences du spécialiste en logiciel, de son intuition et de son expérience avec des logiciels similaires. L'efficacité de cette approche de test s’appuie aussi sur ses connaissances, qui peuvent provenir de sources diverses: observation du comportement du logiciel pendant les essais, une familiarité avec le domaine, une bonne connaissance de la

plateforme technologique, les défaillances observées par le passé, les types de défauts plus courants découverts dans cette organisation, les risques associés à une partie du logiciel en particulier, comporte toutefois des limites.

et

ainsi

de

suite.

Cette

approche

Procédons par un exemple : Un module accepte une donnée d’entrée dont le domaine de validité est les nombres entiers entre 1 et 100 inclusivement. Le testeur choisit (au hasard) les valeurs 55, 24 et 3 pour trois cas de test. Est-ce que ces trois valeurs sont suffisantes pour démontrer que le module rencontre

ses spécifications? Devrait-on utiliser plus (ou moins) de valeurs pour faire une utilisation optimale des ressources? Est-ce qu’il y a d’autres valeurs qui sont plus susceptibles de révéler des défauts? Devrait-on utiliser des valeurs de test à

l’extérieur

d’un

certain

domaine

de

validité

(c.-à-d.

pas

un

entier,

zéro,

négatif, supérieur à 100, ...)? Le principal avantage de cette technique est la génération rapide des données d’entrée pour les tests. En contrepartie, son principal inconvénient est qu’il est peu susceptible de mener à un jeu de données de tests "efficaces" (c.-à-d. à

haute probabilité de révéler des défauts).

52

2 Les tests boite noire

2.3.3 LA SEPARATION EN CLASSES D’EQUIVALENCE Cette

technique,

aussi

nommée

partition

d’équivalence,

vise

a

choisir

les

données d’entrées de manière a augmenter l’efficacité des cas de tests. Elle a pour objectif de réduire le nombre de cas de tests à un niveau raisonnable tout

en conservant une bonne couverture. L’ingénieur logiciel se préoccupe ici de la séparation

du

domaine

d’entrée

(aussi

applicable

au

domaine

de

sortie)

en

classes d’équivalence. Toutes les valeurs comprises dans une classe d’équivalence sont considérées "égales" (c.-à-d. sollicitent le logiciel de la même manière, ou ont une probabilité équivalente de révéler des défauts). Chaque entrée du logiciel à tester est spécifiée pour représenter une plage de valeurs. Le testeur doit choisir une classe d’équivalence valide qui couvre la plage permise et deux classes d’équivalence invalides, en dehors de chaque

extrémité de la plage valide (voir tableau 2.1). Tableau 2.1 Exemple de classes d'équivalence pour le domaine = entiers {1.50}

Classe d'équivalence

| Description

Validité

1

1