Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Le zéro bug comment faire?
Bonjour à tous,
Je voulais savoir vous connaissez les méthodes ou les langages qui permettent de faire 0 bug.
Je sais que pour la plus part des besoins aucun véritable effort n'est fait pour avoir 0 bug, car bien trop cher.
Mais pour certains besoins très critiques, c'est indispensable et j'aimerais savoir comment il procèdent si vous savez
Donaldo
Déjà , zéro bug, qu'est-ce que ça veut dire ?Envoyé par Donaldo
Bonjour à tous,
Je voulais savoir vous connaissez les méthodes ou les langages qui permettent de faire 0 bug.
Je sais que pour la plus part des besoins aucun véritable effort n'est fait pour avoir 0 bug, car bien trop cher.
Mais pour certains besoins très critiques, c'est indispensable et j'aimerais savoir comment il procèdent si vous savez
Donaldo
Par zéro bug, je suppose que tu veux dire: un programme qui effectue correctement la tâche qui lui est assignée par l'utilisateur, et ce, sans planter, dans un domaine raisonnable de cas d'utilisation ?
Dans les systèmes très critiques, il y a plusieurs manières de faire, qui peuvent être utilisées conjointement.
Des méthodes d'automatisation:
- la génération de code,
- la vérification automatique de code: analyse statique, voire preuve automatisée de fonctionnement,
Des méthodes d'ingéniérie logicielle plus traditionnelles:
- l'utilisation de langages de haut niveau insistant sur la sécurité,
- la revue formelle de code,
- les tests plans de tests systématiques et automatisés, avec couverture maximale des cas d'utilisation: on teste tous les cas possibles.
Il y a aussi, mais c'est un autre domaine, la prise en compte de la tolérance de panne avec de la redondance dans le système en production.
Il te faudrait un langage formel genre Z.
Mais meme si tu prouves que ton logiciel va faire ce qui lui est demande, il n'y a rien qui peut empecher de faire des erreurs dans la specification.
Bonjour,
pour avoir zéro bug, cela veut dire tester la totalité des cas possibles. Donc dès que le programme devient intéressant pour un utilisateur, c'est impossible.
Je sais qu'il existe quelques langages basés sur le formalisme mathématiques, donc quelque chose de juste. Utiliser ces langages permet d'éviter un très grand nombre d'erreur.
Non, on peut prouver qu'il n'y a pas de bug sans forcément faire de tests.
Par exemple avec l'aide de COQ. Bon, après c'est super long à faire, mais ça peut être utile pour des bibliothèques sur lesquelles tout le monde s'appuie.
Après il est possible de prouver que tes algorithmes n'ont pas de bugs, mais ça veut pas dire que ça a bien été implémenté (une erreur dans l'écriture ou des cas aux limites qui se passent différemment)
Et aussi que la spécification ne correspond pas forcément à ce à quoi ta tête pense comme dit bredelet.
Mais il doit bien y avoir des outils prouvant qu'un code implémente bien un algorithme.
Le projet ASTREE le fait (analyse statique) pour un sous-ensemble du langage C.
Il y avait une biblio en langage C prouvée totalement en COQ (ça avait pris quelques mois), mais je sais pas comment ils ont fait exactement.
Mais quand même, je crois qu'ils suivent le code source pas à pas dans la démarche (c'est pour ça que ça prend des mois), parce que sinon prouver un algorithme c'est relativement rapide à faire par rapport à un code source.
Si je me souviens bien de mes cours, le langage ada était réputé très fiable, et, pour ce que j'en sais il est encore utilisé dans les applications embarquées qui necessitent un haut niveau de fiabilité.
Après pour les méthodes... Je crois que la premiere et la plus importante des choses, c'est d'avoir une équipe dédié aux tests qui sait comment les faire de facon la plus exhaustive possible. Ca n'est pas imparable (rien n'est imparable), mais c'est un sacré filtre a bug.
Et quand je dis équipe dédié au tests, ce sont bien des gens qui ne font que ca et dont c'est le métier, pas des developpeurs qui vont faire des tests quand ils ont 5mn a perdre.
Alors, si vous permettez, puisque c'est vaguement mon domaine d'expertise, je me permettrais quelques commentaires.
Le terme bug mélange plusieurs notions et donc une certaine incertitude. En général, lil faudrait dire qu'il existe des défauts qui engendre un comportement défaillant et ont pour origine une erreur humaine. Cependant, on emploie souvent le mot « bug » pour ces trois choses différentes. Une erreur humaine pourrait ne pas générer de défauts. Un défaut pourrait ne pas générer un comportement défaillant.
Soyons lucide, on ne peut rien y faire. Les « bugs » seront présents à un moment ou un autre quelque part. Sir Tony Hoare disait que « si vous avez l'impression qu'il n'y a pas de bug dans votre programme, c'est soit que votre logiciel est trop petit pour en avoir, soit que vous ne les avez pas encore vu. »
On peut certes faire appel à des méthodes formelles. Celle-ci peuvent permettre de valider (faire le bon logiciel) et vérifier (le faire correctement) un logiciel. Oui mais, pour le vérifier il faut que la méthode formelle englobe tout le processus et que les outils soit eux-même prouvé... et pour la validation, on ne peut pas l'assurer à 100%. C'est impossible puisque pour tout formaliser il faudrait que le langage naturel soit formalisable. Il y a toujours la possibilité qu'une erreur ce soit glissée dans la spécification. Pour cela, on peut passer par des simulations, du model-checking ou tout autre méthode d'exploration. Cependant, rien n'est jamais sûr. C'est pourquoi même les méthodes les plus accomplis (et il vaut mieux parler de B que de Z qui est son ancêtre dépassé — quoique pourra en dire Jim Woodcock) ont quand même de longue séance de validation a priori (simulation, storyboarding, etc.) et a posteriori (tests d'acceptation) du processus.
Une des grandes difficultés est qu'on ne peut prouver une propriété ou chercher une erreur à laquelle on a déjà pensé. C'est bien de démontrer que M vérifie A. Mais si le piège était dans B et qu'on l'a oublié, il n'y a rien à faire. C'est un problème insurmontable: on ne peut pas penser à tout.
Finalement, pour les langages, ADA est plus qu'un peu utilisé... il est le langage principal de tous les systèmes critiques ou presque. C'est-à-dire que l'aéronautique, le nucléaire, l'aérospatiale, l'armement et le transport de manière général s'en sert pour toute implémentation à risque. Ce qui en fait un des langages le plus répandu dans le monde en nombre de ligne de code (maintenant c'est un langage très verbeux aussi). Il est possible que des langages modernes et extrêmement fiables finissent par le remplacer, comme OCaml ou Haskell (ou un autre petit nouveau qui n'existe pas encore... pourquoi pas).
Dans l'état actuel de la recherche, il existe plusieurs moyens de générer du code sûr à 100% vis-à-vis des spécifications (programmeur, comptez vos abattis). Ce n'est qu'une question de moyen. Depuis le bug d'Intel et Ariane, les erreurs logiciels importantes dans les domaines critiques sont extrêmement rares. Mais le problème se déplace en amont : comment spécifier correctement ? comment penser aux bonnes propriétés ? comment les écrire proprement ?
En fait quand je pensais 0 bug je pensais peut être a des éléments tel que dans les centrales nucléaire ou la ligne 14, ou les fusées enfin a pas mal de choses.
Tient ça serait a cause de tous ses problèmes que vous évoquez qu'on entends parler de plus en plus des bonnes pratiques de programmation et gestion des exceptions?
Les bonnes pratiques, ont en entend parler parce, justement, ce sont de bonnes pratiques. On se rend compte qu'en appliquant quelques concepts simples, on arrive a réduire significativement les bugs alors pourquoi s'en priver ? Je ne pense pas que cela viennent directement des applications "sensibles".
Et je persite a dire que pour avoir une appli "0 bug", au dela de toutes les méthodes pour limiter un maximum les risques d'erreurs en amont, il faut avoir des psychopathes fini en guise de testeurs et il faut leur donner les outils necessaire pour faire leur taf dans les meilleures conditions possible.
Intéressant ce que dit Garulfo...
Ce que j'ai retenu de mes cours du CNAM :
Un 'morceau' de programme (module, fonction...) doit être comme une boîte noire qui dit :
- ce qu'elle accepte en entrée ;
- ce qu'elle donnera en sortie si l'entrée est correcte ;
- ce qu'elle retournera comme erreur(s) si l'entrée est incorrecte.
Pour tester la boîte noire :
1) tester un jeu de cas normaux pour s'assurer qu'une entrée correcte donne un résultat correct ;
2) tester les cas aux limites pour s'assurer que même aux bornes de la plage d'acceptation ça fonctionne toujours correctement ;
3) tester un jeu d'entrées au delà des limites pour s'assurer que les cas d'erreur fonctionnent ;
4) tester avec des entrées incohérentes pour s'assurer que ces cas d'erreur sont pris en compte. Ce dernier cas est ce qu'un ancien informaticien d'IBM appelait le 'monkey test' : imaginer un singe devant le clavier qui tape n'importe quoi. Si le programme résiste, il y a de bonnes chances qu'il résiste à tout.
Un exemple simple pour comprendre...
Soit une fonction qui dit si ce qu'on lui donne en entrée est un entier pair ou impair.
Cette fonction accepte les entiers compris entre -10 puissance 10 et +10 puissance 10 et retourne la chaîne de caractères 'impair' si l'entrée est un entier impair, 'pair' si c'est un entier pair et 'indéterminé' si c'est autre chose qu'un entier.
Il faudra tester cette fonction :
1) avec des entiers positifs et négatifs pairs et impairs compris dans les limites fixées par les spécifications ;
2) avec des les entiers aux bornes supérieure et inférieure et pour le zéro ;
3) avec des entiers au delà des limites (> +10 puissance 10 et < -10 puissance 10) ;
4) avec des nombres non entiers et du texte, du mélange de nombre et de texte (comment la fonction réagit si je lui donne '20 euros' ?).
Quand on est face à une interface de logiciel, penser aussi au 'monkey test' en testant tout ce à quoi le singe pourrait avoir accès : les menus, les liens cliquables, les touches de fonction, les autres zones de saisie que celle qu'on teste...
Que doit-il se passer si on interrompt l'utilisation (panne, retour à la page précédente, changement de fonction alors qu'on a pas terminé de faire ce qu'on était en train de faire...) ?
Je pense que quand on a testé tout ça, on peut considérer qu'on a un programme fiable... à condition que celui qu'il soit utilisé dans ses conditions normales.
Imaginons que vous vouliez utiliser le cas d'erreur de la fonction décrite plus haut pour dire si un nombre est décimal. Votre programme s'assure que l'entrée est un nombre. Ça fonctionne avec les entrées et les nombres à virgule compris dans les limites. Mais que se passe t-il si vous donnez à votre programme un entier hors limites de la fonction ? Celle-ci vous retournera 'indéterminé' et votre programme interprétera ça comme 'décimal' !
Vous avez fait l'erreur d'utiliser une fonction pour autre chose que ce à quoi elle est destinée.
J'ai le souvenir que le système de la ligne 14 a été (au moins partiellement) vérifié avec Z.
Un des aspects dans la qualité absolue qui n'a pas encore été évoquée ici est la "gestion du changement": il ne suffit pas de livrer quelque chose bien construit et bien testé mais il faut aussi pouvoir le faire évoluer.
Cela 'complexifie' le problème... et oblige à une recherche de la simplicité.
- W
Pour ma culture personnelle, c'est quoi le 'système de la ligne 14' ?
100% d'accord avec Garulfo (ça t'étonnes ?
Et aussi bêtement que pour qu'une preuve soit irréfutable, et qu'un logiciel soit garanti garantir un code sans bug, il faudrait que ses auteurs et concepteurs et programmeurs soient parfaits
La notion de "zéro bug" revient à la notion de perfection, qui, on le sait tous, n'est pas partie de la nature humaine ...
ligne 14 = METEOR
C'est un métro qui fonctionne sans conducteur.
Des systèmes de preves formelles ont été utilisés pour valider le système.
Les traces que j'en ai retrouvé parlent d'ASA+ et de B (que je confond allègrement avec Z).
- W
C'est un des objectifs que doit atteindre tout système dont la mission peut mettre en cause la sécurité des personnes.100% d'accord avec Garulfo (ça t'étonnes ?
Et aussi bêtement que pour qu'une preuve soit irréfutable, et qu'un logiciel soit garanti garantir un code sans bug, il faudrait que ses auteurs et concepteurs et programmeurs soient parfaits
La notion de "zéro bug" revient à la notion de perfection, qui, on le sait tous, n'est pas partie de la nature humaine ...
Ce sont effectivement des méthodologies et des gens ayant une attitude mentale assez particulière.
-W
De toute facon, personne n'est parfait alors entre erreurs logiques,sémantiques et tout le bazar, si un programme fait 30 lignes de code, il est "débuggable" assez facilement alors que si ton projet fait 100000 lignes de codes ou plus (t'en fera pas des millions tout seul hein?) ça sera très très dur voir impossible selon le projet de garantir 0 bugs!
Je trouve un peu le débat stérile car l'erreur est souvent de nature humaine donc...
La vrai question serait plutôt de se dire: Comment faire pour limiter les possibilités de bug et de les rendre minimes?Ce serait plutôt pour moi le meilleur moyen de rendre un système le plus sur possible..Et cela ne s'applique pas qu'a la programmation!
Pour moi, ça dépend du budget. Chaque niveau de qualité en plus augmente dramatiquement le budget. J'ai participé longtemps à une TMA dans le milieu bancaire. On avait un bon niveau de fiabilité, avec de rares bugs qui trainaient. On facturait 9 heures, tout compris(devis+réal+specs+tests unitaires+asistance à la recette+livraison) par opération "unitaire"(genre je modifie 2 libellés en durs, ou je change une formule de calcul).
Un jour, on a eu un bug avec des conséquences clients importantes(sans entrer dans le détail, des courriers ne sont pas partis). Donc le client(la banque) nous a demandé de fiabilisé encore nos livraisons. Nous avons ajouté 2 étapes : (1)un cahier de tests systématique pour toute évolutions - fut-elle ridicule, et (2) une pré-recette avant de laisser la main à la MoA pour la vraie recette. Nôtre fiabilité globale a augmenté(1 seul incident de prod en 6 mois), mais le tarif est passé de 9 à 20 heures par opération unitaire.
Pour la ligne 14, ils ont du payer encore bien plus pour un code "simple". mais ils avaient une exigence de qualité encore bien plus grande. De ce que j'ai lu dans les posts précédents, la validation a du couter bien plus cher que le code lui-même(vu le contexte, ça me parait justifier). Mais aux yeux des décideurs financiers, peu d'applications méritent un budget de validation à la hauteur du budget de réalisation - d'ou le nombre de bugs constatés dans certaines applis(vous avez dit jeu PC ?)
Les tests, c'est bien, mais ce n'est pas ce qui garantit que tu n'as pas de bugs. En fait si tu suis des pratiques de bonne programmation (Ada est une bonne base) et que tu utilises des tests unitaires, tu peux avoir disons 95% du code sans bugs. Ensuite tu peux faire verifier ton code par un pair, mettre en place d'autres tests et avoir 99% du code sans bug. Mais tu n'arriveras jamais a eliminer completement le 1% restant par ces methodes.
Le seul moyen d'avoir un code sans defaut (supposant qu'il n'y a pas de defaut dans la specification, dans l'outil utilise et dans le materiel) est d'utiliser une methode formelle.
Comme dit Garulfo tout ca coute des sous.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager