Les tests d'intégration
Vérifier que des modules corrects séparément fonctionnent ensemble : les défauts d'interface, les stratégies d'intégration en un bloc, descendante et ascendante, les bouchons et les pilotes, et l'intégration avec une base réelle.
- 26 cartes
- 4 thèmes
- Gratuit
Le programme, thème par thème
Le poids de chaque thème suit celui que lui donne l'examen.
- Notions
- Questions
- Ranger et relier
- Mises en situation
Quelques cartes du deck
Test d'intégration : de quoi s'agit-il ?
Voir la réponse
Test qui vérifie que des modules déjà corrects séparément fonctionnent ensemble, en particulier à leurs interfaces.
Il cherche les fautes entre les modules : appel avec les paramètres dans le mauvais ordre, mauvaise unité, format de date différent. Elles n'existent dans aucun module pris seul.
Le module Facture appelle le module Tarif, qui n'est pas encore écrit. Pour tester Facture seul, que faut-il écrire ?
- Un bouchon qui remplace Tarif et renvoie un prix prévu
- Un pilote qui appelle Tarif à la place de Facture
- Un pilote qui remplace Facture et lance Tarif directement
- Rien : Facture se teste toujours sans que Tarif existe
Voir la réponse
Un bouchon qui remplace Tarif et renvoie un prix prévu
Facture appelle Tarif : c'est le module appelé qui manque, donc c'est lui qu'on remplace, par un bouchon. Un pilote remplacerait un appelant manquant.
En intégration descendante, on écrit des … pour les modules du dessous ; en intégration ascendante, des … pour les modules du dessus.
Voir la réponse
En intégration descendante, on écrit des bouchons pour les modules du dessous ; en intégration ascendante, des pilotes pour les modules du dessus.
On remplace toujours ce qui manque : en descendant, ce sont les modules appelés qui manquent ; en montant, ce sont les modules appelants.
Bouchon : de quoi s'agit-il ?
Voir la réponse
Module provisoire qui remplace un module appelé, pas encore intégré, et renvoie des réponses prévues d'avance.
Il permet de tester le module appelant avant que ce qu'il appelle existe. Il fournit les données, il ne calcule rien.
Deux équipes livrent chacune un module testé de son côté. Assemblés, ils produisent une trajectoire fausse : l'un fournit des livres-force secondes, l'autre attend des newtons secondes. Quelle est la nature de la faute ?
- Une faute de calcul dans l'un des modules, que ses tests unitaires auraient dû trouver
- Une faute de performance : les modules échangent trop de données entre eux
- Une faute d'interface : chaque module est juste selon sa propre unité
- Une faute d'ergonomie : l'utilisateur du système n'a pas compris l'écran
Voir la réponse
Une faute d'interface : chaque module est juste selon sa propre unité
C'est la perte de la sonde Mars Climate Orbiter, en 1999 : un logiciel au sol produisait des impulsions en livres-force secondes, alors que le logiciel de navigation les lisait en newtons secondes, l'unité que prévoyait le contrat d'interface. Chaque calcul était juste dans sa propre unité ; la faute n'existe que dans l'échange entre les deux.