Vous êtes sur la page 1sur 92

Supprimer filigrane Wondershare

PDFelement

Tests et Qualité des Logiciels

14 avril 2020
Supprimer filigrane Wondershare
PDFelement
Syllabus
Tests et qualité des logiciels

► Unité d’Enseignement : UF3

► Crédits : 5, Coefficient : 3

► 1 cours, 1 TD, 1 TP
► Objectifs :
■ la mise en place et l’accompagnement d’une démarche
en informatique,
■ l’élaboration et la conduite de protocoles de tests
d’applications logicielles.
Supprimer filigrane Wondershare
PDFelement

Tests et qualité des logiciels

► Programme du cours théorique :


1. Qualité de logiciel
2. Introduction au test de logiciels
3. Tests statiques vs. Tests dynamiques
4. Tests fonctionnels
5. Tests structurels
6. Tests unitaires
7. Test d’intégration
► Références bibliographiques :
■ Sommerville, lan. Le génie logiciel et ses applications. Paris
InterEditions, 1988.
■ David Gustafson, génie logiciel. Série Schaum, Ediscience,
2003.
■ G. Teneau, J-G. Ahanda. Guide commenté des normes et
référentiels. Éditions Eyrolles, 2009.

□ ► « 3 2/91
Supprimer filigrane Wondershare
PDFelement
Syllabus
Tests et qualité des logiciels

► Note finale = 0.5 * Examen + 0.25 * TD + 0.25 * TD


■ Note de TD : 5 pts participation au tableau + 5 pts
appréciation + 10 pts micro- interrogation.
■ Note de TP : moyenne des notes sanctionnant la résolution
d’exercices proposées pendant les séances de TP.
■ En cas d’absence à une séance de TP ou de TD, les justificatifs
doivent être remis, au plus tard, à la séance suivante.
► URL des polycopiés : www.mediafire.com/7fhnlp3i8a5j2f
Supprimer filigrane Wondershare
PDFelement
Introduction
Pourquoi tester?

But : CONSTRUIRE DES LOGICIELS SANS DÉFAILLANCE =>


impossibilité théorique

Enjeux :
► Éliminer les défauts qui conduisent à des défaillance avant
exploitation.
► Assurer l’adéquation du logiciel à des normes légales ou
contractuelles (certification).
► Vérifier, lors de l’exploitation, que les évolutions corrigent les
défaillances existantes et n’en créées pas de nouvelles.

□ ► « 3
4/91
Supprimer filigrane Wondershare
PDFelement
Chaîne de l’erreur
De l’erreur vers la panne

Figure 1 - Chaîne de l’erreur1

1. Pradat-Peyre JF., Pratique des tests logiciels, Dunod, 2017.


< □ ► < (5 ► < - ►
5/91
Supprimer filigrane Wondershare
PDFelement
Chaîne de l’erreur
Types de pannes

► Une suite de défaillances peut entraîner une panne du


logiciel ou du système.
► Défaillance = Résultats inattendus (calculs erronés, fenêtre
mal placée, message non affiché, etc.) ou Service non rendu
(données non stockées, fenêtre non ouverte, etc.). Le logiciel
fonctionne toujours.
► Panne = Arrêt total ou partiel du logiciel ; nécessité de
redémarrer le logiciel ou le système.
Supprimer filigrane Wondershare
PDFelement
Chaîne de l'erreur
Mesures de fonctionnement

Deux indicateurs sont utilisés :


► MTBF (Mean Time Between Failure) : Temps moyen de
bon fonctionnement entre deux défaillances ou pannes, temps
de réparation compris. A maximiser.
► MTTR (Mean Time To Repair) : Temps moyen de remise
en route après une panne. A minimiser.
Supprimer filigrane Wondershare
PDFelement
pes des tests

Les tests montrent la présence de défauts : Non l’absence


d’erreurs.
Les tests exhaustifs sont impossibles : On ne peut tester
tous les cas possibles, sauf pour du code très simple.
Tester tôt : Plus tôt une erreur est découverte, moins
coûteuse est la correction.
Exemple : Les études menées sur le coût associé à la détection
d’une erreur montre que :
■ si une erreur décelée lors de la phase de définition des besoins
coûte 1,
■ cette erreur décelée en phase de conception coûte 10,
■ et une erreur décelée en phase d’exploitation coûte 100.
Supprimer filigrane Wondershare
PDFelement
pes des tests

Regroupement des défauts : Règle des « 80/20 » qui


énonce que 80% des défauts sont localisés dans 20% du
logiciel. Comment identifier ces 20% ?
Le paradoxe du pesticide : A trop appliquer le même
produit, il devient inefficace. Au bout d’un moment, la même
série de tests ne permettra plus de découvrir de nouvelles
erreurs, car elle a permis de trouver toutes les erreurs pour
lesquelles elle était faite.
Supprimer filigrane Wondershare
PDFelement
Principes des tests

► Les tests dépendent du contexte : En fonction de


l’utilisation du composant, les objectifs et les types de tests ne
seront pas les mêmes : tests fonctionnels, tests de
performances, test de la sécurité, etc.
► L’illusion de l’absence de défaut : on recherche des défauts
par rapport à ce qui a été exprimé comme attentes théoriques
du logiciel, qui peuvent être différentes des attentes réelles du
logiciel : il ne suffit pas de détecter puis de corriger tous les
défauts trouvés pour rendre un logiciel utilisable.

□ ► «51 10/91
Supprimer filigrane Wondershare
PDFelement
Processus de test

► Planifier les tests : Prévoir quoi tester (performance,


sécurité, fiabilité, qui doit tester et quels plates-formes et
outils utiliser.
► Spécifier les tests : Préciser quoi tester (quelles parties du
logiciels), quelles techniques utiliser (test fonctionnel,
structurel, ...).
► Concevoir les tests : Définir les scénarios de tests
(spécification des fonctions à tester, technique et outils à
utiliser pour le test de chaque fonction).
► Établir les conditions de tests : Prévoir pour chaque
scénario de tests les jeux de valeurs (données de test) à fournir
au logiciel pour réaliser ce scénario.
Supprimer filigrane Wondershare
PDFelement
Processus de test

► Définir les conditions d’arrêt d’une campagne de tests :


Préciser à partir de quel moment arrêter les tests.
► Contrôler les résultats : Comparer les données fournies par
l’exécution des tests par rapport aux données attendues ou
constatées lors de phases précédentes de tests.
► Valider les tests vis-à-vis des exigences : Vérifier qu’à
toute exigence correspond au moins un scénario de test
(mesure de la complétude des tests) et, à l’opposé, vérifier
qu’un scénario de test sert à valider au moins une exigence
(mesure de l’efficacité des tests).

□ ► «51 12/91
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Cycle en « V »

Spécification

Conceplioii
préliininai re

Conception
détaillée

◄ ► ◄ ► ◄ ► < 13/91
Supprimer filigrane Wondershare
PDFelement
Préparation des tests

► Pendant les phases analyse et définition des besoins et


conception
► Préparer la mise en œuvre lors des phases dédiées à l’assurance
qualité
► Une bonne réalisation permettra de faire des tests efficaces
Supprimer filigrane Wondershare
PDFelement
Préparation des tests
Phase d’analyse et définition des besoins

Il faut s’intéresser aux VV&T :

► Validation (Fait-on le bon logiciel?),

► Vérification (Le logiciel est-il bien fait?), et

► Tests (Peut-on découvrir des défauts -Testabilité?)


Supprimer filigrane Wondershare
PDFelement
Préparation des tests
Phase d’analyse et définition des besoins

► A cette étape, il faut faire le tri entre exigences


fonctionnelles exigences non fonctionnelles
(contraintes).

► Il faut éliminer les exigences imprécises, car difficilement


testables (par exemple,« l’application pourra être utilisée par
toute personne sachant manipuler une souris »).

► Lors d’une maintenance corrective, et après correction, il sera


important de vérifier que les corrections n’ont pas affecté des
parties du système qui fonctionnaient correctement (tests de
non-régression).
Supprimer filigrane Wondershare
PDFelement
Préparation des tests
Conception globale

Dans la conception globale, il faut construire une architecture


testable :

► Appliquer le principe de forte cohésion (les entités d’un


même module sont fortement liées) et faible couplage (les
modules sont peu interdépendants les uns des autres) ;

► Les résultats intermédiaires de longues chaînes de traitement


doivent être visibles (et récupérables au travers de « logs »
appropriés) ;
Supprimer filigrane Wondershare
PDFelement
Préparation des tests
Conception globale

► Prévoir un processus de traitement des erreurs et un


mécanisme de journalisation en vue d’une analyse ultérieure;

► Définir les interfaces des différents modules et donner un plan


des interdépendances des modules;

► Définir un ordre d’intégration et planifier les tests d’intégration


en termes de ressources humaines et matérielles.
Supprimer filigrane Wondershare
PDFelement
Préparation des tests
Conception détaillée

Dans cette phase, il faut construire les cas de tests et prévoir les
environnements pour réaliser ces tests. Deux stratégies sont
possibles :

► l’approche « classique » où le développeur code puis teste à


l’aide de tests unitaires;

► l’approche « Test Driven Development » où le développeur


conçoit et code les tests avant de coder le composant.
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Développement itératif

◄ ► ◄ ► ◄ ► ◄ 20/91
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Principes des méthodes de développement « agile »

« Adaptation du logiciel et des équipes aux changements de


contexte et aux modifications de spécifications intervenant pendant
le processus de développement. » 2

► Exemple de méthodes « agiles » : RAD (Rapid Application


Development), UP (Unified Process), ou XP (Extrême
Programming), ...

2. Pradat-Peyre JF., Pratique des tests logiciels, Dunod, 2017.


Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
XP (eXtrem Programming)

Objectif de XP
livraison rapide de versions de système utilisables immédiatement

Personnage central de la méthode


Le chef de projet, appelé : « coach »ou « tracker »

Caractéristiques d’un projet XP

► Coach expérimenté et connaissant la gestion des conflits


► Projet de petite taille et application indépendante
► Equipe expérimentée
► Relations de confiance entre le client et l’équipe projet
► le client est également un bon analyste des besoins
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
XP (eXtrem Programming)

itérations de
1 a 4 semaines itérations de

Exploration

► La phase de maintenance est la phase « nominale »du cycle


► La maintenance est itérée jusqu’à la réalisation de toute les
fonctionnalités, ou la mort du projet par « inertie »
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Les niveaux de test

1. Tests unitaires
2. Tests d’intégration
3. Tests système et tests de validation
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Les niveaux de test - Tests unitaires

Test unitaire
► teste les éléments de bas niveau : les composants
► un composant est testé indépendamment des autres
► on peut utiliser des « bouchons »(stubs)
► un composant peut être une fonction, une méthode, une
classe, une bibliothèque, etc.
► un composant contenant plusieurs sous-composant sera testé
lorsque chaque sous-composant a été testé (par exemple, une
classe composée de méthodes)
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Les niveaux de test - Tests unitaires

Défauts recherchés
► Variables utilisées et non initialisées
► Conditions inversées
► Sortie de boucle prématurée
► Absence de vérification des conditions d’entrée dans le
composant
► Utilisation d’un pointeur nul
► etc.

□ ► «51 26/91
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Les niveaux de test - Tests d’intégration

Un test d’intégration se concentre sur :

► les interfaces entre les composants,


► les interactions entre les différentes parties du système
► les interfaces entre systèmes

On ne teste pas les résultats du composant intégré

► On ne s’intéresse qu’aux interactions.


► On s’intéresse également à l’ordre d’intégration.
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Les niveaux de test - Tests d’intégration

Trois stratégies possible :

La stratégie du Big Bang

► intégrer tous les composants en même temps


► méthode simple, mais détection des défaillances difficile
► marche pour de petites applications

La stratégie par lots fonctionnels

► intégrer ensemble les composants travaillant dans un même


contexte (selon une logique métier)
► un big bang rationnel
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Les niveaux de test - Tests d’intégration

Les stratégies incrémentales

► classer les composants en composants de « bas niveau »et en


composants de « haut niveau »

► trois stratégies :
■ Ascendant : de bas en haut, localisation des erreurs plus facile,
les composants bas niveau sont les mieux testé (généralement
inutile, car les composants les plus simples)
■ Descendant : de haut en bas, l’architecture est testée tôt,
nécessite des bouchons
■ Mixte : intégrer en premier les composants les plus sensibles,
essayer de minimiser les inconvénients de chaque stratégies, et
maximiser les avantages

□ ► «51 29/91
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Les niveaux de test - Tests système et tests de validation

Test de validation
► La validation permet de tester un système par rapport à ses
spécifications fonctionnelles et non fonctionnelles (ISO 9126)
■ Utilité,
■ Utilisabilité,
■ Maintenabilité,
■ Evolutivité,
■ maintenabilité,
■ portabilité.

► Ce sont des tests Boîte noire.

► On teste dans un environnement aussi proche que possible de


l’environnement réel d’utilisation.
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Les niveaux de test - Tests système et tests de validation

Les documents en entrée des tests de validation


► Les spécifications fonctionnelles : que doit faire le logiciel
(exigences fonctionnelles)

► Les spécifications non fonctionnelles : comment « tourne »le


logiciel (performance, tolérance aux pannes, sécurité, etc.) et
comment est conçu le logiciel (maintenabilité, évolutivité -
couplage et cohésion)

► Le manuel utilisateur : comment utiliser le logiciel

► Tout autre document : cas d’utilisation, historique des


versions, etc. pour pouvoir apprécier quels sont les tests utiles
à effectuer à ce niveau de tests
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Les niveaux de test - Tests système et tests de validation

► Chercher des défauts par rapport aux spécifications


fonctionnelles : tests de validation

► Chercher des défauts par rapport aux spécifications non


fonctionnelles : tests système

► les tests de validation sont toujours menés par une équipe


indépendante

► On cherche a avoir une couverture maximale des différentes


fonctionnalités et cas d’utilisation.
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Les niveaux de test - Tests système et tests de validation

► Chercher des défauts par rapport aux spécifications


fonctionnelles : tests de validation

► Chercher des défauts par rapport aux spécifications non


fonctionnelles : tests système

► les tests de validation sont toujours menés par une équipe


indépendante

► On cherche a avoir une couverture maximale des différentes


fonctionnalités et cas d’utilisation.
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Les tests d’acceptation, tests alpha et tests bêta

► Même niveau que les tests de validation, objectifs différents

► Objectif :
■ vérifier le fonctionnement du système par rapport aux besoins
et aux spécifications

■ évaluer le niveau de préparation du système avant son


déploiement (installation, administration, etc.)
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Les tests d’acceptation, tests alpha et tests bêta

► Types de tests :

■ Tests d’acceptation par les utilisateurs, qui permet de


vérifier l’aptitude et l’utilisabilité du système par des
utilisateurs dans l’environnement cible

■ Tests d’acceptation opérationnelle, où les administrateurs


analysent des opérations comme les sauvegardes et les
restaurations du système, la gestion des utilisateurs, la gestion
de la sécurité, etc.
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Les tests d’acceptation, tests alpha et tests bêta

► Types de tests :

■ Tests d’acceptation contractuelle, où le client vérifie la


conformité du logiciel au contrat, et ils sont généralement
associés au versement d’une partie des montants dus par le
client

■ Tests d’acceptation réglementaire, où on vérifie la


conformité du logiciel par rapport aux règlements et
législations en cours
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Les tests d’acceptation, tests alpha et tests bêta

► Test alpha (ce — test) :

■ Tests d’acceptation réalisés par une équipe différente de


l’équipe de développement, mais de la même entreprise

■ Elles permettent à l’équipe de développement d’avoir une


vérification du logiciel en situation réelle, sans la présence du
client réel, et donc avec moins de stress.

□ ► «51 37/91
Supprimer filigrane Wondershare
PDFelement
Les tests dans le cycle de développement
Les tests d’acceptation, tests alpha et tests bêta

► Test bêta (/3 — test) :

■ Tests qui suivent les tests alpha

■ Tests d’acceptation réalisés par de vrais clients (bêta-testeurs),


qui auront le droit d’utiliser un logiciel récent, gratuitement ou
en avant-première.

■ Elles permettent à l’équipe de développement d’avoir une


vérification du logiciel en situation réelle, sans la présence du
client réel, et donc avec moins de stress.
Supprimer filigrane Wondershare
PDFelement
Types de tests
Tests non fonctionnels

► Valider le logiciel sur des critères non fonctionnels

► Le modèle ISO 9126 défini 6 critères de qualité :


■ fonctionnalité
■ utilisabilité
■ fiabilité
■ performance
■ maintenabilité
■ évolutabilité (portabilité)
Supprimer filigrane Wondershare
PDFelement
Types de tests
Tests de non-régression (tests de confirmation)

► Quand un défaut est corrigé, on doit re-testé avec les mêmes


tests ou des tests ciblés sur le défaut original pour confirmer
que celui-ci a bien été corrigé.

► Ils recherchent des défauts dans des parties déjà testées, en


répétant les tests sur un logiciel déjà testé, mais modifié, avec
pour but de mettre à jour tout défaut introduit ou découvert
après ces changements.
Supprimer filigrane Wondershare
PDFelement
Stratégie des tests
Tests statiques et tests dynamiques

Il existe deux types de tests :

► Tests statiques : Dans lesquels le code est testé sans


exécution. C’est un test boîte blanche qui nécessite une bonne
connaissance du codage.

► Tests dynamiques : Dans lesquels le code est testé avec


exécution. C’est un test boîte noire qui nécessite une bonne
connaissance métier, mais peut être réalisé par des non
informaticiens.
Supprimer filigrane Wondershare
PDFelement
Stratégie des tests
Les stratégies dynamiques

Il existe deux types de tests :

► Pour un test efficace, il faut trouver les bonnes données de test

► Bonnes données de test = valeurs d’environnement qui


mettent en défaut le logiciel
Supprimer filigrane Wondershare
PDFelement
Stratégie des tests
Les stratégies dynamiques

Il existe plusieurs techniques de tests dynamiques :

► Les techniques aléatoires

► Les techniques boîte noire

► Les techniques boîte blanche

□ ► «51 43/91
Supprimer filigrane Wondershare
PDFelement
Stratégie des tests
Techniques aléatoires (Random testing)

► Principe : « Plus on essaiera de valeurs distinctes plus on


aura de chance de découvrir une erreur »

► Il s’agit de générer un grand nombre de données de test


aléatoirement => très simple et automatisable

► Dans ce cas, la quantité prime sur la qualité

► On peut améliorer la génération des données, en ajoutant des


critères de choix statistiques (distribution des données,
fréquence des cas de test, etc.) : tests statistiques

► Autre amélioration : tests par mutation


Supprimer filigrane Wondershare
PDFelement
Stratégie des tests
Techniques boîte noire (Black box testing)

► Principe : « Ensemble de techniques qui se basent seulement


sur les spécifications lors de l’élaboration des jeux de valeurs »

► Il s’agit de générer un grand nombre de données de test


aléatoirement => très simple et automatisable

► Dans ce cas, la quantité prime sur la qualité

► On peut améliorer la génération des données, en ajoutant des


critères de choix statistiques (distribution des données,
fréquence des cas de test, etc.) : tests statistiques

► Autre amélioration : tests par mutation


Supprimer filigrane Wondershare
PDFelement
Stratégie des tests
Techniques boîte noire (Black box testing)

Parmi les tests boîte noire, on peut citer :

► Technique Ail Singles et Ail Pairs

► Technique par classes d’équivalence et tests aux limites

► Tests avec une table de décision


Supprimer filigrane Wondershare
PDFelement
Techniques boîte noire
Technique Ail Singles et Ail Pairs

► Tester une fonction en prenant en compte toutes les valeurs


possibles de ses paramètres est impossible

► Par exemple, la fonction /"(pi, p2. p3), avec : pl peut prendre


5 valeurs possibles (1, 2, 3, 4, 5), p2, 4 valeurs (a, b, c, d) et
p3, 3 valeurs (I, II, III).
On a doit avoir 5 * 4 * 3 = 60 tests différents.

► On peut réduire le nombre de tests, en utilisant les techniques


Ail Singles ou Ail Pairs
Supprimer filigrane Wondershare
PDFelement
Techniques boîte noire
Technique Ail Singles

► Chaque valeur de chaque paramètre doit apparaître au moins


une fois dans un des cas de tests

► Dans l’exemple précédent, ces tests suffisent :


■ f (l,a, /)
■ f&bjl)
■ f(3, c, ///)
■ /)
■ f & 3,11)
► Chaque valeur a été testé au moins une fois

► Mais ces tests ne suffisent pas, si le résultat dépend d’une


paire particulière de données
Supprimer filigrane Wondershare
PDFelement
Techniques boîte noire
Technique Ail Pairs

► Chaque paire de valeurs doit apparaître au moins une fois dans


un des cas de tests

► Dans l’exemple précédent, ces tests suffisent :


f(l,a,/) f(2,a, //) f^,a,lll) f(4,a,/) f(5,a, II)
f(l,b, //) f (2, b, ///) f(4, b, II) III)
///) f(2,c,/) f(3,c, //) f(4, c, ///) f(5,c, II)
f(l,d,/) f(2,d,ll) f(3, d, ///) f(4,c/,/) f(5,d,II)

► Ail Pairs ne marche plus lorsqu’une association particulière


entre tous les paramètres est importante

► Ces techniques ne marchent pas lorsqu’il s’agit de tester des


paramètres non dénombrables (entiers, réels, etc.)
Supprimer filigrane Wondershare
PDFelement
Techniques boîte noire
Technique par classes d’équivalence et tests aux limites

Ces techniques se caractérisent par :

► Détecter les classes d’équivalence pour chaque paramètre


d’entrée.

► Une classe d’équivalence constitue un ensemble de données


pour lequel le code à tester a le même comportement.

► On suppose donc que tester avec une seule valeur de cette


ensemble suffit.
Supprimer filigrane Wondershare
PDFelement
Techniques boîte noire
Technique par classes d’équivalence et tests aux limites

► Il existe deux classes possibles :

■ la classe nominale : qui correspond au comportement normal


du code,
■ et la classe hors limite : qui correspond au comportement
anormal du code (exception, message d’erreur, etc.)

► On ajoute également un autre test : le test aux limites

► Il s’agit de prendre des valeurs à la limite de la classe nominal.

□ ► «51 51/91
Supprimer filigrane Wondershare
PDFelement
Techniques boîte noire
Tester avec une table de décision

Cette technique se caractérise par :

► Il s’agit de faire correspondre une combinaison d’entrées (une


condition) avec une action que doit faire le code

► On construit une table de décision qui faut correspondre


chaque condition à une action

► Il faut trouver toute les combinaisons possibles des conditions


avec les actions à réaliser
Supprimer filigrane Wondershare
PDFelement
Techniques boîte noire
Tester avec une table de décision

Soit la spécification suivante :

fS/' ((a>0)A(6>0)) alors 41


s/ ~>((a > 0) A (6 > 0)) A (a < 0) alors 42
1 Si ^((a>0)A(b>0))A-(a<0) alors 43

► Deux conditions :
Cl = ((a > 0)A(b > 0)), C2 = (a < 0)

► Trois actions : /Al, A2. A3

□ ► «51 53/91
Supprimer filigrane Wondershare
PDFelement
Techniques boîte noire
Tester avec une table de décision

Table de décision :

Cl (a > 0) A (a < 0) A (a > 0) A (a < 0) A (a > 0) A (a < 0) A (a > 0) A (a < 0) A


(b > 0) (b > 0) (b < 0) (fe < Q) (b > 0) (b > 0) (fe < Q) (fe < Q)
C2 a < 0 a < 0 a < 0 a>-cr a > 0 a > 0 a > 0
Al impossible
A2 impossible X
A3 impossible

□ ► « [5i
54/91
Supprimer filigrane Wondershare
PDFelement
Techniques boîte noire
Tester avec une table de décision

Deux cas d’erreur peuvent être détectés dans une table de


décision :

► Une action qui n’est déclenchée par aucune condition —> Une
spécification n’a pas été codée

► deux actions contradictoires qui sont déclenchés par les mêmes


conditions —> Une spécification incohérente
Supprimer filigrane Wondershare
PDFelement
Stratégie des tests
Techniques boîte blanche (White box testing)

► Principe : « Basés sur les détails de réalisation du logiciel


(son code ou sa structure) pour générer les valeurs de tests »

► Ce sont des tests structurels

► Le logiciel est représenté par des graphes :


■ le graphe de contrôle : représente la partie « contrôle »
(instructions conditionnelles, instructions de répétitions,
instructions de branchements)
■ le graphe flots de données : représente les données (l’accès aux
données)

► Les chemins menant du point d’entrée au point de sortie


passent par des expressions conditionnelles, et donc dépendent
de la valeur des données en entrée du logiciel —> couverture
des tests
Supprimer filigrane Wondershare
PDFelement
Stratégie des tests
Techniques boîte blanche (White box testing)

Parmi les tests boîte blanche, on peut citer :

► L’analyse statique de code

► Analyse du flot de données

► La qualimétrie

► La revue de code

□ ► «51 57/91
Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
L’analyse statique de code

L’analyse du flot de données permet de détecter 3 types d’erreurs


possibles :

► Une variable utilisée sans avoir été définie au préalable

► Une variable définie sans être utilisée par la suite

► Une variable définie, puis redéfinies, sans avoir été utilisée


entre la définition et la redéfinition
Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
Analyse du flot de données

On analyse le code pour vérifier certain aspects :

► Utilisation de constructions syntaxiques non ambiguës (règles


de dénomination commune, en-têtes prédéfinis, etc.)
► Vérifier que la complexité du code (niveau d’imbrication des
boucles, nombre d’instructions et de paramètres par méthode
ou sous-programme, etc.)
► Vérifier que les instructions ne conduiront pas le programme à
se comporter de façon erronée (variables non initialisées,
dépassement de capacité, dépassement de tableau, etc.)
► Vérifier la structure du logiciel (code mort, héritage dans les
classes, etc.)
Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
La qualimétrie

La qualimétrie est un domaine d’analyse permettant d’évaluer la


qualité du logiciel grâce à des mesures appelées métriques, telles
que :

► Le nombre cyclomatique de McCabe


► Les métriques d’Halstead
► Les métriques de Chidamber et Kemerer
Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
La qualimétrie

Le nombre cyclomatique de McCabe (1976) :

► Calcule le nombre de chemins linéaires indépendants, appelés


nombre cyclomatique ou complexité cyclomatique
= Nbarcs Nbnoeuc]s + 1
NB : étant le nombre d’arcs et de noeuds du graphe de
contrôle

► Plus le nombre cyclomatique est grand, plus il y aura de


chemins d’exécution différents, et donc de difficultés à tester

► En général, le nombre de test d’un composant doit être le


même que son nombre cyclomatique

► Un bon code doit avoir un nombre cyclomatique inférieur à 15


Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
La qualimétrie

Les métriques d’Halstead (1977) :

► Evalue la taille du programme en comptant le nombre


d’opérateurs, d’opérandes et leur nombre d’apparition

► C’est plutôt une métrique de maintenance


Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
La qualimétrie

Les métriques d’Halstead (1977) :

► On peut calculer l’indice de maintenabilité d’un module :


IMmodule —

171 5, 2 * ln( Vmoyen) 0, 23 * CCmoyen 16, 2 * ln(LOCmoyen)


Vmoyen : volume moyen par module (opérateurs, opérandes)

CCmoyen ■ nombre cyclomatique moyen par module


Vmoyen ■ LOC moyen par module

► Plus IM est élevée, plus le logiciel est facile à maintenir

► Les seuils sont :


■ IM > 85 : maintenance facile
■ 65 < IM < 85 : maintenance correcte
■ IM < 65 : difficulté à maintenir
Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
La qualimétrie
Les métriques de Chidamber et Kemerer (1994) :

► Six métriques orientées vers la conception 00


■ WMC (Weighted Method per Class) : mesure la complexité
d’une classe
■ DIT (Depth of Inheritence Tree) : compléxité de l’architecture
00 (élevé = trop complexe, bas = mauvaise utilisation de
l’héritage)
■ NOC (Number Of Children) : représente la généricité d’une
classe (élevé = effort de test important, bas = mauvaise
utilisation de l’héritage)
■ CBO (Coupling Between Object Classes) : couplage entre une
classe et les autres classes
■ RFC (Response For a Class) : nombre de méthodes appelées
dans la classe à la réception d’un message (élevé = trop
complexe)
■ LCOM (Lack of Cohésion in Methods) : cohésion d’une classe
(élevé = peu de cohésion)
Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
La revue de code

« Technique d’évaluation en détail, d’un document, d’un module de


code source, d’une correction, etc. par un groupe de personnes pour
détecter les défauts, les violations des standards et des conventions,
ainsi que tout autre problème » 3

Une revue a pour objectifs :


► Trouver des défauts
► Vérifier la conformité par rapport aux spécifications et aux
standards
► Vérifier la complétude des fonctions
► Viser l’acceptation du produit

3. ANSI/IEEE Std. 1028-1997


Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
La revue de code

Il y a 3 types de revue :

► buddy check (desk check) : revue légère du produit qui est


conduite par l’auteur en association avec quelques personnes
(les copains)

► walkthrough : Plus formelle, elle est conduite par l’auteur qui


présente son travail (code, documentation, exigences, etc.) lors
d’une réunion à un groupe de personnes qui apportent des
remarques
► inspection : Très formelle, parce qu’ont doit établir un agenda
d’inspection, la préparer avec les acteurs et produire un rapport
Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
La couverture des tests

► Dans le cas du test structurel, on considère l’ensemble des


chemins reliant le point d’entrée au point de sortie du graphe
de contrôle et du flot de données.

► On sélectionne les données d’entrée déclenchant l’exécution de


certains de ces chemins.

► Le nombre de chemin est parfois très élevé (cas des boucles),


on défini alors des critères de couverture plus limité.
Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
La couverture des tests

Les critère de couvertures du graphe de contrôle sont :

► Couverture de toutes les instructions

► Couverture de tous les enchaînements

► Couverture de tous les i-chemins

► Couverture de tous les chemins

« □ ► < SP ► ◄ - ► 68/91
Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
La couverture des tests

Les critère de couvertures du flot de données sont :

► Couverture de toutes les assignations


chaque assignation d’une variable doit être exécutée au moins
une fois par un chemin atteignant ensuite une utilisation de la
variable.

► Couverture de toutes les utilisations


chaque assignation d’une variable doit être exécutée au moins
une fois pour toutes les utilisations qu’elle atteint; de plus,
tous les arcs issus de ces utilisations doivent être couverts.
Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
La couverture des tests

► Couverture de toutes les P-utilisations


C’est une version plus faible du critère précédent, sauf qu’on se
limite aux utilisation dans un Prédicat (une condition).

► Couverture de toutes les D-U-chemins


C’est une version plus forte du critère toutes les utilisations, où
de plus, dans chaque boucle, chaque sous chemins entre une
assignation et une utilisation qu’elle atteint doit être exécuté,
en se limitant aux sous-chemins faisant 0 ou 1 itération.
Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
La couverture des tests

Exemple :
► Couverture de toutes les
assignations
■ variable a: 1 — 2 — 4 — 6
■ variable b : 1 — 2 — 4 — 6
■ variable c: 1 — 2 — 3 — 4 — 6
■ on teste donc2 chemins :
l-2-4-6et
1-2-3-4-6

□ ► «51 71/91
Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
La couverture des tests

Exemple :
► Couverture de toutes les
utilisations
■ variable a : 1 — 2 — 4 — 6
1-2-3-4-6
■ variable b : 1 — 2 — 4 — 6
■ variable c : 1 — 2 — 3 — 4 — 6
■ on teste donc 2 chemins :
l-2-4-6et
1-2-3-4-6

□ ► «51 72/91
Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
La couverture des tests

Exemple :
► Couverture de toutes les
P-utilisations
■ variable a : 1 — 2 — 4 — 6
1-2-3-4-6
■ variable b : 1 — 2 — 4 — 6
■ variable c : —
■ on teste donc 2 chemins :
l-2-4-6et
1-2-3-4-6

□ ► «51 73/91
Supprimer filigrane Wondershare
PDFelement
Techniques boîte blanche
La couverture des tests

► Couverture de toutes les


Exemple :
D-U-chemins
■ variable a : 1 — 2 — 4 — 6
1-2-3-4-6
■ variable b : 1 — 2 — 4 — 6
■ variable c : 1 — 2 — 3 — 4 — 6
1-2-3-4-
5-4-6
■ on teste donc 3 chemins :
1-2-4-6, 1-2-3-4-6
etl-2-3-4-5-4-6

□ ► «51 74/91
Supprimer filigrane Wondershare
PDFelement
Tests d’intégration
Intégrât

► Un intégrât logiciel contient un ensemble de fonctions


associées

► Sa complexité est variable, réalisé par 2 à 4 programmeurs


pendant 6 à 9 mois

► Sa taille peut être de 15 000 à 20 000 LS (ou 150 à 300 Points


de Fonctions)
Supprimer filigrane Wondershare
PDFelement
Tests d'intégration
Intégrât

Un intégrât doit respecter les modalités de qualité suivantes :

► FURPSE (Functionality, Usability, Reliability, Performance


ServiceabiIity, Evolutivity)

► Respect du contrat qui lie l’intégrât à son environnement

► Sa modularité

► CQFD (Cost, Quality, Fonctionnalité Deadline)


Supprimer filigrane Wondershare
PDFelement
Tests d'intégration
Processus d’intégration

C’est un processus progressif :

► Regrouper les composants de base du système : intégrât de


rang 0

► Construire des intégrats de rang 1 à partir des intégrats du


rang 0

► Construire des intégrats de rang 2

► ...

► Construire l’intégrât final : le système.


Supprimer filigrane Wondershare
PDFelement
Tests d'intégration
Stratégies d’intégration

Deux stratégies :

► Stratégie silo (verticale)

► Stratégie continue

□ ► < [5i O c\ o
78/91
Supprimer filigrane Wondershare
PDFelement
Tests d’intégration
Stratégies d’intégration

► Stratégie silo (verticale) :

1. Tester chaque intégrât dans un environnement simulé (stubs)

2. Tester les intégrats par combinaison (deux-à-deux,


trois-à-trois, etc.)

3. Valider le système

Stratégie lente
Supprimer filigrane Wondershare
PDFelement
Tests d'intégration
Stratégies d’intégration

► Stratégie continue :

1. Valider les interfaces (architecture) entre intégrats (le contenu


des intégrats est simulé)

2. Intégrer progressivement les contenus

■ Stratégie rapide, mais demande une grande organisation et une


grande expérience du chef de projet
Supprimer filigrane Wondershare
PDFelement
Tests d’intégration
Règles d’application des tests d’intégration

Il y a certaines règles à respecter pour de meilleurs tests


d’intégration :

1. La productivité des tests dépend de la qualité et de la


structure de la documentation

2. Le nombre de tests dépend du nombre de composants et de la


complexité des relations entre les composants

3. Garantir la non-régression par la re-exécution de tous les tests


précédemment acquis
Supprimer filigrane Wondershare
PDFelement
Documentation des tests

Un plan de tests contient les informations suivantes :

► La référence du document

► Les références aux documents cités dans le plan de test


(documents de spécifications, normes qualité, ...)

► Une introduction décrivant l’objet du plan de tests

► Les éléments devant être testés (composants, modules, classes,


interfaces, ...)
Supprimer filigrane Wondershare
PDFelement
Documentation des tests

► Les fonctionnalités devant être testées du point de vue de


l’utilisateur (contrairement au point précédent)

► Les fonctionnalités ne devant pas être testées du point de vue


utilisateur

► Les critères de sorties (quand arrêter les tests)

► L’environnement matériel et logiciel nécessaire au test

► L’ordonnancement des différentes étapes de tests

► ...

□ ► «51 83/91
Supprimer filigrane Wondershare
PDFelement
Critères d’arrêt des tests

Quand doit-on arrêter les tests?


► => Trop tôt : erreurs non détectées
► => Trop tard : parte de temps
Critères possibles :
► => Tous les tests prévus et planifiés ont été correctement
exécutés
► => Atteindre un niveau donné par rapport au nombre de
défauts découverts par unités de temps
► Autres critères possibles :
■ Fin des délais de développement, fin du budget, explosion du
nombre de défauts trouvés (abondant), acceptation dans l’état
du logiciel par le client

□ ► «51 84/91
Supprimer filigrane Wondershare
PDFelement
Estimation de l'effort de test

Deux étapes :

1. Estimer le coût global du logiciel (avec une méthode


d’estimation telle que COCOMO)

2. Appliquer un facteur pour l’estimation de l’effort de test (entre


20% et 40% de l’effort global, selon la taille du logiciel)

3. Corriger cette estimation selon la complexité attendue des tests


Supprimer filigrane Wondershare
PDFelement
Outils de test

Il y a quatre type d’outils :

► Outils de tests statiques

► Outils pour les tests dynamiques

► Outils de tests fonctionnels des applications web

► Outils d’aide à la gestion des tests


Supprimer filigrane Wondershare
PDFelement
Outils de test
Outils de tests statiques

Il s’agit principalement d’outils de revue de code, à la recherche


d’erreurs (pattern d’erreur) ou pour vérifier l’adéquation du code
par rapport à un standard (nommage, conception du code, etc.) En

Java, on peut citer deux outils libres :


► FindBugs™ : http://findbugs.sourceforge.net/
► Checkstyle : https://checkstyle.sourceforge.io/
Supprimer filigrane Wondershare
PDFelement
Outils de test
Outils pour les tests dynamiques

► Outils de tests unitaires : frameworks xUnit : jUnit (pour le


langage Java), cllnit (pour le C), phpUnit (pour le PHP), ...

► Outils de tests d’intégration et d’intégration continue :


Continuum (https://Continuum.apache.org) ou Jenkins
(https://Jenkins.io)

► Outils de tests de charge, de tests de stress ou de tests


de performance : Apache JMeter™
(https://jmeter.apache.org)
Supprimer filigrane Wondershare
PDFelement
Outils de test
Outils de tests fonctionnels des applications web

Réaliser une série de transactions sur le site web, la série de


transactions élémentaires étant elle-même une transaction. Un
échec sur une de ces transactions peut entraîner un échec de
l’ensemble des transactions.

► Sélénium WebDriver : https://www.selenium.dev

□ ► «51 89/91
Supprimer filigrane Wondershare
PDFelement
Outils de test
Outils d’aide à la gestion des tests

Gestion des exigence, des plan de tests ou des anomalies.

► Redmine : https://www.redmine.org
► Bugzilla : www.bugzilla.org

□ ► «51 90/91
Supprimer filigrane Wondershare
PDFelement

Bon courage !

□ ► «51 91/91

Vous aimerez peut-être aussi