Garanti par la théorie du temps réel
Si t'as pas d'OS temps réel, t'as perdu.
Nullement garanti par des tests.
Personne n'a dit que les tests offraient de garanties.
Fallacieux car Il n'y pas de specification formelle (juste une informelle pour ça).
Bienvenu dans la vraie vie ! Je dirais que la grande majorité des spécifications logicielles telles qu'exprimées par le client sont informelles, incomplètes ou insuffisantes, et c'est ma principale remarque initiale. Toutes les tentatives de formalisation à partir de ces specs (specs détaillées, specs formelles puis pre-post conditions) passent par une interprétation humaine de specs informelle, et c'est là que le test reste utile. Tu es obligé de rédiger un cahier de tests, tu peux le faire valider par le client pour voir s'il est conforme à ses attentes, tu le soumets aux équipes de validation qui vont y jeter un regard humain et y déceler des erreurs d'interprétation, y ajouter leur interprétation, etc.
Un valideur formelle ne valide pas les specs, d'où l'intérêt de mon exemple qui n'a strictement rien de fallacieux, et qui au contraire me paraît très réaliste.
Pour tout état du programme, la police affiché (l'affichage fait partie de l'état) est celle de l'environement.
Je te pari que t'es incapable de prouver une telle propriété.
[^] # Re: Se passer des tests ...
Posté par TImaniac (site web personnel) . En réponse au journal La preuve de programme : où en est-on ?. Évalué à 2.
Si t'as pas d'OS temps réel, t'as perdu.
Nullement garanti par des tests.
Personne n'a dit que les tests offraient de garanties.
Fallacieux car Il n'y pas de specification formelle (juste une informelle pour ça).
Bienvenu dans la vraie vie ! Je dirais que la grande majorité des spécifications logicielles telles qu'exprimées par le client sont informelles, incomplètes ou insuffisantes, et c'est ma principale remarque initiale. Toutes les tentatives de formalisation à partir de ces specs (specs détaillées, specs formelles puis pre-post conditions) passent par une interprétation humaine de specs informelle, et c'est là que le test reste utile. Tu es obligé de rédiger un cahier de tests, tu peux le faire valider par le client pour voir s'il est conforme à ses attentes, tu le soumets aux équipes de validation qui vont y jeter un regard humain et y déceler des erreurs d'interprétation, y ajouter leur interprétation, etc.
Un valideur formelle ne valide pas les specs, d'où l'intérêt de mon exemple qui n'a strictement rien de fallacieux, et qui au contraire me paraît très réaliste.
Pour tout état du programme, la police affiché (l'affichage fait partie de l'état) est celle de l'environement.
Je te pari que t'es incapable de prouver une telle propriété.