Vérifier méthodiquement la correction, la robustesse et la fiabilité d’une solution

Fiche pédagogique du chapitre

Objectifs d’apprentissage

À la fin de ce chapitre, l’étudiant devra être capable de :

• expliquer le rôle des tests dans le développement d’un algorithme ;
• construire un jeu d’essai contenant des cas normaux, limites et incorrects ;
• identifier les valeurs minimales et maximales pertinentes pour un problème ;
• réaliser une table de trace afin de suivre l’évolution des variables et des conditions ;
• analyser le comportement d’une boucle sur plusieurs itérations ;
• distinguer une erreur de syntaxe, une erreur d’exécution et une erreur logique ;
• détecter une boucle infinie et une mauvaise initialisation ;
• valider les données saisies avant leur utilisation ;
• concevoir une saisie contrôlée qui se répète tant que la donnée est invalide ;
• tester un algorithme de manière méthodique et documenter les résultats obtenus.

Prérequis

• connaître les variables, les constantes et les types de données simples ;
• savoir utiliser les opérateurs arithmétiques, relationnels et logiques ;
• maîtriser les structures conditionnelles ;
• maîtriser les boucles Pour, TantQue et Répéter…Jusqu’à ;
• savoir lire et écrire un algorithme en pseudo-code.

Plan du chapitre

7.1 Jeu d’essai

7.2 Table de trace

7.3 Types d’erreurs

7.4 Validation des données

Applications, exercices, corrigés et synthèse

Organisation pédagogique indicative

Introduction aux tests et à la validation

La conception d’un algorithme ne s’arrête pas à son écriture. Une solution qui paraît correcte à la lecture peut contenir une erreur de calcul, une condition mal formulée, une variable non initialisée ou une boucle qui ne se termine jamais. Le test consiste à exécuter mentalement ou réellement l’algorithme avec des données choisies afin d’observer son comportement.

La validation vise à vérifier que l’algorithme répond au problème posé pour toutes les données autorisées. Elle s’appuie sur des jeux d’essai pertinents, des résultats attendus connus, des tables de trace et une analyse systématique des erreurs. Tester ne permet pas toujours de démontrer mathématiquement l’absence totale d’erreur, mais cela augmente fortement la confiance accordée à la solution.

7.1 Jeu d’essai

7.1.1 Définition d’un jeu d’essai

Un jeu d’essai est un ensemble organisé de données utilisées pour tester un algorithme. Chaque donnée ou combinaison de données constitue un cas de test. Pour chaque cas, on précise les entrées, le résultat attendu et, après exécution, le résultat obtenu.

Un jeu d’essai de qualité ne se limite pas à une seule valeur choisie au hasard. Il couvre les situations représentatives du problème : fonctionnement habituel, frontières du domaine, données interdites et cas particuliers susceptibles de révéler une erreur.

7.1.2 Cas normal

Un cas normal correspond à une situation courante, clairement située à l’intérieur du domaine valide. Il permet de vérifier le fonctionnement principal de l’algorithme, sans solliciter immédiatement ses frontières.

Pour un algorithme qui calcule la moyenne de trois notes comprises entre 0 et 20, le triplet (12, 14, 16) constitue un cas normal. Le résultat attendu est 14.

7.1.3 Cas limite

Un cas limite utilise une valeur placée sur une frontière du domaine ou juste à proximité. Les erreurs de comparaison apparaissent fréquemment à ces endroits, par exemple lorsque l’on écrit < au lieu de ≤.

• Borne minimale : tester la plus petite valeur autorisée.
• Borne maximale : tester la plus grande valeur autorisée.
• Valeur juste en dessous : vérifier que la valeur interdite est rejetée.
• Valeur juste au-dessus : vérifier que la valeur interdite est également rejetée.

7.1.4 Cas incorrect

Un cas incorrect fournit une donnée qui ne respecte pas les règles du problème. Il permet de vérifier que l’algorithme refuse proprement la valeur, affiche un message compréhensible et évite un calcul impossible.

• une note égale à 25 alors que les notes doivent être comprises entre 0 et 20 ;
• un diviseur égal à zéro ;
• une chaîne de caractères saisie alors qu’un entier est attendu ;
• une date impossible telle que le 31 février ;
• une quantité négative pour un nombre d’articles.

7.1.5 Valeurs minimales et maximales

Les valeurs minimales et maximales peuvent être imposées par l’énoncé, par le type de donnée, par une règle métier ou par une contrainte physique. Elles doivent être identifiées avant la rédaction des tests.

7.1.6 Méthode de construction d’un jeu d’essai

1. Identifier précisément les entrées et leur domaine autorisé.
2. Déterminer les résultats attendus sans utiliser l’algorithme à tester.
3. Choisir au moins un cas normal représentatif.
4. Ajouter les bornes minimales et maximales.
5. Tester les valeurs situées juste avant et juste après les bornes.
6. Ajouter des données incorrectes et des cas particuliers.
7. Exécuter ou tracer l’algorithme pour chaque cas.
8. Comparer les résultats obtenus aux résultats attendus et documenter les écarts.

7.1.7 Exemple complet : validation d’une note

Algorithme étudié

7.2 Table de trace

7.2.1 Définition et objectif

Une table de trace est un tableau qui représente, étape par étape, l’exécution d’un algorithme. Chaque ligne correspond généralement à une instruction significative ou à une itération. Les colonnes représentent les variables, les conditions évaluées et les sorties produites.

Le traçage manuel oblige à respecter l’ordre exact des instructions. Il permet de comprendre un algorithme, de vérifier les calculs intermédiaires et de localiser l’endroit où le comportement s’écarte du résultat attendu.

7.2.2 Suivi de l’évolution des variables

À chaque affectation, la nouvelle valeur remplace l’ancienne. La table doit donc indiquer l’état de la variable après l’exécution de l’instruction. Lorsque la variable n’a pas encore reçu de valeur, on peut noter « non définie ».

Exemple séquentiel

7.2.3 Suivi des conditions

Lorsqu’un algorithme rencontre une condition, celle-ci est évaluée à Vrai ou Faux. La table de trace doit indiquer la valeur de la condition et la branche réellement exécutée.

Extrait conditionnel

7.2.4 Suivi des répétitions

Pour une boucle, chaque itération est représentée séparément. Il faut suivre la variable de contrôle, les accumulateurs, la condition de continuation et les valeurs affichées. Cette représentation révèle souvent les erreurs de borne ou de mise à jour.

Somme de 1 à 4

À la sortie de la boucle, la variable somme vaut 10. Le résultat correspond à 1 + 2 + 3 + 4.

7.2.5 Détection des erreurs

Une table de trace permet de détecter plusieurs anomalies : valeur utilisée avant initialisation, condition toujours vraie, compteur non modifié, calcul effectué une fois de trop ou de moins, mauvaise branche conditionnelle et écrasement prématuré d’une variable.

7.2.6 Conseils pour construire une table de trace

• créer une colonne pour chaque variable importante ;
• ajouter une colonne pour les conditions qui déterminent le chemin d’exécution ;
• indiquer les sorties produites par les instructions Écrire ;
• utiliser une ligne par étape ou par itération ;
• ne pas modifier une valeur avant d’avoir utilisé l’ancienne valeur dans le calcul ;
• arrêter la trace dès que l’algorithme se termine ou lorsqu’une boucle infinie est démontrée.

7.3 Types d’erreurs

7.3.1 Erreur de syntaxe

Une erreur de syntaxe correspond au non-respect des règles d’écriture du pseudo-code ou du langage de programmation. Le traducteur, l’interpréteur ou le compilateur ne peut pas comprendre correctement l’instruction.

• mot-clé mal orthographié ;
• parenthèse ou guillemet non fermé ;
• FinSi, FinPour ou FinTantQue manquant ;
• opérateur d’affectation mal utilisé ;
• séparateur ou indentation incorrecte dans certains langages.

Exemple d’erreur de syntaxe

7.3.2 Erreur d’exécution

Une erreur d’exécution apparaît lorsque l’algorithme est syntaxiquement acceptable, mais rencontre une opération impossible pendant son fonctionnement. Elle dépend souvent des données fournies.

• division par zéro ;
• accès à une position inexistante d’un tableau ;
• conversion impossible d’une chaîne en nombre ;
• fichier ou ressource indisponible ;
• dépassement de capacité numérique.

Algorithme vulnérable à une division par zéro

Pour a = 10 et b = 2, le calcul réussit. Pour b = 0, l’algorithme tente une opération interdite. La donnée doit donc être validée avant la division.

7.3.3 Erreur logique

Une erreur logique produit un résultat incorrect sans nécessairement interrompre l’exécution. Elle est souvent plus difficile à détecter, car le programme semble fonctionner. Elle provient d’une mauvaise formule, d’une condition incorrecte ou d’un ordre d’instructions inadapté.

Formule incorrecte à cause de la priorité des opérateurs

L’expression précédente divise uniquement note3 par 3. La formule correcte est : moyenne <- (note1 + note2 + note3) / 3.

7.3.4 Boucle infinie

Une boucle infinie ne rencontre jamais sa condition d’arrêt. Elle se produit lorsque la condition est toujours vraie ou lorsque les variables qui influencent cette condition ne sont pas correctement modifiées.

Boucle infinie : i n’est jamais incrémenté

La correction consiste à ajouter i <- i + 1 dans la boucle. Il faut ensuite vérifier que la progression rapproche effectivement la variable de la condition d’arrêt.

7.3.5 Mauvaise initialisation

Une variable d’accumulation, de comptage ou de recherche doit recevoir une valeur initiale adaptée. Une mauvaise initialisation fausse toutes les étapes suivantes.

Mauvaise initialisation d’un produit

Le produit restera toujours égal à zéro. Pour calculer 1 × 2 × 3 × 4, il faut initialiser produit à 1.

7.3.6 Tableau récapitulatif

7.4 Validation des données

7.4.1 Principe général

Valider une donnée consiste à vérifier qu’elle possède le type, le format et la valeur attendus avant de l’utiliser. La validation protège l’algorithme contre les calculs impossibles et améliore la qualité des messages adressés à l’utilisateur.

7.4.2 Vérification d’un intervalle

Pour vérifier qu’une valeur x appartient à l’intervalle [min, max], on utilise la condition x >= min ET x <= max. Pour rejeter la valeur et répéter la saisie, la condition de boucle peut être x < min OU x > max.

Validation d’une note

7.4.3 Contrôle du type de donnée

Le contrôle du type vérifie qu’une saisie peut être interprétée comme un entier, un réel, un booléen ou une autre donnée attendue. Dans un pseudo-code introductif, on peut représenter ce contrôle par une opération EstEntier ou LectureRéussie. Dans un langage de programmation, il faut utiliser les mécanismes de conversion et de gestion des erreurs proposés par le langage.

Schéma conceptuel de contrôle du type

Le contrôle du type doit précéder le contrôle de l’intervalle. Il est impossible de comparer correctement le texte « douze » aux nombres 0 et 20.

7.4.4 Répétition de la saisie en cas d’erreur

Une saisie contrôlée est généralement réalisée avec TantQue ou Répéter…Jusqu’à. La boucle Répéter est naturelle lorsque l’on souhaite obligatoirement demander la valeur une première fois.

7.4.5 Gestion des valeurs impossibles

Certaines valeurs sont syntaxiquement correctes et appartiennent au bon type, mais restent impossibles dans le contexte. Une quantité négative, un mois égal à 13 ou une date du 31 février sont des exemples de valeurs sémantiquement impossibles.

• vérifier les contraintes générales : signe, intervalle et format ;
• vérifier les contraintes dépendantes d’autres données ;
• afficher un message qui indique précisément la règle non respectée ;
• éviter de poursuivre le traitement avec une valeur invalide ;
• prévoir éventuellement une option d’annulation ou une valeur sentinelle clairement documentée.

7.4.6 Ordre recommandé des validations

1. Vérifier que la donnée a bien été saisie.
2. Vérifier le type ou le format.
3. Vérifier les bornes générales.
4. Vérifier les règles métier et les dépendances entre données.
5. Accepter la donnée et poursuivre le traitement uniquement si tous les contrôles réussissent.

7.4.7 Messages d’erreur utiles

Applications guidées

Les applications suivantes mettent en œuvre les méthodes de validation et de test étudiées. Pour chacune, on identifie le domaine valide, on écrit l’algorithme, puis on propose un jeu d’essai.

Application 1 — Vérifier qu’une note est comprise entre 0 et 20

Le programme doit demander une note réelle et répéter la saisie tant que la valeur n’appartient pas à l’intervalle [0, 20].

Application 2 — Vérifier qu’un diviseur est différent de zéro

Avant une division, le diviseur doit être contrôlé. Le dividende peut être nul, positif ou négatif, mais le diviseur ne doit jamais être nul.

Application 3 — Demander un nombre positif

L’expression « nombre positif » doit être interprétée avec précision. En mathématiques, strictement positif signifie supérieur à zéro. Si zéro est accepté, on parle de nombre positif ou nul.

Version à analyser

Version corrigée

Application 4 — Tester un algorithme sur plusieurs jeux de données

On considère un algorithme qui détermine la mention associée à une note valide : « Insuffisant » si la note est inférieure à 10, « Passable » de 10 inclus à 12 exclu, « Assez bien » de 12 inclus à 14 exclu, « Bien » de 14 inclus à 16 exclu et « Très bien » à partir de 16.

Ce jeu d’essai cible volontairement les seuils. Un test uniquement réalisé avec les notes 8, 13 et 18 ne permettrait pas de détecter une erreur sur les comparaisons aux valeurs 10, 12, 14 ou 16.

Synthèse du chapitre

Règles essentielles à retenir

• définir le résultat attendu avant d’exécuter un test ;
• inclure dans le jeu d’essai des cas normaux, limites, incorrects et particuliers ;
• tester les deux bornes et les valeurs situées immédiatement autour de celles-ci ;
• utiliser une table de trace pour suivre les variables, les conditions, les itérations et les sorties ;
• distinguer les erreurs de syntaxe, d’exécution et de logique ;
• initialiser chaque variable selon son rôle avant de l’utiliser ;
• vérifier qu’une boucle progresse vers une condition d’arrêt ;
• contrôler le type, le format, l’intervalle et les règles métier des données ;
• ne jamais effectuer une opération risquée avant d’avoir validé ses opérandes ;
• documenter chaque test par ses entrées, son résultat attendu, son résultat obtenu et son verdict.

Démarche de validation en cinq étapes

Fiche de test réutilisable

Travaux dirigés

Exercice 1 — Construire un jeu d’essai

Un algorithme accepte un âge compris entre 0 et 120 inclus. Proposer un jeu d’essai comprenant au moins deux cas normaux, les deux bornes, les valeurs juste en dehors des bornes et une donnée de type incorrect.

Exercice 2 — Tester un tarif de livraison

Les frais sont gratuits à partir de 500 DH, égaux à 30 DH pour un montant compris entre 200 DH inclus et 500 DH exclu, et égaux à 50 DH en dessous de 200 DH. Proposer un jeu d’essai centré sur les seuils.

Exercice 3 — Compléter une table de trace

Tracer l’algorithme suivant pour n = 5 : somme <- 0 ; Pour i allant de 1 à n Faire somme <- somme + 2*i FinPour. Indiquer i, somme avant et somme après chaque itération.

Exercice 4 — Détecter une erreur logique

L’algorithme calcule la moyenne de quatre notes avec l’expression moyenne <- n1 + n2 + n3 + n4 / 4. Expliquer l’erreur, proposer un jeu d’essai qui la met en évidence et corriger l’expression.

Exercice 5 — Corriger une boucle infinie

Analyser : i <- 10 ; TantQue i > 0 Faire Écrire(i) FinTantQue. Identifier l’erreur et proposer une correction qui affiche de 10 à 1.

Exercice 6 — Mauvaise initialisation

Un algorithme veut calculer le produit des entiers de 1 à n, mais initialise produit à 0. Montrer par une trace pour n = 3 pourquoi le résultat est incorrect, puis corriger l’initialisation.

Exercice 7 — Validation d’un choix de menu

Écrire un algorithme qui demande un choix entier compris entre 1 et 5 et répète la saisie tant que le choix n’est pas valide.

Exercice 8 — Validation d’une date simplifiée

Écrire un algorithme qui demande un mois et vérifie qu’il est compris entre 1 et 12. Ajouter ensuite un contrôle simplifié du jour : de 1 à 31.

Exercice 9 — Division contrôlée

Écrire un algorithme qui lit deux réels, contrôle que le second est différent de zéro, puis affiche leur quotient. Préparer quatre tests, dont un avec une première saisie invalide du diviseur.

Exercice 10 — Diagnostic d’erreurs

Pour chacun des cas suivants, indiquer le type d’erreur dominant : parenthèse manquante ; division par zéro ; moyenne calculée avec une formule incorrecte ; compteur non modifié dans TantQue ; maximum initialisé à zéro lorsque toutes les valeurs peuvent être négatives.

Corrigé indicatif des travaux dirigés

Corrigé de l’exercice 1

Corrigé de l’exercice 2

Corrigé de l’exercice 3

Corrigé de l’exercice 4

La division est appliquée uniquement à n4. Avec les notes 10, 10, 10 et 10, l’expression incorrecte donne 10 + 10 + 10 + 2,5 = 32,5 au lieu de 10. La correction est : moyenne <- (n1 + n2 + n3 + n4) / 4.

Corrigé de l’exercice 5

La variable i n’est jamais modifiée, donc la condition i > 0 reste toujours vraie.

Corrigé de l’exercice 6

Avec produit = 0, chaque multiplication donne 0 : 0 × 1 = 0, puis 0 × 2 = 0 et 0 × 3 = 0. L’élément neutre de la multiplication est 1 ; il faut donc écrire produit <- 1.

Corrigé de l’exercice 7

Corrigé de l’exercice 8

Ce contrôle reste simplifié : il accepte par exemple le 31 février. Une validation complète doit prendre en compte le nombre de jours de chaque mois et les années bissextiles.

Corrigé de l’exercice 9

Exemples de tests : (10, 2) → 5 ; (0, 3) → 0 ; (-9, 3) → -3 ; a = 8 et b saisi successivement 0 puis 4 → message d’erreur puis résultat 2.

Corrigé de l’exercice 10

Glossaire

Auto-évaluation

Répondre par « Oui », « Partiellement » ou « Non » aux affirmations suivantes :