"Formel" dans beaucoup de cas veux simplement dire "correctement définit", par exemple en C, "(i <> 32" ne donne pas tout le temps le même résultat. Ensuite, il faut un moyen pour décrire les attendus ("théorème" ou "spec" ou "HLR"), et ensuite, il faut bien les trouver, ce qui est souvent beaucoup plus complexe qu'on ne le croit.
Une bonne suite de teste permet de vérifier le comportement attendu mais à tendance à congeler le code. Car il devient couteux de le modifier si la suite de teste n'est pas assez souple. Le cas typique est le fait de changer une constante dans le code, ce qui prend 1 min, mais qui nécessite de recalculer à la main des centaines de valeurs de testes. Personne ne veut le faire.
Il y a une nouvelle méthode de teste qui permet de vérifier que les tests sont corrects. C'est bien plus intéressant que la couverture de code qui ne vérifie que la "traversé" du code et non son résultat. Cela permet de trafiquer les entrée pour augmenter le taux de couverture sans rajouter un seul test.
Il s'agit de la technique de "mutation testing". L'idée est de modifier un peu le code automatiquement et de vérifier que cela plante bien un teste.
Un moyen assez simple pour éviter de congeler une application est d'avoir un "golden model", en gros la même application recodé autrement, ou par une autre équipe (l'équipe de teste ?). Ce code de test permet de calculer les sorties attendues, et sa complexité ne dépasse jamais celle de l'application testée. Ainsi, changer une constante prendra seulement 2 fois 1 min.
Le teste consiste a vérifier que les 2 codes se comportent de la même façon. il faut évidement travailler en "boite noir", sinon le copier-coller va tuer l’intérêt de la méthode.
Il reste à générer les entrées du code comme le font déjà les "fuzzers".
[^] # Re: Méthodes formelles ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Un peu d’Open Hardware pour la rentrée (et beaucoup de LinuxBoot). Évalué à 4.
"Formel" dans beaucoup de cas veux simplement dire "correctement définit", par exemple en C, "(i <> 32" ne donne pas tout le temps le même résultat. Ensuite, il faut un moyen pour décrire les attendus ("théorème" ou "spec" ou "HLR"), et ensuite, il faut bien les trouver, ce qui est souvent beaucoup plus complexe qu'on ne le croit.
Une bonne suite de teste permet de vérifier le comportement attendu mais à tendance à congeler le code. Car il devient couteux de le modifier si la suite de teste n'est pas assez souple. Le cas typique est le fait de changer une constante dans le code, ce qui prend 1 min, mais qui nécessite de recalculer à la main des centaines de valeurs de testes. Personne ne veut le faire.
Il y a une nouvelle méthode de teste qui permet de vérifier que les tests sont corrects. C'est bien plus intéressant que la couverture de code qui ne vérifie que la "traversé" du code et non son résultat. Cela permet de trafiquer les entrée pour augmenter le taux de couverture sans rajouter un seul test.
Il s'agit de la technique de "mutation testing". L'idée est de modifier un peu le code automatiquement et de vérifier que cela plante bien un teste.
Un moyen assez simple pour éviter de congeler une application est d'avoir un "golden model", en gros la même application recodé autrement, ou par une autre équipe (l'équipe de teste ?). Ce code de test permet de calculer les sorties attendues, et sa complexité ne dépasse jamais celle de l'application testée. Ainsi, changer une constante prendra seulement 2 fois 1 min.
Le teste consiste a vérifier que les 2 codes se comportent de la même façon. il faut évidement travailler en "boite noir", sinon le copier-coller va tuer l’intérêt de la méthode.
Il reste à générer les entrées du code comme le font déjà les "fuzzers".
"La première sécurité est la liberté"