En fait, il y a deux niveau. Le premier but d'un test, c'est de montrer que ton appli fait ce qu'elle doit faire. C'est le test fonctionnel, ou unitaire lorsqu'on se concentre sur un bout de code.
Moi j'interesse ici a la fiabilite (j'avais pas realise en ecrivant le journal, mais c'est vraiment le sujet). Comment prouver que l'appli ne fait jamais ce qu'elle ne doit pas faire. En gros, comment eviter a tout prix le segfault. Un utilisateur peut comprendre qu'une fonction ne fontionne pas bien. Mais un crash, ca reste incomprehensible et ca donne une tres tres mauvaise impression.
Apres, l'extension de "comment prouver que l'appli ne fait jamais ce qu'il faut pas meme quand on a la torture" peut etre vu comme "comment trouver le jeu de test qui torture l'appli suffisamment pour etre sur qu'elle resiste bien". On peut penser au cas simpliste du mec qui se code son strlen et qui est tout content parce que il marche. Sauf que quand tu lui passes un pointeur nul, paf, ca plante.
La preuve formelle, je ne connais que de nom mais apparemment, c'est tres difficile a conciler avec le travail quotidien du developpeur. Il faut y consacrer des resources et une intelligence non negligeable pour un resultat qui peut sembler minimal a cote de ce qu'on est capable de coder avec les memes resources.
Je developpe un OS pour carte a puce (proprietaire, mais aussi open source, cf jayacard.sf.net) et je voudrai etre sur qu'il est securise.
La technique de la mutation de code me parait une bonne approche. En plus de la couverture de code, ca permet de localiser des zones sombres. Je suis preneur d'autres trucs.
[^] # Re: pas une preuve
Posté par Philippe F (site web personnel) . En réponse au journal couverture de code. Évalué à 3.
Moi j'interesse ici a la fiabilite (j'avais pas realise en ecrivant le journal, mais c'est vraiment le sujet). Comment prouver que l'appli ne fait jamais ce qu'elle ne doit pas faire. En gros, comment eviter a tout prix le segfault. Un utilisateur peut comprendre qu'une fonction ne fontionne pas bien. Mais un crash, ca reste incomprehensible et ca donne une tres tres mauvaise impression.
Apres, l'extension de "comment prouver que l'appli ne fait jamais ce qu'il faut pas meme quand on a la torture" peut etre vu comme "comment trouver le jeu de test qui torture l'appli suffisamment pour etre sur qu'elle resiste bien". On peut penser au cas simpliste du mec qui se code son strlen et qui est tout content parce que il marche. Sauf que quand tu lui passes un pointeur nul, paf, ca plante.
La preuve formelle, je ne connais que de nom mais apparemment, c'est tres difficile a conciler avec le travail quotidien du developpeur. Il faut y consacrer des resources et une intelligence non negligeable pour un resultat qui peut sembler minimal a cote de ce qu'on est capable de coder avec les memes resources.
Je developpe un OS pour carte a puce (proprietaire, mais aussi open source, cf jayacard.sf.net) et je voudrai etre sur qu'il est securise.
La technique de la mutation de code me parait une bonne approche. En plus de la couverture de code, ca permet de localiser des zones sombres. Je suis preneur d'autres trucs.