Cours T-LSI ADBD - la structure

• Les fondamentaux de Tests

• Les tests pendant le Cycle de Vie Logiciel (SLC)

• Les tests statiques

• Les techniques de tests

• La gestion des tests

• Les outils de support aux Tests

Les fondamentaux des tests

1.1 Qu'est-ce qu’un test?

1.2 Pourquoi les tests sont-ils nécessaires ?

1.3 Les sept principes généraux des tests

1.4 Processus de test

1.5 La psychologie des tests

1.6 Quiz

15
 LO-1.1.1 (K1) Identifier les objectifs habituels des tests

Pour un projet donné, les objectifs du test peuvent inclure :

1. évaluer les produits d’activités tels que les exigences, les User Stories, la conception et le code

2. vérifier si toutes les exigences spécifiées ont été satisfaites

3. valider si l'objet de test est complet et fonctionne comme attendu par les utilisateurs et
autres parties prenantes
4. Construire la confiance dans le niveau de qualité de l'objet de test
5. Prévenir des défauts
6. Trouver des défaillances et des défauts

17
 LO-1.1.1 (K1) Identifier les objectifs habituels des tests (Suite…)

7. Fournir suffisamment d'information aux parties prenantes pour leur permettre de prendre des
décisions éclairées, en particulier en ce qui concerne le niveau de qualité de l'objet de test

8. Réduire le niveau de risque d'une qualité logicielle inadéquate (p. ex. des défaillances non
détectées auparavant se produisant en opération)

9. Se conformer aux exigences ou aux normes contractuelles, légales ou réglementaires, et/ou

pour vérifier la conformité de l’objet de test à ces exigences ou normes.

18
 Rôle des tests (K2)
Le test n’a pas pour objectif de
– Diagnostiquer les fautes
– Corriger les défauts
– Prouver qu’un logiciel est correcte

Le test a pour objectif de

– Mettre en évidence les défauts d’un logiciel
– Prouver la conformité fonctionnelle
– Donner une indication de la qualité du logicielle => un niveau de confiance
– Prévenir des défauts

25
 Prévenir les défauts (K2)

Revue des documents

Conception des tests tôt
dans le cycle de vie
Identification et résolution des
Réflexion sur les cas de tests problèmes avant le codage
Vérification des bases de test existantes
prévenir les défauts

Tests rigoureux des systèmes et

Analyse du code
de la documentation
Réduction des risques  Identification et résolution des
Augmentation de la qualité défauts dans le code
Respect des exigences légales  prévenir les défaillances
Atteinte des normes spécifiques
 Tests et qualité (K2) ISO 25010
• Les tests logiciels sont un moyen d’évaluer la qualité du logiciel et de réduire le risque de
défaillance de logiciel lors de son fonctionnement

Aptitude
Portabilité
fonctionnelle Transfert
Répond
aux besoins vers un autre
Securité
fonctionnels environnement
Accèsà des
informations autorisées
Fiabilité Maintenabilité
Maturité Effort pour
Tolérance les évolutions Compatibilité
aux pannes
Interopérabilité
Facilité Efficacité du
d’utilisation rendement
User Performance,
Experience charge, stress
 Combien de test est suffisant? (K2)
Comment juger la quantité de tests suffisante?
– Ce n’est jamais suffisant x
– Quand on a fait ce qu’on a planifié x
– Quand le client est content x
– Quand on a prouvé que le système fonctionne correctement x
– Quand on est confiant que le système fonctionne correctement x
– Ca dépend du risque sur le système 



Prendre en compte l’évaluation des risques
comment faire un minimum de tests pour un minimum de risques

30
Test Vs Debogage

Testing Debugging

Tester Developer
 Test est l'exploration du système
afin de trouver des défauts
Observe failure Investigate and  Debogage est un processus de
isolate defect détermination des causes des
erreurs (bugs) dans un code et de
les corriger
Fix defect

Re-test to
confirm failure
no longer Check fix works
occurs

31
Verification Vs Validation

• Est-ce que nous avons bien

Verification
construit le produit?
• Est-ce que nous avons construit le
Validation
bon produit?

32
1.2 Pourquoi les Tests sont-ils nécessaires?
• Les systèmes logiciels deviennent une part de notre existence, des
applications commerciales aux produits de grande consommation

• Des logiciels ne fonctionnant pas correctement peuvent générer

de nombreux problèmes: pertes financières, temps, réputations,
allant même aux blessures ou mort

• Il est important de détecter et de corriger ces défaillances avant

qu’elles soient livrés aux clients

34
1.2.2 Assurance qualité et test
• La gestion de la qualité comprend toutes les activités qui dirigent et contrôlent
une organisation en matière de qualité

• L’assurance qualité est principalement axée sur le respect des processus

adéquats, afin de donner l'assurance que les niveaux de qualité appropriés seront
atteints (processus, produits d’activité de bonne qualité, causes des erreurs,
application des résultats de rétrospective)

• Le contrôle de la qualité comprend diverses activités, y compris des activités de

test, qui contribuent à l'atteinte de niveaux de qualité adéquats.

37
1.2.3 Erreurs, défauts et défaillances
• Les erreurs peuvent survenir suite à de nombreuses raisons, telles
que :
- Les contraintes de temps, la faillibilité humaine, l’inexpérience ou le manque de
compétence des participants au projet
- Une mauvaise communication entre les participants au projet, y compris au sujet des
exigences et de la conception
- La complexité du code, de la conception, de l'architecture, du problème sous-jacent
à résoudre, et/ou des technologies utilisées
- Les malentendus sur les interfaces intra-système et inter-système, en particulier
lorsque de telles interfaces intra-système et inter-système sont très nombreuses.
- Des technologies nouvelles, peu connues
- la pollution peuvent causer des défauts dans le firmware

38
 1.2.3 Erreurs, défauts et défaillances

• Les défaillances peuvent être causées par :

- Une erreur humaine causée par une échéance serrée, complexité du code,
infrastructure ou multiple interaction entre les systèmes

- Une condition d’environnement (radiation, magnétisme, pollution, etc.)

39
1.2.3 Erreurs, défauts et défaillances
• Erreur(= méprise) => Défaut(=Bug) => Défaillance qui peut être aussi
causée par les conditions de l’environnement
• En effectuant des tests, il est possible de mesurer la qualité des logiciels en terme de
défauts trouvés
• En comprenant les causes principales des défauts trouvés dans d’autres projets, les
processus peuvent être améliorés, ce qui ensuite peut prévenir l’apparition de ces
défauts => améliorer la qualité des systèmes futurs. C’est un aspect de l’assurance
qualité
• Les tests devraient être intégrés comme une activité de l’assurance qualité
(e.g., en utilisant des standards de développement, de la formation et de
l’analyse des défauts)
• C’est l’aspect d’aide à la décision => en prenant en compte le niveau de
risque
40
1.2.4 Défauts, causes racines et effets
• Les causes racines des défauts (Root Cause Analysis)
• Les causes racines des défauts sont les premières actions ou
conditions qui ont contribué à la création des défauts.
• Les défauts peuvent être analysés pour identifier leurs causes racines,
afin de réduire l'apparition de défauts similaires à l'avenir.
• L'analyse des causes racines peut conduire à des améliorations de
processus qui préviennent l'introduction d'un nombre important de
défauts futurs

42
Principes généraux des tests (K2)

1 Les tests montrent la présence de défauts

2 Les tests exhaustifs sont impossibles

3 Tester tôt

4 Regroupement des défauts

5 Paradoxe du pesticide

6 Les tests dépendent du contexte

7 L’illusion de l’absence des erreurs

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

Les tests réduisent la probabilité que les défauts restent cachés dans le logiciel

47
 Principe 2 : Les tests exhaustifs sont impossibles
 Test exhaustif?
 Quand tous les tests planifiés sont exécutés?
 Quand les testeurs sont extenués?
 Quand toutes les combinaisons depré conditions et inputs sont terminées?

Why notjust"testeverything"?
Tout tester (toutes les combinaisons d’entrées et de pré-

Avr.4menus conditions) n’est pas faisable sauf pour des cas triviaux

3 options/ menu

systemhas20 Average:10fields/ screen2types

screens input / field
(dateasJan3 or3/1)
(numberasintegerordecimal) Around
100 possiblevalues
Total for 'exhaustive' testing:
Au lieu de procéder à des tests exhaustifs, l'analyse des
20 x 4 x 3 x 10 x 2 x 100 = 480,000 tests
If 1 second per test, 8000 mins, 133 hrs, 5,5 days risques et les priorités devraient être utilisées pour
(not counting finger trouble, faults or retest) concentrer les efforts de test..
48
10 secs ~= 8 wks, 1 min ~= 1 yrs, 10 min ~= 10 yrs
Principe 2 : Les tests exhaustifs sont impossibles (Suite…)

Donnez la priorité aux tests afin

que, chaque fois que vous
arrêtez les tests, vous ayez
effectué les meilleurs tests dans
le temps disponible.

50
 Principe 3 : Tester tôt

• Pour détecter tôt les défauts, à la fois des activités de tests

statiques et des activités de tests dynamiques doivent être
lancées le plus tôt possible dans le cycle de vie du logiciel (SLC)
• Le fait de tester tôt est parfois appelé « shift left »
• Tester tôt dans le SLC permet de réduire ou d’éliminer des
changements coûteux

Plus une erreur est découverte tard dans le cycle de vie plus la correction
est coûteuse.

51
 Principe 4 : Regroupement des défauts

 Concentration des efforts de test sur les modules contenant la majorité

des défauts
 Modules complexes: algorithmique, cyclomatique…
 Métiers complexes: pas ou peu de spécification
 Nouveaux Modules: encore non mature
 Nouvelles technologies: encore non maitrisée

• Approximately80%ofthe problems arecausedby20%of the modules (Pareto principle)

52
Principe 5 : Paradoxe du pesticide

Si les mêmes tests sont répétés de nombreuses fois 

le même ensemble de cas de tests ne trouvera plus de nouveaux
défauts.

 Revoir et réviser régulièrement les cas de tests

 Ecrire de nouveaux tests, différents des anciens

 Couvrir d’autres chemins dans le logiciel ou le système

53
 Principe 6 : Les tests dépendent du contexte

Les tests sont effectués différemment dans des contextes différents.

Un système archaïque sera testé différemment d’un système plus intelligent.

e.g.Les logiciels critiques de sûreté seront testés différemment d’un site
de commerce électronique

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

Trouver et corriger des défauts n’aide pas si le système conçu est

inutilisable et ne comble pas les besoins et les attentes des utilisateurs.

• Par exemple, tester en profondeur toutes les exigences spécifiées et corriger tous les
défauts trouvés pourrait toujours produire un système qui est difficile à utiliser, qui ne
répond pas aux besoins et aux attentes des utilisateurs ou qui est moins performants
comparé à d'autres systèmes concurrents

55
1.4.1 Le processus de test dans le contexte
• Les facteurs contextuels qui influencent le processus de test d'une
organisation comprennent
− Le modèle de SLC et les méthodologies de projet utilisées
− Les niveaux de test et les types de test prévus
− Les risques liés aux produits et aux projets
− Le domaine d’activités
• Les contraintes opérationnelles incluent
− Les budgets et ressources
− Les délais
− La complexité
− Les exigences contractuelles et réglementaires, etc.
58
1.4.2 Activités et tâches de test

59
1.4.2 Activités et tâches de test
• Chaque groupe d’activités est composé d’activités constitutives
• Chaque activité au sein de chaque groupe d’activités peut à son tour consister en de
multiples tâches individuelles, qui peuvent varier d'un projet ou d'une version à une autre
• De plus, même si plusieurs de ces groupes d’activités peuvent sembler logiquement
séquentiels, ils sont souvent mis en œuvre de façon itérative
• Le développement Agile implique de petites itérations de conception de logiciels, de
construction et de test qui se produisent en continu, soutenues par une planification régulière.
Ainsi, les activités de test se déroulent également de façon itérative et continue dans le cadre
de cette approche de développement.
• Même en mode séquentiel, la séquence logique par étapes des activités induira le
chevauchement, la combinaison, de sorte qu’une adaptation de ces activités principales dans
le contexte du système et du projet est habituellement nécessaire

60
1.4.2 Activités et tâches de test

Planification des tests

• La planification des tests implique de définir les objectifs du test et
l’approche retenue pour atteindre les objectifs du test dans le respect
des contraintes imposées par le contexte
Exemple: spécifier les techniques et tâches de test appropriées, et
produire un calendrier de test pour respecter une date limite
• Les plans de test peuvent être revus en fonction des retours sur les
activités de pilotage et de contrôle

61
1.4.2 Activités et tâches de test
Pilotage et contrôle des tests
• Le pilotage des tests implique la comparaison régulière de l’avancement réel par
rapport au plan de test à l'aide des métriques de pilotage définies dans le plan de
test
• Le pilotage et le contrôle des tests se basent sur l'évaluation des critères de
sortie, que l'on appelle « definition of done » dans certains cycles de vie
• Par exemple, l’évaluation des critères de sortie pour l'exécution des tests dans le
cadre d’un niveau de test (La vérification des résultats et logs de test par rapport
aux critères de couverture spécifiés)

62
1.4.2 Activités et tâches de test
Analyse de test (quoi tester?)
• Pendant l’analyse de test, les bases de test sont analysées pour
identifier les caractéristiques testables et définir les conditions de test
associées (quoi tester, critère de couverture mesurable).
− Activité 1: Analyser les bases de test appropriées au niveau de test considéré
(UML, l’implémentation de la base des composants ou du système, rapport
d’analyse de risque fonctionnel , non fonctionnel et structurel)
− Activité 2 : Evaluer les bases de test et des éléments de test pour identifier
des défauts de différents types (Ambiguïtés, Incohérences, Inexactitudes,
Contradictions, etc)

63
1.4.2 Activités et tâches de test
• Activité 3: Identifier les caractéristiques (éléments) et les ensembles de
caractéristiques à tester
• Activité 4: Définir et prioriser les conditions de test pour chaque
caractéristique en fonction de l’analyse des bases de test et en tenant
compte des caractéristiques fonctionnelles, non-fonctionnelles et
structurelles, des autres facteurs métiers et techniques, et des niveaux de
risque
• Activité 5: Capturer la traçabilité bidirectionnelle entre chaque élément
des bases de test et les conditions de test associées
• Les conditions de test qui doivent être utilisées comme objectifs de test
dans des chartes de test (durant les sessions des tests)

64
1.4.2 Activités et tâches de test

• Remarque: activités d’analyse de test ne se contentent pas de vérifier si

les exigences sont cohérentes, correctement exprimées, et complètes,
mais aussi de valider si les exigences capturent correctement les
besoins des clients, utilisateurs et des autres parties prenantes
Exemple: les techniques telles que le BDD (Behavior-Driven
Developement) et ATDD (Acceptance Test-Driven Development), qui
impliquent la définition des conditions de test et de cas de test à partir
des User Story et des critères d’acceptation avant le codage, permettent
aussi de vérifier, valider et détecter des défauts dans les User Stories et
les critères d’acceptation
65
1.4.2 Activités et tâches de test
Conception des tests (Comment tester?)
• Concevoir et prioriser les cas de test et les ensembles de cas de test
− Identifier les données de test nécessaires pour les conditions de test et les cas
de test
− Concevoir l'environnement de test et identifier l'infrastructure et les outils
nécessaires
− Etablir la traçabilité bidirectionnelle entre les bases de test, les conditions de
test, les cas de test et les procédures de test
• La déclinaison des conditions de test lors de la conception implique
souvent l’utilisation de techniques de test

66
1.4.2 Activités et tâches de test
Implémentation des tests (Est-ce que tout est en place pour exécuter les
tests?)
• Développer et prioriser les procédures de test, et, éventuellement, créer
des scripts de test automatisés
− Créer des suites de tests à partir des procédures de test et (le cas échéant) des
scripts de tests automatisés
− Positionner les suites de tests dans un calendrier d'exécution des tests de manière à
obtenir une exécution efficace des tests
• Construire l’environnement de test (y compris, potentiellement, les harnais
de test, la virtualisation des services, les simulateurs et d’autres éléments
d’infrastructure) et vérifier que tout le nécessaire a été correctement mis
en place

67
1.4.2 Activités et tâches de test
− Préparer les données de test et s’assurer qu’elles sont correctement chargées dans l’environnement de test
− Vérifier et mettre à jour la traçabilité bidirectionnelle entre les bases de test, les conditions de test, les cas de
test, les procédures de test et les suites de tests
Les tâches de conception et d’implémentation des tests sont souvent combinées.
• Dans le cas des tests exploratoires et d’autres types de tests basés sur l’expérience, la conception
et l’implémentation des tests peuvent être réalisées et éventuellement être documentées lors de
l’exécution des tests.
• Les tests exploratoires peuvent être basés sur des chartes de test (produites dans le cadre de
l’analyse de test)
• Les tests exploratoires sont exécutés immédiatement, en même temps que leur conception et
leur implémentation

68
1.4.2 Activités et tâches de test
Exécution des tests
• Enregistrer les IDs et les versions des éléments de test ou de l’objet de
test, des outils de test et des testware
− Exécuter les tests manuellement ou à l’aide d'outils d'exécution de test
− Comparer les résultats obtenus avec les résultats attendus
− Analyser les anomalies afin d’établir leurs causes probables
• Vérifier et mettre à jour la traçabilité bidirectionnelle entre les bases
de test, les conditions de test, les cas de test, les procédures de test
et les résultats des tests
• Test de confirmation et de régression
69
1.4.2 Activités et tâches de test
Clôture des tests
• Vérifier si tous les rapports de défauts sont clôturés, et saisir des
demandes de modification ou des items du backlog du produit pour
tous les défauts non résolus à la fin de l’exécution des tests
• Créer un rapport de synthèse de test à communiquer aux parties
prenantes
− Finaliser et archiver l’environnement de test, les données de test,
l'infrastructure de test et autres testware pour une réutilisation ultérieure
− Remettre le testware aux équipes de maintenance, aux autres équipes de
projet, et/ou à d’autres parties prenantes qui pourraient bénéficier de son
utilisation
− Analyser les leçons apprises des activités de test terminées
70
1.4.3 Les produits d’activités du test
• Produits d’activités de la planification des tests (Le plan de test comprend
des informations sur les bases de test, critère E/S, risque)
• Produits d’activités du pilotage et contrôle des tests (compris les rapports
d'avancement des tests, synthèse des tests, un résumé des résultats de
l'exécution)
• Produits d’activités de l’analyse de test (comprennent les conditions de
test définies et priorisées, dont chacune est idéalement traçable de façon
bidirectionnelle avec le ou les élément(s) spécifiques des bases de test
qu'elle couvre) Pour les tests exploratoires, l'analyse de test peut impliquer
la création de chartes de test.
• Produits d’activités de la conception des tests (La conception de cas de
tests de haut niveau, affiner ou finaliser les conditions , les données,
l’environnement)

71
1.4.3 Les produits d’activités du test
• Produits d’activités de l’implémentation des tests
− Les procédures de test et l’ordonnancement de ces procédures de test
− Les suites de test
− Un calendrier d'exécution des tests.
• l'atteinte des critères de couverture établis dans le plan de test peut être
démontrée par une traçabilité bidirectionnelle entre les procédures de test
et des éléments spécifiques des bases de test, au travers des cas de test et
des conditions de test
• la création et à la vérification de données de test et de l'environnement de
test. Les conditions de test définies dans l'analyse de test peuvent être
affinées (finalisées) lors de l’implémentation des tests
• Les résultats attendus concrets qui sont associés à des données concrètes
de test sont identifiés à l'aide d'un oracle de test
72
1.4.3 Les produits d’activités du test
• Produits d’activités de l’exécution des tests
• La documentation du statut de chaque cas de test ou des procédures de
test (exemple: prêt à être exécuté, réussite, échec, blocage, délibérée, etc.)
• Les rapports de défauts
• La documentation précisant quel(s) élément(s) de test, objet(s) de test,
outils de test et testware ont été impliqués dans le test.
• Idéalement, une fois l'exécution des tests terminée, le statut de chaque
élément des bases de test peut être déterminé et indiqué par traçabilité
bidirectionnelle avec la ou les procédures de test associée(s).

73
1.4.3 Les produits d’activités du test
• Produits d’activités de la clôture des tests
• les rapports de synthèse de test
• les mesures à prendre pour améliorer les projets ou les itérations
ultérieurs

74
1.4.4 Traçabilité entre les bases de test
et les produits d’activités du test
• Importance d'établir et de maintenir la traçabilité tout au long
du processus de test entre chaque élément des bases de test et
les divers produits d'activités du test associés à cet élément.
• Une bonne traçabilité facilite:
 L’analyse de l'impact des changements
 L’audit des tests
 La satisfaction des critères de gouvernance IT
 L’amélioration du caractère compréhensible des rapports
d'avancement des tests et des rapports de synthèse de test
 La restitution des aspects techniques des tests aux parties
prenantes en des termes qu'elles peuvent comprendre
 L’apport d’information pour évaluer la qualité du produit,
l’aptitude du processus et l'avancement du projet par
rapport aux objectifs métier

75
 1.5 La Psychologie des Tests
• Un certain degré d’indépendance (évitant le parti-pris de l’auteur) est
souvent plus efficace pour détecter des défauts et des défaillances.
• Plusieurs niveaux d’indépendance peuvent être définis, comme les niveaux
suivants présentés du plus faible au plus élevé :
• Tests conçus par la (les) personne(s) qui a (ont) écrit le logiciel à tester (niveau
faible d’indépendance).
• Tests conçus par une (des) autre(s) personne(s) (exemple: équipe de
développement).
• Tests conçus par une (des) personne(s) d’un groupe différent au sein de la même
organisation (exemple: équipe de test indépendante) ou par des spécialistes de test
(exemple: spécialistes en tests de performance ou utilisabilité)

77
1.5 La Psychologie des Tests
• Tests conçus par une (des) personne(s) d’une organisation ou société
différente (exemple: sous-traitance ou certification par un organisme externe)
• Il existe plusieurs manières d’améliorer la communication et les
relations entre les testeurs et leurs interlocuteurs :
• Commencer par une collaboration plutôt que par des conflits – rappeler à
chacun l’objectif commun de systèmes de meilleure qualité
• Communiquer les découvertes sur le produit de façon neutre et factuelle sans
critiquer la personne responsable, par exemple, écrire des rapports
d’incidents (ou des résultats de revues) objectifs et factuels.

78
Réponse (b)
Réponse (c)
Réponse (c)
Réponse (b)
Réponse (c)
Réponse (a)
Réponse (d)
Réponse (c)
Réponse (b)
Réponse (b)
Differentiate the following test work products ++

 Test suite : Suite de test : Ensemble de plusieurs cas de tests pour un composant ou
système à tester, dont les post-conditions d’un test sont souvent utilisées comme pré-
conditions du test suivant
 Test case : Cas de test : un ensemble de valeurs d’entrée, de préconditions d’exécution,
de résultats attendus et de postconditions d’exécution, développées pour un objectif ou
une condition de tests particulier, tel qu’exécuter un chemin particulier d’un programme
ou vérifier le respect d’une exigence spécifique
 Test script : Script de test : Généralement utilisé pour se référer à une spécification de
procédure de test, surtout une procédure automatisée
 Test charter : Charte de test : Une expression d’objectifs de test et éventuellement
d’idées de test au sujet de la façon de tester. Les agréments de test sont utilisés en test
exploratoire.
Differentiate the following test work products ++
 Test strategy : Stratégie de test : Document de haut niveau définissant, pour un
programme, les niveaux de tests à exécuter et les tests dans chacun de ces niveaux
 Test procedure : Spécification de procédure de test : Document spécifiant la séquence
d’actions pour l’exécution d’un test. Aussi connu sous le terme de script de test ou script
de test manuel.
 Test basis : Base de tests : tous les documents à partir desquels les exigences d’un
composant ou système peuvent être déduites. La documentation sur laquelle les cas de
tests sont basés
 Test specification : Spécification de test : Document qui consiste en une spécification de
conception du test, des spécifications de cas de test et/ou des spécifications de
procédures de test.
 Test data : Données de tests : Donnée existante (ex. : dans une base de données) avant
qu’un test ne soit exécuté et qui affecte ou est affectée par le composant ou système en
test.
 Testware : les scripts, les entrées, les résultats attendus, les procédures d’installation et
de nettoyage, les fichiers, les bases de données, les environnements
Differentiate the following test work products ++
 Test policy : Politique de test : Document de haut niveau décrivant les principes,
approches et objectifs majeurs de l’organisation concernant l’activité de test.
 Test plan : Plan de test : Document décrivant l’étendue, l’approche, les ressources et le
planning des activités de test prévues. Il identifie entre autres les éléments et
caractéristiques à tester/ l’affectation des tâches/ le degré d’indépendance des testeurs/
l’environnement de test/ les techniques de conception des tests / les techniques de
mesure des tests à utiliser ainsi que tout risque nécessitant la planification de
contingence.
 Test process : Processus de test : Processus de test fondamental comprenant la
planification, la spécification, l’exécution, l’enregistrement et la vérification de
l’achèvement.
 Test Harness : Harnais de test : Environnement comprenant les bouchons et les pilotes
nécessaires pour exécuter un test.
Tester pendant le cycle de vie logiciel (K2)

2.1 Les modèles de développement logiciel

2.2 Niveaux de tests
2.3 Types de tests
2.4 Tests de maintenance
2.5 Quizz

2
Modèle en cascade

Incompréhension
Spécification Spécification
des besoins

Conception
Fausse
conception
Développement

Test Développement

Produit ne
Maintenance satisfait pas
le besoin
Modèle en cascade
50% des défaillance sont introduites lors de la phase de
collecte des besoins client et de l’écriture des
spécifications
Modèle en V
Tests Tests

Expression des besoins Validation

Tests

Specification des exigences Vérification

Tests

Conception du système Intégration

Tests

Conception des composants Tests unitaires

Tests

Design Implementation Run

Tests Tests
 Modèle itératif (Agile)

• Développement de logiciels agiles

Un groupe de méthodologies de développement logiciel basées sur un
développement incrémentiel itératif, où les exigences et les solutions
évoluent grâce à la collaboration entre des équipes interfonctionnelles
auto-organisées.

• Tests agiles
Pratique de test pour un projet utilisant des méthodologies de
développement logiciel Agile, incorporant des techniques et des
méthodes, telles que la programmation extrême (XP), traitant le
développement comme le client des tests et mettant l'accent sur le
paradigme de conception axé sur les tests.
11
Conception tôt des tests

• Conception des tests trouve des défauts

• Défauts détectés tôt sont moins chers à réparer
• Défauts les plus importants trouvés en premier
• Prévention défauts avant l’intégration
• Arrête la multiplication des défauts
• Aucun effort supplémentaire, reprogrammer la conception des tests

12
2.2 Niveaux de Tests

13
2.2 Niveaux de Tests
• Tests de composants / Unitaires :
Objectif: Empêcher les défauts de passer à des niveaux de test plus élevés
Bases de tests: Exigences des composants, conception détaillée (par unité),
Code, Modèle de données
Objets habituels de test: Composants, programmes, conversions de données /
utilitaires ou programmes de migration, modules de bases de données
• Peut nécessiter de mettre en place des objets fictifs, une virtualisation des
services, des harnais de test, des bouchons (stubs) et des pilotes (drivers).
• Les tests de composants peuvent inclure des tests de fonctionnalités et des
tests de caractéristiques non-fonctionnelles ainsi que des tests structurels.

14
 • Les cas de test sont dérivés des livrables tels que les spécifications des
composants (spécifications détaillées), la conception du logiciel ou le modèle
de données.
Approches spécifiques et responsabilités
• Ils sont faits dans un environnement de développement.
• Préparer et automatiser les cas de tests unitaires avant le développement
s’appelle tester d’abord. l'approche dite « test-first », Test-Driven
Development (TDD)
Défauts et défaillances courants (si incident => RCA)
• Fonctionnalité incorrecte (par exemple, non conforme aux
spécifications de conception)· Problèmes de flux de données,
Code et logique incorrects

15
2.2 Niveaux de Tests
• Tests d’intégration :
1. Test d’intégration des composants teste les interactions entre les
composants logiciels (fait après test de composant)
2. Test d’intégration système teste l’interaction entre les différents systèmes
(fait après test système)
Bases de test
Diagrammes de séquence, Spécifications des protocoles d’interface et de
communication, Cas d’utilisation, Workflows, Conception du logiciel et du
système
Objets de test
Sous-systèmes, Interfaces, Micro-services, Bases de données, APIs

16
Défauts et défaillances courants
• Défaillances dans la communication entre les composants, Décalages au niveau des
interfaces

− Données incorrectes, données manquantes ou encodage incorrect des données

− Mauvais séquencement ou synchronisation des appels d'interfaces

• Défaillances dans la communication entre les systèmes

• Structures de message incohérentes entre les systèmes

• Les tests d’intégration testent les interfaces entre les composants, les interactions entre
différentes parties d’un système comme par exemple le système d’exploitation, le
système de fichiers, le matériel ou les interfaces entre les systèmes
17
 • Des stratégies d’intégration systématique peuvent être basées sur l’architecture des
systèmes (telles que top-down ou buttom-up), les tâches fonctionnelles, les
séquences d’exécution de transactions, ou d’autres aspects du système ou du
composant.
• Afin d’isoler facilement les fautes, et détecter les défauts au plus tôt, l’intégration
devrait normalement être incrémentale plutôt qu’être effectuée en une fois (“big
bang”)

• Les tests d'intégration de composants sont souvent la responsabilité des développeurs

(niveau unitaire).
• Les tests d'intégration de systèmes relèvent généralement de la responsabilité des
testeurs (niveau système)
18
2.2 Niveaux de Tests
• Tests système :
Objectifs des tests système
• Réduire les risques
• Vérifier si les comportements fonctionnels et non-fonctionnels du
système sont tels qu'ils ont été conçus et spécifiés
• Valider que le système est complet et fonctionnera comme prévu
• Renforcer la confiance dans la qualité du système dans son
ensemble
• la vérification de la qualité des données peut être un objectif
19
Objets de test : Système, application
• Ce sont des tests qui traitent le comportement du système /
produit complet dans un environnement de test qui devrait
correspondre à la cible finale ou à un environnement de
production de façon à minimiser les risques de défaillances dues à
l’environnement
• Ces tests sont opérés par une équipe de test indépendante, ils
peuvent être aussi bien fonctionnels que non-fonctionnels
• Ils peuvent aussi être
• des tests boîte blanche (basées sur les structures)
• boîte noire (basées sur les spécifications avec une table de
décision par exemple)
20
Défauts et défaillances courants
• Calculs incorrects
• Comportement fonctionnel ou non-fonctionnel du système incorrect
ou inattendu. Flux de contrôle et/ou de données incorrects au sein
du système
• Réalisation incorrecte et incomplète des tâches fonctionnelles de
bout en bout. Incapacité du système à fonctionner correctement
dans le ou les environnements de production
Approches spécifiques et responsabilités
• le comportement global de bout en bout du système
• L'implication tôt en amont des testeurs dans l’affinement des User
Stories ou dans les activités de tests statiques

21
2.2 Niveaux de Tests
• Tests d’acceptation
• C’est la responsabilité du client finale du système
• L’objectif est d’établir un niveau de confiance par rapport au
logiciel
• La recherche d’anomalies n’est pas l’objectif principal des tests
d’acceptation
• Les tests d’acceptation peuvent évaluer si le système est prêt à
être déployé et utilisé, bien qu’il ne soit nécessairement pas le
dernier niveau ;
exemple: une intégration système à grande échelle peut arriver
après les tests d’acceptation du système.
22
• Les formes habituelles des tests d’acceptation incluent :
• Tests d’acceptation utilisateur qui vérifient l’aptitude et
l’utilisabilité du système par des utilisateurs.
• Tests (d’acceptation) opérationnelle qui englobe les tests
• des backups et restaurations;
• la reprise après sinistre;
• la gestion des utilisateurs;
• les tâches de maintenance;
• les chargements de données et tâches de migration;
• la vérification périodique des vulnérabilités de sécurité.
• Tests d’acceptation contractuelle et réglementaire

23
• Les tests Alpha sont exécutés sur le site de
l’organisation effectuant le développement mais
pas par les équipes de développement
• Les tests Béta ou tests sur le terrain sont exécutés
par des personnes sur leurs sites propres

24
Bases de test
• Exigences utilisateur ou métier, réglementations, contrats légaux et
normes, cas d’utilisation, exigences système, documentation système ou
utilisateur, procédures d'installation, rapports d'analyse des risques
• Procédures de sauvegarde et de restauration(opérationnel), procédures
de reprise après sinistre, instructions de déploiement et d'installation,
objectifs de performance, ensembles de base de données, normes ou
règlements de sécurité
Défauts et défaillances courants
• Les workflows du système ne répondent pas aux exigences métier ou
utilisateurs
Approches et responsabilités spécifiques =>client

25
Niveaux des tests

bas niveau de conception

Tests unitaires White box developpeur
Niveaux des tests (code)

haut/bas developpeur
White box
Niveau de conception

Tests systèmes Besoins des utilisateurs Black box Testeur

Besoins des utilisateurs Black box Client / Utilisateur

Tests alpha : pré-version : effectués sur le site de l'organisation de

développement mais pas par l'équipe de développement

Tests bêta : pré-version : effectués par le client sur son propre site
2.3 Types de Tests

27
2.3 Types de Tests
• Tests Fonctionnels : les fonctionnalités offertes par le système « Quoi? »
• Les tests fonctionnels concernent le comportement extérieur du logiciel (tests boîte noire) et
peuvent être exécutés à tous les niveaux de tests.
• Interopérabilité
• Tests Non-Fonctionnels: « Comment? »
Les tests non-fonctionnels incluent
• sécurité
• les tests de performances
• tests de charge (grand nombre d’utilisateurs)
• tests de stress
• tests d’utilisabilité
• tests de maintenabilité
• tests de fiabilité
• tests de portabilité.

28
2.3 Types de Tests
• Les tests non fonctionnels concernent l’aspect extérieur du logiciel et la plupart
du temps utilisent les techniques de conception de tests boîte noire.

• Ces tests peuvent être référencés dans un modèle qualité tel que celui défini
par ISO 9126 et ISO 25010.
• Les tests non-fonctionnels peuvent être effectués à tous les niveaux de tests.
Le terme de tests non-fonctionnels décrit les tests requis pour mesurer les
caractéristiques des systèmes et logiciels.

29
2.3 Types de Tests
• Tests de la Structure / Architecture Logicielle (Tests Structurels) :
• Les tests structurels (boîte blanche) peuvent être effectués à tous les niveaux
de tests.
• A tous les niveaux de tests, mais spécialement dans les tests de composants
et les tests d’intégration de composants
• Des outils peuvent être utilisés pour mesurer la couverture du code
• Si la couverture n’est pas de 100%, alors de nouveaux tests peuvent être
conçus pour tester les éléments manquants et ainsi augmenter la couverture
(voir chapitre 4 pour la couverture).
• Les techniques structurelles sont utilisées de façon optimale après les
techniques basées sur les spécifications, pour aider à mesurer l’ampleur des
tests via l’évaluation de la couverture d’un type de structure.

30
 2.3 Types de Tests
• Tests liés aux changements
• Quand un défaut est détecté et corrigé, le logiciel devrait être re-testé pour
confirmer que le défaut original a été correctement réparé. Ceci est appelé test
de confirmation
• Ré-exécuter des tests sur un programme déjà testé s’appelle « test de
régression ». Cela se fait après que des modifications du programme aient eu
lieu.
• Les tests de régression peuvent être exécutés à tous les niveaux de tests, et
s’appliquent aux tests fonctionnels, non-fonctionnels et structurels ; ce sont les
bons candidats à l’automatisation.

31
 Tests boîte noire
Types de Tests

Tests Fonctionnels
Tests boîte blanche

Tests liés aux

Tests Non-
Fonctionnels changements
2.4 Tests de Maintenance
• Les tests de maintenance sont effectués sur un système opérationnel existant
et sont déclenchés par des modifications, migrations ou suppression de
logiciels ou de systèmes.
• Les modifications incluent
• Changements dus aux évolutions planifiées (ex. livraisons de nouvelles
versions), aux modifications correctives et d’urgence
• Changements d’environnements tels que les montées en version planifiées
des systèmes d’exploitation, des bases de données
• Patchs de correction des vulnérabilités de sécurité potentielles ou
découvertes d’un système d’exploitation.
• Selon le changement, les tests de maintenance peuvent être effectués à
chacun ou à tous les niveaux de tests et pour certains ou tous les types de
tests (selon l’analyse d’impact)
33
2.4 Tests de Maintenance
Analyse de l’impact en cas de maintenance
• L'analyse d'impact peut être effectuée avant qu'un changement ne soit
apporté, pour aider à déterminer si le changement devrait être apporté en
fonction des conséquences potentielles dans d'autres parties du système.
• L'analyse d'impact peut être difficile si
• Les cas de test ne sont pas documentés ou sont obsolètes
• La traçabilité bidirectionnelle entre les tests et les bases de test n'a pas été
maintenue
• Le support de l'outillage est faible ou inexistant
• Les personnes impliquées n'ont pas de connaissance du domaine et/ou du système
• Nouvelles découvertes

34
Quizz
1) Qu’est-ce qu’une exigence non-fonctionnelle ?
1. Une exigence laissée de côté suite à un arbitrage de l’équipe de test
2. Une exigence contraste par d’autres exigences
3. Une exigence ne se rapportant pas aux fonctionnalités
4. Une qui n’impacte pas l’expérience utilisateur

35
2) Lors de la phase de conception des spécifications, quelle pratique
estla plus adéquate ?
1. Le testeur n’est pas impliqué dans cette phase
2. Le testeur effectue une revue des spécifications afin de détecter au
plus tôt les points à éclaircir ou à corriger
3. Le testeur rédige une partie des spécifications
4. Le testeur rédige l’intégralité des spécifications

36
3) La qualité est définie comme...
1. Le taux de conformité aux standards en vigueur de la réalisation
spécifique d'un composant, système ou processus
2. La mesure relative à la satisfaction exprimée par les clients ou
utilisateurs à l'issue de la conception d'un composant, système ou
processus
3. Le ratio entre la part des composants, systèmes ou processus sans
anomalies et la totalité de ces objets
4. Le degré par lequel un composant, système ou processus atteint
des exigences spécifiées et/ou des besoins ou attentes des clients
ou utilisateurs

37
4) Dans quel ordre se déroulent en principe les différents niveaux de tests ?

1. Tests de composants, tests d'intégration, tests système, tests d'acceptation

2. Tests de composants, tests système, tests d'acceptation, tests d'intégration
3. Tests de composants, tests d'acceptation, tests système, tests d'intégration
4. Tests de composants, tests d'acceptation, tests d'intégration, tests système

38
5) L'agilité s'oppose-t-elle au test ?

1. Non. L'agilité s'oppose au test manuel mais met l'accent sur les tests
automatisés.
2. Non. L'agilité favorise une exécution fréquente des tests afin d'éviter les
régressions d'une itération à l'autre.
3. Non. Une démarche agile se doit de rechercher constamment à améliorer les
processus de développement, donc de tester différentes solutions.
4. Non. C'est l'inverse : ce sont les standards du test qui s'opposent à l'agilité, qui
abandonne la qualité au profit de la rapidité

39
6) Quand faut-il commencer à tester ?

1. Dès que le code est suffisamment stable. Le risque, en commençant les

tests trop tôt, est de confondre ce qui est en cours et ce qui contient
réellement des défauts.
2. Dès qu'il existe un brouillon de spécification. Des bugs peuvent déjà
exister dans la documentation.
3. Dès le début du développement. C'est ce qu'on appelle le TDD (Test
Driven Development).
4. Dès qu'une version alpha du projet est disponible. Il ne faut pas attendre
la version beta, car elle est directement déployée chez le client.

40
7) Considérant les énoncés suivants sur les relations entre les activités de développement du logiciel
et les activités de test dans le cycle de vie du développement du logiciel :

1. Chaque activité de développement devrait avoir une activité de test correspondante.

2. Les tests devraient commencer dès que les versions finales des documents sont disponibles.
3. La conception et l'implémentation des tests doivent commencer pendant l'activité
de développement correspondante.
4. Les activités de test devraient commencer dès les premières étapes du cycle
de développement du logiciel.

Lequel des éléments suivants indique CORRECTEMENT le vrai et le faux ?

• A. Vrai – 1, 2; Faux – 3, 4
• B. Vrai – 2, 3; Faux – 1, 4
• C. Vrai – 1, 2, 4; Faux – 3
• D. Vrai – 1, 4; Faux – 2, 3

41
8) Étant donné que les tests effectués ont les caractéristiques suivantes :
- ils sont basés sur des spécifications d'interface ;
- ils sont concentrés sur la recherche d'erreurs de communication ;
- l'approche de test comprend à la fois des types de test fonctionnels et
structurels.

Lequel des niveaux de test suivants est le PLUS susceptible d'être

réalisé ?
A. Test d'intégration des composants
B. Test d'acceptation
C. Test système
D. Test de composants
42
9) Lequel des énoncés suivants concernant les types
et les niveaux de test est CORRECT ?
A. Les tests fonctionnels et non fonctionnels peuvent être effectués au
niveau des tests système et d'acceptation, tandis que les tests
boîte-blanche sont limités aux tests de composants et d'intégration.
B. Le test fonctionnel peut être effectué à n'importe quel niveau de
test, tandis que les tests boîte-blanche sont réalisés au niveau test
de composants.
C. Il est possible d'effectuer des tests fonctionnels, non fonctionnels et
des tests boîte blanche à n'importe quel niveau de test.
D. Les tests fonctionnels et non fonctionnels peuvent être effectués à
n'importe quel niveau de test, tandis que les tests boîte-blanche
sont limités aux tests de composants et d'intégration.
43
• 10)Quelle réponse compare LE MIEUX les objectifs des tests de confirmation et des tests de régression ?

A. L’objectif des tests de régression est de s’assurer que tous les tests précédemment exécutés fonctionnent
toujours correctement, alors que l’objectif des tests de confirmation est de s’assurer que toute correction faite
sur une partie du système n’a pas affecté négativement d’autres parties

B. L’objectif des tests de confirmation est de vérifier qu’un défaut trouvé précédemment a été corrigé, alors
que l’objectif des tests de régression est de s’assurer que d’autres parties du système n’ont pas été affectées
négativement par la correction.

C. L’objectif des tests de régression est de s’assurer que tout changement fait sur une partie du système n’a pas
causé la défaillance d’une autre partie, alors que l’objectif des tests de confirmation est de vérifier que tous les
tests précédemment exécutés donnent toujours le même résultat qu’avant

D. L’objectif des tests de confirmation est de confirmer que les changements sur le système ont été faits avec
succès, alors que l’objectif des tests de régression est d’exécuter les tests ayant précédemment échoué pour
44
s’assurer qu’ils fonctionnent maintenant correctement
11)Quelle réponse décrit CORRECTEMENT un intérêt de l’analyse
d’impact dans la maintenance ?
A. L’analyse d’impact est utilisée pour déterminer si une correction
devrait être apportée en fonction des conséquences potentielles
B. L’analyse d’impact est utilisée pour définir comment les données
devraient être migrées vers le système en maintenance
C. L’analyse d’impact est utilisée pour décider quelles corrections à
chaud ont le plus de valeur pour l’utilisateur
D. L’analyse d’impact est utilisée pour déterminer l’efficacité des
nouveaux cas de test de maintenance
45
 UNIVERSITÉ DE SFAX
Institut Supérieur d’Informatique et de Multimédia

Tests de logiciels
Certification ISTQB
TLSI ADBD

Cours 3: Techniques Statiques (K2)

par
Asma Sellami Mnif & Aicha Idriss
[email protected]
3.1 Bases des tests statiques

Techniques
de test

Statique Dynamique

Analyse statique Revue

2
3.1 Bases des tests statiques (Suite…)
• Les techniques de tests statiques reposent sur l'examen manuel (revues) ou
l'analyse du code outillée (analyse statique) ou de la documentation du projet
sans exécution du code.
• Tout produit logiciel peut être revu, y compris les exigences, les spécifications,
les spécifications de conception, le code, les plans de test, les spécifications de
test, les cas de test, les scripts de test, les guides de l’utilisateur ou pages web
• Les revues permettent une détection et une correction anticipées des défauts
• Les revues, les analyses statiques et les tests dynamiques ont le même objectif
qui consiste à identifier les défauts
− Améliorer la cohérence et la qualité interne des produits d'activités, tandis que les tests dynamiques
se concentrent généralement sur les comportements visibles de l'extérieur
− Ils sont complémentaires : les techniques statiques trouvent les causes des défauts, les tests
dynamiques trouvent les défaillances elles mêmes

3
3.2 Processus de revue

• Les revues formelles sont caractérisées par la participation de

l'équipe, la documentation des résultats de la revue et la
documentation des procédures pour la conduite de la revue
• Le caractère formel d'un processus de revue est lié à des facteurs tels
que le modèle de cycle de vie de développement du logiciel, la
maturité du processus de développement, la complexité du produit
d’activités à revoir, toute exigence légale ou réglementaire, et/ou la
nécessité d'une traçabilité d'audit.
• La focalisation d'une revue dépend des objectifs fixés pour la revue
(par exemple, trouver des défauts, gagner en compréhension, former
les participants tels que des testeurs et de nouveaux membres de
l'équipe, ou discuter et décider par consensus).
4
3.2.1 Processus de revue de produits d’activités
• Planification
• Définir le périmètre, qui comprend le but de la revue, les documents ou parties de documents à revoir et
les caractéristiques de qualité à évaluer
• Estimer l'effort et le temps requis
• Identifier les caractéristiques de la revue telles que le type de revue avec les rôles, les activités et les
checklists
• Sélectionner les personnes qui participeront à la revue et attribuer des rôles
• Définir des critères d'entrée et de sortie pour les types de revue plus formels (p. ex. inspections)
• Vérifier que les critères d'entrée soient satisfaits (pour les types de revue plus formels)
• Lancement de la revue
• Distribuer le produit d'activités (physiquement ou par voie électronique) et d'autres documents, comme
des formulaires de saisie des défauts, des checklists et des produits d'activités connexes
• Expliquer le périmètre, les objectifs, le processus, les rôles et les produits d'activités aux Participants
• Répondre à toutes les questions que les participants peuvent avoir au sujet de la revue
• Préparation individuelle (ou Revue individuelle)
• Revoir tout ou partie du produit d'activités
• Noter les défauts potentiels, les recommandations et les questions
5
3.2.1 Processus de revue de produits d’activités (Suite…)
• Communication et analyse des problèmes
• Communiquer les défauts potentiels identifiés (p. ex. lors d'une réunion de revue)
• Analyser les défauts potentiels, leur affecter un responsable et un statut
• Évaluer et documenter les caractéristiques de qualité
• Évaluer les résultats de la revue en fonction des critères de sortie pour prendre une décision de revue
(rejet ; changements majeurs nécessaires ; acceptation, éventuellement avec des changements mineurs)
• Correction et production de rapports (Re travail)
• Produire des rapports de défauts pour les constatations qui nécessitent des changements
• Corriger les défauts trouvés (correction généralement réalisée par l'auteur) dans le produit d'activités
revu
• Communiquer les défauts à la personne ou à l'équipe concernée (lorsqu'ils se trouvent dans un produit
d'activités lié au produit d'activités revu)
• Enregistrer l'état actualisé des défauts (dans les revues formelles), y compris éventuellement l'accord de
l'auteur du commentaire concerné
• Recueillir des métriques (pour les types de revue plus formels)
• Vérifier que les critères de sortie sont satisfaits (pour les types de revue plus formels)
• Accepter le produit d'activités lorsque les critères de sortie sont satisfaits
6
3.2.2 Rôles et responsabilités dans une revue formelle

• Auteur
• Crée le produit d'activités revue
• Corrige les défauts du produit d’activités revue (si nécessaire)
• Manager
• Est responsable de la planification de la revue
• Décide de la mise en œuvre des revues
• Affecte le personnel, le budget et le temps
• Vérifie le rapport coût-efficacité en continu
• Met en œuvre les mesures appropriées en cas de résultats inadéquats
• Facilitateur (modérateur)
• Assure le bon déroulement des réunions de revue (quand elles ont lieu)
• Fait la médiation, si nécessaire, entre les différents points de vue
• Est souvent la personne dont dépend le succès de la revue

7
3.2.2 Rôles et responsabilités dans une revue formelle (Suite…)

• Responsable de la revue
• Prend la responsabilité générale de la revue
• Décide qui sera impliqué et organise quand et où elle aura lieu)
• Réviseurs
• Il peut s'agir d'experts du domaine, de personnes travaillant sur le projet, d'intervenants ayant un intérêt
pour le produit d’activités et/ou de personnes ayant des compétences techniques ou métier spécifiques
• Ils identifient les défauts potentiels du produit d’activités à revoir
• Ils peuvent représenter différentes perspectives (p. ex. testeur, programmeur, utilisateur, opérateur,
analyste métier, expert en utilisabilité, etc.)
• Scribe (Rapporteur)
• Recueille les défauts potentiels découverts au cours de l'activité de revue individuelle
• Enregistre les nouveaux défauts potentiels, les points en suspens et les décisions prises lors de la réunion
de revue (durant son déroulement)

8
3.2.3 Types de revue

• Revue informelle (p. ex., par un collègue, en binôme, revue de pair)

• Objectifs :
− détecter d’éventuels défauts
− générer de nouvelles idées ou solutions, résoudre rapidement des problèmes mineurs

• Ne repose pas sur un processus formel (documenté)

• Peut ne pas comporter de réunion de revue
• Peut être effectué par un collègue de l'auteur ou par d'autres personnes
• Les résultats peuvent être documentés
• L'utilité varie selon les réviseurs
• L'utilisation de checklists est facultative
• Très couramment utilisé dans le développement Agile

9
 3.2.3 Types de revue (Suite…)
• Relecture technique (Walkthrough)
• Objectifs :
− trouver des défauts, améliorer le produit logiciel, envisager des implémentations alternatives,
évaluer la conformité aux normes et aux spécifications,
− échange d'idées sur des techniques ou des variations de style, formation des participants,
obtention d'un consensus
• La préparation individuelle avant la réunion de revue est facultative
• La réunion de revue est généralement dirigée par l'auteur du produit d’activités
• Le rôle de scribe est obligatoire
• L'utilisation de checklists est facultative
• Peut prendre la forme de scénarios, d’essais à blanc ou de simulations
• Des rapports de défauts et des rapports de revue peuvent être produits
• Peut varier dans la pratique de plutôt informel à très formel)

10
3.2.3 Types de revue (Suite…)

• Revue technique
• Objectifs :
− obtention d'un consensus, détection de défauts potentiels
− évaluer la qualité et renforcer la confiance dans le produit d’activités revu, générer de nouvelles
idées, motiver et permettre aux auteurs d'améliorer les produits d’activités futurs, envisager des
implémentations alternatives
• Les réviseurs doivent être des pairs techniques de l'auteur et des experts techniques dans la
même discipline ou dans d'autres disciplines
• Une préparation individuelle avant la réunion de revue est requise
• La réunion de revue est facultative, et de préférence dirigée par un facilitateur formé
(généralement pas l'auteur)
• Le rôle de scribe est obligatoire, de préférence pas l'auteur
• L'utilisation de checklists est facultative
• Des rapports de défauts et des rapports de revue sont généralement produits

11
3.2.3 Types de revue (Suite…)
• Inspection
• Objectifs :
− détecter les défauts potentiels, évaluer la qualité et renforcer la confiance dans le produit d’activités, prévenir de
futurs défauts similaires par l'apprentissage de l'auteur et l'analyse des causes racines
− motiver et permettre aux auteurs d'améliorer les futurs produits d’activités et le processus de développement de
logiciels, parvenir à un consensus
• Suit un processus défini avec des résultats formels documentés, basé sur des règles et des checklists
• Utilise des rôles clairement définis, comme ceux spécifiés à la section 3.2.2 qui sont obligatoires, et peut inclure un
lecteur spécialisé (qui lit le produit d’activités à haute voix pendant la réunion de revue)
• Une préparation individuelle avant la réunion de revue est requise
• Les réviseurs sont soit des pairs de l'auteur, soit des experts dans d'autres disciplines pertinentes pour le produit
d’activités concerné
• Des critères d'entrée et de sortie spécifiés sont utilisés
• Le rôle de scribe est obligatoire
• La réunion de revue est dirigée par un facilitateur formé (pas l'auteur)
• L'auteur ne peut pas agir à titre de responsable de la revue, de lecteur ou de scribe
• Des rapports de défauts et des rapports de revue sont produits
• Des métriques sont collectées et utilisées pour améliorer l'ensemble du processus de développement logiciel, y compris
le processus d'inspection
12
3.2.4 Application des techniques de revue
• Ad hoc
• Les réviseurs reçoivent peu ou pas de directives sur la façon dont cette tâche devrait être accomplie.
• Les réviseurs examinent généralement le produit d’activités de façon séquentielle, en identifiant et en
documentant les problèmes au fur et à mesure qu'ils les rencontrent.
• La révision ad hoc est une technique couramment utilisée qui nécessite peu de préparation. Cette
technique dépend fortement des compétences des réviseurs et peut donner lieu à des constats qui font
double emploi car signalés par différents réviseurs.
• Basée sur les checklists
• Une revue basée sur une checklist est une technique systématique, pour laquelle les réviseurs détectent
les problèmes sur la base de checklist qui sont distribuées au début de la revue (par exemple, par le
facilitateur)
• Une checklist consiste en une série de questions basées sur des défauts potentiels, qui peuvent être issus
de l'expérience. Les checklists devraient être spécifiques au type de produit d’activités examiné et
devraient être mises à jour régulièrement pour couvrir les types de problèmes qui ont été omis lors de
revues précédentes.
• Le principal avantage de la technique basée sur les checklists est la couverture systématique des types de
défauts courants. Il faut prendre soin de ne pas simplement suivre la checklist lors de la revue individuelle,
mais aussi de rechercher des défauts en dehors de la checklist.
13
3.2.4 Application des techniques de revue
• Scénarios et essais à blanc
• Dans le cadre d'une revue fondée sur des scénarios, les réviseurs reçoivent un guide structuré sur la façon
de lire le produit d’activités.
• Une approche fondée sur des scénarios aide les réviseurs à effectuer des "essais à blanc" sur le produit
d’activités en fonction de l'utilisation prévue du produit d’activités (si le produit d’activités est documenté
dans un format approprié, comme les cas d'utilisation par exemple).
• Ces scénarios permettent aux réviseurs d’être mieux guidés sur la façon d'identifier des types de défauts
spécifiques qu’avec uniquement les éléments d’une checklist.
• Comme pour les revues basées sur des checklists, afin de ne pas manquer certains types de défauts (p. ex.,
des caractéristiques manquantes), les réviseurs ne devraient pas être limités aux scénarios documentés..
• Basée sur les rôles
• Une revue basée sur les rôles est une technique par laquelle les réviseurs évaluent le produit d’activités du
point de vue de rôles individuels des parties prenantes.
• Les rôles typiques comprennent des types d'utilisateurs finaux spécifiques (expérimentés, inexpérimentés,
seniors, enfants, etc.) et des rôles spécifiques dans l'organisation (administrateur utilisateur, administrateur
système, testeur de performance, etc.).

14
3.2.4 Application des techniques de revue
• Basée sur la perspective
• Dans une lecture basée sur la perspective, de façon semblable à une revue basée sur les rôles, les réviseurs
adoptent différents points de vue des parties prenantes dans le cadre d'une revue individuelle.
• Les points de vue habituels des parties prenantes comprennent l'utilisateur final, le marketing, le
concepteur, le testeur ou les opérations.
• L'utilisation de différents points de vue des parties prenantes permet d'approfondir la revue individuelle
avec moins de doublons de défauts entre les réviseurs.
• De plus, la lecture basée sur la perspective exige également que les réviseurs essaient d'utiliser le produit
d’activités revue pour produire le produit qu'ils en tireraient.
Par exemple, un testeur pourrait essayer de générer des brouillons de tests d'acceptation en réalisant
une lecture basée sur la perspective d'une spécification des exigences pour voir si toute l'information
nécessaire est bien incluse.
• De plus, dans le cadre de la lecture basée sur la perspective, on s'attend à ce que des checklists soient
utilisées.

15
3.2.5 Facteurs de réussite des revues
 Facteurs de réussite organisationnels pour les revues
• Chaque revue a des objectifs clairs, définis lors de la planification de la revue et utilisés comme
critères de sortie mesurables
• Le type de revue est choisi en fonction des objectifs, du type et du niveau des produits d’activités
logiciels, mais aussi en tenant compte des participants
• Toutes les techniques de revue utilisées, telles que la revue basée sur les checklists ou sur les rôles,
sont appropriées pour l'identification efficace des défauts dans le produit d’activités à revoir
• Toutes les checklists utilisées couvrent les principaux risques et sont actualisées
• Les documents volumineux sont rédigés et révisés en petits morceaux, de sorte que le contrôle de la
qualité est réalisé en fournissant aux auteurs un feed-back précoce et fréquent sur les défauts
• Les participants ont suffisamment de temps pour préparer
• Les revues sont planifiées avec un délai de notification suffisant
• Le management appuie le processus de revue (p. ex. en intégrant suffisamment de temps pour les
activités de revue dans les échéanciers des projets)
16
 3.2.5 Facteurs de réussite des revues (Suite…)
 Facteurs de réussite liés aux participants aux revues
• Le choix des bonnes personnes contribue à l'atteinte des objectifs de la revue, par exemple, des personnes ayant des
compétences ou des perspectives différentes, qui peuvent utiliser le document comme intrant de leurs activités
• Les testeurs sont considérés comme des réviseurs appréciés qui contribuent à la revue et aussi apprennent à propos
du produit d’activités revu, ce qui leur permet de produire des tests plus efficaces et de préparer ces tests plus tôt
• Les participants consacrent suffisamment de temps et d'attention aux détails
• Les revues sont effectuées sur de petits morceaux, de sorte que les réviseurs ne perdent pas leur concentration
pendant la revue individuelle et/ou la réunion de revue (quand elle a lieu)
• Les défauts trouvés sont identifiés, compris et traités avec objectivité
• La réunion est bien gérée, de sorte que les participants considèrent qu'il s'agit d'une utilisation efficace de leur
temps
• La revue est menée dans un climat de confiance ; le résultat ne sera pas utilisé pour l'évaluation des participants
• Les participants évitent le langage corporel et les comportements qui pourraient indiquer l'ennui, l'exaspération ou
l'hostilité envers les autres participants
• Une formation adéquate est fournie, en particulier pour les types de revue plus formels tels que les inspections
• Une culture de l'apprentissage et de l'amélioration des processus est encouragée 17
3.3 Analyse statique outillée

• L’accent est mis sur l’apprentissage et l’amélioration du processus.

• L'objectif de l'analyse statique est de trouver des défauts dans le
code source et les modèles logiciels.
• Les outils d'analyse statique analysent le code du programme et
sont typiquement utilisés par des développeurs avant et pendant
les tests de composants et les tests d'intégration.
• Les outils d'analyse statique peuvent produire un nombre
important de messages d'avertissement qui doivent être gérés
convenablement afin de permettre une utilisation optimale de
l'outil.

18
3.3 Analyse statique outillée

• La valeur des tests statiques est :

• La détection très tôt de défauts avant l’exécution des tests.
• Une information très tôt sur certains aspects suspects du code ou de la
conception, par le calcul de métriques, par exemple une mesure de
complexité élevée.
• L’identification de défauts difficilement détectables par des tests
dynamiques.
• La détection de dépendances et d’inconsistances dans les modèles logiciels
tels que des liens dans les modèles logiciels.
• L’amélioration de la maintenabilité du code et de la conception.
• La prévention des défauts, si les leçons sont prises en compte lors du
développement.
19
3.3 Analyse statique outillée

• Les défauts typiques découverts par des outils d’analyse statique

incluent :
• Référencement d’une variable avec une valeur indéfinie.
• Interface inconsistante entre modules et composants.
• Variables qui ne sont jamais utilisées ou déclarées de façon incorrecte.
• Code non accessible (code mort).
• Logique absente et erronée (potentiellement des boucles infinies).
• Constructions trop compliquées.
• Violation des standards de programmation.
• Vulnérabilités de sécurité.
• Violation de syntaxe dans le code et les modèles logiciels.
20
Réponse a)
Réponse d)
Réponse d)
Réponse a)
 UNIVERSITÉ DE SFAX
Institut Supérieur d’Informatique et de Multimédia

Tests de logiciels
Certification ISTQB
TLSI ADBD

Cours 4: Techniques de test

par
Asma Sellami Mnif & Aicha Idriss
[email protected]
4.1 Introduction

Technique
de test

Dynamique

Statiques

Boîte-noire
Boîte- sur
blanche l’expérience

2
4.2 Catégories de techniques de test
» Statique (pas d’exécution)
» Revue des documents, code source, etc.

» Fonctionnelle (black box)

» Basée sur le comportement

» Structurelle (white box)

» Basée sur la structure

3
4.2 Catégories de techniques de test

• Les techniques de test boite noire (techniques basées sur les spécifications) sont
une façon de dériver et de sélectionner les conditions de test, les cas de test où
les données de test.
• Les techniques de test boite noire incluent les tests fonctionnels et non
fonctionnels.
• Les techniques basées sur les spécifications n’utilisent aucune information
concernant la structure interne d ’un composant ou système à tester.
• Les techniques de test boite blanche (techniques basées sur les structures) sont
basées sur une analyse de la structure d’un composant ou du système.
• Ces deux techniques peuvent être combinées avec des techniques basées sur
l’expérience pour déterminer ce qui dit être testé.

4
4.2 Catégories de techniques de test

» Caractéristiques des techniques de conception basées sur les

spécifications:
– Les modèles, soit formels soit informels sont utilisés pour la spécification
des problèmes à résoudre, des logiciels ou des composants.
– Depuis ces modèles les cas de test sont dérivés de façon systématique.
» Caractéristiques des techniques de conception basées sur la
structure:
– L’information sur la manière dont le logiciel est construit est utilisée pour
dériver les cas de test.
– Le niveau de couverture du logiciel peut être mesuré à partir des cas de
test existants.
– Des cas de test complémentaires peuvent être dérivés systématiquement
pour augmenter la couverture.

5
4.2 Catégories de techniques de test

• Caractéristiques des techniques basées sur l’expérience:

• La connaissance et l’expérience des personnes sont utilisées pour
dériver les cas de test.

• La connaissance des testeurs, des développeurs, utilisateurs et autres

parties prenantes concernant le logiciel, son utilisation et son
environnement sont autant de sources d’information.

• La connaissance des défauts possibles et de leur distribution est une

autre source d’information.

6
 4.3 Techniques basées sur les spécifications ou boîte noire

Partitions d’équivalence
• Les entrées d’un logiciel sont divisées en groupes qui doivent
monter un comportement similaire et un traitement identique.
• Les partitions peuvent être identifiées pour les sorties, les valeurs
internes, les valeurs liées au temps et pour les paramètres
d’interface.
• Des tests peuvent être conçus pour couvrir toutes les partitions.

• Les partitions sont applicables à tous les niveaux de tests.

7
 4.3 Techniques basées sur les spécifications ou boîte noire
• Closing price filter 5%
• If Limit <= 1.05 * closing price , l’ordre est acquité
• If Limit > 1.05 * closing price , L’ordre est rejeté

L <= 1.05*closing price L > 1.05*closing price

1.05 * closing price

Partition 1 Partition 2

8
 4.3 Techniques basées sur les spécifications ou boîte noire

Analyse des valeurs limites

• Les valeurs min et max d’une partition sont ses valeurs limites.

• Des tests peuvent être conçus pour couvrir les valeurs limites valides et
invalides.

• Une valeur de chaque limite est sélectionnée pour un test.

• L’analyse de ces valeurs peut être appliquée à tous les niveaux de test.

• C’est une technique complémentaire à celle des partitions d’équivalence.

9
4.3 Techniques basées sur les spécifications ou boîte noire
• Exercice

10
 4.3 Techniques basées sur les spécifications ou boîte noire

Tests par tables de décision

• Les conditions d’entrée et les actions sont souvent décrites de façon à ce
qu’elles peuvent être soit vraies soit fausses (Booléen).
• Les tables de décision contiennent les conditions de déclenchement, souvent
des combinaisons de vrais et faux pour toutes les conditions d’entrée, et sur
les actions résultantes pour chaque combinaison de conditions.
• Chaque colonne de la table correspond à une règle de gestion qui définit une
combinaison unique de conditions qui résultent en l'exécution de l'action
associée à cette règle.
11
4.3 Techniques basées sur les spécifications ou boîte noire

Conditions Rule 1 Rule 2 Rule 3 Rule 4

Modality Marker Market Any Price Any Price

Validity FOK E&E FOK E&E

Actions

Results Y Y N N

12
 4.3 Techniques basées sur les spécifications ou boîte noire

• Test de transition d’état

• Un système peut montrer plusieurs réponses différentes en fonction des
conditions actuelles ou passées (son état).

• Cet aspect du système peut être montré par un diagramme d'états et de

transitions.

• Cela permet au testeur de visualiser le logiciel en termes d'états, de transitions

entre les états, de données d'entrées et des actions qui peuvent résulter de ces
transitions.

• Cette technique est utilisée pour couvrir une séquence typique d’états, et pour
exécuter toutes les transitions.

13
4.3 Techniques basées sur les spécifications ou boîte noire
• Exemple:

14
 4.3 Techniques basées sur les spécifications ou boîte noire

• Test de cas d’utilisation

• Un cas d’utilisation décrit l’interaction entre acteurs qui produit un
résultat ayant une valeur pour l’utilisateur du système ou le client.

• Chaque cas d’utilisation a des pré-conditions, qui doivent être atteintes

pour que ce cas d’utilisation soit exécuté avec succès.

• Chaque cas d’utilisation se termine par des post-conditions, qui sont les
résultats observables et l’état final du système après la fin de l’exécution
du cas d’utilisation.

15
4.3 Techniques basées sur les spécifications ou boîte noire
• Exemple:

16
4.4 Techniques basées sur la structure ou boîte blanche

• Test des instructions et couverture

• La couverture des instructions est l’évaluation du pourcentage d’instructions exécutables qui ont été
exercées par une suite de cas de test.
• La couverture des instructions est déterminée par le nombre d’instructions exécutables couvertes par
des cas de test (conçus ou exécutés) divisé par le nombre de toutes les instructions exécutables dans le
code testé.

Couverture des = nombre d’instructions exécutables

instructions nombre de toutes les instructions exécutables

17
4.4 Techniques basées sur la structure ou boîte blanche

read(a) Test Input Expected

1
2 IF a > 6 THEN case output
3 b=a
4
1 7 7
ENDIF
5
print b

As all statements are ‘covered’ by

this test case, we have achieved
100% statement coverage

18
4.4 Techniques basées sur la structure ou boîte blanche

• Test des décisions et couverture:

• La couverture des décisions, liées aux tests de branches, est l’évaluation des
pourcentages de résultats de décisions (p.ex. les options Vrai et Faux d’une
instruction IF) qui ont été traitées par une suite de cas de test.
• La couverture des décisions est supérieure à la couverture des instructions:
• Une couverture de 100% des décisions garantit une couverture à 100% des
instructions.
• L’inverse n’est pas vrai.
number of decisions outcomes exercised
Couverture des =
décisions total number of decision outcomes

19
Couverture des chemins d’exécutio1 234
n
12 12 123
 Wait

Example 1
Wait for card to be inserted Yes
Valid Display
IF card is a valid card THEN
card? “Enter..
display “Enter PIN number”
IF PIN is valid THEN No
select transaction
Reject Valid Yes Select
ELSE (otherwise)
card PIN? trans...
display “PIN invalid”
No
ELSE (otherwise)
reject card Display
End “PIN in..

End
 Read
Example 2
Read A Yes Yes
IF A > 0 THEN A>0 A=21
IF A = 21 THEN
Print “Key” No No
Print
ENDIF
ENDIF

End

• Cyclomatic complexity: 3
• Minimum tests to achieve:
• Statement coverage: 1
• Branch coverage: 3
 Read
Example 3
Read A
Read B Yes No
A>0 B=0 Print
IF A > 0 THEN
IF B = 0 THEN No Yes
Print “No values” Yes
ELSE Print A>21 Print
Print B No
IF A > 21 THEN
Print A
ENDIF End
ENDIF
ENDIF • Cyclomatic complexity: 4
• Minimum tests to achieve:
• Statement coverage: 2
• Branch coverage: 4 _
 Yes
Read A<0 Print

Example 4 No
Read A Note: there Print
Read B
IF A < 0 THEN are 4 paths
Print “A negative”
Yes
ELSE B<0 Print
Print “A positive”
ENDIF No
IF B < 0 THEN Print
Print “B negative”
ELSE
Print “B positive”
ENDIF End
• Cyclomatic complexity: 3
• Minimum tests to achieve:
• Statement coverage: 2
• Branch coverage: 2_
 Yes
Read A<0 Print

Example 5 No
Read A
Read B
Yes
IF A < 0 THEN B<0 Print
Print “A negative”
ENDIF
No
IF B < 0 THEN
Print “B negative”
ENDIF End

• Cyclomatic complexity: 3
• Minimum tests to achieve:
• Statement coverage: 1
• Branch coverage: 2
 Yes
Read A<0 Print

Example 6 No

Read A
IF A < 0 THEN Yes
Print “A negative” A>0 Print
ENDIF
No
IF A > 0 THEN
Print “A positive”
ENDIF
End

• Cyclomatic complexity: 3
• Minimum tests to achieve:
• Statement coverage: 2
• Branch coverage: 2
4.4 Techniques basées sur la structure ou boîte blanche

Couverture de conditions et couverture de conditions

multiples
• Le concept de couverture peut aussi être appliqué aux autres
niveaux de tests
• Par exemple, au niveau intégration, le pourcentage des modules,
composants ou classes qui ont été exercées par une suite de cas de
test peut être exprimé comme une couverture de modules,
composants ou classes
27
4.5 Techniques basées sur l’expérience
• Les tests basés sur l'expérience sont conçus à partir des compétences des testeurs, de leur intuition et
de leur expérience avec des applications et technologies similaires. Les tests intuitifs peuvent être utiles
pour identifier des tests spéciaux, difficilement atteints par des approches formelles.

• L'estimation d'erreur ou « attaque par faute »:

• Comment l'application a fonctionné antérieurement,· Quels types d'erreurs les développeurs ont
tendance à faire· Les défaillances qui se sont produites dans d'autres applications

• Les tests exploratoires (informel et temps défini):

• Comprennent la conception et l'exécution des tests, l'écriture des résultats de tests et l'apprentissage

• Très utile lorsque les spécifications sont rares ou non adéquates, et que le test est soumis à de sévères
contraintes de temps

28
4.6 Tests basés sur Checklist
• Dans les tests basés sur des checklists, les testeurs conçoivent, implémentent et
exécutent des tests pour couvrir les conditions de test figurant dans une
checklist. Au cours de l'analyse, les testeurs créent une nouvelle checklist ou
complètent une checklist existante, mais les testeurs peuvent également utiliser
une checklist existante sans modification.

• En l'absence de cas de tests détaillés, les tests basés sur des checklists peuvent
fournir des lignes directrices et un certain degré de cohérence. Comme il s'agit de
listes de haut niveau, il est probable qu'il y ait une certaine variabilité dans les
tests réels, ce qui pourrait entraîner une plus grande couverture des tests, mais
29 une reproductibilité plus faible
4.7 Sélectionner les techniques de test

• Le choix des techniques de tests à utiliser dépend:

• De système à tester.
• Les objectifs de test.
• Les exigences client.
• Le risque.
• Lors de la création de cas de test, les testeurs utilisent généralement
une combinaison de techniques de tes
 d) est la valeur correcte. Les tests initialement conçus testent les valeurs limites suivantes : Inférieure : -1, supérieure : 100
Par conséquent, la couverture des valeurs limites atteintes est de 100 %. Les valeurs d'entrée utilisées pour exécuter les tests couvrent toutes ces valeurs limites.