Module : test du produit et documentation

Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application

web ou mobile )
Réalisé et Présenté par : Mme Medjerab.L

Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou

application web ou mobile )

Introduction :

Le 4 juin 1996 la fusée Ariane 5-01 s’est éclaté après quelques secondes de son
démarrage causant des dégâts humains et matériels :

Le 23 juillet, la commission d'enquête remet son rapport :

La fusée a eu un comportement nominal jusqu'à la 36ème seconde de vol. Puis les

systèmes de référence inertielle (SRI) ont été simultanément déclarés défaillants. Le SRI
n'a pas transmis de données correctes parce qu'il était victime d'une erreur d'opérande
trop élevée du "biais horizontal" .

Les raisons :

1) Un bout de code d’Ariane V (concernant le positionnement et la vitesse de la fusée)

repris dans Ariane V

2) il contenait une conversion d’un flottant sur 64 bits en un entier signé sur 16 bits

3) pour Ariane V, la valeur du flottant dépassait la valeur maximale pouvant être

convertie

4) défaillance dans le système de positionnement

5) la fusée a “corrigé” sa trajectoire

6) suite à une trop grande déviation, Ariane V s’est détruite !

Être humain, développe des logiciel qui peuvent présenter des défaillances ; bugs causant
des dégâts humains et matériels surtout lorsqu’il s’agit de systèmes critiques ( militaires ;
santé ; financiers et autres)

Pour cela il est indispensable de faire des validation , vérification , et tests (V V T) avant
de lancer un logiciels sur le marché

1 / 20
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Présenté par : Mme Medjerab.L

[Link]

Anomalie (fonctionnement ): C’est la Différence entre le comportement attendu et le

comportement observé

Défaut (interne) : élément ou absence d’élément dans le logiciel entraînant une anomalie

Erreur (programmation,conception) : comportement du programmeur ou du concepteur

conduisant à un défaut

Bug Il décrit le dysfonctionnement d’un programme informatique , lorsque le bug est

bénin, il se résume la plupart du temps au plantage d’un logiciel ; à l’impossibilité
d’effectuer une action, voire à une perte d’information

Exemples de bugs informatiques

En informatique, un bug (de l’anglais bug, « insecte ») est un défaut de conception d’un
programme informatique à l’origine d’un dysfonctionnement. Ce nom vient du tout premier
incident informatique qui a été causé par un insecte. La gravité du dysfonctionnement peut
aller de bénigne (défauts d’affichage mineurs) à majeure (crash système pouvant
entraîner de graves accidents : par exemple, l’explosion du Vol 501 d’Ariane 5). Un bug
peut résider dans un logiciel applicatif, dans les logiciels tiers utilisés par ce logiciel
applicatif, voire dans le micrologiciel d’un composant matériel comme ce fut le cas du bug
de la division du Pentium3. Un patch (terme francisé en « rustine ») est un morceau de
logiciel destiné à corriger un ou plusieurs bugs. »

2 / 20 [Link]
quelles-differences/
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Réalisé et Présenté par : Mme Medjerab.L

 Le 9 Septembre 1945 à 15h45 le premier bug de l’histoire informatique a eut lieu ! Il

s’agit d’une mite bloquée dans un relais sur le calculateur électromagnétique Mark I
de l’Université de Harvard, et qui donna le terme de bug (bogge en français) pour
désigner une erreur informatique (étant donné que bug signifie insecte en anglais),
grâce à la mathématicienne Grace Murray Hopper.

 Bug de l’an 2000 : la pendule indique Janvier 1900 au lieu de Janvier 2000 « Le
passage informatique à l’an 2000, couramment appelé bug de l’an 2000 ou bogue
de l’an 2000, a suscité de sérieuses inquiétudes à cause de problèmes de
conception et donc de programmation portant sur le format de la date dans les
mémoires des ordinateurs et, par conséquent dans les matériels informatiques,
ainsi que dans les logiciels. Dans de nombreux programmes et beaucoup de bases
de données, il manquait les deux chiffres 19 correspondant au siècle, de sorte
qu’au passage de 99 à 100, en réalité 00, de nombreux dysfonctionnements
devaient se produire dans ces traitements informatiques, 00 correspondant à
l’année 1900 au lieu de 2000. »

