Tu as du lire l'interview en diagonal car il me semble qu'il donne un nom explicite: DO-178B. It’s a quality standard for safety-critical aviation products
Effectivement je l'ai raté quand on regarde cette norme, il semble chercher à appliquer le critère le plus poussé (la couverture MCDC), mais il y a bien d'autres critères de dans qui me questionne sur comment il a fait :
Les activités de développement et de vérification doivent être confiées à des équipes indépendantes. → bon je présume que c'est le client aéronautique qui finance ça
Les exigences de bas niveau (ou exigences de conception) doivent être formellement vérifiées. → sur un logiciel déjà existant c'est ultra long/couteux à faire
Tout ce qui est spécifié doit être formellement vérifié : la couverture fonctionnelle doit être assurée. Les documents doivent aussi être formellement vérifiés. → je ne suis pas sûr de ce qu'ils entendent par formellement. Je ne sais pas s'il s'agit de pouvoir relier un comportement spécifié à un test où s'il s'agit de vérification formelle au sens de preuve (je présume que c'est le premier)
Et il y en a d'autres, la couverture MCDC n'est qu'un détail technique et pas le plus important dans ce standard.
Comment tu fais pour valider que tes tests testent ?
La méthode la plus connue c'est de faire du test de mutant. Il s'agit de modifier le code et de voir si un test trouve le mutant.
Je ne vais pas m'étaler sur ce que tu imagine ou non derrière mon commentaire. C'est un sujet qui m'intéresse donc je ne suis pas béa devant, mais je m'interroge de comment on met en place de la qualité et le standard montre bien que les tests ne sont qu'une partie de cela.
[^] # Re: Passionnant
Posté par barmic 🦦 . En réponse au journal Le petite histoire derrière SQLite (une interview de Richard Hipp). Évalué à 5.
Effectivement je l'ai raté quand on regarde cette norme, il semble chercher à appliquer le critère le plus poussé (la couverture MCDC), mais il y a bien d'autres critères de dans qui me questionne sur comment il a fait :
Et il y en a d'autres, la couverture MCDC n'est qu'un détail technique et pas le plus important dans ce standard.
La méthode la plus connue c'est de faire du test de mutant. Il s'agit de modifier le code et de voir si un test trouve le mutant.
Je ne vais pas m'étaler sur ce que tu imagine ou non derrière mon commentaire. C'est un sujet qui m'intéresse donc je ne suis pas béa devant, mais je m'interroge de comment on met en place de la qualité et le standard montre bien que les tests ne sont qu'une partie de cela.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll