CHAPITRE 2 : TEST LOGICIEL ET VALIDATION

« Tester peut révéler la présence de bugs, jamais leur absence. » La phrase est de Dijkstra, elle date de 1970, et elle n'a pas vieilli. Elle ne dit pas que tester est inutile : elle dit ce qu'on achète avec un test : de la confiance, pas une garantie. Tout l'art consiste à obtenir le plus de confiance possible avec le moins de tests possible.

Vérification et validation : deux questions distinctes

On emploie souvent les deux mots comme des synonymes. Ils répondent pourtant à des questions différentes, et confondre les deux coûte cher.

La vérification demande : construit-on le produit correctement ? Le logiciel est-il conforme à sa spécification ?
La validation demande : construit-on le bon produit ? La spécification répond-elle au besoin réel ?

Un logiciel peut passer toute la vérification et rater la validation : il fait exactement ce qui est écrit, et ce qui est écrit ne sert à personne. C'est le projet livré dans les délais, conforme au cahier des charges, que les utilisateurs n'ouvrent jamais.

La vérification se mesure contre un document. La validation se mesure contre un usage. Il faut les deux.

Les quatre niveaux de test

Le cycle en V est souvent présenté comme un modèle de développement dépassé. Son intérêt reste intact pour une raison : il met en face de chaque document de conception le niveau de test qui le vérifie.

Niveau	Objet	Qui l'écrit	Référence
Unitaire	une fonction, une classe, isolée	le développeur	la conception détaillée
Intégration	le dialogue entre modules	développeurs ou testeurs	la conception d'architecture
Système	le produit entier, en conditions réelles	l'équipe de test	les spécifications
Acceptation	la réponse au besoin	le client, ou son représentant	l'expression des besoins

Ce que le V apporte vraiment : les tests d'un niveau se préparent dès que son document de gauche est rédigé, pas à la fin. Écrire les tests d'acceptation au moment où l'on recueille les besoins est l'exercice le plus rentable du projet : il révèle les ambiguïtés avant la première ligne de code.

Combien de tests, et où ?

La forme n'est pas décorative, elle traduit une économie. Un test unitaire s'exécute en millisecondes et désigne précisément la fonction fautive. Un test de bout en bout prend des secondes, dépend du réseau, de la base, de l'affichage, et quand il échoue il faut encore chercher pourquoi.

La forme inverse, beaucoup de tests de bout en bout, peu de tests unitaires, porte un nom : le cône de glace. La suite devient lente, elle échoue au hasard, et au bout de quelques semaines l'équipe prend l'habitude de relancer sans lire. À ce moment, les tests ne servent plus à rien tout en coûtant encore.

Concevoir des cas de test sans lire le code

Les techniques boîte noire construisent les cas à partir de la spécification seule. Elles s'appliquent à tous les niveaux, et ce sont celles que les examens demandent le plus souvent.

Partitions d'équivalence et valeurs limites

L'idée des partitions d'équivalence : découper le domaine des entrées en classes telles que, à l'intérieur d'une classe, le programme se comporte de la même façon. Tester une valeur de la classe vaut alors pour toute la classe.

L'idée des valeurs limites : les erreurs se logent aux frontières. Un < écrit là où il fallait ≤, une borne oubliée. On teste donc les deux côtés de chaque frontière.

Sur une quantité acceptée de 1 à 50, on ne teste pas cinquante valeurs. On en teste six : 0 et 1 de part et d'autre de la borne basse, 50 et 51 de part et d'autre de la borne haute, plus 2 et 49 si l'on applique la variante à trois points. Tester 25 n'apprend rien que 2 n'apprenne déjà.

La table de décision

Quand le comportement dépend de plusieurs conditions combinées, les partitions ne suffisent plus : c'est la combinaison qui compte. La table de décision énumère les cas.

Chez NKILItech, la remise accordée dépend de deux conditions : le client est-il sous contrat, et l'intervention est-elle urgente ?

Cas	Sous contrat	Urgent	Remise appliquée
1	oui	non	20 %
2	oui	oui	10 %
3	non	non	0 %
4	non	oui	0 %, majoration de 15 %

Deux conditions booléennes donnent quatre combinaisons, donc quatre cas de test. Avec trois conditions on monte à huit, avec quatre à seize : la table sert aussi à montrer au client que sa règle est plus compliquée qu'il ne le croyait.

Mesurer ce qu'on a réellement testé

Les techniques boîte blanche partent du code. Leur produit le plus connu est la couverture.

Critère	Ce qu'il exige	Ce qu'il rate
Couverture d'instructions	chaque ligne exécutée au moins une fois	un `if` sans `else` : le cas faux n'est jamais pris
Couverture de branches	chaque condition évaluée à vrai et à faux	les combinaisons de conditions d'un `&&`
Couverture de chemins	chaque parcours complet	rien, mais le nombre de chemins explose avec les boucles

Un chiffre à manier avec prudence. « 90 % de couverture » ne dit pas que 90 % des comportements sont corrects. Cela dit que 90 % des lignes ont été exécutées : même sans qu'aucune assertion ne vérifie quoi que ce soit.

On peut atteindre 100 % de couverture avec des tests qui ne vérifient rien. La couverture détecte ce qui n'est pas testé ; elle ne prouve pas que le reste l'est bien.

Quand s'arrêter

Aucun critère ne dit « c'est fini ». On arrête sur une combinaison de signaux : le budget et le délai sont consommés, les critères de couverture convenus sont atteints, le taux de découverte de nouveaux défauts s'effondre, et les défauts restants sont connus et jugés acceptables.

Ce dernier point mérite d'être écrit noir sur blanc. Livrer avec des défauts connus est une décision normale : à condition qu'elle soit prise par celui qui en porte la responsabilité, et pas découverte par le client.

Ce qu'il faut retenir

Vérification : conforme à la spécification. Validation : conforme au besoin.
Quatre niveaux : unitaire, intégration, système, acceptation, chacun vérifie un document du cycle en V.
Les tests se préparent dès que leur document de référence existe.
Pyramide : beaucoup d'unitaires, peu de bout en bout. L'inverse est le cône de glace.
Partitions d'équivalence pour couvrir le domaine, valeurs limites pour les frontières, table de décision pour les combinaisons.
La couverture mesure ce qui a été exécuté, pas ce qui a été vérifié.
Un test ne prouve jamais l'absence de défaut.

Exercice d'application

Le module de calcul des pénalités de retard

NKILItech s'engage sur des délais d'intervention et verse une pénalité quand elle les dépasse. La règle, telle qu'elle figure au contrat :

Règle de pénalité

Le délai contractuel est de 48 heures. En deçà, aucune pénalité. De 48 heures exclues à 72 heures incluses, la pénalité vaut 5 % du montant de l'intervention. Au-delà de 72 heures, elle vaut 15 %. La pénalité est plafonnée à 50 000 FCFA. Elle ne s'applique pas aux clients hors contrat.

Identifiez les classes d'équivalence du délai, puis les valeurs limites à tester.
Construisez la table de décision des deux conditions « sous contrat » et « plafond atteint ».
Proposez un jeu de cas de test minimal, sous forme de tableau avec l'entrée et le résultat attendu. Prenez 400 000 FCFA comme montant de référence.
À quel niveau du cycle en V ces tests se situent-ils ? Quel autre niveau faut-il prévoir, et pourquoi ?
La spécification contient une ambiguïté. Laquelle, et comment la lèveriez-vous ?

Voir le corrigéMasquer

1. Classes et limites du délai.

Trois classes d'équivalence :

délai ≤ 48 → 0 %
48 < délai ≤ 72 → 5 %
délai > 72 → 15 %

Deux frontières, donc quatre valeurs limites immédiates : 48 et 49 autour de la première, 72 et 73 autour de la seconde.

