Numérique et sciences informatiques (spécialité) · Première
Spécification et tests : quiz de NSI en Première
Publié le 6 novembre 2026 · Mis à jour le 6 novembre 2026 · Signaler une erreur
L'essentiel
- Une spécification décrit les exigences qu'un produit doit satisfaire : elle dit ce que fait une fonction, pas comment elle le fait 4.
- Un test confronte une réalisation à sa spécification : à une entrée donnée correspond un résultat attendu, et le verdict est un succès ou un échec 5.
- Un test unitaire vérifie une partie précise d'un programme, indépendamment du reste 5.
- Réussir quelques tests ne prouve pas qu'une fonction est correcte : choisis des cas variés, dont les cas limites.
- Écrire les tests avant le code évite d'être influencé par ce code 5.
Avant de commencer
Ce quiz couvre la notion de spécification et de test telle qu'on la rencontre en NSI : ce que dit la spécification d'une fonction, ce qu'est un test unitaire, comment choisir des cas de test utiles, et pourquoi on écrit parfois les tests avant le code. Il t'entraîne aussi à lire un énoncé de type épreuve pratique, où l'on te fournit une spécification et parfois un jeu de test.
Quiz
16 questions · correction immédiate · ton score reste sur ton appareil.
-
La spécification est l'ensemble des exigences qu'un produit doit satisfaire 4. Le code source est une réalisation de la spécification, pas la spécification elle-même : c'est l'erreur tentante. La liste des erreurs trouvées relève du résultat des tests, et un temps d'exécution n'est qu'une mesure.
-
Une spécification dit ce que la fonction fait : entrées acceptées, conditions à respecter, résultat attendu. Imposer une boucle
forplutôt quewhiledécrit comment programmer, ce qui relève de l'implémentation. Les trois autres propositions décrivent bien le contrat entre l'appelant et la fonction. Il est tentant de croire que tout détail est utile, mais une bonne spécification laisse le choix de la méthode. -
Un test unitaire est une procédure qui vérifie le bon fonctionnement d'une portion précise d'un programme, appelée unité ou module 5. Il ne mesure pas la vitesse de la machine et ne traduit rien. Surtout, il ne remplace pas la spécification : au contraire, il s'appuie sur elle pour savoir quel résultat attendre.
-
C'est faux. L'intérêt du test unitaire est précisément de tester un module indépendamment du reste du programme 5. Si l'on ne testait que l'ensemble, une erreur serait plus difficile à localiser : on saurait que quelque chose ne va pas, sans savoir quelle fonction est en cause.
-
La somme vaut et il y a trois éléments, donc la moyenne est . L'erreur fréquente consiste à diviser par 2, ou à renvoyer le dernier élément, 12. Un test construit sur cet exemple vérifierait justement que la fonction renvoie 8.
-
Un sujet d'épreuve pratique peut proposer un jeu de test avec les réponses attendues 2. Il associe donc des entrées à des résultats attendus. Le temps passé à programmer ou le nom d'un fichier ne servent pas à juger la conformité de la fonction : ces propositions sont des distracteurs sans lien avec le test.
-
Un test compare le résultat obtenu au résultat attendu pour une entrée. Trois succès montrent la conformité sur trois cas, pas sur tous. Il reste possible qu'un cas non testé, par exemple un tableau à un seul élément, mette la fonction en défaut. La dernière réponse est absurde : un test réussi n'est pas faux, il est simplement limité.
-
C'est vrai. Un test doit correspondre aux spécifications ; on écrit donc les tests en premier, puis on fait en sorte qu'ils passent, plutôt que d'écrire le code d'abord et de risquer d'être influencé par lui en rédigeant les tests 5. Si l'on écrit le test après coup, on a tendance à tester ce que le code fait, et non ce qu'il devrait faire.
-
La fonction de test appelle un code qui n'existe pas encore, elle doit donc échouer ; elle sert à définir ce que l'on teste 5. Ce n'est pas la spécification qui est en cause, et un test n'a pas vocation à échouer en permanence : une fois le code écrit, on attend que le test passe.
-
Ce premier exercice t'oppose à un algorithme explicitement inscrit au programme, sans difficulté particulière, que tu dois coder d'après la spécification donnée dans le sujet 2. Le sujet peut aussi fournir un jeu de test ou un programme à trous à compléter 2. Il n'y a ni dissertation ni conception libre : la spécification est justement là pour cadrer le travail.
-
Un tableau à un seul élément est le plus petit cas permis par la spécification : si la fonction initialise mal son maximum ou boucle à tort sur le deuxième élément, ce test le révèle. Les autres tests sont corrects mais ressemblent à des cas ordinaires. Dans
[1, 2, 3], le maximum est de plus en dernière position, ce qui ne teste qu'une configuration. -
Le nombre 7 est impair, on applique donc la seconde règle : . L'erreur tentante est de doubler (14) sans regarder la parité. Un bon jeu de test contiendrait un pair, par exemple , et un impair, afin de couvrir les deux branches de la spécification.
-
L'instruction
assertvérifie qu'une condition est vraie ; si elle est fausse, une erreur d'assertion interrompt le programme et signale l'échec. Un test donne un verdict net, succès ou échec 5 : « proche de 8 » ne suffit pas pour un résultat entier censé être exact. Python ne corrige jamais un résultat de lui-même. -
La couverture de code indique quelle proportion des instructions du programme est réellement parcourue quand on lance tous les tests, l'objectif étant d'en atteindre la totalité ou une part fixée à l'avance 5. Elle ne compte ni les commentaires ni les lignes de la spécification. Une couverture élevée n'est pas une preuve de correction, mais une instruction jamais exécutée par les tests est une zone non vérifiée.
-
C'est faux : il existe une multitude de cadriciels permettant de réaliser facilement des tests unitaires, dans les principaux langages de programmation 5. L'histoire en témoigne : JUnit, créé en 1997 par Kent Beck et Erich Gamma, a entraîné la création de nombreux autres cadriciels de la famille xUnit 5.
Les questions qu'on se pose
Quelle différence entre la spécification et le programme ?
La spécification décrit les exigences à satisfaire : quelles entrées sont acceptées, quel résultat est attendu 4. Le programme est une manière de les réaliser. Plusieurs programmes très différents peuvent respecter la même spécification, tant que, pour chaque entrée permise, ils donnent le résultat attendu.
Combien de tests faut-il écrire pour une fonction ?
Il n'y a pas de nombre magique. Vise des cas variés : un cas ordinaire, les cas limites permis par la spécification (tableau à un élément, valeur nulle…), et un cas pour chaque branche du raisonnement. La couverture de code aide à vérifier que les tests parcourent bien les instructions du programme 5. Réussir peu de tests ne prouve cependant pas que la fonction est correcte.
Que faire si un test échoue alors que ma fonction me semble juste ?
Vérifie d'abord le test lui-même : le résultat attendu doit se déduire de la spécification, pas du code. Refais le calcul à la main. Si le test est bon, la différence entre résultat obtenu et résultat attendu te montre où chercher dans la fonction : trace-la pas à pas sur cette entrée précise. À l'épreuve pratique, un jeu de test fourni avec les réponses attendues te permet de te contrôler de cette façon 2.
Sources
- Programmes et ressources en numérique et sciences informatiques — voie générale, Éduscol. Consulté le 6 novembre 2026.
- Ressource officielle Éduscol — Spécification et tests, Éduscol. Consulté le 6 novembre 2026.
- Banque des épreuves pratiques de spécialité NSI, Éduscol. Consulté le 6 novembre 2026.
- Spécification (norme technique), Wikipédia. Consulté le 6 novembre 2026.
- Test unitaire, Wikipédia. Consulté le 6 novembre 2026.
Les numéros dans le texte renvoient à ces sources. Une source qui ne dit pas ce qu'on lui fait dire ? Signale-le.