Méthodologies de test de logiciels Page | 1

Unité I
Introduction
Qu'est-ce que le test ?
Termes associés : SQA, QC, Vérification, Validation
Vérification de la fonctionnalité pour la conformité par rapport aux spécifications données
Par l'exécution de l'application logicielle
Un test
Passes : Fonctionnalité OK.
Échecs : Fonctionnalité de l'application NOK.
Bug/Défaut/Faute : Écart par rapport à la fonctionnalité attendue.
Ce n'est pas toujours évident.
Objectif du test
1. Pour attraper les insectes
• Les bugs sont dus à une communication imparfaite entre les programmeurs
• Spécifications, conception, fonctionnalités de bas niveau
• Les statistiques disent : environ 3 bugs / 100 déclarations
2. Raisons liées à la productivité
• Efforts insuffisants en matière d'assurance qualité => Taux de rejet élevé =>
Reprises plus importantes => Coûts nets plus élevés
• Statistiques:
• Coûts d’assurance qualité : 2% pour les produits de consommation
80 % pour les logiciels critiques
• Qualité > Productivité
3. Objectifs des tests
Objectif principal des tests : prévention des bugs
Bug évité ^ l'effort de retravail est économisé [rapport de bug, débogage, correction,
nouveau test]
Si cela n’est pas possible, les tests doivent atteindre leur objectif secondaire de découverte de
bourgeons.
Bonne conception de test et tests ^ diagnostic clair ^ correction facile des bugs
Testez la pensée conceptuelle
À partir des spécifications, écrivez les spécifications de test. D'abord et ensuite le code.
Élimine les bugs à chaque étape du SDLC.
Si cela échoue, des tests permettent de détecter les bugs restants.
4. 5 phases dans la réflexion du testeur
Phase 0 : indique qu'il n'y a aucune différence entre le débogage et les tests
> Aujourd’hui, c’est un obstacle à la réalisation de tests de qualité et à la création de
logiciels de qualité.
Phase 1 : les tests visent à montrer que le logiciel fonctionne
> Un test échoué montre que le logiciel ne fonctionne pas, même si de nombreux tests
réussissent.
> Objectif non atteignable.
Phase 2 : indique que le logiciel ne fonctionne pas
> Un test raté le prouve.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 2

> Les tests doivent être repensés pour tester les logiciels corrigés.
> Mais nous ne savons pas quand arrêter de tester.
Phase 3 : dit Test de réduction des risques
> Nous appliquons les principes du contrôle de qualité statistique.
> Notre perception de la qualité du logiciel change lorsqu’un test réussit ou échoue.
> Par conséquent, la perception du risque lié au produit diminue.
> Libérer le produit lorsque le risque est inférieur à une limite prédéterminée.
Phase 4 : Un état d’esprit concernant « ce que les tests peuvent faire et ne peuvent pas faire ». « Qu’est-ce qui
rend un logiciel testable ».
> L’application de ces connaissances réduit la quantité de tests.
> Les logiciels testables réduisent les efforts
> Les logiciels testables ont moins de bugs que le code difficile à tester
Objectif cumulé de toutes ces phases :
> Cumulatif et complémentaire. L'un mène à l'autre.
> Les tests de la phase 2 à eux seuls ne montreront pas que le logiciel fonctionne
> Utilisation de méthodes statistiques pour tester la conception afin de réaliser de bons
tests à des risques acceptables.
> La plupart des logiciels testables doivent être débogués, doivent fonctionner et doivent
être difficiles à casser.
5. Tests et inspections
1. L'inspection est également appelée test statique.
2. Les méthodes et les objectifs des tests et de l’inspection sont différents, mais l’objectif est de
détecter et de prévenir différents types de bogues.
3. Pour prévenir et attraper la plupart des bugs, nous devons
1. Revoir
2. Inspecter et
3. Lire le code
4. Effectuer des visites guidées du code
Quelques points importants :
Conception des tests Après les tests et les corrections, repensez les tests et testez les tests repensés
Prévention des bugs
Mélange de différentes approches, en fonction des facteurs
culture, environnement de développement, application, taille du projet, histoire, langue
Méthodes d'inspection
Style de conception
Analyse statique
Langues – avoir une syntaxe forte, une vérification de chemin et d’autres contrôles
Méthodologies de conception et environnement de développement
Il vaut mieux savoir :
Paradoxe des pesticides
Barrière de complexité
Dichotomies
division en deux groupes ou entités particulièrement mutuellement exclusifs ou contradictoires la dichotomie entre
théorie et pratique

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 3

Examinons-en six :
1. Test et débogage
2. Tests fonctionnels et structurels
3. Concepteur vs testeur
4. Modularité (conception) vs efficacité
5. Programmation en SMALL Vs programmation en BIG
6. Acheteur vs constructeur
Tests et débogage
1. Les tests servent à trouver des bugs.
2. Le débogage consiste à trouver la cause ou l’idée fausse menant au bogue.
3. Leurs rôles sont confondus pour être les mêmes. Mais il existe des différences dans les
objectifs, les méthodes et
psychologie appliquée à ces
# Essai Débogage
1 Commence par des conditions connues. Utilise Commence avec des conditions initiales
une procédure prédéfinie. A des résultats potentiellement inconnues. La fin ne peut
prévisibles. être prédite.
2 Planifié, conçu et programmé. Les procédures et la durée ne sont pas
limitées.
3 Une démonstration d’une erreur ou d’une Un processus déductif.
exactitude
4 Prouve apparente.
le succès ou l’échec du programmeur. C'est la justification du programmeur.
5 Cela devrait être prévisible, ennuyeux, Il y a des sauts intuitifs, des conjectures, de
contraint, rigide et inhumain. l'expérimentation et de la liberté.
6 Une grande partie des tests peut être effectuée Impossible sans une connaissance détaillée
sans connaissances en conception. du design.
7 Peut être réalisé par une personne extérieure à Doit être effectué par un initié (équipe de
l’équipe de développement. développement).
8 Une théorie établit ce que les tests peuvent faire Il n'y a que des résultats rudimentaires (sur
ou ne pas faire. ce qui peut être fait). Le temps, l’effort, la
manière, etc. dépendent des capacités
humaines. – L’automatisation est un rêve.
9 L’exécution et la conception des tests peuvent Débogage
être automatisées.

Tests fonctionnels et structurels

Tests fonctionnels : traite un programme comme une boîte noire. Les sorties sont vérifiées pour
vérifier leur conformité aux spécifications du point de vue de l'utilisateur.
Tests structurels : examine les détails de mise en œuvre : style de programmation, méthode de
contrôle, langage source, base de données et détails de codage.
Intercalation des tests fonctionnels et structurels :
Un bon programme est construit en couches externes.
La couche extérieure est une fonction système pure du point de vue de l'utilisateur.
Chaque couche est une structure dont la couche externe est sa fonction.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 4

Exemples :

Pour un modèle de programmes donné, les tests structurels peuvent être effectués en premier,
puis les tests fonctionnels, ou vice-versa. Le choix dépend de ce qui semble être le choix
naturel.
Les deux sont utiles, ont des limites et ciblent différents types de bugs. Les tests fonctionnels
peuvent en principe détecter tous les bugs, mais prendraient un temps infini. Les tests
structurels sont intrinsèquement finis, mais ne peuvent pas détecter tous les bugs.
L'art des tests consiste à déterminer quel pourcentage d'allocation est destiné à la structure par
rapport au pourcentage destiné au fonctionnement.
Concepteur vs testeur
Complètement séparé dans les tests de boîte noire. Les tests unitaires peuvent être effectués par
l'un ou l'autre.
L’art des tests consiste à équilibrer la connaissance de la conception et de ses préjugés avec
l’ignorance et les inefficacités.

Les tests sont plus efficaces si le concepteur, le programmeur et le testeur sont indépendants
dans tous les tests unitaires, d'intégration d'unité, de composant, d'intégration de composant, de
système et de fonctionnalités formelles du système. La mesure dans laquelle le concepteur de
test et le programmeur sont séparés ou liés dépend du niveau de test et du contexte.

# Programmeur / Designer Testeur

1 Les tests conçus par les concepteurs sont Grâce à ses connaissances sur la conception de
davantage orientés vers les tests tests internes, le testeur peut éliminer les tests
structurels et se limitent à ses limites. inutiles, optimiser et réaliser une conception de
test efficace.
2 Il est probable que cela soit biaisé. Les tests conçus par des testeurs indépendants
sont exempts de biais.
3 Il essaie de faire le travail de la manière la Le testeur doit être méfiant, intransigeant, hostile
plus simple et la plus propre, en essayant et obsédé par la destruction du programme.
de réduire la complexité.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 5

Modularité (conception) vs efficacité

1. La conception du système et des tests peuvent toutes deux être modulaires.
2. Un module implique une taille, une structure interne et une interface, ou, en d'autres termes.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 6

3. Un module (composant discret bien défini d'un système) est constitué d'une complexité interne
et d'une complexité d'interface et a une taille.

# Modularité Efficacité
1 Plus le composant est petit, plus il est Implique un plus grand nombre de composants et
facile à comprendre. donc un plus grand nombre d'interfaces, ce qui
augmente la complexité et réduit l'efficacité (=>
plus de bugs probables)
2 Les petits composants/modules sont
répétables indépendamment avec moins de Efficacité supérieure au niveau du module,
retouches (pour vérifier si un bug est lorsqu'un bug survient avec de petits composants.
3 corrigé).
Les cas de test microscopiques nécessitent Un nombre plus élevé de cas de test implique une
des configurations individuelles avec des plus grande possibilité de bugs dans les cas de
données, des systèmes et le logiciel. Il test. Cela implique plus de retouches et donc
peut donc y avoir des bugs. moins d'efficacité avec des cas de test
microscopiques
4 Il est plus facile de concevoir de grands Moins complexe et efficace. (La conception peut
modules et des interfaces plus petites à un ne pas être suffisante pour comprendre et mettre
niveau supérieur. en œuvre. Il faudra peut-être le décomposer au
niveau de la mise en œuvre.)
Programmation en SMALL Vs programmation en BIG
Impact sur l'environnement de développement en raison du volume des exigences des clients
# Petit Grand
1 Cela se fait plus efficacement par des moyens Un grand nombre de programmeurs et un
informels, intuitifs et sans formalité – grand nombre de composants.
si cela est fait par 1 ou 2 personnes pour une
population d'utilisateurs petite et intelligente.
2 La taille du programme implique des effets
Fait pour par exemple, pour soi-même, pour son
non linéaires (sur la complexité, les bugs,
bureau ou pour l'institut.
l’effort, la qualité des retouches).
3 La couverture complète des tests est facilement Le niveau d'acceptation pourrait être : une
réalisable. couverture de test de 100 % pour les tests
unitaires et pour les tests globaux ≥ 80 %.

Acheteur vs constructeur (organisation client vs développeur)

Le fait que l’acheteur et le constructeur soient la même organisation brouille les pistes en matière de responsabilité.
Séparez-les pour clarifier la responsabilité, même s’ils font partie de la même organisation.
La responsabilité augmente la motivation pour la qualité.
Les rôles de toutes les parties impliquées sont les suivants :
Constructeur:
Les conceptions sont destinées à et sont responsables envers l'acheteur.
Acheteur:
Paie pour le système.
Espère tirer des bénéfices des services fournis à l'utilisateur.
Utilisateur:
Bénéficiaire ultime du système.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 7

Les intérêts sont protégés par le testeur.

Testeur:
Dédié à la destruction du s/w (constructeur)
Teste les logiciels dans l'intérêt de l'utilisateur/opérateur.
Opérateur:
Vit avec : Les erreurs du constructeur Caractéristiques obscures de
l'acheteur
Les oublis du testeur Plaintes des utilisateurs
Un modèle pour tester
Un modèle de test - avec un environnement de projet - avec des tests à différents niveaux.
(1) comprendre ce qu'est un projet.
(2) regardez les rôles des modèles de test.
1. Projet:
Un système archétypique (produit) permet des tests sans complications (même pour un grand projet).
Tester une routine unique et une routine utilisée très régulièrement est différent.
Un modèle de projet dans un monde réel se compose des 8 composants suivants :
1) Application : Un système en ligne en temps réel (avec des terminaux distants) fournissant des
réponses rapides aux demandes des utilisateurs (pour les services).
2) Personnel : Personnel de programmation de taille gérable avec des spécialistes en conception
de systèmes.
3) Calendrier : le projet peut prendre environ 24 mois du début à la fin. Période de maintenance
de 6 mois.
4) Spécifications : est bon. documenté. Les sans-papiers sont bien compris dans l'équipe.
5) Test d'acceptation : L'application est acceptée après un test d'acceptation formel. Au début, c'est
la responsabilité du client, puis celle de l'équipe de conception du logiciel.
6) Personnel : Le personnel technique comprend : Une combinaison de professionnels
expérimentés et de programmeurs juniors (1 à 3 ans) avec différents degrés de connaissance de
l'application.
7) Normes :
Norme de programmation, de test et d'interface (documentée et suivie).
Une base de données centralisée de normes est développée et administrée
8) Objectifs : (d'un projet)
On s’attend à ce qu’un système fonctionne de manière rentable pendant > 10 ans (après
l’installation).
Des systèmes similaires avec jusqu’à 75 % de code en commun pourraient être mis en
œuvre à l’avenir.
9) Source : (pour un nouveau projet) est une combinaison de
Nouveau code - jusqu'à 1/3
D'un système fiable antérieur - jusqu'à 1/3
Réhébergé depuis une autre langue et un autre système d'exploitation - jusqu'à 1/3
10) Historique : Généralement :
Les développeurs abandonnent avant que leurs composants ne soient testés.
Excellent travail mais peu documenté.
Des changements inattendus (majeurs et mineurs) de la part du client peuvent survenir

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 8

Des étapes importantes peuvent être franchies, mais la date de livraison est respectée.
Problèmes d’intégration, avec certains matériels, refonte de certains composants etc…..

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 9

Un projet modèle est

Un projet bien mené et réussi.
Combinaison de gloire et de catastrophe

2. Rôles des modèles pour les tests