Attention à la lecture : 48 appartient à la classe sans pénalité (« en deçà », et 48 h est le délai contractuel respecté), tandis que 72 appartient à la classe à 5 % puisque la borne est incluse. C'est exactement le genre de détail qu'un < écrit pour un ≤ fait basculer.

Si l'unité est l'heure entière, 49 et 73 sont les premiers dépassements. Si le délai peut être fractionnaire, il faut tester 48,01 et 72,01, ce qui renvoie à la question 5.

2. Table de décision.

Cas	Sous contrat	Pénalité calculée > 50 000	Résultat
1	non	sans objet	0 FCFA
2	oui	non	la pénalité calculée
3	oui	oui	50 000 FCFA

Le cas « hors contrat » rend la seconde condition sans objet : inutile de le dédoubler. Une table de décision bien faite fusionne les colonnes indifférentes au lieu d'énumérer mécaniquement les quatre combinaisons.

3. Jeu de cas de test. Montant de référence : 400 000 FCFA. À 5 %, la pénalité vaut 20 000 ; à 15 %, elle vaut 60 000, donc au-dessus du plafond.

N°	Contrat	Délai (h)	Montant	Attendu	Ce qu'il éprouve
1	oui	47	400 000	0	classe sans pénalité
2	oui	48	400 000	0	borne basse incluse
3	oui	49	400 000	20 000	premier dépassement
4	oui	72	400 000	20 000	borne haute incluse
5	oui	73	400 000	50 000	passage à 15 %, et plafond
6	oui	73	300 000	45 000	15 % sous le plafond
7	oui	80	340 000	50 000	plafond exactement atteint
8	non	96	400 000	0	hors contrat, retard majeur

Vérification du cas 6 : 15 % de 300 000 = 45 000, sous le plafond, donc versé tel quel. Du cas 7 : 15 % de 340 000 = 51 000, au-dessus du plafond, ramené à 50 000. Le cas 7 est le plus intéressant du lot : il se tient juste au-dessus de la frontière du plafond.

Huit cas couvrent trois classes de délai, les quatre valeurs limites, les deux côtés du plafond et la condition de contrat.

4. Niveaux concernés.

Ces cas sont des tests unitaires : ils portent sur une fonction de calcul, avec des entrées simples et un résultat vérifiable sans rien d'autre.

Il faut prévoir au moins deux autres niveaux. Un test d'intégration, parce que la fonction ne décide pas seule qu'un client est sous contrat : elle interroge l'annuaire des clients, et ce dialogue peut échouer, répondre lentement ou renvoyer une valeur inattendue. Et un test d'acceptation, pour que le client confirme que la règle appliquée est bien celle qu'il avait en tête, ce qui nous amène au point suivant.

5. L'ambiguïté.

« De 48 heures exclues à 72 heures incluses » : que vaut un délai de 48 h 30 ?

La spécification ne dit pas si le délai se compte en heures entières ou s'il peut être fractionnaire. Si l'on arrondit à l'heure inférieure, 48 h 30 devient 48 h et ne donne aucune pénalité. Si l'on arrondit au-dessus, elle devient 49 h et déclenche les 5 %. Sur une intervention à 400 000 FCFA, l'écart est de 20 000 FCFA, et il se produira régulièrement.

Une seconde zone d'ombre : le plafond de 50 000 FCFA est-il par intervention ou par mois et par client ? Le contrat dit « la pénalité est plafonnée », au singulier, ce qui suggère l'intervention, mais ce n'est qu'une interprétation.

Comment on la lève : on ne devine pas, on demande, et on fait écrire la réponse dans la spécification. C'est précisément à cela que sert l'écriture des tests d'acceptation au moment du recueil des besoins : elle force la question avant que le code n'existe, pas après la première facture contestée.

Pour vous évaluer. Un sujet d'examen complet accompagne ce chapitre : un QCM de dix questions, deux exercices et un problème d'entreprise, le tout corrigé.

Examen Test logiciel et validation : Génie logiciel avancé