Qu'est-ce qui constitue un bug?

En fait, qu'est-ce qu'un bug? des règles prédéfinies?

Un bug est:

Un bogue logiciel est le terme commun utilisé pour décrire une erreur, une faille, une erreur, une panne ou une défaillance dans un programme ou un système informatique qui produit un résultat incorrect ou inattendu, ou fait en sorte qu'il se comporte de manière involontaire. (De Wikipedia )

Voici une autre bonne définition de ce qui constitue un bug. Soit:

1. Le programme ne s'est pas comporté conformément aux intentions du programmeur. ou
2. Les intentions du programmeur ne répondaient pas aux attentes communes et raisonnables des utilisateurs.

La communauté Ubuntu a une excellente définition de bogue dans ce wiki , soulignant en particulier la différence entre le bogue et les fonctionnalités manquantes :

Un bogue logiciel est une erreur ou une erreur dans un programme informatique qui le fait ne pas fonctionner comme il le devrait. Cela pourrait être aussi simple que de ne pas fonctionner du tout, ou aussi compliqué qu'un résultat subtilement incorrect [...] Certaines choses ne sont pas des bugs, mais il manque des fonctionnalités qui devraient être raisonnablement incluses. Les fonctionnalités manquantes ne doivent pas être signalées comme des bogues, mais plutôt les spécifications des fonctionnalités doivent être écrites pour elles.

Bien qu'il soit difficile de tracer une ligne séparant les deux définitions et de répondre à la question, s'agit-il de bogues ou de fonctionnalités manquantes? , il est possible de donner quelques indications:

• s'il s'agit d'un problème qui aurait de nombreux détails à résoudre, il s'agit probablement d'une fonctionnalité. Par exemple, l'impossibilité d'écrire des fichiers en toute sécurité sur une partition Windows moderne est une fonctionnalité manquante.
• L'incapacité d'écrire des fichiers en toute sécurité sur une partition ReiserFS serait un bogue.

La différence entre les deux assertions est la suivante: la première est plus répandue (prend en charge les fenêtres modernes FS) et peut donc être considérée comme une fonctionnalité manquante, tandis que l'autre met l'accent sur un problème unique (ne peut pas écrire dans ReiserFS) - un bogue spécifique.

Si vous êtes intéressé, je vous recommande de jeter un œil au wiki de l' équipe BugSquad . La lutte contre les bogues est l'une des activités les plus intéressantes du cycle de développement logiciel, en plus d'être une excellente opportunité d'apprentissage :-)

Merci!

Je vais prendre une balançoire. Principalement, comportement non prévu par le concepteur / programmeur (actualisation d'une mauvaise conception). En termes de bugs que vous devez signaler aux gens, tout ce qui rend le programme plus difficile à utiliser et correspond à la description ci-dessus. Cela inclut, du pire au moins grave, les plantages du système, les plantages X, les plantages de programmes et tout bogue de programme interne.

Les bogues qui provoquent des plantages ou des fermetures de fenêtres provoquent généralement une sorte de sortie vers stderror si vous avez exécuté l'application à partir d'un terminal, cela peut être utile. Consultez également les journaux système pour les rapports d'erreur.

Un bogue est une erreur dans un programme ou un système informatique, donc le programme ne fonctionne pas correctement ou ne fonctionne pas du tout. Les bogues peuvent donc être le résultat d'un code de programmation incorrect ou d'un code de programmation qui n'est pas suffisamment robuste et ne peut pas gérer certaines exceptions (par exemple: division par 0)

A toutes fins pratiques, le terme "bug" doit être évité car il est trop flou.

La meilleure réponse à votre question remplit un livre entier: "Pourquoi les programmes échouent" par Andreas Zeller. Un livre qui devrait être sur la bibliothèque de tous les programmeurs. L'auteur fait également un bon effort pour ne pas les appeler "bugs" (lire la suite). Parce que comme la réponse de crncosta le suggère déjà, un "bug" n'est pas seulement une erreur de programmation. C'est pourquoi certaines personnes préfèrent le terme «problème» à la place (ce qui conduit à «problème tracker» au lieu de «bug tracker»).

Parce que ce qui est perçu comme un bug par un utilisateur final ne doit pas du tout être un bug. Cela peut être - même si cela est souvent utilisé comme une excuse boiteuse - simplement par conception. Cependant, certains échecs, une fois observés, sont classés comme "bogues", même s'ils sont dus à un manque de fonctionnalité.

L'auteur du livre susmentionné consacre plusieurs pages à la définition de termes tels que échec et défaut et décrivant pourquoi «bug» n'est pas un terme approprié (trop flou).

Résumé de sa terminologie:

1. le programmeur crée le défaut
2. le défaut provoque une infection ("état de programme défectueux")
3. l'infection se propage
4. l'infection provoque l' échec ("comportement observable mauvais / involontaire")
5. l'observateur (généralement l'utilisateur final) voit l' échec

Comme vous pouvez le voir, l'auteur fait la distinction entre la cause et l'effet, qui dans le cas de "bug" est presque toujours mélangé. La plupart du temps, le terme "bug" est appliqué au défaut , à l' infection et à l' échec .