1) Présentation générale :
■ Le processus de test commence avec un programme intégré dans un environnement.
■ La nature humaine de susceptibilité à l’erreur conduit à 3 modèles.
■ Créez des tests à partir de ces modèles et exécutez-les
Les résultats sont attendus ^ C'est bon
inattendu ^ Réviser les tests et le programme. Réviser le modèle de bogue et le programme.
2) Environnement : comprend
Tout le matériel et les logiciels (firmware, système d'exploitation, éditeur de liens, chargeur,
compilateur, utilitaires, bibliothèques) nécessaires à l'exécution du programme.
En général, les bugs ne résultent pas de l'environnement. (avec du matériel et des logiciels établis)
■ Mais cela découle de notre compréhension de l’environnement.
3)
Programme : Compliqué à comprendre en détail.
Traitez d'une vue d'ensemble simplifiée.
Concentrez-vous sur la structure de contrôle en ignorant le traitement et concentrez-vous sur le
traitement en ignorant la structure de contrôle.
■ Si le bogue n'est pas résolu, modifiez le modèle du programme pour inclure plus de faits, et si cela
échoue, modifiez le programme.
4) Bugs : (modèle de bug)
Catégorisez les bugs comme initialisation, séquence d'appel, variable erronée, etc.
Une spécification incorrecte peut nous amener à la confondre avec un bug de programme.
Il existe 9 hypothèses concernant les bugs.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 10

Hypothèse d'un insecte bénin :

1) La croyance que les insectes sont apprivoisés et logiques.
2) Les bugs faibles sont logiques et sont exposés par des moyens logiques.
3) Les insectes subtils n’ont pas de modèle définissable.
Hypothèse de la localisation des insectes :
4) Croyance selon laquelle les bugs sont localisés.
5) Des bugs subtils affectent ce composant et ceux qui lui sont externes.
Hypothèse de contrôle de dominance :
6) Croyance selon laquelle la plupart des erreurs se situent dans les structures de contrôle, mais
les erreurs de flux de données et de structure de données sont également courantes.
7) Les bugs subtils ne sont pas détectables uniquement via la structure de contrôle.
(bugs subtils => provenant de la violation des limites de la structure des données et de la séparation
données-code)
Hypothèse de séparation code/données :
■ Croyance que les bugs respectent la séparation du code et des données dans la programmation
HOL.
■ Dans les systèmes réels, la distinction est floue et c'est pourquoi de tels bugs existent.
Hypothèse Lingua Salvator Est :
■ Croyance que la syntaxe et la sémantique du langage éliminent la plupart des bugs.
■ Mais de telles fonctionnalités ne suffiront peut-être pas à éliminer les bugs subtils.
Corrections Hypothèse d'Abide :
■ Croyance qu’un bug corrigé reste corrigé.
■ Les bugs subtils ne le sont peut-être pas. Par exemple
Une correction dans une structure de données 'DS' en raison d'un bug dans l'interface entre les modules A
& B, pourrait avoir un impact sur le module C utilisant 'DS'.
Hypothèse des balles d’argent :
■ Croyance selon laquelle la langue, la méthode de conception, la représentation, l'environnement,
etc. offrent une immunité contre les bugs.
■ Pas pour les bugs subtils.
■ Souvenez-vous du paradoxe des pesticides.
Hypothèse : Le sadisme suffit
■ Croyance selon laquelle un côté sadique, un manque de ruse et d'intuition (par des testeurs
indépendants) suffisent à extirper la plupart des bugs.
■ Les bugs subtils et coriaces ne sont peut-être pas… – ils nécessitent une méthodologie et des
techniques. Hypothèse des testeurs angéliques :
Croyance selon laquelle les testeurs sont meilleurs dans la conception de tests que les programmeurs dans
la conception de code.
5) Essais
:■ Procédures formelles.
■ La préparation des entrées, la prédiction et l'observation des résultats, la documentation des tests,
l'exécution et l'observation des résultats sont sujettes à des erreurs.
■ Un résultat de test inattendu peut nous amener à réviser le test et le modèle de test.
Tests 6) et niveaux :
3 types de tests (avec des objectifs différents)

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 11

1) Tests unitaires et de composants

a. Une unité est le plus petit élément de logiciel qui peut être compilé/assemblé, lié, chargé et placé
sous le contrôle d'un harnais de test/pilote.
b. Tests unitaires : vérification de l'unité par rapport aux spécifications fonctionnelles et également de
l'implémentation par rapport à la structure de conception.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 12

c. Les problèmes révélés sont des bugs unitaires.

d. Un composant est un agrégat intégré d'une ou plusieurs unités (voire d'un système
entier)
e. Test des composants : vérification du composant par rapport aux spécifications
fonctionnelles et de la structure implémentée par rapport à la conception.
f. Les problèmes révélés sont des bugs de composants.
2) Tests d'intégration :
a. L'intégration est un processus d'agrégation de composants en composants plus grands.
b. Vérification de la cohérence des interactions dans la combinaison des composants.
c. Des exemples de tests d'intégration sont des séquences d'appel ou de retour incorrectes,

f. Séquence de tests :
Tests unitaires/composants pour A, B. Tests d'intégration pour A et B. Tests de
composants
des critères pour
de validation de données incohérents et une gestion incohérente des objets
de données.
d. Les tests d'intégration et les tests d'objets intégrés sont différents
Composante (A,B)
3) Tests du système

• Le système est un composant important.

• Concerne les problèmes et les comportements qui peuvent être testés au niveau de
l’ensemble ou d’une partie majeure du système intégré.
• Inclut les tests de performance, de sécurité, de responsabilité, de sensibilité de
configuration, de démarrage et de récupération
Après avoir compris un projet, un modèle de test, voyons maintenant enfin,
Rôle du modèle de test :

■ Utilisé pour le processus de test jusqu'à ce que le comportement du système soit correct ou
jusqu'à ce que le modèle soit insuffisant (pour les tests).
■ Des résultats inattendus peuvent forcer une révision du modèle.
■ L'art du test consiste à créer, sélectionner, explorer et réviser des modèles.
■ Le modèle doit pouvoir exprimer le programme.
Conséquences des bugs

Conséquences: (comment les bugs peuvent affecter les utilisateurs)

Ces effets varient de légers à catastrophiques sur une échelle de 10 points.
• Bénin
• Bug esthétique tel qu'une sortie mal orthographiée ou une impression mal alignée.
• Modéré
• Les résultats sont trompeurs ou redondants, ce qui affecte les performances.
• Ennuyeux
• Le comportement des systèmes est déshumanisant, par exemple lorsque les noms sont
tronqués/modifiés arbitrairement ou lorsque des factures de 0,0 $ sont envoyées.
• Jusqu'à ce que les bugs soient corrigés, les opérateurs doivent utiliser des séquences de

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 13

commandes non naturelles pour obtenir une réponse appropriée.

• Dérangeant
• Transactions légitimes refusées.
• Par exemple, un distributeur automatique de billets peut ne pas fonctionner correctement avec
une carte bancaire ou une carte de crédit.
• Sérieux
• Perdre la trace des transactions et des événements de transaction. La responsabilité est donc
perdue.
• Très grave
Le système effectue une autre transaction au lieu de celle demandée, par exemple créditer un autre
compte, convertir les retraits en dépôts.
• Extrême
• Fréquent et arbitraire – pas sporadique ni inhabituel.
• Intolérable
• Corruption irrécupérable à long terme de la base de données.
(pas facile à détecter et peut entraîner une panne du système.)
• Catastrophique
• Le système tombe en panne et s’arrête.
• Infectieux
• Corrompt d’autres systèmes, même s’il ne tombe pas en panne.

Attribution de la gravité
• Attribuez des valeurs flexibles et relatives plutôt qu'absolues au bogue (types).
• Le nombre de bugs et leur gravité sont des facteurs qui déterminent quantitativement la qualité.
• Les organisations conçoivent et utilisent des mesures quantitatives et de qualité basées sur les éléments
ci-dessus.
• Les pièces sont pondérées en fonction de l'environnement, de l'application, de la culture, du coût de
correction, de la phase SDLC actuelle et d'autres facteurs.
• Cauchemars
• Définir les cauchemars – qui pourraient survenir à cause des bugs – dans le contexte de
l’organisation/de l’application.
• Les cauchemars quantifiés aident à calculer l’importance des bugs.
• Cela aide à prendre une décision sur le moment où arrêter les tests et publier le produit.
Quand arrêter les tests
1. Énumérez tous les cauchemars en fonction des symptômes et des réactions de l’utilisateur à leurs
conséquences.
2. Convertir les conséquences en un coût. Il pourrait y avoir des coûts de reprise (mais si la portée
s’étend au public, il pourrait y avoir des coûts de poursuites judiciaires, des pertes commerciales, des
fusions de réacteurs nucléaires).
3. Commandez-les du plus cher au moins cher. Jetez ceux avec lesquels vous pouvez vivre.
4. Sur la base de l'expérience, des données mesurées, de l'intuition et des statistiques publiées, on postule
le type de bugs à l'origine de chaque symptôme. C'est ce qu'on appelle le « processus de conception
des bugs ». Un type de bogue peut provoquer plusieurs symptômes.
5. Classez les bugs responsables par probabilité décroissante (jugée par l'intuition, l'expérience, les
statistiques, etc.). Calculez l'importance d'un type de bug comme :

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 14

Importance du type de bogue j = 2 C P jk jk où,

tous les k
C jk = coût dû au type de bogue j provoquant le cauchemar k
P jk = probabilité que le type de bogue j provoque le cauchemar k
(Coût dû à tous les types de bugs = ∑ ∑ C jk P jk )
tous k tous j
6. Classez les types de bugs par ordre d’importance décroissante.
7. Tests de conception et processus d'inspection QA les plus efficaces contre les bugs les plus importants.
8. Si un test est réussi ou lorsqu'une correction est effectuée pour un test échoué, certains cauchemars
disparaissent. Au fur et à mesure que les tests progressent, révisez la liste des probabilités et des
cauchemars ainsi que la stratégie de test.
9. Arrêtez les tests lorsque la probabilité (importance et coût) s’avère sans importance.
Cette procédure pourrait être implémentée formellement dans le SDLC.
Points importants à noter :
• Concevoir un nombre raisonnable et fini de tests avec une forte probabilité d’éliminer les cauchemars.
• Les suites de tests s'usent.
• À mesure que les programmeurs améliorent leur style de programmation, l’assurance qualité
s’améliore.
• Par conséquent, connaissez et mettez à jour les suites de tests selon les besoins.
Taxonomie des insectes
nous avions vu le:
1. Importance des bugs – quantification statistique de l'impact
2. Conséquences des bugs – causes, cauchemars, arrêt des tests
Nous allons maintenant voir le :
3. Taxonomie des insectes – avec quelques remèdes
Afin de pouvoir créer son propre modèle d'importance des bogues pour une organisation dans le but
de contrôler les coûts associés…
■ Pourquoi la taxonomie ?
Étudier les conséquences, les cauchemars, la probabilité, l’importance, l’impact et les méthodes de prévention
et de correction.
■ Adoptez une taxonomie connue pour l’utiliser comme cadre statistique sur lequel votre stratégie de
■ test est basée.
1. 6 catégories principales avec sous-catégories.
2. Exigences, fonctionnalités, fonctionnalités Bugs 24,3 % de bugs
3. Bugs structurels 25.2%
4. Bogues de données 22.3%
5. Bugs de codage 9.0%
6. Interface, intégration et bugs système 10.7%
Bugs de test et de conception de test 2.8 %

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 15

1) Exigences, fonctionnalités, bugs de

fonctionnalités3 types de bugs : bugs liés aux exigences et spécifications, bugs liés aux
J fonctionnalités et aux interactions avec les fonctionnalités. Bugs liés aux
E exigences et spécifications.
■ Incomplétude, ambiguïté ou contradiction
■ Hypothèses de l'analyste inconnues du concepteur
■ Il se peut que quelque chose manque lorsque les spécifications changent
II. Bugs ■ deCeux-ci sont coûteux : introduits au début du SDLC et supprimés à la
■ Les problèmes de spécifications créent des bugs de fonctionnalités
fonctionnalit
Un bug de fonctionnalité erroné a des conséquences sur la conception
■ La fonctionnalité manquante est facile à détecter et à corriger
Les améliorations gratuites peuvent accumuler des bugs, si elles
■ augmentent la complexité
La suppression
111. Bugs d'interaction de fonctionnalités peut favoriser les bugs
des fonctionnalités
■ Ils surviennent en raison d'interactions imprévisibles entre des groupes de fonctionnalités
ou des fonctionnalités individuelles. Plus tôt on les élimine, mieux c'est, car ils sont
coûteux s'ils sont détectés à la fin.
■ Exemples : transfert d’appel et appel en attente. Lois fiscales fédérales, étatiques et
locales.
■ Pas de remède magique. Énoncez et testez explicitement les combinaisons importantes
Remèdes
■
Utiliser des langages de spécification formels de haut niveau pour éliminer la
communication interhumaine
■
Il s'agit uniquement d'un soutien à court terme et non d'une solution à long terme
■
Assistance à court terme :
■ Les langages de spécification formalisent les exigences et permettent ainsi une
génération automatique de tests. C'est rentable.
■ Accompagnement à long terme :
■ Même avec un excellent langage de spécification, le problème n’est pas éliminé,
mais est déplacé à un niveau supérieur. Seules les ambiguïtés et contradictions
simples peuvent être supprimées, laissant place à des bugs plus tenaces.
Techniques de test
■ Les techniques de test fonctionnel (tests de flux de transaction, tests de syntaxe, tests de
domaine, tests logiques et tests d'état) peuvent éliminer les bogues liés aux exigences et
aux spécifications.
2) Bugs structurels

nous examinons les 5 types, leurs causes et leurs remèdes.

I. Bugs de contrôle et de séquence
II. Bugs logiques
III. Traitement des bugs
IV. Bugs d'initialisation
V. Bugs et anomalies de flux de données
I. Bugs de contrôle et de séquence :
> Chemins laissés de côté, code inaccessible, code spaghetti et code pachinko.
> Imbrication incorrecte des boucles, terminaison de boucle ou retour en arrière incorrect,
commutateurs mal conçus.
> Étapes de processus manquantes, traitement dupliqué ou inutile, GOTO incessants.
> Programmeurs novices.

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 16

> Ancien code (langage assembleur et Cobol) , X

Prévention et contrôle :
> Traitement théorique et,
> Tests unitaires, structurels, de chemin et fonctionnels. T
II. Bugs logiques
> Incompréhension de la sémantique des structures de contrôle et des opérateurs logiques
> Mauvaise disposition des cas, y compris les cas impossibles et les cas nécessaires
ignorés,
> Utilisation d'un opérateur similaire, simplification incorrecte, confusion entre Ex-OR et
OR inclusif.
> Instructions conditionnelles profondément imbriquées et utilisant de nombreuses
opérations logiques dans 1 instruction.
Prévention et contrôle :
Tests logiques, contrôles minutieux, tests fonctionnels
III. Traitement des bogues
■ Arithmétique, algébrique, évaluation de fonctions mathématiques, sélection
d'algorithmes et traitement général, conversion de type de données, ignorance des
débordements, utilisation incorrecte des opérateurs relationnels.
Prévention
■ Pris dans les tests unitaires et n'ayant qu'un effet localisé
■ Méthodes de test de domaine
IV. Bugs d'initialisation
> Oublier d'initialiser l'espace de travail, les registres ou les zones de données.
> Valeur initiale incorrecte d'un paramètre de contrôle de boucle.
> Accepter un paramètre sans contrôle de validation.
> Initialiser avec un type ou un format de données incorrect.
> Très commun.
Remèdes (prévention et correction)
> Outils de programmation, déclaration explicite et vérification de type dans le langage
source, préprocesseurs.
> Les méthodes de test de flux de données aident à la conception des tests et au
débogage.
V. Bugs et anomalies de flux de données
> Rencontrez une variable non initialisée.
> Ne pas stocker les données modifiées.
> Réinitialisation sans utilisation intermédiaire.
> Détecté principalement par l'exécution (test).
Remèdes (prévention et correction)
Méthodes de test de flux de données et méthodes de test basées sur des matrices
3. Bogues de données
Cela dépend des types de données ou de la représentation des données. Il existe 4 sous-catégories.
I. Bugs de données génériques
II. Données dynamiques vs données statiques
III. Bugs d'information, de paramètres et de contrôle
IV. Bugs liés au contenu, à la structure et aux attributs
I. Bugs de données génériques
■ En raison des spécifications des objets de données, des formats, du nombre d'objets et de leurs
valeurs initiales.

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 17

■ Aussi courant que dans le code, en particulier lorsque le code migre vers les données.
■ Le bogue de données introduit un bogue d'instruction opérationnelle et est plus difficile à
trouver.
■ Composants généralisés avec réutilisabilité – lors de la personnalisation à partir de données
paramétriques volumineuses vers une installation spécifique.
Remèdes (prévention et correction) :
■ L'utilisation de tables de contrôle au lieu de code permet au logiciel de gérer de nombreux
types de transactions avec moins de bogues de données. Les tables de contrôle ont un langage
de programmation caché dans la base de données.
Attention - il n'y a pas de compilateur pour le langage de contrôle caché dans les tables de
données
II. Données dynamiques vs données statiques
Bogues de données dynamiques Bugs de données statiques
Transitoire. Difficile à attraper. Fixé dans la forme et le contenu.
En raison d'une erreur dans l'initialisation d'un objet de Apparaître dans le code source ou la base de données,
stockage partagé. directement ou indirectement
En raison de déchets impurs/restants dans une ressource Un logiciel de production de code objet crée une table de
partagée. données statique – des bugs sont possibles
Exemples Exemples
Variable générique et partagée Logiciel système de télécommunication : paramètres
génériques, un grand programme générique et un
programme adaptateur de site pour définir les valeurs des
paramètres,
Postprocesseurcréer des déclarations
: pour installer des de données,
packages etc.
logiciels.
Structure de données partagée
Les données
initialisé sont
au moment de l'exécution – avec une
configuration gérée par des tables.
Prévention Prévention
Validation des données, tests unitaires Traitement du temps de compilation Fonctionnalités du
langage source
III. Bugs d'information, de paramètres et de contrôle
Les données statiques ou dynamiques peuvent se présenter sous l’une des trois formes. C'est une
question de perspective.
Ce qui est information peut être un paramètre de données ou des données de contrôle ailleurs dans un
programme.
Exemples : nom, code de hachage, fonction les utilisant. Une variable dans différents contextes.
> Information : dynamique, locale à une transaction ou tâche unique.
> Paramètre : paramètres passés à un appel.
> Contrôle : données utilisées dans une structure de contrôle pour une décision.
Insectes
> Des bugs généralement simples et faciles à attraper.
> Lorsqu'une sous-routine (avec un bon code de validation des données) est modifiée, l'oubli de
mettre à jour le code de validation des données entraîne ces bogues.
Mesures préventives (prévention et correction)
> Code de validation des données approprié.
IV . Bugs liés au contenu, à la structure et aux attributs
■ Contenu : il s'agit de modèles de bits purs et les bugs sont dus à une mauvaise
interprétation ou à une corruption de ceux-ci.
■ Structure : taille, forme et alignement de l'objet de données en mémoire. Une structure

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 18

peut avoir des sous-structures.

■ Attributs : Sémantique associée au contenu (par exemple, entier, chaîne, sous-routine).
Insectes
■ La gravité et la subtilité augmentent du contenu aux attributs à mesure qu'ils
deviennent moins formels.
■ Les bugs structurels peuvent être dus à une déclaration erronée ou lorsque le même
contenu est interprété différemment par plusieurs structures (mappage différent).
■ Les bugs d'attribut sont dus à une mauvaise interprétation du type de données,
probablement au niveau d'une interface
Mesures préventives (prévention et correction)
■ Bonne documentation sur la langue source et bon style de codage (y compris le
dictionnaire de données).
■ Les structures de données doivent être administrées globalement. Les données locales
migrent vers le global.
■ Les langages fortement typés empêchent la manipulation mixte des données.
■ Dans un programme en langage assembleur, utilisez des macros d'accès aux champs et
n'accédez pas directement à aucun champ.
4. Bugs de codage
> Les erreurs de codage créent d’autres types de bugs.
> Les erreurs de syntaxe sont supprimées lorsque le compilateur vérifie la syntaxe.
> Erreurs de codage
typographique, mauvaise compréhension des opérateurs ou des instructions ou cela
pourrait être simplement arbitraire.
> Bugs de documentation
> Des commentaires erronés pourraient conduire à une maintenance incorrecte.
> Les techniques de test ne peuvent pas éliminer les bugs de documentation.
Solution:
Inspections, assurance qualité, dictionnaires de données automatisés et systèmes de
spécifications.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 19

5. Bugs d'interface, d'intégration et de systèmes

Il existe 9 types de bugs de ce type.
Interfaces externes
1.
Interfaces internes
2.
Bugs d'architecture matérielle
Bugs du système d'exploitation
3.
Bugs d'architecture logicielle
Bugs de contrôle et de séquence
4.
Bugs de gestion des ressources
Bugs d'intégration
5.
Bugs système
Interfaces externes
6.
Moyens de communication avec le monde : pilotes, capteurs, terminaux d'entrée, lignes de
communication.
Le critère de conception principal devrait être la robustesse.

❖ Bugs : timing invalide, hypothèses de séquence liées à des signaux externes, mauvaise compréhension des
formats externes
et aucun codage robuste.
❖ Les tests de domaine, les tests de syntaxe et les tests d'état sont adaptés aux tests d'interfaces externes.
b) Interfaces internes
❖ Doit s'adapter à l'interface externe.
❖ Avoir des bugs similaires à l'interface externe
❖ Bugs provenant d'une mauvaise utilisation
❖ Conception de protocole, formats d'entrée-sortie, protection contre les données corrompues, séquence
d'appel de sous-routine, appel-
paramètres.
Remèdes (prévention et correction) :
❖ Méthodes de test de domaine et de test de syntaxe.
❖ Bonne conception et normes : bon compromis entre le nombre d'interfaces internes et la complexité de
l'interface.
❖ Un bon test d’intégration consiste à tester toutes les interfaces internes avec le monde extérieur.
c) Bugs d'architecture matérielle :
❖ Un programmeur logiciel peut ne pas voir la couche matérielle / l'architecture.
❖ Les bugs logiciels provenant de l'architecture matérielle sont dus à une mauvaise compréhension du
fonctionnement du matériel.
❖ Les bugs sont dus à des erreurs dans :
V Mécanisme de pagination, génération d'adresses
Instructions du périphérique VI/O, code d'état du périphérique, protocole du périphérique
V S'attendre à ce qu'un périphérique réponde trop rapidement ou attendre trop longtemps une réponse,
en supposant qu'un périphérique est initialisé, gestion des interruptions, adresse du périphérique
d'E/S
Hypothèse de simultanéité VH/W, condition de concurrence H/W ignorée, erreur de format de données
de périphérique, etc.
❖ Remèdes (prévention et correction) :
o Bonne programmation et tests de logiciels.
o Centralisation des logiciels d'interface H/W.
o De nos jours, le matériel dispose de modes de test et d'instructions de test spéciaux pour tester la
fonction H/W. o Un simulateur H/W élaboré peut également être utilisé.
d) Bogues du système d'exploitation :
❖ En raison de:
V Incompréhension de l'architecture matérielle et de l'interface par le système d'exploitation

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 20

V Non-gestion de tous les problèmes matériels par le système d'exploitation

Des bugs dans le système d'exploitation lui-même et certaines corrections peuvent laisser des
bizarreries.
Des bugs et des limitations du système d'exploitation peuvent être cachés quelque part dans la
documentation.
❖ Remèdes (prévention et correction) :
• Mêmes que ceux pour les bugs matériels.

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 21

V Utiliser les spécialistes de l'interface du système d'exploitation

V Utilisez des modules d’interface explicites ou des macros pour tous les appels du système
d’exploitation.
V Ce qui précède peut localiser les bugs et simplifier les tests.
e) Bugs d'architecture logicielle : (appelés interactifs)
Les sous-routines passent par des tests unitaires et d'intégration sans détection de ces bugs. Cela
dépend de la charge lorsque le système est sollicité. Ce sont les plus difficiles à trouver et à corriger.
> En raison de :
V Hypothèse qu’il n’y a pas d’interruptions, ou, échec de blocage ou de déblocage d’une
interruption.
V Hypothèse selon laquelle le code est réentrant ou non réentrant.
V Contournement des verrouillages de données, ou, échec d'ouverture d'un verrouillage.
V Hypothèse selon laquelle une routine appelée réside en mémoire ou non.
V Hypothèse que les registres et la mémoire sont initialisés, ou que leur contenu n'a pas changé.
V Réglage local des paramètres globaux & Réglage global des paramètres locaux.
>Remèdes :
V Bonne conception pour l'architecture logicielle.
> Techniques d'essai
V Toutes les techniques de test sont utiles pour détecter ces bugs, les tests de stress en particulier.
f) Bugs de contrôle et de séquence :
❖ En raison de :
V Horaire ignoré
V Hypothèse selon laquelle les événements se produisent dans une séquence spécifiée.
V Démarrer un processus avant que ses prérequis ne soient remplis.
V En attente d’une combinaison impossible de conditions préalables.
V Ne pas reconnaître quand les conditions préalables sont remplies.
V Spécification d'une priorité, d'un état du programme ou d'un niveau de traitement incorrect.
V Étapes de processus manquantes, erronées, redondantes ou superflues.
>Remèdes :
V Bon design.
V contrôle de séquence hautement structuré - utile
V Mécanismes de contrôle de séquence interne spécialisés tels qu'un langage de contrôle de tâches
interne - utiles.
V Stockage des étapes de séquence et des prérequis dans une table et traitement interprétatif par le
processeur de contrôle ou le répartiteur - plus facile à tester et à corriger les bugs.
V Techniques de test
Les tests de chemin appliqués aux graphiques de flux de transaction sont efficaces.
g) Problèmes de gestion des ressources :
> Ressources : Internes : tampons de mémoire, blocs de file d'attente, etc. Externe : disques etc.
> En raison de:
V Mauvaise ressource utilisée (lorsque plusieurs ressources ont une structure similaire ou des types de
ressources différents dans le même pool).
V Ressource déjà utilisée ou blocage
V Ressource non renvoyée au bon pool, Échec du renvoi d'une ressource. Utilisation des ressources
interdite à l'appelant.
>Remèdes :
V Conception : conserver une structure de ressources simple avec le moins de types de ressources, le
moins de pools possible et aucune gestion de ressources privées.
V Concevoir une structure de ressources complexe pour gérer toutes sortes de transactions afin
d’économiser de la mémoire n’est pas une bonne idée.
V Centralisez la gestion de tous les pools de ressources via des gestionnaires, des sous-routines, des

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 22

macros, etc.
> Techniques d'essai
• Tests de chemin, tests de flux de transactions, tests de flux de données et tests de stress.
h) Bugs d'intégration :
Ils sont détectés tardivement dans le SDLC et provoquent des dysfonctionnements sur plusieurs
composants et sont donc très coûteux.
> En raison de:
V Incohérences ou incompatibilités entre les composants.
V Erreur dans une méthode utilisée pour transférer directement ou indirectement des données
entre des composants. Certaines méthodes de communication sont : les structures de données,
les séquences d'appel, les registres, les sémaphores, les liens de communication, les protocoles,
etc.
> Remèdes :
V Utiliser de bonnes stratégies d’intégration.
> Techniques de test
V Ceux destinés aux interfaces, aux tests de domaine, aux tests de syntaxe et aux tests de flux de
données lorsqu'ils sont appliqués à plusieurs composants.
i) Bugs système :
Peu fréquents, mais coûteux
> En raison de :
Les bogues V ne sont pas attribués à un composant particulier, mais résultent de la totalité des
interactions entre de nombreux composants tels que :
programmes, données, matériel et système d'exploitation
>Remèdes :
V Des tests approfondis à tous les niveaux et les techniques de test mentionnées ci-dessous
> Techniques d'essai
V Tests de flux de transactions.
V Tous les types de tests à tous les niveaux ainsi que les tests d'intégration sont utiles.
6. Bugs de test et de conception de test
Les bugs dans les tests (scripts ou processus) ne sont pas des bugs logiciels.
Il est difficile et prend du temps d'identifier si un bug provient du logiciel ou du script/de la procédure de test.
1) Les bugs peuvent être dus à :
> Les tests nécessitent du code qui utilise des scénarios et des bases de données complexes pour être
exécutés.
Bien qu'un test fonctionnel indépendant fournisse un point de vue impartial, ce manque de partialité peut
conduire à une interprétation incorrecte des spécifications.
> Critères de test
Le processus de test est correct, mais le critère permettant d'évaluer la réponse du logiciel aux tests
est incorrect ou impossible.
V Si un critère est quantitatif (débit ou temps de traitement), le test de mesure peut perturber la valeur
réelle.
> Remèdes :
i. Débogage des tests :
Tests et débogage de tests, scripts de test, etc. Plus simple lorsque les tests ont un effet localisé.
ii. Assurance qualité des tests :
Surveiller la qualité des tests indépendants et de la conception des tests.
iii. Automatisation de l'exécution des tests :
Les bugs d’exécution des tests sont éliminés par des outils d’automatisation de l’exécution des tests
et non par des tests manuels.
iv. Automatisation de la conception des tests :
La conception des tests est automatisée comme l’automatisation du développement de logiciels.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 23

Pour un taux de productivité donné, il réduit le nombre de bugs.

Unité II
Graphiques de flux et tests de chemin
Notions de base : définition des tests de chemin
Une famille de techniques de tests structurels basées sur la sélection judicieuse d'un ensemble de chemins de
test à travers les programmes.
V Objectif : Choisir suffisamment de chemins pour garantir que chaque instruction source soit exécutée au
moins une fois.
{ Il s'agit d'une mesure de l'exhaustivité de la couverture du code (pendant les tests unitaires : # états
exécutés au moins une fois / # états au total).
V Il est principalement utilisé pour les tests unitaires sur les nouveaux logiciels.
V Son efficacité diminue à mesure que la taille du logiciel augmente.
V Nous utilisons les techniques de test de chemin de manière indirecte.
V Les concepts de test de chemin sont utilisés dans et avec d'autres techniques de test
Hypothèses
V Le logiciel emprunte un chemin différent de celui prévu en raison d'une erreur.
V Les spécifications sont correctes et réalisables.
V Les bogues de traitement se trouvent uniquement dans les instructions de flux de contrôle
V La définition et l'accès aux données sont corrects
Observations
V Les langages de programmation structurés nécessitent moins de tests de chemin.
• Le langage assembleur, Cobol, Fortran, Basic et les langages similaires rendent les tests de chemin
nécessaires.
Graphique de flux de contrôle
VA Représentation simplifiée, abstraite et graphique de la structure de contrôle d'un programme utilisant
des blocs de processus, des décisions et des jonctions.

Bloc de processus :
Séquence VA d'instructions de programme ininterrompues par des décisions ou des jonctions avec une
seule entrée et une seule sortie.
Jonction:
Point VA dans le programme où le flux de contrôle peut fusionner (dans un nœud du graphique)

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 24

V Exemples : cible de GOTO, Jump, Continue

Décisions :
Point du programme VA auquel le flux de contrôle peut diverger (en fonction de l'évaluation d'une
condition).

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 25

V Exemples : IF stmt. Branchement conditionnel et instruction Jump.

Déclarations de cas :
V Une branche ou une décision multidirectionnelle.
V Exemples : En langage assembleur : table d'adresses de saut, GOTO multiples, Case/Switch. Pour la
conception de tests, l'instruction Case et la décision sont similaires.
Graphique de flux de contrôle vs organigrammes
Graphique de flux de contrôle Organigramme
Représentation compacte du programme Habituellement une description de plusieurs pages

Se concentre sur les entrées, les sorties et le flux de Se concentre sur les étapes du processus à l'intérieur
contrôle entrant et sortant du bloc.
Les détails internes d'un bloc de processus ne sont pas Chaque partie du bloc de processus est dessinée
affichés
Création d'un graphe de flux de contrôle à partir d'un programme
V Traduction d'une instruction en un élément pour obtenir un organigramme classique
V Ajoutez des étiquettes supplémentaires si nécessaire
V Étapes du processus de fusion
V Une boîte de processus est impliquée à chaque jonction et décision
V Supprimer les étiquettes externes
V Représenter le contenu des éléments par des nombres.
• Nous avons maintenant des nœuds et des liens

Traduction d'une instruction en un élément pour obtenir un organigramme classique

ENTRÉE X,
ENTRÉE XY V := X - Y
YZ := X + Y
V := X - Y
SI Z >= 0 ALLER À
N := 0 Z := Z - V
JOE : Z := Z + V
SAM
SAM : Z := Z - V
POUR N = 0 À V
Z := Z - 1
SUIVANT N
FIN

Étapes du processus de
fusion
ENTRÉE X, Y
Z := X + Y
V := X - Y
SI Z >= 0 ALLER À
SAM JOE : Z := Z + V SAM :
Z := Z - V
POUR N = 0 À V
Z := Z - 1
SUIVANT N FIN

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 26

Une boîte de processus est impliquée sur chaque jonction et décision, supprimez les étiquettes
externes, représentez le contenu des éléments par des nombres.
ENTRÉE X, Y
Z := X + Y
V := X - Y
SI Z >= 0 ALLER À
SAM
JOE : Z := Z + V
SAM: Z := Z - V
POUR N = 0 À V
SUIVANT N
FIN
Notation de liste chaînée d'un graphe de flux de contrôle
Traitement des nœuds, étiquette, décision Nœud suivant
1 (DÉBUT; ENTRÉE X, Y; Z := X+Y ; V := XY) : 2
2 ( Z >= 0 ? ) : 4 (VRAI)
: 3 (FAUX)
3 (JOE : Z := Z + V) :4
4 (SAM : Z := Z – V ; N := 0) 5
5 (BOUCLE; Z := Z -1) 6
6 (N = V ?) :7 (FAUX)
: FIN (VRAI)
7 (N := N + 1) :
5
Concepts de test de chemin
1. Le chemin est une séquence d'instructions commençant à une entrée, une jonction ou une décision et se
terminant à une autre, ou éventuellement à la même jonction ou décision ou à un point de sortie.
Le lien est un processus unique (bloc) entre deux nœuds.
Un nœud est une jonction ou une décision.
Un segment est une séquence de liens. Un chemin est constitué de plusieurs segments.
Un segment de chemin est une succession de liens consécutifs appartenant au même chemin. (3,4,5)
La longueur d'un chemin est mesurée par le nombre de liens dans le chemin ou par le nombre de nœuds
traversés.
Le nom d'un chemin est l'ensemble des noms des nœuds le long du chemin. (1,2,3 4,5, 6)
(1,2,3,4, 5,6,7, 5,6,7, 5,6)
Test de chemin Le chemin est un chemin « d'entrée à sortie » à travers un bloc de traitement.
2. Entrée / Sortie pour une routine, des blocs de processus et des nœuds.
Les routines à entrée unique et à sortie unique sont préférables.
Appelées routines bien formées.
Il existe une base formelle pour les tests.
Les outils pourraient générer des cas de test.
Routines à entrées multiples / sorties multiples : (mal formées)
• Une approche faible : par conséquent, convertissez-la en une routine à entrée unique / sortie
unique.
• Problèmes d’intégration :
Grand nombre d'interfaces interprocessus. Crée des problèmes d'intégration.
Il y a plus de cas de test et un traitement formel est également plus difficile.
• Questions théoriques et outils
• Il n’existe pas de bonne base formelle.
• Les outils peuvent ne pas parvenir à générer des cas de test importants.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 27

Convertir une routine à entrées/sorties multiples en une routine à entrée/sortie unique :

V Utiliser un paramètre d'entrée et une instruction case à l'entrée => entrée unique

V Fusionner toutes les sorties en un point de sortie unique après avoir défini un
paramètre de sortie sur une valeur.

Cas
Stratégie de test pour les routines à entrées/sorties multiples
V Débarrassez-vous d'eux.
V Contrôlez ceux dont vous ne pouvez pas vous débarrasser.
V Convertir en routines d'entrée/sortie uniques.
V Effectuez des tests unitaires en traitant chaque combinaison entrée/sortie comme s’il s’agissait d’une
routine complètement différente.
V Reconnaître que les tests d’intégration sont plus lourds
V Comprendre les stratégies et les hypothèses des générateurs de tests automatiques et confirmer qu’ils
fonctionnent (ou non) pour les routines à entrées multiples/sorties multiples.
3. Critères fondamentaux de sélection du chemin
Un ensemble minimal de chemins pour pouvoir effectuer des tests complets.
V Chaque passage dans une routine, de l'entrée à la sortie, à mesure qu'on la parcourt, est un chemin potentiel.
V Ce qui précède inclut le traçage de 1 à n fois le traçage d'un bloc interactif séparément.
Remarque : un bogue pourrait rendre un chemin obligatoire non exécutable ou créer de nouveaux chemins non
liés au traitement.
Prescriptions complètes de tests de parcours :
1. Exercez-vous sur tous les chemins, de l’entrée à la sortie.
2. Exercez chaque affirmation ou instruction au moins une fois.
3. Exercez chaque branche et chaque instruction de cas dans chaque direction, au moins une fois.
♦ Point 1 => point 2 et 3. ♦ Les points 2 et 3 ne sont pas identiques
♦ Le point 1 n’est pas pratique. ♦ Pour un langage structuré, Point 3 => Point 2
Critères de test de chemin :
1. Test de chemin (Pg) :
Exécutez tous les chemins de contrôle de flux possibles à travers le programme ; mais généralement
limités aux chemins d'entrée-sortie.
Implique une couverture du chemin à 100 %. Impossible à réaliser.
2. Test d'énoncé (P1) :
Exécutez toutes les instructions du programme au moins une fois sous le même test.
100 % de couverture des déclarations => 100 % de couverture des nœuds.

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 28

Désigné par C1
C1 est une exigence de test minimale dans la norme de test unitaire IEEE : ANSI 87B.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 29

3. Test de branche (P2) :

Exécutez suffisamment de tests pour garantir que chaque alternative de branche a été exercée au moins
une fois lors d’un test.
Désigné par C2
Objectif : couverture de 100 % des succursales et couverture de 100 % des liens.
Pour un logiciel bien structuré, les tests et la couverture des branches incluent la couverture des
instructions
Choisir suffisamment (le moins) de chemins pour atteindre les niveaux C1+C2
1. Est-ce que chaque décision a Y et N (C2) ?
2. Les cas d'appel d'énoncé de cas sont-ils marqués
(C2) ? Chemins Décisions Lien de processus
3. Est-ce que toutes les branches à trois voies sont
couvertes (C2) ? 2 5 un b c d et f g
4. Est-ce que chaque lien est couvert au moins une abdeg Y Y Y Y Y Y Y
fois (C1) ?
Apportez de petits changements au chemin en acdeg Non Y Y Y Y Y Y
changeant uniquement abdefeg Y N Y Y Y Y Y Y
1 lien ou nœud à la fois.
Règles révisées de sélection de chemin acdefeg Non Y Y Y Y Y Y Y
1. Choisissez le chemin d'entrée/sortie le plus
simple et le plus judicieux sur le plan fonctionnel
3. Choisissez des chemins supplémentaires mais sans signification fonctionnelle évidente (uniquement pour
atteindre la couverture C1+C2).
4. Soyez à l'aise avec les chemins choisis. Jouez avec vos intuitions, utilisez votre intuition pour atteindre les
niveaux C1+C2
5. Ne suivez pas les règles à la lettre, sauf en ce qui concerne la couverture
4. Test des chemins impliquant des boucles
Les bugs dans les instructions itératives ne semblent pas être découverts par C1+C2.
Mais en testant aux limites de la variable de boucle.
Types d'énoncés itératifs
1. Instruction à boucle unique.
2. Boucles imbriquées.
3. Boucles concaténées.
4. Boucles horribles
Notons le nombre minimum d'itérations par nmin, le nombre maximum d'itérations par nmax, la valeur de la
variable de contrôle de boucle par V, le nombre de cas de test par T, le nombre
d'itérations effectuées par n
• Plus tard, nous analysons les temps de test en boucle

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 30

1. Test d'une instruction de boucle unique (trois cas)

Cas 1. nmin = 0, nmax = N, aucune valeur exclue

1. Contourner la boucle.
Si vous ne pouvez pas, il y a un bug, nmin ≠ 0 ou une mauvaise casse.
2. La valeur de la variable de boucle (de contrôle) V
pourrait-elle être négative ? pourrait-elle sembler spécifier
un –ve n ?
3. Essayez un passage dans l'instruction de boucle : n = 1
4. Essayez deux passages dans l'instruction de boucle : n =
2
Pour détecter les anomalies du flux de données
d’initialisation :
Variable définie et non utilisée dans la boucle, ou initialisée dans la boucle et utilisée en
dehors de la boucle.
5. Essayez n = nombre typique d'itérations : nmin < n < nmax
6. Essayez n = nmax -1
7. Essayez n = nmax
8. Essayez n = nmax + 1.
Qu'est-ce qui empêche V (& n) d'avoir cette valeur ?
Que se passe-t-il si c'est forcé ?
Cas 2. nmin = +ve, nmax = N, aucune valeur exclue

1. Essayez nmin - 1
La valeur de la variable de boucle (de contrôle) V pourrait-elle être < nmin Qu'est-ce qui empêche
cela ?
2. Essayez nmin
3. Essayez nmin + 1
4. Une fois, sauf si couvert par un test précédent.
5. Deux fois, sauf si couvert par un test précédent.
4. Essayez n = nombre typique d'itérations : nmin < n < nmax
5. Essayez n = nmax -1
6. Essayez n = nmax
7. Essayez n = nmax + 1.
Qu'est-ce qui empêche V (& n) d'avoir cette valeur ?
Que se passe-t-il si c'est forcé ?
Cas 3. Boucle unique avec valeurs exclues
1. Traitez cela comme des boucles simples avec des valeurs exclues sous forme de deux ensembles.
2. Exemple:
V = 1 à 20 excluant 7,8,9 et 10
Les cas de test à tenter sont pour :
V = 0,1,2,4,6,7 et V = 10,11,15,19,20,21
(les majuscules soulignées ne sont pas censées fonctionner)
2. Test d'une instruction de boucle imbriquée
V Multiplier le nombre de tests pour chaque boucle imbriquée =>
très grand nombre de tests
V Une technique de sélection de test :
1. Commencez par la boucle la plus intérieure. Définissez toutes les boucles externes sur les valeurs de
paramètres d'itération minimales : Vmin.
2. Testez le Vmin, Vmin + 1, V typique, Vmax - 1, Vmax pour la boucle la plus intérieure. Maintenez les

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 31

boucles extérieures pour

Vmin. Des tests d'extension sont nécessaires pour les valeurs hors limites et exclues.
3. Si vous avez terminé avec la boucle la plus extérieure, passez à l’étape 5. Sinon, sortez d'une boucle
et effectuez l'étape 2 avec toutes les
d'autres boucles définies sur des valeurs typiques.
4. Effectuez les cinq cas pour toutes les boucles du nid simultanément.
• Devoir : vérifier le nombre de cas de test = 12 pour l'imbrication = 2, 16 pour 3, 19 pour 4.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 32

V Compromis sur # cas de test pour le temps de traitement.

V Développer des tests pour résoudre les problèmes potentiels associés à l'initialisation des variables et
aux combinaisons et plages exclues.
• Appliquez le théorème de Huang à deux reprises pour détecter les problèmes d'initialisation des
données.
3. Test des instructions de boucle
Deux boucles sont concaténées s'il est possible d'en atteindre une après avoir quitté l'autre tout en
concaténées
restant sur le chemin de l'entrée à la sortie.
Si ceux-ci sont indépendants les uns des autres, traitez-les comme des boucles indépendantes
Si leurs valeurs d'itération sont interdépendantes et qu'elles suivent le même chemin, traitez-les
comme une boucle imbriquée. Les délais de traitement s'additionnent.
4. Tester des boucles
V Évitez-les.
horribles
{ Même après avoir appliqué certaines techniques de chemins, les cas de test résultants ne
{ sont pas définitifs.
{ Trop de cas de test.
^ La réflexion requise pour vérifier les points finaux, etc. est unique pour chaque
Temps de programme.
test en boucle
V Temps de test plus long pour toutes les boucles si tous les cas extrêmes doivent être testés.
Des temps d’exécution de test déraisonnablement longs indiquent des bugs dans le logiciel ou les
spécifications.
Cas : tester des boucles imbriquées avec une combinaison de valeurs extrêmes entraîne des temps de test
longs.
V Montrez que cela est dû à des spécifications incorrectes et corrigez les spécifications.
• Prouver que des cas extrêmes combinés ne peuvent pas se produire dans le monde réel. Arrêtez ces
tests.
V Mettre en place des limites et des contrôles pour éviter les cas extrêmes combinés.
V Testez avec les combinaisons de valeurs extrêmes, mais utilisez des nombres différents.
V Le problème du temps de test est résolu en redimensionnant les valeurs limites de test.
• Peut être réalisé via une compilation séparée, en appliquant un correctif, en définissant des
valeurs de paramètres, etc.
Efficacité des tests de chemin
/ Les tests de chemin (principalement P1 et P2) détectent environ 65 % des bugs des tests unitaires, soit
environ 35 % de tous les bugs.
• Plus efficace pour les logiciels non structurés que pour les logiciels structurés.
V Limites
> Les tests de chemin peuvent ne pas assurer la couverture attendue si des bogues surviennent.
> Les tests de chemin ne révèlent pas nécessairement des fonctions totalement erronées ou
manquantes.
> Les tests de chemin au niveau de l'unité peuvent ne pas détecter les erreurs d'interface entre les
routines.
> Les erreurs de base de données et de flux de données peuvent ne pas être détectées.
> Les tests de chemin au niveau de l'unité ne peuvent pas révéler de bogues dans une routine en
raison d'une autre.
> Toutes les erreurs d’initialisation ne sont pas détectées par les tests de chemin.
> Les erreurs de spécification ne peuvent pas être détectées.
Beaucoup de travail
> Création d'un graphique de flux, sélection de chemins à couvrir, recherche de valeurs de
données d'entrée pour forcer ces chemins, configuration de cas de boucle et de combinaisons.
Une conception de test minutieuse et systématique permettra de détecter autant de bugs que l'acte de
tester.

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 33

Le processus de conception des tests à tous les niveaux est au moins aussi efficace pour détecter les
bugs que l'exécution du test conçu par ce processus.
V Techniques de test de chemin plus complexes que P1 et P2
> Entre P2 et Pα
■ Compliqué et peu pratique
> Plus faible que P1 ou P2.
■ Pour les tests de régression (incrémentiels), c'est rentable

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 34

Prédicats, expressions de prédicats

{ Chemin
> Une séquence de liens de processus (et de nœuds)
Prédicat V
> La fonction logique évaluée lors d'une décision : Vrai ou Faux. (Binaire, booléen)
Prédicat composé V
> Deux ou plusieurs prédicats combinés avec AND, OR etc.
• Prédicat de chemin
> Chaque chemin correspond à une succession de valeurs Vrai/Faux pour les prédicats parcourus
sur ce chemin.
> Un prédicat associé à un chemin.
« X > 0 est vrai » ET « W est soit négatif, soit égal à 122 » est vrai
> Logique à valeurs multiples / Branchement à plusieurs voies
Interprétation des prédicats
V La substitution symbolique d’opérations le long du chemin afin d’exprimer le prédicat uniquement en
termes du vecteur d’entrée est appelée interprétation du prédicat.
Un vecteur d'entrée est un ensemble d'entrées d'une routine disposées sous forme de tableau
unidimensionnel.
V Exemple :
ENTRÉE X, Y ENTRÉE X
SUR X ALLER À A, B, C SI X < 0 ALORS Y:= 2
A: Z := 7 @ ALLER À H SINON Y := 1
B: Z := -7 @ ALLER À H SI X + Y*Y > 0 ALORS …
C: Z := 0 @ ALLER À H
H : FAIS QUELQUE CHOSE
K: SI X + Z > 0 ALLER À BON SINON ALLER À MIEUX
L'interprétation du prédicat peut ou non dépendre du chemin. SI -7 > 3 ..
Les prédicats de chemin V sont la forme spécifique des prédicats des décisions le long du chemin
sélectionné après interprétation.
Dépendance du processus
V Une variable d’entrée est indépendante du traitement si sa valeur ne change pas suite au traitement.
V Une variable d’entrée dépend du processus si sa valeur change à la suite du traitement.
Le prédicat VA dépend du processus si sa valeur de vérité peut changer suite au traitement.
Le prédicat VA est indépendant du processus si sa valeur de vérité ne change pas suite au traitement.
V La dépendance du processus d'un prédicat ne découle pas de la dépendance du processus des variables
V Exemples : X + Y = 10 Incrémenter X et décrémenter Y.
X est impair Ajoutez un numéro pair à X
V Si toutes les variables d'entrée (sur lesquelles un prédicat est basé) sont indépendantes du processus,
alors le prédicat est indépendant du processus
Corrélation
V Deux variables d’entrée sont corrélées si chaque combinaison de leurs valeurs ne peut pas être spécifiée
indépendamment.
V Les variables dont les valeurs peuvent être spécifiées indépendamment sans restriction ne sont pas
corrélées.
Une paire de prédicats dont les résultats dépendent d’une ou plusieurs variables en commun sont des
prédicats corrélés.
V Chaque chemin à travers une routine n’est réalisable que si tous les prédicats de cette routine ne sont
pas corrélés.
V Si une routine comporte une boucle, alors au moins un prédicat de décision doit dépendre du processus.
Sinon, il y a une valeur d'entrée que la routine boucle indéfiniment.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 35

Expression de prédicat de chemin

V Chaque chemin sélectionné mène à une expression booléenne associée, appelée expression de prédicat
de chemin, qui caractérise les valeurs d'entrée (le cas échéant) qui entraîneront le parcours de ce
chemin.
V Sélectionnez un chemin d’entrée/sortie. Écrivez les prédicats non interprétés pour les décisions prises le
long du chemin. S'il y a des itérations, notez également la valeur de la variable de contrôle de boucle
pour ce passage. En les convertissant en prédicats contenant uniquement des variables d’entrée, nous
obtenons un ensemble d’expressions booléennes appelées expressions de prédicat de chemin.
V Exemple (les entrées étant des valeurs numériques) :
Si X 5 > 0 .OU. X 6 < 0 alors
X1 + 3X2 + 17 >= 0
X3 = 17
X4 – X1 >= 14 X2
UN X5>0 E: X 6 < 0
B: X1 + 3X2 + 17 >= 0 F: X1 + 3X2 + 17 >= 0
C: X3 = 17 G: X3 = 17
D: X4 – X1 >= 14 X2 H : X4 – X1 >= 14 X2
Conversion en forme d'expression de prédicat :
ABCD + EBCD ^ ( A + E ) BCD
Si nous prenons le chemin alternatif pour l'expression : D alors (A + E ) BCD
Couverture du prédicat :

V Regardez les exemples et les possibilités de bugs : ABCD A+B+C+D

> En raison de la sémantique de l’évaluation des expressions logiques dans les langages,
l’expression entière peut ne pas toujours être évaluée.
> Il se peut qu'un bug ne soit pas détecté.
> Un mauvais chemin peut être emprunté en cas de bug.
V Nous réalisons qu'en atteignant le niveau C2, le programme pourrait encore cacher quelques bugs de
flux de contrôle.
V Couverture du prédicat :
> Si toutes les combinaisons possibles de valeurs de vérité correspondant au chemin sélectionné
ont été explorées sous un test, nous disons que la couverture du prédicat a été atteinte.
> Plus solide que la couverture des branches.
> Si toutes les combinaisons possibles de tous les prédicats sous toutes les interprétations sont
couvertes, nous avons l’équivalent d’un test de chemin total.
Test de cécité
• arriver sur le bon chemin – même à travers une mauvaise décision (au niveau du prédicat). En raison
de l'interaction de certaines instructions, un prédicat bogué fonctionne et le bogue n'est pas détecté par
les valeurs d'entrée sélectionnées.
• calculer un nombre erroné de tests sur un prédicat en ignorant le nombre de chemins pour y arriver.
• Ne peut pas être détecté par les tests de chemin et nécessite d'autres stratégies
• Aveuglement d'affectation : un prédicat bogué semble fonctionner correctement car la valeur
spécifique choisie dans une instruction d'affectation fonctionne à la fois avec le prédicat correct et
bogué.
Correct Poussette
X := 7 X := 7
SI Y > 0 ALORS … SI X + Y > 0 ALORS … (vérifier si Y=1)
L'égalité aveuglante :
• Lorsque le chemin sélectionné par un prédicat antérieur aboutit à une valeur qui fonctionne à la fois pour le bon
et le mauvais

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 36

prédicat buggé.
Correct Poussette
SI Y = 2 ALORS … SI Y = 2 ALORS ..
SI X + Y > 3 ALORS … SI X > 1 ALORS … (vérifier si X>1)
• Auto-aveuglant
• Lorsqu’un prédicat bogué est un multiple du prédicat correct et que le résultat est indiscernable le
long de ce chemin.
Correct Poussette
X := Un X := Un
SI X - 1 > 0 ALORS … SI X + A -2 > 0 ALORS … (vérifiez s'il y a un X, A)

Des chemins réalisables

1. L'objectif est de sélectionner et de tester juste assez de chemins pour obtenir une notion satisfaisante
d'exhaustivité des tests tels que C1 + C2.
2. Extrayez le graphique de flux de contrôle du programme et sélectionnez un ensemble de chemins de
couverture provisoires.
3. Pour un chemin dans cet ensemble, interprétez les prédicats.
4. Tracez le chemin en multipliant les prédicats composés individuels pour obtenir une expression booléenne.
Exemple : (A + BC) ( D + E)
5. Multiplier et obtenir la forme somme des produits de l'expression du prédicat de chemin :
AD + AE + BCD + BCE
6. Chaque terme de produit désigne un ensemble d’inégalités qui, si elles sont résolues, produiront un vecteur
d’entrée qui pilotera la routine le long du chemin sélectionné.
7. Un ensemble de valeurs d’entrée pour ce chemin est trouvé lorsque l’un des ensembles d’inégalités est résolu.
Une solution trouvée => le chemin est réalisable. Sinon, le chemin est inaccessible.
Sensibilisation au chemin
C'est l'acte de trouver un ensemble de solutions à l'expression du prédicat de chemin.
En pratique, pour un chemin sélectionné, trouver le vecteur d’entrée requis n’est pas difficile. S'il y a des
difficultés, cela peut être dû à des bugs.
Procédures heuristiques :
Choisissez un ensemble de chemins facilement sensibilisables et sélectionnez des chemins difficiles à sensibiliser
pour obtenir une meilleure couverture.
Identifiez toutes les variables qui influencent les décisions. Pour les variables dépendantes du processus,
exprimez la nature de la dépendance du processus sous la forme d’une équation, d’une fonction ou de tout ce qui
est pratique et clair. Pour les variables corrélées, exprimez la relation logique, arithmétique ou fonctionnelle
définissant la corrélation.
1. Identifier les prédicats corrélés et documenter la nature de la corrélation pour les variables. Si le même
prédicat apparaît dans plus d’une décision, les décisions sont évidemment corrélées.
2. Démarrez la sélection du chemin avec des prédicats non corrélés et indépendants. Si la couverture est atteinte,
mais que le chemin comporte des prédicats dépendants, il y a un problème.
3. Si la couverture n'est pas encore atteinte avec des prédicats indépendants non corrélés, étendez l'ensemble de
chemins en utilisant des prédicats corrélés ; de préférence indépendants du processus (ne nécessitant pas
d'interprétation)
4. Si la couverture n'est pas atteinte, étendez l'ensemble de chemins en utilisant des prédicats dépendants
(généralement requis pour couvrir les boucles), de préférence non corrélés.
5. Enfin, utilisez des prédicats corrélés et dépendants.
6. Pour chacun des chemins sélectionnés ci-dessus, répertoriez les variables d’entrée correspondantes. Si la
variable est indépendante, indiquez sa valeur. Pour les variables dépendantes, interprétez le prédicat, c'est-à-
dire répertoriez la relation. Pour les variables corrélées, indiquez la nature de la corrélation avec d’autres
variables. Déterminer le mécanisme (relation) permettant d’exprimer les combinaisons interdites de valeurs de
variables, le cas échéant.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 37

7. Chaque chemin sélectionné génère un ensemble d’inégalités, qui doivent être satisfaites simultanément pour
forcer le chemin.

Exemples de sensibilisation au chemin

1. Prédicats simples indépendants non corrélés
2. Prédicats corrélés indépendants
3. Prédicats dépendants
4. Générique

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 38

1. Prédicats simples indépendants non corrélés

4 prédicats => 16 combinaisons

Ensemble de chemins possibles = 8
Chemin Valeurs des
prédicats
abcdef U C
aghcimkf — BCD
——
aglmjef U
U B D
abcdef N U —
C
abcimjef U —
abcimkf N U CD
CD
aghcdef — Colombi
e-
U Britanni
aglmkf U B D
N
Un cas simple de résolution (obtenu par la procédure de recherche d'un ensemble de
2. d’inéquations.
Prédicats indépendants corrélés chemins de recouvrement)

Chemins corrélés => certains chemins sont irréalisables, c'est-à-dire des chemins redondants.

c'est-à-dire, n décisions mais # chemins sont < 2n

En raison de la pratique de sauvegarde du code,
le code est très difficile à maintenir.
Éliminez les décisions corrélées. Reproduisez le code commun.

Si un chemin raisonnable choisi n’est pas réalisable,

- Il y a un bug.
- la conception peut être simplifiée.
- mieux comprendre les décisions corrélées

3. Prédicats dépendants Décision corrélée supprimée et CFG simplifié

Habituellement, la plupart des traitements n’affectent pas le flux de contrôle.
Utiliser la simulation informatique pour la sensibilisation de manière simplifiée.
Les prédicats dépendants contiennent généralement des instructions de boucle itérative.
Instructions de boucle For :
Déterminez la valeur de la variable de contrôle de boucle pour un certain nombre d'itérations, puis travaillez en
arrière pour déterminer la valeur des variables d'entrée (vecteur d'entrée).
4. Le cas général
Aucune procédure simple pour résoudre les valeurs du vecteur d'entrée pour un chemin sélectionné.
1. Sélectionnez les cas à couvrir sur la base de chemins fonctionnellement raisonnables.
Des routines bien structurées permettent une sensibilisation facile.
Les chemins intraitables peuvent avoir un bug.
2. Commencez par emprunter le chemin comportant le moins de décisions. Sélectionnez les chemins
avec le moins de boucles
3. Commencez à la fin du chemin et répertoriez les prédicats tout en traçant le chemin en
sens inverse. Chaque prédicat impose des restrictions sur le prédicat suivant (dans l’ordre
inverse).
4. Continuez à tracer le long du chemin. Choisissez la gamme de valeurs la plus large pour les

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 39

variables affectées et cohérente avec les valeurs qui ont été déterminées jusqu’à présent.
5. Continuez jusqu'à l'entrée et établissez ainsi un ensemble de conditions d'entrée pour le chemin.

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 40

Si la solution n'est pas trouvée, le chemin n'est pas réalisable, il peut s'agir d'un bug.
Alternativement:
1. Dans le sens avant, énumérez les décisions à prendre.
Pour chaque décision, répertoriez la plus large gamme de valeurs d’entrée.
2. Choisissez un chemin et ajustez toutes les valeurs d’entrée. Ces valeurs restreintes sont utilisées pour la
décision suivante.
3. Continuer. Certaines décisions peuvent dépendre et/ou être corrélées à des décisions antérieures.
4. Le chemin est irréalisable si les valeurs d’entrée deviennent contradictoires, voire impossibles.
Si le chemin est atteint, essayez un nouveau chemin pour une couverture supplémentaire.
Avantages et inconvénients des deux approches :
La méthode directe demande généralement moins de travail.
vous ne savez pas où vous allez lorsque vous tracez le graphique.
Instrumentation de trajectoire

Résultat d'un test :

Résultats observés. Mais il se peut qu'il n'y ait aucun résultat attendu pour un test.
Résultat:
Tout changement ou absence de changement à la sortie.
Résultat attendu :
Tout changement attendu ou absence de changement à la sortie (prévu dans le cadre de la conception).
Résultat réel :
Résultat observé
Exactitude coïncidente :
Lorsque les résultats attendus et réels correspondent,
• Les conditions nécessaires pour que le test soit réussi sont remplies.
• Les conditions réunies ne sont probablement pas suffisantes.
(le résultat attendu peut être atteint pour une mauvaise raison)
Chem
in
1.

2.

L'instrumentation de chemin est ce que nous devons faire pour confirmer que le résultat a été atteint par le
chemin prévu.
Méthodes d'instrumentation
Stratégie générale :
1. Basé sur le traçage interprétatif et l'utilisation d'un programme de traçage interprétatif.
2. Une trace confirme que le résultat attendu est ou n'est pas obtenu le long du chemin prévu.
3. La trace informatique est peut-être trop massive. Le traçage manuel peut être plus simple.
Créateurs de traversées ou de liens :
Simple et efficace
1. Nommez chaque lien.
2. Instrumenter les liens pour que le lien soit enregistré lorsqu'il est exécuté (pendant le test)
3. La succession de lettres depuis l'entrée jusqu'à la sortie d'une routine correspond au chemin d'accès

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 41

Instrumentation de marqueur à liaison unique :

un exemple

Exemple de chemin : moi

Instrumentation du marqueur à liaison unique : pas
assez bonne

Problème:
Le traitement dans les liens peut être perturbé par des Peut-être en raison des instructions GOTO, le
bugs. chemin différent, mais aboutissant à nouveau au contrôle prend une
chemin prévu. Instrumentation du marqueur à
double liaison :

Le problème est résolu.

Deux marqueurs de lien spécifient le nom du chemin ainsi que le début et la fin du lien.
3. Technique des compteurs
de liens : V Moins perturbateur et moins informatif.
V Incrémenter un compteur de liens à chaque fois qu'un lien est traversé. La longueur du chemin
pourrait confirmer le chemin prévu.
• Pour éviter le même problème qu'avec les marqueurs, utilisez des compteurs à double lien.
Attendez-vous à un nombre pair =
le double de la longueur. (auparavant c'était seulement entre
les décisions)
K. Nuka Raju Professeur associé, DIET
Méthodologies de test de logiciels Page | 42

• Maintenant, placez un compteur de liens sur chaque lien.

S'il n'y a pas de boucles, le nombre de liens est = 1.
V Additionnez le nombre de liens sur une série de tests, par exemple un ensemble de couverture.
Confirmez le nombre total de liens avec celui attendu.
L'utilisation de compteurs à double lien évite le même problème mentionné précédemment.
Liste de contrôle pour la procédure :
V Les valeurs du compteur de lien de début sont-elles égales aux valeurs du compteur de lien de
fin ?
V Le nombre de liens d’entrée de chaque décision est-il égal à la somme des nombres de liens des
liens de sortie de cette décision ?
V La somme des nombres de liaisons d’entrée pour une jonction est-elle égale au nombre de
liaisons de sortie pour cette jonction ?
V Les nombres totaux correspondent-ils aux valeurs que vous avez prédites lors de la conception
de l'ensemble de test de couverture ?
V Cette procédure et la liste de contrôle pourraient résoudre le problème de l'instrumentation.
Limites
La sonde d'instrumentation V (marqueur, compteur) peut perturber les relations de
synchronisation et masquer les bugs des conditions de course.
La sonde d'instrumentation V (marqueur, compteur) peut ne pas détecter les bogues dépendant de
l'emplacement.
V Si la présence ou l'absence de sondes modifie les choses (par exemple dans la base de données)
de manière erronée, alors les sondes cachent le bug dans le programme.
Instrumentation de chemin - Mise en œuvre
Pour les tests unitaires : l'implémentation peut être assurée par un outil de test complet.
Pour des tests de niveau supérieur ou pour tester un langage non pris en charge :
V L'introduction de sondes pourrait introduire des bugs.
L'instrumentation V est plus importante pour les niveaux supérieurs de structure de programme
comme le flux de transactions
V À des niveaux plus élevés, les écarts dans la structure sont plus possibles et les frais généraux
d'instrumentation peuvent être moindres.
Pour les langages prenant en charge l'assemblage conditionnel ou la compilation :
Les sondes V sont écrites dans le code source et classées par catégories.
Des compteurs V et des marqueurs de traversée peuvent être implémentés.
V Peut activer sélectivement les sondes souhaitées.
Pour les langages ne prenant pas en charge l'assemblage/la compilation conditionnelle :
V Utilisez des macros ou des appels de fonctions pour chaque catégorie de sondes. Cela peut avoir
moins de bugs.
Une routine à usage général VA peut être écrite.
En général:
V Plan d'instrumentation avec sondes à niveaux de détails croissants.
Mise en œuvre et application des tests de chemin
1. Intégration, couverture et chemins dans les composants appelés
1. Principalement utilisé dans les tests unitaires, en particulier les nouveaux logiciels.
2. Dans un processus de test d’intégration ascendant idéaliste – intégration d’un composant à la
fois. Utilisez des stubs pour les composants de niveau inférieur (sous-routines), testez les

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 43

interfaces, puis remplacez les stubs par de véritables sous-routines.

3. En réalité, l’intégration se déroule par blocs de composants associés. Les talons peuvent être
évités. Il faut réfléchir aux chemins à l’intérieur de la sous-routine.
Pour obtenir une couverture C1 ou C2 :
L'interprétation des prédicats peut nous obliger à traiter une sous-routine comme un code
en ligne.
• La sensibilisation devient plus difficile.
V Le chemin sélectionné peut être irréalisable car le traitement des composants appelés
peut le bloquer.
Faiblesses des tests de chemin :
V On suppose que des tests efficaces peuvent être effectués un niveau à la fois sans se
soucier de ce qui se passe aux niveaux inférieurs.
Problèmes de couverture de prédicat V et d'aveuglement.
2. Application des tests de chemin au nouveau code
V Effectuer des tests de chemin pour la couverture C1 + C2
V Utilisez une procédure similaire à celle des tests d’intégration ascendants idéalistes, en utilisant
une suite de tests mécanisés.
V Un chemin bloqué ou non réalisable peut signifier un bug.
V Lorsqu'un bug se produit, le chemin peut être bloqué.
3. Application des tests de chemin à la maintenance
V Les tests de chemin sont d’abord appliqués au composant modifié.
V Utilisez une procédure similaire à celle des tests d’intégration ascendants idéalistes, mais sans
utiliser de stubs.
V Sélectionnez les chemins pour atteindre C2 sur le code modifié.
V Des stratégies nouvelles et plus efficaces pourraient émerger pour assurer une couverture en
phase de maintenance.
4. Application des tests de chemin au réhébergement
V Les tests de chemin avec couverture C1 + C2 sont un outil puissant pour réhéberger d'anciens
logiciels.
V Le logiciel est réhébergé car il n'est pas plus rentable de prendre en charge l'environnement
d'application.
V Utiliser les tests de chemin en conjonction avec des générateurs de tests structurels
automatiques ou semi-automatiques.

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 44

Unité III
Test du flux de transaction
Flux de transaction
Le flux de transaction représente le traitement d'un système. Des méthodes de tests fonctionnels sont
appliquées pour tester TF.
Graphique de flux de transaction
TFG représente un modèle comportemental (fonctionnel) du programme (système) utilisé pour les tests
fonctionnels par un testeur système indépendant.
Transaction
V est une unité de travail vue du point de vue de l'utilisateur du système.
V consiste en une séquence d’opérations effectuées par un système, des personnes ou des dispositifs
externes.
V est créé (naissance) en raison d'un acte extérieur et jusqu'à son achèvement (clôture), il demeure sous
forme de documents historiques.

1. accepter les entrées 7. Accepter les entrées

2. Valider les entrées 8. Valider les entrées
(Naissance de tr.) 9. Traiter la demande
10. Mettre à jour le fichier
3. Transmettre un accusé de
11. Sortie de transmission
réception à l'utilisateur 12. Enregistrer la transaction dans le journal et la
4. Entrée de processus nettoyer (clôture)
5. Recherche de fichier
6. Demande de direction à
l'utilisateur Utilisateurs Vue d'une
transaction
Exemple : la séquence d'étapes d'une transaction dans un système de recherche d'informations en ligne

Une seule étape

Séquence de plusieurs
opérations
Contrôleur de terminal 4-►
Exemple: Processeur

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 45

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 46

Définitions

Graphique de flux de transaction : un scénario entre les utilisateurs et l'ordinateur

Flux de transaction : une séquence interne d'événements dans le traitement d'une transaction
Utilisations de Transaction-flow
V Spécification des exigences des systèmes volumineux, en ligne et complexes.
V Systèmes de réservation de compagnies aériennes, systèmes de contrôle du trafic aérien.
V Les boucles sont moins nombreuses par rapport au CFG. Les boucles sont utilisées pour le traitement des
erreurs de saisie utilisateur
Mise en œuvre du flux de transaction (dans un système)
V Implicite dans la conception de la structure de contrôle du système et de la base de données associée.
V Aucune correspondance directe biunivoque entre les « processus » et les « décisions » du flux de
transactions et le composant de programme correspondant.
Le flux de transaction VA est un chemin emprunté par la transaction à travers une succession de modules de
traitement.
La transaction VA est représentée par un jeton.
• Un graphique de flux de transaction est une représentation picturale de ce qui arrive aux jetons.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 47

Structure de contrôle du système

Le système V est contrôlé par un planificateur…
La transaction VA est créée en remplissant un bloc de contrôle de transaction (TCB) par les entrées utilisateur et
en plaçant ce jeton sur l'entrée Q du planificateur.
Le planificateur V l'examine et le place sur le processus Q approprié tel que A. Lorsque A a terminé avec le
jeton, il replace le TCB sur le planificateur Q.
V Scheduler l'achemine vers le processus suivant après avoir examiné le jeton :
1. Il contient des tables ou du code pour acheminer un jeton vers le processus suivant.
2. Il peut contenir des informations de routage uniquement dans des tableaux.
3. Le planificateur ne contient aucun code/donnée. Les modules de traitement contiennent du code pour le
routage.
Système de traitement des transactions (simplifié) :
V Il y a de nombreux flux Tr. & Tr-dans le système.
V Scheduler appelle les processus A à E ainsi que les lectures et écritures sur disque et bande.
V L'ordre d'exécution dépend de la priorité et d'autres raisons.
La structure cyclique comme dans cet exemple est courante dans les systèmes de contrôle de processus et de
communication.
♦ Les critères du mécanisme de mise en œuvre dépendent des performances et de l’optimisation des ressources.
Une perspective de flux de transactions
Les tests de flux de transaction sont une technique de boîte de blocs. (car nous n'avons rien supposé concernant
l'ordinateur, les communications, l'environnement, le système d'exploitation, l'identité ou la structure de la
transaction ou l'état.) 1. TFG est une sorte de DFG.
V TFG possède des jetons et DFG possède des objets de données avec l'historique des opérations qui leur sont
appliquées.
De nombreuses techniques de CFG s'appliquent à TFG et DFG
2. Les nœuds de décision de TFG disposent de sorties d'exception vers le processus de récupération central.
3. Nous ignorons donc l’effet des interruptions dans un flux de transaction.
Flux de transactions – décisions de division et de fusion
Fractionnements de transactions (Naissances)
1. Un point de décision au sein du TFG

2. Biosis

3. Mitose

Fusions d'opérations
1. Jonction

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 48

2. Absorption

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 49

3. Conjugaison

TFG – scission, fusion des transactions

V Plusieurs significations désormais pour les symboles de décision et de jonction dans un TFG.
V Un modèle TFG simple ne suffit pas à représenter les systèmes multiprocesseurs et les systèmes de
coordination associés.
Le modèle V Petrinet utilise des opérations pour tout ce qui précède. Mais les Petrinets sont appliqués aux tests
de protocoles H/W et N/W, mais pas aux logiciels.
Modèle TFG simplifié
V Ajouter de nouveaux flux Tr pour la biose, la mitose, l'absorption et la conjugaison
V Problèmes pour le programmeur, le concepteur et le concepteur de tests.
V Nécessité de concevoir des tests spécifiques – possibilité de bugs.
Structure du flux de transaction
Raisons du manque de structure
1. Les processus impliquent des utilisateurs humains
2. Une partie du flux provenant de systèmes externes
3. Erreurs, échecs, dysfonctionnements et actions de récupération
4. Nombre de transactions, complexité. Client & Environnement
5. Nouvelles transactions et modifications
6. Approximation de la réalité
7. Tentative de structuration
Transaction - Test de flux - Étapes
Tout d’abord, créez/obtenez des flux de transaction
V Représenter explicitement
V Détails de conception des principaux flux Tr
V Créer à partir de PDL
V Cartes HIPO et représentations Petrinet
Objectif – Tracer la transaction
1. Inspections, examens et visites guidées
Commencez par la conception préliminaire
1. Réalisation de visites guidées
V Discutez suffisamment des types de transactions (98 % des transactions)
V Besoins des utilisateurs et termes fonctionnels (indépendants de la conception)
V Traçabilité des exigences
2. Tests de conception pour la couverture C1 + C2
3. Couverture supplémentaire (> C1+C2)
V Chemins avec boucles, valeurs extrêmes, limites de domaine
V Cas étranges, longs et potentiellement gênants Tr.
4. Concevoir des cas de test pour Tr. Scissions et fusions
5. Publier les chemins de test sélectionnés en avance
6. Acceptation de l'acheteur – tests fonctionnels et d'acceptation
2. Sélection du chemin
• Ensemble de couverture (C1+C2) de Tr fonctionnellement sensible.
V Ajouter des chemins difficiles
> Révision avec les concepteurs et les exécutants
> Exposition des problèmes d'interface et du traitement dupliqué
> Il peut rester très peu de bugs d'implémentation
L'ensemble de couverture de chemin de flux de transaction appartient aux tests de fonctionnalités du système.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 50

3. Sensibilisation
V Chemins fonctionnels et sensés – Simple
V Erreur, exception, chemins d'interface de protocole externe - Difficile
Test des flux Tr. avec des interfaces externes
V Utilisez des correctifs et des points d'arrêt, désaccordez-vous et enfreignez les règles,
4. Instrumentation
Les compteurs V Link ne sont pas utiles.
V Besoin
> Tracer
> Files d'attente sur lesquelles résidaient les jetons
> Entrées et sorties du répartiteur
> Un journal de bord
Intégrer l'instrumentation à la conception du système
5. Bases de données de test
V Conception et maintenance d'une base de données de test - Effort
V Erreurs
> Méconnaissance de la conception d'une base de données de tests administrée de manière centralisée
> Conception de la base de données de test par les testeurs
> Utilisation d'une base de données pour tous les tests (4 à 5 requis) Nécessite des concepteurs de systèmes
et de tests expérimentés
6. Exécution des tests
V Utiliser l'automatisation de l'exécution des tests
V Il faut faire un grand nombre de tests pour la couverture C1+C2
Données - Tests de flux - Notions de base
Anomalie
Traitement déraisonnable des données
V Utilisation de l'objet de données avant qu'il ne soit défini
V L'objet de données défini n'est pas utilisé
Les tests de flux de données (DFT) utilisent le graphique de flux de contrôle (CFG) pour explorer les anomalies de
flux de données.
V La DFT conduit à des stratégies de test entre Po et P1/P2 Définition
DFT est une famille de stratégies de test basées sur la sélection de chemins à travers le flux de contrôle du
programme afin d'explorer la séquence d'événements liés à l'état des objets de données.
Exemple
Choisissez suffisamment de chemins pour garantir que chaque élément de données a été initialisé avant son
utilisation ou que tous les objets ont été utilisés pour quelque chose.
Motivation
V Confiance dans le programme
V Conception dominée par les données. Le code migre vers les données.
V Code source pour les déclarations de données
V Machines à flux de données contre Von Neumann
> Résumé MIMD
> Le langage et le compilateur s'occupent des calculs parallèles Contrôle
du flux de programme avec le paradigme de Von Neumann Étant donné m, n, p, q,
trouver e. e = (m+n+p+q) * (m+npq) a := m + nb := p + qc := a + bd := a - b

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 51

e := c * d
> Plusieurs représentations de graphiques de flux de contrôle possibles.
Flux de programme utilisant le paradigme des machines à flux de données
COMMENCER
PAR DO
LIRE m, n, n, p, q
FIN PAR
PAR DO
a := m+n
b := p+q
FIN PAR
PAR DO
c := a+b
d := ab
FIN PAR
PAR DO
e := c * d
FIN PAR
FIN

V Graphique de flux de contrôle

> Représentations multiples
Graphique de flux de données V
V Une spécification pour les relations entre les objets de données. Couvrant DFG => Explorer toutes les
relations sous un test. Hypothèses
V Problèmes dans un flux de contrôle
V Problèmes avec les objets de données
Graphiques de flux de données (DFG)
V C'est un graphe avec des nœuds et des liens dirigés
V Testez la méthode Von Neumann -
> Convertir en CFG
> Annoter : actions du programme (poids)
État et utilisation de l'objet de données
Actions du programme (d, k, u) :
Défini (créé) - explicitement ou (d)
Tué (libéré) - directement ou(k)
Utilisé - (u)
o Dans un calcul - (c)
o Dans un prédicat - directement ou (p)
indirectement
Anomalies de flux de données

Une séquence de deux lettres d'actions (d, k, u)

dd : inoffensif, suspect

dk :probablement un bug.
du : normale

kd : normale
k :inoffensif, mais probablement un bug
moi : un bug

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 52

au royaume- normale. Redéfinition.

uni normale
euh normale
Actions sur les objets de données
- aucune action du DÉBUT à ce
point De ce point jusqu'à la
-d anomalie normale
- toi

-k anomalie

k- normale
tu - normal - peut-être une anomalie

d- peut-être anormal
Graphique d'état d'anomalie de flux de données
/ État de l'objet de données
> K, D, U, A
Étape de traitement V
> k, d, u
Graphique d'état d'anomalie de flux de données
V État de l'objet
V Graphique d'état du flux de données impitoyable

Graphique d'état
d'anomalie de flux de
données
Graphique d'état du flux de données pardonnant

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 53

Graphiques d'état du flux de données

V Différence dans le traitement des anomalies
V Le choix dépend de l'application, de la langue, du
contexte
Détection d'anomalies statiques et dynamiques
V Analyse statique des flux de données
V Analyse dynamique
• Valeursdedel'analyse
Insuffisance donnéesstatique
intermédiaires
(pour le flux de données)
1. Validation des variables mortes
2. Validation des pointeurs dans les tableaux
3. Validation des pointeurs pour les enregistrements
et les pointeurs
4. Adresses dynamiques pour les appels de sous-
programmes dynamiques
5. Identifier une fausse anomalie sur un chemin
inaccessible
6. Anomalies
• Basé sur CFGrécupérables et graphique d'état
alternatif
V CFG annoté avec les actions du
7. Concurrence, interruptions, problèmes système
programme
Modèle
Poids desde flux de
liaisons données
en V : dk, dp, du etc.
V Pas le même que DFG
V Pour chaque variable et objet de
données
V Nœuds d'entrée et de sortie
Procédure de construction
V Identification unique du nœud
Poids V sur la liaison de sortie
V Nœuds prédicatifs
V Séquence de liens
> Rejoindre
> Concaténer les poids
> L'inverse
un
Exemple: –1
Z = b + -----------
COMMENCER un - 1
ENTRÉE a, b, n Lire abn
Z := 0
SI a = 1 ALORS Z := 1
ALLER À TERMINÉ1
r := 1 c := 1 Y
POUVOIR:
c := c * a
r := r + 1
SI r <= n ALORS ALLER À
Z := (c – 1) / (a – 1)
PUISSANCE
FAIT1 :
Z := b + Z
FIN

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 54

CFG annoté – Modèle de flux de données pour Z

CFG annoté – Modèle de flux de données pour c

CFG annoté – Modèle de flux de données pour r

CFG annoté – Modèle de flux de données pour b

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 55

CFG annoté – Modèle de flux de données pour n

CFG annoté – Modèle de flux de données pour un

Définitions
V par rapport à une variable ou à un objet de données 'v'
V Supposons que tous les chemins DF soient réalisables
1. Définition - segment de chemin clair n° k, kd
V Segment de chemin sans boucle
V Segment de chemin simple
V du chemin du nœud i au nœud k
V définition-claire et simple c
V définition claire et sans bouclep
Stratégies DFT
V Chemins tout-du (ADUP)
V Stratégie de toutes les utilisations (AU)
V Tous les usages p/quelques usages c et Tous les usages c/quelques usages p
V Stratégie de toutes les définitions
V Stratégie de tous les usages p, de tous les usages c
But
Conception de tests, développement de cas de tests
1. Chemins tout-terrain (ADUP)
Y DFT le plus fort
V Chaque chemin pour chaque variable pour chaque définition pour chaque utilisation
2. Stratégie de toutes les utilisations (AU)
V Au moins un segment de chemin clair de définition de chaque définition de chaque variable vers chaque
utilisation de cette définition doit être exercé sous un certain test.
• Au moins un segment de chemin de chaque définition vers chaque utilisation qui peut être atteinte à partir de
cette définition.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 56

3. Tous les usages p/quelques usages c et Tous les usages c/quelques usages p
V APU + c
Plus fort que P2
V ACU + p
Plus faible que P2
4. Stratégie Toutes Définitions (AD)
V Couvrir chaque définition par au moins un p ou un c
{ Plus faible que ACU + p et APU + c
5. Stratégie d'utilisation de tous les prédicats et de toutes les utilisations informatiques
V APU :
> Inclure un chemin sans définition pour chaque définition de chaque variable, de la définition à
l'utilisation du prédicat.
VACUUM :
> Inclure pour chaque définition de chaque variable au moins un chemin sans définition depuis la
définition vers chaque utilisation informatique.
Ordonner les stratégies
Tous les chemins

Tous les chemins

Chemins à usages
multiples (AU)

Succursales
P2

Tests, maintenance et débogage dans le contexte du flux de données

Tranchage :
Une tranche de programme statique VA est une partie d'un programme défini par rapport à une variable
« v » et à une instruction « s ». Il s'agit de l'ensemble de toutes les instructions qui pourraient affecter
la valeur de « v » à l'instruction « s ».
Stmt1 var v
stmt2
Stmt3 var v
Stmt4 var v
État s var v
Découpage en dés :
Le programme VA est une partie de la tranche dans laquelle toutes les stmts qui sont connues pour être
correctes ont été supprimées.
V Obtenu à partir de « tranche » en incorporant les informations d'exactitude issues des tests/débogage.
Débogage :
V Sélectionnez une tranche.
V Réduisez-le à un dé.
V Affinez les dés jusqu'à ce qu'il n'y ait qu'une seule étape défectueuse.
Découpage dynamique :

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 57

V Raffinement du découpage statique

• Seuls les chemins réalisables vers les instructions en question sont inclus.
Les méthodes de découpage rassemblent les tests, la maintenance et le débogage.
Application de la théorie des flux de travail
V Tests aléatoires de comparaison, P2, AU - par Ntafos
>AU détecte plus de bugs que
1- P2 avec plus de cas de test
1- RT avec moins de cas de test
V Comparaison de P2, AU - par Sneed
> AU détecte plus de bugs avec une exigence de couverture des données de 90 %.
V Comparaison de # cas de test pour ACU, APU, AU et ADUP par Weyuker en utilisant le système de test
ASSET
> Cas de test normalisés. t = a + b * d d = # décisions binaires
> Au plus d+1 cas de test pour P2 sans boucle
> # Cas de test / Décision
ADUP > AU > APU > ACU > APU révisé
V Comparaison de # cas de test pour ACU, APU, AU et ADUP par Shimeall & Levenson
Cas de test V normalisés. t = a + b * d (d = # décisions binaires)
V Au plus d+1 cas de test pour P2 sans boucle
V # Cas de test / Décision
> ADUP ~ ½ APU*
> AP ~ CA
V DFT contre P1, P2
> La DFT est efficace
> Effort pour couvrir le chemin défini ~ Idem
> DFT suit la couverture des variables
> La conception des tests est similaire

DFT - OUTILS
V Développement rentable
V Outils commerciaux :
V peut éventuellement faire mieux que les outils commerciaux
> Intégration plus facile dans un compilateur
> Des tests efficaces

Questions des articles précédents

1. Comment les tests de flux de données (DFT) sont-ils utiles pour combler les lacunes des tests de chemin ?
2. Expliquez les graphiques de flux de données (DFG).
3. Comment détecter une anomalie ? Expliquez les différents types d’anomalies de flux de données et les
graphiques d’état d’anomalie de flux de données.
4. Écrire des applications de tests de flux de données.
5. Nommez et expliquez les stratégies de test de flux de données.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 58

Unité - IV
Test de domaine
Domaines et chemins :
Test de domaine
V Views Programmes comme classificateurs de données d'entrée
• Vérifie si la classification est correcte
Modèle de test de domaine

Deux vues pour le modèle de domaine

V Basé sur les spécifications
V Tests fonctionnels
V Basé sur les informations de mise en œuvre
V Technique structurelle
Besoins en matière de tests de domaine
Variables V
> Combinaisons simples de deux variables
> Nombres de - oC à + oC
V Variables d'entrée sous forme de nombres
Programmes sans boucle V
V Aucune connaissance structurelle n'est nécessaire. Spécifications uniquement.
V Pour chaque cas d'entrée,
> Un chemin hypothétique pour les tests fonctionnels
> Un cheminement réel pour les tests structurels
Domaine
Ensemble de nombres connectés simples VA
V Pas d'ensembles discrets arbitraires
V Défini par les limites
> Une ou plusieurs limites
> Spécifié par des prédicats
> Des insectes sont probablement présents aux
limites
V Une ou plusieurs variables
Prédicats
V Interprétation
> Essais structurels - CFG
> Tests fonctionnels - DFG
V spécifie la limite du domaine
Prédicats V n dans la séquence ^ 2n domaines
> Ou, juste deux domaines A .ET. GROUPE. C

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 59

Chemins
V Au moins un CHEMIN à travers le programme
V Plus de chemins pour les domaines déconnectés
Points à retenir
V Le domaine d'un programme sans boucle correspond à un ensemble de nombres définis sur le vecteur d'entrée
V Pour chaque domaine, il existe au moins un chemin à travers la routine, le long duquel le traitement de ce
domaine est effectué
V L'ensemble des prédicats interprétés parcourus sur ce chemin (c'est-à-dire l'expression du prédicat du chemin)
définit les limites du domaine.
Fermeture de domaine
Limite : Fermé / Ouvert
X>=MIN X<=MAX

Dimensionnalité du domaine
V Une dimension par variable
V Au moins un prédicat
> Tranches à travers le domaine
précédemment défini
Limite de découpage en V
• Les N-espaces
Hypothèses sur les sont coupés par des hyperplans
bogues Le traitement est OK. La définition du domaine peut
être
^ Leserronée.
limites sont
fausses.
^ Les prédicats sont
V faux.
Une fois le vecteur d'entrée défini sur le bon chemin, il est
{ D'autres bugs traité.
correctement provoquant des erreurs
{ de domaine… Représentation à
double zéro V Domaines ambigus
•
Z Vérification du zéro en virgule
flottante Domaines contradictoires

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 60

V Domaines sur-spécifiés
> X > 3 .ET. X < 2 .ET. Y > 3
V Erreurs de limites
V Fermeture des frontières
V Décalé
V Erreurs de limites….
> Incliné
> Manquant
> Limite supplémentaire
• Inversion de la fermeture

Logique défectueuse
> Simplification des prédicats
composés

Restrictions
1. Exactitude par coïncidence
> DT ne peut pas détecter
Exemple
• Résultat représentatif Test de
partition Équivalence d'entrée
2. Limites simples et prédicats composés
Prédicats composés
V

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 61

Impact de .OR.
> Concave, déconnecté
> Domaines adjacents avec la même fonction
> Exemple
ABC + DÉF
V Éliminer les prédicats composés
3. Homogénéité fonctionnelle des bugs
V La forme fonctionnelle est toujours conservée
ax + par >= c
V Les bugs sont uniquement dans a, b, c
4. Espace vectoriel linéaire
V Prédicat de limite linéaire, interprété
V Opérateurs relationnels simples
V Conversion à l'espace vectoriel linéaire
> Coordonnées polaires 2D
> Polynômes
V Problèmes avec des limites non linéaires
5. Logiciel sans boucle
Prédicat V pour chaque itération
> Boucle sur toute la transaction
> Boucle définie
De beaux domaines
V Exigences
> Bugs ^ domaines mal définis
• Avant DT
> Analyser les spécifications
> Assurez-vous que les spécifications des limites sont cohérentes et complètes
Domaines implémentés
V Compléter, Cohérent et Traiter toutes les entrées
Domaines spécifiés
V Incomplet, incohérent
Effort du programmeur/concepteur
De beaux domaines
• Linéaire, complet, systématique, orthogonal, constamment fermé et convexe

Avantages
V Facilité de DT
• Moins d'apparitions de bugs

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 62

Les limites sont

1. Linéaire
2. Complet 5. Cohérence de la
3. Systématique fermeture
4. Orthogonal 6. Convexe
1. Limites linéaires 7. Simplement
Inégalités linéaires interprétées connecté
Hyperplan n-dim :
n+1 Points
n+1 + 1 cas de test

Non linéaire
Transformer
2. Limites complètes
V Couvrir l'espace numérique total (- oC , +
oC ) > Un ensemble de tests
Incomplet…
V Raisons
V/ Essais
3. Limites systématiques
V Inégalités linéaires différant par une
constante g (j, c) = j + k * c
V fj (X) ≥ kj ou, fj (X) ≥ g (j, c)

• Lignes parallèles

Secteurs identiques dans un cercle

DT
Tester un ^ Tests pour d'autres domaines
domaine O
4. Limites orthogonales
V Deux limites ou ensembles de limites
V Parallèle aux axes
V DT
> Chaque ensemble indépendamment
> # Teste un O (n)
Limites orthogonales
Ensembles inclinés en V
> transformation
> Cas de test : O(n)

V Cercles concentriques avec lignes radiales

> Coordonnées rectangulaires
> Polaire
r ≥ aj .ET. r < aj+1 .ET.

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 63

e≥ej .ET. e
Limites non orthogonales
• Intersections de test = O ( n2 ) + O (n)

V Exemple
> Même opérateur relationnel pour les limites
systématiques

6. Domaine convexe
V La ligne joignant deux points quelconques se trouve
dans le domaine
V DT
> n points actifs et 1 point hors-champ

Concave
V « Mais, cependant, sauf, ou… » dans Spécifications
Manipulez le V avec un soin particulier
7. Domaine simplement connecté
• En une seule pièce

V 2 domaines complémentaires
> D1 : Convexe ^ D2 : Concave, non connecté
Programmeur / Designer V
> Partie convexe Première

Domaines laids
En général
De mauvaises spécifications
Programmeur / Designer simplifie => Du laid au bon
possibilité d'introduction de plus de bugs ?!?
Causes
1. Limites non linéaires
2. Ambiguïtés et contradictions
3. Simplifier la topologie
4. Rectifier les fermetures de frontières

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 64

1. Limites non linéaires

Transformation en V
2. Ambiguïtés
V Trous dans l'espace vectoriel d'entrée.
V Limite manquante
V Détecté par les langages et outils de spécification.
Contradictions..
• Chevauchement de
• Remplissage de
trous

• Assemblage des
pièces

3. Simplification de la topologie
V Complexité !
> Concavité, trous, déconnexion
• Lissage de la concavité

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 65

Correct:
> Connecter des segments de limite déconnectés
> Repousser les limites à l'infini
4. Rectification des fermetures de frontières.
V crée des fermetures dans une direction pour des limites parallèles avec des fermetures
dans les deux directions • Forcer un hyperplan englobant à appartenir au domaine.

Stratégie générale de DT
V Sélectionnez des points de test proches des limites.
V Définir une stratégie de test pour chaque bug possible lié à la limite
V Points de test pour un domaine utiles pour tester son domaine adjacent.
V Exécutez les tests. Grâce à une analyse post-test, déterminez si des limites sont défectueuses et
si oui, comment ?
V Exécutez suffisamment de tests pour vérifier chaque limite de chaque domaine
DT pour les bugs de domaine spécifiques
En général,
V Point intérieur
V Point extérieur
V Quartier Epsilon
V Point extrême

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 66

K. Nuka Raju Professeur associé, DIET

 Méthodologies de test de logiciels Page | 67

1. Domaines 1-d
2. Domaines 2D
3. Prédicats d'égalité et d'inégalité
4. Tests aléatoires
5. Test des domaines n-dimensionnels
1. Test des domaines 1-D : Des insectes aux frontières ouvertes

Bug de
fermeture

Bug de
décalage vers
la gauche

Bug de
décalage vers la
droite

Limite manquante

Limite
supplémentaire

2. Test des domaines 2D

1. Bug de fermeture
2. Décalage des limites : haut/bas
3. Limite inclinée
4. Limite supplémentaire
5. Limite manquante

Figue:
2 n : Tests de partage de domaines
3 n : pas de partage de tests par
domaines

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 68

3. Prédicats d'égalité et d'inégalité

• Un prédicat d'égalité définit une ligne en 2D

4. Tests aléatoires
Point VA au centre : vérifie le calcul

5. Test des domaines n-dimensionnels (stratégie) n-

dimensions, p segments de frontière
V (n+1)*p cas de test : n points actifs et 1 point hors tension
{ Extrême pt partagé : 2 * p points
{ Les égalités sur m dimensions créent un sous-espace de nm dimensions
V Domaines orthogonaux avec fermetures de limites cohérentes, orthogonales aux axes et limites
complètes
Procédure de > Tests indépendants
résolution des
valeurs Procédure simple.
Identifier les variables d'entrée
Besoin ud'outils.
n. Identifier les variables qui apparaissent dans les prédicats définissant le domaine, tels que les
b. prédicats de contrôle de flux
c. Interpréter tous les prédicats de domaine en termes de variables d'entrée :
1. Transformer le non-linéaire en linéaire
d. 2. Trouver le chemin du flux de données
Expression de prédicat avec p # prédicats.
f. Trouver # domaines : < 2 p
f. Résoudre les inégalités pour les points extrêmes
Utilisez des points extrêmes pour résoudre les problèmes proches des points…
K. Nuka Raju Professeur associé, DIET
Méthodologies de test de logiciels Page | 69

Efficacité
V Rentable
V Bugs sur les limites, points extrêmes
V Tests logiques du matériel – outils intensifs

Tests de domaines et d'interfaces

Domaine V
• Gamme

Test de
compatibilité de la plage d'interface/du domaine
V Testez chaque variable indépendamment
V Trouver une fonction inverse
• Construire un super domaine

Test de domaine – Questions des examens de l'année précédente

1. Expliquez les domaines sympas et laids.

2. Qu'est-ce que le test de domaine ? Discuter des applications des tests de domaine
3. Expliquez les bugs de limite de domaine pour les domaines bidimensionnels
4. Quel est le but des tests de domaine ? Donner sa représentation schématique
5. Définissez les concepts suivants.
1. Domaines
2. Fermeture de domaine
3. Dimensionnalité du domaine
4. Hypothèses de bugs pour les tests de domaine
6. Expliquez les limites simples des domaines et les prédicats composés.
7. Classez ce qui peut mal se passer avec les limites, puis définissez une stratégie de test pour
chaque cas dans les tests de domaine.

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 70

Unité – V
Chemins, produits de chemin et expressions régulières

Chemin Produits et expressions

Motivation:
V Le graphique de flux est une représentation abstraite d'un programme.
V Une question sur un programme peut être mappée sur une question équivalente sur un graphique de
flux approprié.
V Ce sera une base pour les tests de syntaxe et les tests d'état
Expression de chemin
V Une représentation algébrique d'ensembles de chemins dans un graphe de flux.
Expression régulière
V Expressions de chemin converties à l'aide de lois et de poids arithmétiques en une fonction algébrique.
V Annotez chaque lien avec un nom.
V Le nom du chemin lorsque vous parcourez un chemin (segment) exprimé sous forme de concaténation
des noms de liens est le produit du chemin.

V Exemples de produits de chemin entre 1 et 4 : abd abccbdabcbcbd

Expression de chemin
• Simplement : dériver en utilisant les produits de chemin.

V Exemple
1. { abd, abcbd, abcbcbd , ….. } abd + abcbd + abcbcbd + ….

2. { abcd , abfhebcd , abfigebcd , abfijd }

abcd + abfhebcd + abfigebcd + abfijd

V Non commutatif :

Le nom du chemin pour deux segments de chemin successifs est la concaténation de

leurs produits de chemin. Y = déf
X = abc XY = abcdef
un X = aabc X a = abc XaX = abc abc
X = ab + cd Y = ef + gh XY = abef + abgh + cdef + cdgh
Segments de parcours et produits
Boucles en V
an
a1
= un a2
= aa a3
= aaa = aaaaa … n fois
X2
X = abc X1
= abc = (abc)2 = abc-bc
• Élément
d'identitéa0 = 1 X0
=1 (chemin de longueur 0)
Chemin Produit
XY ≠ YX en général
• Associatif
A ( BC ) = ( AB ) C = ABC : Règle 1
Désigne un ensemble de chemins en parallèle entre deux nœuds.
• Commutatif

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 71

X + Y = Y + X • Associatif : Règle
(X+Y)+Z=X+(Y+Z)=X+Y+Z :Règle 32
• Distributif
X + tout sous-ensemble de X = X : Règle 4
X = a + bc + abcd X + a = X + bc + abcd =X
• Boucle
Un ensemble infini de chemins parallèles.

b* = b0 + b1 + b2 + b3 + …… ()b
X* = X0 + X1 + X2 + X3 + …… un c"
X+ = X1 + X2 + X3 + …
• XX* = X* X = X+ ♦ aa* = a* a
Xn X0 X1 X2 X3
= + + + Plus de + …… + Xn
• règles…
Xm
+ Xn = Xn si n ≥ m :Règle 6
= Xm si n < m
Xm Xn
= Xm+n :Règle 7
Xn
X* = X* Xn = X* : Règle 8
Xn
X+ = X+ Xn = X+ :Règle 9
X X+ = X+ X* = X+
* :Règle 10
• Éléments d'identité ..
1 : Chemin de longueur nulle
1+1 = 1 :Règle 11
1X = X1 = X :Règle 12
1n
= 1n = 1* = 1+ = 1 :Règle 13
1+ + 1 = 1* = 1 :Règle 14
0 : ensemble de chemins vide
:Règle 15
X+0=0+X=X
:Règle 16
X0 = 0X = 0
* ..=1 :Règle 17
0 = 1 + 0 + 02 + 03 + .
A (B + C) = AB + AC (A
+ B) C = AC + BC
Absorption
X+X=X : Règle 5
Procédure de réduction

+
un

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 72

V Pour convertir un graphique de flux en une expression de chemin qui désigne l'ensemble
Procédure
de de réduction
tous les chemins nœud par nœud
d'entrée/sortie.
en V
Étapes d'initialisation
1. Combinez toutes les liaisons série en multipliant leurs
2. expressions de chemin.
*
3. Supprimez
Combinez tous les liens parallèles en ajoutant leurs
toutes les boucles automatiques - remplacez-
4. les par des liens de la forme X Sélectionnez un nœud non 1
Remplacez-le par un ensemble de liens équivalents, dont les expressions de chemin correspondent à
toutes les manières dont vous pouvez former un produit de l'ensemble des liens entrants avec
l'ensemble des liens sortants de ce nœud.

5. Combinez toutes les liaisons série en multipliant leurs expressions de chemin. (comme à l'étape 1)
6. Combinez tous les liens parallèles en ajoutant leurs expressions de chemin. (comme à l'étape
2)
7. Retirez toutes les boucles automatiques. (comme à l'étape 3)
8. S'il n'y a qu'un seul nœud entre les nœuds d'entrée et de sortie, l'expression du chemin pour le
graphique de flux est l'expression du chemin du lien. SINON, revenez à l'étape 4.
Expression de chemin pour un graphe de flux
V n'est pas unique
V dépend de l'ordre de suppression des nœuds.
Exemple de procédure de réduction
Étape inter-termes (étape 4 de l'algorithme)
V Étape fondamentale.
V Supprime les nœuds un par un jusqu'à ce qu'il y ait un nœud d'entrée et un nœud de sortie.
V Remplacez le nœud par les produits de chemin de tous les liens entrants avec tous les liens sortants
et en interconnectant ses voisins immédiats.
Traitement des termes de boucle

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 73

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 74

Exemple

(bgif)*b(c+gkh)d

(ilhd)*imf(bgif)*b(c+gkh)d

{(ilhd)*imf(bgif)*b(c+gkh)d}* (ilhd)*e
------------------------ — ----------------------(
2

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 75

Expression du chemin du graphique de flux :

a(bgif)*b(c+gkh)d {(ilhd)*imf(bgif)*b(c+gkh)d}* (ilhd)*e

Identités/Règles
(A+B)* = ( A* + B* ) * I1
= ( A* B* )* I2
= ( Un * B ) * Un * I3
= ( B* Un )* B* I4
= (A*B+A)* I5
= (B*A+B)* I6
(A+B+C+. ..)* = ( A* + B* + C* . )* I7
= ( A* B* C* . . . )* I8
Dérivé en supprimant les nœuds dans des ordres différents et en appliquant les règles de
boucle série-parallèle.
Graphiques de flux structurés
Réductible à un seul lien par application successive des transformations présentées ci-
dessous.

Transformations de graphes de flux structurés

Propriétés
V Aucune transformation interterme.
V Pas de GOTO.
V Aucune entrée ni sortie au milieu d'une boucle.
Quelques exemples

K. Nuka Raju Professeur associé, DIET

Méthodologies de test de logiciels Page | 76

Branchement vers les décisions Dérivation des décisions

Graphiques/codes de flux non structurés :
Questions des examens de l'année précédente
1. Rédigez de brèves notes sur : les produits de chemin, les expressions de chemin,
les sommes de chemin, les boucles.
2. Définir un code structuré. Expliquez l'arithmétique du nombre de chemins
inférieurs.
3. Quelle est la probabilité de boucle d'une expression de chemin. Écrire des règles
arithmétiques. Expliquez avec un exemple.
4. Écrivez les étapes impliquées dans la procédure de réduction des nœuds.
Illustrez toutes les étapes à l’aide de schémas clairement étiquetés.

K. Nuka Raju Professeur associé, DIET