Test: Le test est un ensemble d’activités utilisé pour tester le code source afin de
découvrir (et corriger) les erreurs avant la livraison du logiciel client.

3 / 20
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Présenté par : Mme Medjerab.L

Test : (issue de ‘Le test des logiciels [SX-PR-CK-2000]) : Le test d’un logiciel est une
activité qui fait partie du processus de développement. Il est mené selon les règles de
l’assurance de la qualité (QA) et débute une fois que l’activité de programmation est
terminée. Il s’intéresse aussi bien au code source qu’au comportement du logiciel. Son
objectif consiste à minimiser les chances d’apparitions d’une anomalie avec des moyens
automatiques ou manuels qui visent à détecter aussi bien les diverses anomalies
possibles que les éventuels défauts qui les provoqueraient.

Définition (issue de la norme IEEE-STD729, 1983) : Le test est un processus manuel ou

automatique, qui vise à établir qu’un système vérifie les propriétés exigées par sa
spécification, ou à détecter des différences entre les résultats engendrés par le système et
ceux qui sont attendus par la spécification.

Cas de test: Un cas de test est un ensemble d’instructions destiné à découvrir un type
particulier d’erreur ou d’un défaut dans le système de logiciel en induisant un échec

Essais structuraux: Les essais structuraux est une approche de test où les tests sont
tirés de la connaissance de la structure et la mise en œuvre du logiciel.

Scénario de test : actions à effectuer avant de soumettre le jeu de test Le scénario de

test produit un résultat

Tests fonctionnels : Les tests fonctionnels se réfère à des tests qui implique que
l’observation de la sortie pour certaines valeurs d’entrée, et il n’y a aucune tentative
d’analyser le code, qui produit la sorti

2. Les principes du test de logiciel :

Nous allons définir les sept 7 principes du test suivant :

Principe 1 : Les tests montrent la présence de défaut

Les tests verifient certaines scénario et peuvent montrer si des défauts sont présent dans
ces scenarios .Cette derniére est une information nécessaire mais pas suffisante :

 Les tests peuvent permettre de découvrir des défauts et améliorent la qualité du

logiciel

4 / 20 [Link]
quelles-differences/
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Réalisé et Présenté par : Mme Medjerab.L

 Cependant des résultats de test positif ne sont pas synonyme de zéro défaut

Principe 2 : Les tests exhaustifs sont impossibles

les tests exhaustifs est une approche des tests selon laquelle le site de tests comprennent
toutes les combinaisons de valeurs d’entrée et de préconditions .

Il est impossible de tout tester :

 une explosion combinatoire de nombres de tests:on peut faire face à plusieurs

fonctionnalités , des cas d »utilisation métiers et plusieurs environnements à tester

 Des contraintes de temps et des moyens ( coût du projet fournir des efforts de
tester les cas critique )

Il est do,donc nécessaire de définir quoi tester (les fonctionnalités les plus importantes ) ;
avec quels objectifs mesurables (plan de projet ) et avec quels moyens

Principe 3 : tester tôt

il permet de découvrir et supprimer les défaut aux plus tôt dans le cycle de
développement de logiciel car :

 De nombreux défauts sont introduits très tôt dans un logiciel

 Découvrir tôt des défauts va empêcher leur propagation

 Le coût de correction d’un défaut augmente avec le temps ( un défaut découvert

par le client coûte chers )

Donc l ‘objectif doit être de réduire au maximum,le temps qui s ‘écoule entre l ‘introduction
de défaut et sa détection

Principe 4 : Regroupement des défauts

