Examen de génie logiciel avancé : 2. Test logiciel et validation
Sujet
Partie 1 : Questionnaire à choix multiple
- Selon la formule de Dijkstra, un test peut :
- prouver l'absence de défauts
- révéler la présence de défauts
- garantir la conformité au besoin
- remplacer la relecture de code
- La validation répond à la question :
- construit-on le produit correctement ?
- construit-on le bon produit ?
- le code respecte-t-il les conventions ?
- les performances sont-elles suffisantes ?
- Le niveau de test qui répond à la conception d'architecture est :
- le test unitaire
- le test d'intégration
- le test système
- le test d'acceptation
- Une saisie accepte un entier de 10 à 99. Les valeurs limites à tester sont :
- 10 et 99
- 9, 10, 99 et 100
- 0, 10, 99 et 999
- 1, 10, 50, 99 et 100
- Atteindre 100 % de couverture d'instructions garantit :
- que toutes les branches ont été empruntées
- que chaque ligne a été exécutée au moins une fois
- qu'aucun défaut ne subsiste
- que toutes les combinaisons de conditions ont été éprouvées
- Le « cône de glace » désigne une suite de tests :
- entièrement automatisée
- comportant beaucoup de tests de bout en bout et peu de tests unitaires
- exécutée uniquement avant la livraison
- dont la couverture dépasse 90 %
- Une table de décision à trois conditions booléennes indépendantes comporte :
- 3 cas
- 6 cas
- 8 cas
- 9 cas
- Les tests d'acceptation sont écrits, idéalement :
- par les développeurs, après le codage
- avec le client, au moment du recueil des besoins
- par l'équipe de test, après le test système
- automatiquement, à partir du code
- Un test de non-régression sert à :
- mesurer les performances après une montée en charge
- vérifier qu'une modification n'a pas cassé ce qui fonctionnait
- valider une nouvelle fonctionnalité
- contrôler la couverture du code
- Pour tester un module qui appelle un service distant, on remplace :
- le module par une doublure
- le service distant par une doublure
- les deux par des doublures
- aucun des deux : on teste en réel
Partie 2 : Exercices
Partitions et valeurs limites
Une bibliothèque applique la règle suivante au prêt d'ouvrages :
Règle de prêt
Un adhérent peut emprunter de 1 à 5 ouvrages. En dessous de 1, la demande est rejetée ; au-delà de 5, elle est rejetée également. La durée du prêt est de 14 jours, portée à 21 jours si l'adhérent a plus de 60 ans.
- Donnez les classes d'équivalence du nombre d'ouvrages, puis les valeurs limites à tester.
- Donnez les classes d'équivalence de l'âge, puis les valeurs limites.
- Proposez le jeu de cas de test minimal sous forme de tableau.
Table de décision
Un site de vente applique les frais de livraison suivants :
Règle de livraison
La livraison est gratuite si la commande dépasse 50 000 FCFA. Les clients abonnés bénéficient de la gratuité sans condition de montant. Pour les autres, les frais s'élèvent à 2 000 FCFA, portés à 5 000 FCFA si la livraison est express.
- Identifiez les conditions et les actions.
- Construisez la table de décision complète, puis la table simplifiée.
- Combien de cas de test retenez-vous, et lesquels ?
Partie 3 : Problème
NKILItech : tester le module de facturation
Le module de facturation de NKILItech reçoit une intervention et produit une facture. Il s'appuie sur deux services distants, représentés en pointillés sur le schéma.
Règles de facturation
La durée facturée est arrondie au quart d'heure supérieur, avec un minimum facturé d'une heure. Le tarif horaire vaut 15 000 FCFA pour un client sous contrat et 25 000 FCFA sinon. Les pièces sont facturées au prix coûtant, sans marge. Le numéro de facture est séquentiel et ne doit jamais être réutilisé.
- Pour chacun des quatre niveaux de test, dites ce que vous éprouveriez sur ce module. Soyez précis : donnez pour chaque niveau un exemple de ce que le niveau au-dessous ne peut pas détecter.
- Concevez les cas de test de
calculerDuree()par partitions et valeurs limites. Justifiez chaque valeur. - Donnez quatre cas de test de
appliquerTarif(), avec les montants attendus calculés. - Les deux services distants posent un problème pour les tests unitaires. Lequel, et comment le résolvez-vous ?
- Le numéro de facture ne doit jamais être réutilisé. Proposez un test qui éprouve cette exigence, et expliquez pourquoi un test unitaire classique n'y suffit pas.
Correction
Cherchez avant d'ouvrir. Les corrigés détaillent le raisonnement attendu et le barème.
Corrigé du QCMMasquer
1. Réponse b : révéler la présence de défauts
Un test explore quelques points du domaine d'entrée. Il peut montrer qu'un défaut existe ; il ne peut jamais couvrir tous les cas, donc jamais conclure qu'il n'en reste aucun.
2. Réponse b : construit-on le bon produit ?
La vérification compare le logiciel à sa spécification. La validation compare la spécification au besoin réel. Un logiciel parfaitement vérifié peut échouer à la validation.
3. Réponse b : le test d'intégration
Dans le cycle en V, chaque niveau fait face au document qu'il vérifie. L'architecture décrit comment les modules s'assemblent : c'est l'intégration qui l'éprouve.
4. Réponse b : 9, 10, 99 et 100
On teste de part et d'autre de chaque frontière : 9 et 10 pour la borne basse, 99 et 100 pour la borne haute. Tester 50 n'apprend rien de plus que 10.
5. Réponse b : que chaque ligne a été exécutée au moins une fois
Un if sans else atteint 100 % d'instructions sans jamais éprouver le cas faux. La couverture d'instructions est le critère le plus faible des trois.
6. Réponse b : comportant beaucoup de tests de bout en bout et peu de tests unitaires
C'est la pyramide renversée. La suite devient lente et instable ; l'équipe finit par relancer sans lire, et les tests cessent de servir tout en coûtant encore.
7. Réponse c : 8 cas
Deux valeurs possibles par condition, trois conditions : 2³ = 8 combinaisons. On peut ensuite fusionner les colonnes où une condition est sans objet.
8. Réponse b : avec le client, au moment du recueil des besoins
Les écrire tôt force les questions avant que le code n'existe. C'est l'exercice le plus rentable du projet : il révèle les ambiguïtés de la spécification quand elles ne coûtent encore rien.
9. Réponse b : vérifier qu'une modification n'a pas cassé ce qui fonctionnait
Il rejoue des cas déjà passés. C'est le premier usage qui justifie d'automatiser : un test de non-régression manuel n'est jamais rejoué assez souvent.
10. Réponse b : le service distant par une doublure
On isole le module sous test en substituant une doublure au service distant. Cela rend le test rapide, reproductible, et permet de simuler les pannes qu'on ne saurait pas provoquer en réel.
Corrigé de l'exercice 1Masquer
1. Le nombre d'ouvrages.
Trois classes : n < 1 rejeté, 1 ≤ n ≤
5 accepté, n > 5 rejeté.
Valeurs limites : 0, 1, 5 et 6
On ajoute 2 et 4 si l'on applique la variante à trois points. La valeur 3, au milieu de la classe valide, n'apporte rien de plus que 2.
2. L'âge.
Deux classes : âge ≤ 60 donne 14 jours,
âge > 60 donne 21 jours.
Valeurs limites : 60 et 61
Le piège est dans « plus de 60 ans » : à 60 ans exactement, on n'a
pas plus de 60 ans, donc 14 jours. Un développeur qui écrit
age >= 60 au lieu de age > 60 commet une
erreur qu'aucun test à 30 ou 70 ans ne révélerait.
3. Le jeu de cas.
| N° | Ouvrages | Âge | Attendu | Ce qu'il éprouve |
|---|---|---|---|---|
| 1 | 0 | 35 | rejet | sous la borne basse |
| 2 | 1 | 35 | accepté, 14 jours | borne basse incluse |
| 3 | 5 | 35 | accepté, 14 jours | borne haute incluse |
| 4 | 6 | 35 | rejet | au-dessus de la borne haute |
| 5 | 3 | 60 | accepté, 14 jours | 60 ans exactement |
| 6 | 3 | 61 | accepté, 21 jours | bascule à 21 jours |
Six cas suffisent : quatre pour les bornes du nombre d'ouvrages, deux pour la frontière d'âge. Les deux variables étant indépendantes, il est inutile de croiser toutes leurs valeurs : ce serait 24 cas pour aucune information supplémentaire.
Barème : 1,5 + 1 + 1,5.
Corrigé de l'exercice 2Masquer
1. Conditions et actions.
Trois conditions booléennes : abonné, montant > 50 000, express.
Trois actions possibles : frais à 0, frais à 2 000, frais à 5 000.
2. La table complète compte 2³ = 8 colonnes.
| Cas | Abonné | > 50 000 | Express | Frais |
|---|---|---|---|---|
| 1 | oui | oui | oui | 0 |
| 2 | oui | oui | non | 0 |
| 3 | oui | non | oui | 0 |
| 4 | oui | non | non | 0 |
| 5 | non | oui | oui | 0 |
| 6 | non | oui | non | 0 |
| 7 | non | non | oui | 5 000 |
| 8 | non | non | non | 2 000 |
La table simplifiée fusionne les colonnes où une condition est sans effet. Le tiret note une condition indifférente.
| Règle | Abonné | > 50 000 | Express | Frais |
|---|---|---|---|---|
| R1 | oui | - | - | 0 |
| R2 | non | oui | - | 0 |
| R3 | non | non | oui | 5 000 |
| R4 | non | non | non | 2 000 |
Quatre règles remplacent huit colonnes : dès que le client est abonné, les deux autres conditions ne changent rien.
3. Les cas retenus.
Quatre cas, un par règle de la table simplifiée.
| N° | Entrée | Attendu |
|---|---|---|
| 1 | abonné, 20 000 FCFA, standard | 0 |
| 2 | non abonné, 60 000 FCFA, standard | 0 |
| 3 | non abonné, 20 000 FCFA, express | 5 000 |
| 4 | non abonné, 20 000 FCFA, standard | 2 000 |
On ajoutera utilement les valeurs limites du montant : 50 000, qui ne dépasse pas 50 000, donc frais dus, et 50 001. La règle dit « dépasse », ce qui exclut l'égalité ; c'est là que se loge l'erreur de comparaison.
Barème : 1 + 2 + 1.
Corrigé du problèmeMasquer
1. Les quatre niveaux.
| Niveau | Ce qu'on éprouve | Ce que le niveau inférieur ne voit pas |
|---|---|---|
| Unitaire | chaque fonction isolée : arrondi de la durée, choix du tarif, format du numéro | - |
| Intégration | le dialogue avec l'annuaire et le service de paiement : format des réponses, délais, pannes | l'annuaire renvoie « sous contrat » au format booléen alors que le module attend une chaîne : chaque fonction est juste, l'assemblage est faux |
| Système | la chaîne entière, d'une intervention saisie à une facture imprimée, en conditions réelles | deux factures émises en même temps reçoivent le même numéro : aucun test d'intégration sur un seul appel ne le révèle |
| Acceptation | le comptable de NKILItech vérifie sur ses propres dossiers que les montants correspondent à ce qu'il facturait | l'arrondi au quart d'heure supérieur est appliqué comme spécifié, mais la maison a toujours arrondi à la demi-heure : la spécification est fidèlement implémentée, et fausse |
2. Les cas de calculerDuree().
Deux règles se combinent : l'arrondi au quart d'heure supérieur, et le minimum d'une heure. La frontière est à 60 minutes.
| Entrée | Attendu | Justification |
|---|---|---|
| 1 min | 60 min | minimum : toute durée infime est portée à l'heure |
| 59 min | 60 min | juste sous le minimum |
| 60 min | 60 min | le minimum exactement, et un multiple du quart d'heure |
| 61 min | 75 min | premier dépassement : arrondi au quart supérieur |
| 75 min | 75 min | déjà un multiple : ne doit pas être poussé à 90 |
| 76 min | 90 min | juste après un multiple |
| 0 min | 60 min, ou rejet | cas dégénéré : la spécification ne le traite pas |
Le cas 75 min est le plus important du lot. Un arrondi
écrit avec un + 14 mal placé pousse une durée déjà ronde au
quart suivant : le client paie quinze minutes qu'il n'a pas
consommées, et l'erreur passe inaperçue tant qu'on ne teste que des valeurs
quelconques.
3. Les cas de appliquerTarif().
| N° | Durée facturée | Contrat | Pièces | Montant attendu |
|---|---|---|---|---|
| 1 | 60 min | oui | 0 | 15 000 |
| 2 | 60 min | non | 0 | 25 000 |
| 3 | 90 min | oui | 8 000 | 30 500 |
| 4 | 75 min | non | 12 000 | 43 250 |
Vérification du cas 3 : 90 min = 1,5 h, soit 1,5 × 15 000 = 22 500, plus 8 000 de pièces = 30 500 FCFA.
Vérification du cas 4 : 75 min = 1,25 h, soit 1,25 × 25 000 = 31 250, plus 12 000 = 43 250 FCFA.
Les cas 3 et 4 éprouvent la conversion des minutes en fraction d'heure : une implémentation qui divise par 60 en arithmétique entière renverrait 1 au lieu de 1,25, et facturerait 25 000 au lieu de 31 250.
4. Le problème des services distants.
Un test unitaire doit être rapide, reproductible et isolé. Appeler l'annuaire des clients le rend lent, dépendant du réseau, et son résultat change selon l'état de la base. Il devient impossible de dire si un échec vient du module ou du service.
On remplace chaque service distant par une doublure.
Un bouchon renvoie une réponse fixe : « ce client est sous contrat ». Un simulacre va plus loin et vérifie que le module a bien appelé le service, avec les bons arguments.
Le vrai bénéfice est ailleurs : la doublure permet de provoquer les pannes. Annuaire qui ne répond pas, qui met trente secondes, qui renvoie une erreur ou un client inconnu : autant de situations qu'on ne saurait pas déclencher à la demande sur le service réel, et qui sont précisément celles où le module casse en production.
5. Tester l'unicité du numéro.
Le test : lancer plusieurs générations de factures simultanées, par exemple 200 demandes depuis une dizaine de fils d'exécution, puis vérifier qu'on obtient 200 numéros, tous distincts et sans trou dans la séquence. On répète l'opération plusieurs fois, car un défaut de concurrence ne se manifeste pas à tous les coups.
Pourquoi un test unitaire classique n'y suffit pas : il appelle
genererFacture() une fois, dans un seul fil, sur un compteur
remis à zéro. Il vérifie que la fonction rend un numéro bien formé : pas
qu'elle le rend unique quand deux appels se croisent.
L'unicité n'est pas une propriété d'un appel, c'est une propriété de l'ensemble des appels dans le temps. Elle se teste donc au niveau système, sur l'état réellement partagé, et elle dépend de ce qui garantit la séquence : une séquence de base de données, un verrou. Si le numéro est produit en mémoire par un simple incrément, le test échouera, et c'est exactement ce qu'on veut savoir avant la mise en service.
Barème : 2 pour la question 1, 1,5 pour la question 2, 1 pour la question 3, 1,5 pour la question 4, 1 pour la question 5.
Questions / Réponses
Ajouter un commentaire