En général ; les défaut sont souvent localisés en majorité dans les mêmes modules en
applications. Ceci peut se traduire par :

5 / 20
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Présenté par : Mme Medjerab.L

 Cibler l’effort de test au démarrage du projet sur la base des bilans des projets
similaires, de l ‘expérience de développement du testeur et des versions
précédentes

 Cibler l’effort de test pendant la phase d ‘exécution du test afin de déterminer les
modules pouvant contenir le plus de bugs

Principe 5 : Le paradoxe du pesticide

Le paradoxe du pesticide s ‘applique aux tests ( le pesticide ne tue pas toutes les insectes
puisque ils résistent de plus en plus )

 Après plusieurs applications ; le pesticides ne tue plus les insectes qui sont
devenus résistants

 Les même ensembles de test ne sont plus capable de trouver de nouveaux défauts

les cas de test doivent être renouvelés afin de déterminer plus d’erreurs

Principe 6 : Les tests dépendent du contexte

Les tests doivent être adaptés aux contextes

 Contexte d’utilisation métier du logiciel (cas des systèmes critiques

 Contexte d’exécution du logiciel (environnement plateforme matériel et logiciel)

 Contexte du projet (contraintes temps ; budget ; mode de développement...)

Principe 7 : L’illusion de l’absence d’erreurs

Le principe définit le rôle et l ’intérêt des tests ; donc l’absence des défauts ne signifie pas
que le logiciels est de qualité

 Les besoins des utilisateurs ne sont pas couverts (défaut ; défaillants )

 les utilisateurs ont mal formulé leurs besoins

6 / 20 [Link]
quelles-differences/
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Réalisé et Présenté par : Mme Medjerab.L

Les tests permettent d’augmenter la qualité et éviter les Bugs

3. Les objectifs du test :

les tests ont pour objectif de :

 Vérifier si les exigences spécifiques ont été satisfaites

 Trouver les défauts ; défaillances et Bugs

 Acquérir et renforcer de la confiance dans le niveau qualité du logiciel (être sur

qu’il répond aux besoins)

 Fournir suffisamment des informations fiables aux prises de décisions en

connaissance de cause : réaliser un rapport de détailler les tests effectués, décider
du déploiement du produit

 Prévenir des défaillances et des défauts (prévenir vaut mieux que guérir )

 Réduire le niveau de risque

 Se confier aux exigences ou normes contractuelles ; légales ou réglementaires

l ‘ objectif principal des tests se résume en :

 Trouver des Bugs

 Éliminer les bugs

 vérifier toutes les fonctionnalité ; voir si l’objet de test est complet et valide et s’il
fonctionne comme le souhaite des utilisateurs et les autres parties prenantes

 Améliorer la qualité du produit à tester

7 / 20
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Présenté par : Mme Medjerab.L

L‘ objectif principal des tests c ‘est d’améliorer la qualité du produit à tester ; la finalité
des tests est d’avoir des utilisateurs finaux satisfaits par :

 Les caractéristiques fonctionnels ou non fonctionnels attendu

 l’absence de bugs lors de l’exécution des fonctionnalités :

4. Les Niveaux de test :

4.1. Définition :

Un groupe d’activités de test qui sont organisées et gérées [Link] niveau de test
est lié aux responsabilités dans un projet

4.2. Les niveaux de tests :

Les niveaux de tests sont des moyens de structurer et organiser ces tests (phase de
test). Selon les standards des tests ; il y’a 4 niveaux de tests ayant pour objectifs de
composer les tests

 Tests de composants

 tests d’intégration

 tests système

 tests d’acceptation

figure 2: Les niveaux de tests

8 / 20 [Link]
quelles-differences/
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Réalisé et Présenté par : Mme Medjerab.L

figure 3: Les niveaux de tests selon la pyramide

4. 2.1. Les tests de composants :

Appelé également tests unitaires consistant à tester les composants du logiciel

séparément.

Objectif : Trouver des défauts dans le composant (code ) et empêcher les défauts de
passer à des niveaux plus élevés

Rôle : Souvent réalisés par les développeurs

4. 2.2. Les tests d’intégration :

Intégration : Le processus de combiner des composants ou systèmes en assemblage

plus grands

ils sont exécutés par un testeur à l’interne ou externalisés auprès d’une TRA. (faire appel
à un vrai spécialiste du test logiciel afin que votre projet de Tierce Recette
applicative (TRA) soit un succès. ) En interne ou externalisé, peu importe l’objectif à
atteindre est le même, l’intervention de ce professionnel permet de s’assurer que plusieurs
composantes de votre logiciel interagissent conformément aux cahiers des charges et
délivrent les résultats attendus.

9 / 20
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Présenté par : Mme Medjerab.L

Objectif : montrer des défauts dans les interfaces et interactions de composants ou

systèmes intégrées

Rôle : En général, ces tests sont gérés par des développeurs

4. 2.3. Les tests systèmes :

Consiste à tester le logiciel ou l’application dans son ensemble

À ce niveau, on exécute plusieurs scénarios complets qui constituent les cas d’utilisation
du logiciel. Dans le jargon du test informatique, on le qualifie de test de type boîte noire et
ils permettent de s’assurer de la fonctionnalité globale du logiciel et de son comportement
sur les terminaux d’utilisation. Pour aboutir à des reportings objectifs pour ce type de test,
l’équipe qui en a la charge doit se distinguer et assurer une totale indépendance vis-à-vis
des équipes de développement.

Objectif : Vérifier le comportement du système et valider que le système est complet et

trouver des défauts

Rôle : test, système sont effectués par les testeurs (le type le test de fonctionnalités
test en boite noire)

ce test correspond aux spécifications

4. 2.4. Les tests d’acceptation :

Les tests d ‘acceptation consistant à valider que le produit final correspond bien aux
besoins et aux attentes des clients ou utilisateurs finaux..

Objectif : Établir la confiance dans la qualité du logiciel

Rôle : client/utilisateurs ou son représentant dans le projet( comme PO )

10 / 20 [Link]
quelles-differences/
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Réalisé et Présenté par : Mme Medjerab.L
5. Le Processus de test :

il se déroule en 6 phases d’activité comme suit :

1. La planification des tests 4. Implémentation des tests

2. Analyse des tests 5. Exécution des tests

3. Conception des tests 6. La clôture des test

Ces phases sont accompagnées du pilotage et d’un contrôle de tests :

Les activités de test Tâches Testware (produit
d’activités )

 Définir les objectifs du test  Plan de tests

[Link] planification des tests et l ‘approche retenue pour  Calendrier des
atteindre les objectifs tests

 La réponse de la question  Les conditions de

2. Analyse des tests que teste t on? tests
 Analyser les bases de
tests :
 les spécifications des
exigences
 design
 code
 Les rapports d’analyse des
risques
 définir et prioriser les
conditions de tests
 La réponse de la question  Cas de
[Link] des tests comment tester ? test /données de
 Concevoir et prioriser les test
cas de test et les
ensembles de cas de test
 Identifier les données
 concevoir l’environnement
technique du test
 La réponse de la question :  Scripts de test
[Link]émentation des tests Avez vous maintenant tout  sorties de tests
en place pour exécuter les  Données de tests
tests ?

11 / 20
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Présenté par : Mme Medjerab.L
 Développer et prioriser les
procédures de tests
 créer des sorties de tests à
partir des procédures de
test et les positionner dans
un calendrier d ‘exécution
des tests
 construire l’environnement
de test
 Exécuter les suites de tests  Statut des cas de
[Link]écution des tests
 comparer les résultats tests
obtenus avec les résultats  rapport des défauts
attendus
 Rapport des défauts
 test de confirmation et /ou
test de régression
 Analyser les leçons  Rapport de clôture
6 . clôture des test apprises des activités de des tests
test termines  demande de
 vérifier si tous les rapports changements
de défauts sont clôturés
 Créer un rapport de
synthèse de test
 Le pilotage des tests  Rapport
Le pilotage et contrôle des implique la comparaison d’avancement des
tests ( durant toutes les régulière de l’avancement tests
phases précédentes ) réel par rapport au plan de  informations sur les
test risques
 le contrôle des tests
consiste à prendre les
mesures nécessaire pour
satisfaire aux objectifs du
plan de test
 l’avancement des tests par
rapport au plan est
communiqué aux parties
prenantes dans des
rapports d ‘avancement
des tests

tableau 1 : Le processus de test

12 / 20 [Link]
quelles-differences/
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Réalisé et Présenté par : Mme Medjerab.L
Exemples de Plan de test :
Modèle de plan de test est un document détaillé qui décrit la stratégie de test, les objectifs, le
calendrier, l'estimation et les livrables, ainsi que les ressources requises pour les tests. Le plan de
test nous aide à déterminer l'effort nécessaire pour valider la qualité de l'application testée. Le plan
de test sert de modèle pour mener les activités de test logiciel en tant que processus défini qui est
minutieusement surveillé et contrôlé par le responsable des tests.

figure 4: Le plan du test

13 / 20
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Présenté par : Mme Medjerab.L
Exemples de cas de test :

tableau 2 : exemple 1 de cas de test

14 / 20 [Link]
quelles-differences/
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Réalisé et Présenté par : Mme Medjerab.L

tableau 3 : exemple 2 de cas de test

15 / 20
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Présenté par : Mme Medjerab.L

figure 5 : le rapport de bug

16 / 20 [Link]
quelles-differences/
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Réalisé et Présenté par : Mme Medjerab.L

6. La stratégie des tests :

La stratégie de test est l’art de coordonner les actions du test pour atteindre les
objectifs de qualité du logiciel. C’est à ce moment que vous décidez : comment porter
les efforts de tests , c’est à dire décider lesquels des parties du logiciels qui vont être
tester en priorité, le niveau de test dans lequel ceci va se faire et avec quelle
profondeur :

Test d’ acceptation
Test 4 Test 5

Test systéme
Test 2 Test 3

Test d’intégration Test 1

Grâce à l’analyse des risques ; vous allez classer les exigences selon leurs criticité ,
maintenant vous décider comment tester chacune des exigences et les classer de façon à
réduire au maximums le risque de voir se produire les dysfonctionnement les plus redouté
et cela dans les limites des ressources dont vous disposez :

 Délai  Dimensions de l’équipe

 Budget  leurs niveau d’expertise

 Disponibilité de l’information

Les exigences les plus critiques sont à tester en priorité pour détecter le plus rapidement ;
cela permet d’avoir le temps de les corriger avant la date de mise en disposition (MEP) .

17 / 20
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Présenté par : Mme Medjerab.L

Comme les tests sont des activités à réaliser tout le cycle de vie de projet par des
acteurs multiples : développeurs ; testeurs et le profil d’exploitations ; il convient de
décider en collaboration avec ces acteurs de ou des niveaux de tests (composant ;
intégration ; système et acceptation ou autres )

La collaboration étroite entre les équipes du projet permettra une meilleure vision
d’ensemble de périmétrie et va prévoir d’oublier tester une partie de l’application
de tester deux fois la même chose .

Vous allez ensuite décider avec plus en profondeur de tests allouer à chaque classe
d’exigence an gardant à l’esprit de tester plus en profondeur les exigences les plus
critiques dans l’optique de détecter le anomalies les plus redondante ou au contraire
gagner an confiance des logiciels dans ces exigences les plus attendu .

7. Les techniques de test :

Le choix d’une technique de test s’appuie sur de nombreux facteurs dont par
exemple :

 Type de composant ou système

 Complexité

 Réglementation ou standards à respecter

 Niveau et type de risques (nombres utilisateurs en meme temps )

 Objectifs du test

 Documentation disponible

 Disponibilité et adéquation des compétences

18 / 20 [Link]
quelles-differences/
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Réalisé et Présenté par : Mme Medjerab.L
 Disponibilité et capacité des outils

 Cycle de vie

 utilisation attendu de l’application

 Expérience pass&e sur les techniques appliqués aux composants ou système

On peut définir trois grandes classes de techniques de tests : en Boite noire ; en boite
blanche et basé sur l’expérience

7.1 Les tests en boite noire :

Les tests en « boite noire » ( appelé aussi comportementales ou fonctionnelles ) sont

fondés sur l’analyse des spécifications ; des use cases;des user stories et des processus
métiers . Ils consistent à examiner uniquement les fonctionnalités d’une application, c’est-
à-dire si elle fait ce qu’elle est censée faire, peu importe comment elle le fait. Sa structure
et son fonctionnement interne ne sont pas étudiés. Le testeur doit donc savoir quel est le
rôle du système et de ses fonctionnalités, mais ignore ses mécanismes internes. Il a un
profil uniquement « utilisateur ».
Ainsi, cette méthode sert à vérifier, après la finalisation d’un projet, si un logiciel ou une
application fonctionne bien et sert efficacement ses utilisateurs. En général, les testeurs
sont à la recherche de fonctions incorrectes ou manquantes, d’erreurs d’interface, de
performance, d’initialisation et de fin de programme, ou bien encore d’erreurs dans les
structures de données ou d’accès aux bases de données externes.

Pour cela, ils préparent des scénarios calqués sur les différents chemins utilisateur
possibles sur le système testé. Toutes les fonctionnalités doivent être prises en compte,
pour qu’une fois tous les tests effectués, elles aient toutes été éprouvées. Les tests
consistent à suivre un scenario, et à vérifier pour chaque fonctionnalité que les entrées
(inputs) valides sont acceptées, que celles non valides sont refusées, et bien entendu,
qu’à chaque fois, le résultat (sortie ou output) attendu est bien obtenu. C’est ce que l’on
appelle la méthode « trial and error » (essais et erreurs).
Les avantages de cette méthode sont les suivants :
Simplicité : ces tests sont simples à réaliser, car on se concentre sur les entrées
et les résultats. Le testeur n’a pas besoin d’apprendre à connaître le

19 / 20
Module : test du produit et documentation
Chapitre II : les Tests Du Produit (Logiciel ;Application ;Site ou application
web ou mobile )
Présenté par : Mme Medjerab.L
fonctionnement interne du système ou son code source, qui n’est pas accessible.
Cette méthode est donc également non intrusive.
Rapidité : en raison du peu de connaissances nécessaires sur le système, le
temps de préparation des tests est très court. Les scénarios sont relativement
rapides à créer et à tester, puisqu’ils suivent les chemins utilisateurs, qui sont
relativement peu nombreux selon la taille du système.
Impartialité : on est ici dans une optique « utilisateur » et non « développeur ».
Les résultats du test sont impartiaux pas de contestation possible, comme par
exemple sur l’utilisation de tel processus plutôt qu’un autre selon l’opinion du
développeur.
Mais les tests en « boîte noire » ont également des inconvénients :
Superficialité : étant donné que le code n’est pas étudié, ces tests ne permettent
pas de voir, en cas de problème, quelles parties précises du code sont en cause.
De plus, les testeurs peuvent passer à côté de problèmes ou vulnérabilités sous-
jacentes. Certains problèmes sont également difficilement repérables avec cette
méthode, comme par exemple ceux liés à la cryptographie, ou à des aléas de
mauvaise qualité. C’est donc l’un des tests les moins exhaustifs.
Redondance : si d’autres tests sont effectués, il est possible que celui-ci perde
grandement de son intérêt, puisque son champ d’action a tendance à être inclus
dans celui d’autres tests.

20 / 20 [Link]
quelles-differences/