Bogue

Erreur ou erreurs logicielles ou anomalie logicielle souvent aussi l'arc ( appelé en anglais ), les termes sont issus de la technologie logicielle avec laquelle les composants du système logiciel, les écarts sont référés à un état cible requis ou souhaité pour. Ceux-ci peuvent se produire si z. B. une certaine définition de la spécification est incorrecte ou a été mise en œuvre de manière incorrecte , et conduit initialement à un état d'erreur interne dans le programme , qui à son tour conduit à un comportement ou à un résultat inattendu lors de l' exécution du programme .

Pour la détection et l'élimination la plus complète possible des erreurs de programme, généralement dans les processus de développement de logiciels , i. H. Avant la réelle, l' utilisation « productive » du logiciel, passer par le « logiciel de test » phase du projet , au cours de laquelle est effectué une validation sur. Les erreurs se produisant au cours de ce processus sont courantes et le but des tests est de les trouver, tandis que les erreurs pendant le fonctionnement peuvent représenter des anomalies / dysfonctionnements critiques, en fonction de l'effet de l'erreur. En pratique, les programmes informatiques apparaissent rarement sans erreurs de programme. Une caractéristique de qualité pour les programmes est connue entre autres. la densité de défauts . Il décrit le nombre d'erreurs par 1000 lignes de code ( kilo de lignes de code source ) ou par point de fonction .

Les débogueurs , avec lesquels un programme peut être exécuté et contrôlé pas à pas, sont utiles en tant qu'instruments spéciaux pour rechercher les causes d'erreurs dans les programmes . Dans le cas de logiciels particulièrement critiques (par exemple le contrôle d'aéronefs), une vérification formelle (complexe) est parfois effectuée.

Des traqueurs de bogues (tels que Bugzilla ou Mantis ) sont utilisés pour l' enregistrement et la documentation . Il s'agit notamment des rapports d'erreurs ainsi que des suggestions d'amélioration et des demandes (appelées demandes de fonctionnalités ) des utilisateurs ou des processus généraux. Voir aussi gestion des défauts .

Le processus d'élimination d'une erreur de programme est familièrement appelé correction de bogues . Le résultat de l'amélioration est appelé en termes techniques une correction de bogue, un correctif ou un correctif logiciel .

Définitions

Une erreur de programme ou de logiciel est, sur la base de la définition générale de « erreur »

« Défaut de répondre à une exigence (EN ISO 9000 : 2005) ».

Plus précisément, l'erreur est alors définie comme

« Déviation de la RÉELLE (états ou processus observés, déterminés, calculés) par rapport à la CIBLE (états et processus définis et corrects), si elle dépasse la limite de tolérance prédéfinie [qui peut également être 0]."

Selon l' ISTQB , le terme « erreur » est formé à partir des contextes suivants :

• une action défectueuse (Erreur en anglais)

"L'action humaine qui conduit à une condition d'erreur ([selon IEEE 610])"

• ... entraîne un état d'erreur (Défaut anglais)

"Défaut (état de défaut interne) dans un composant ou un système qui peut altérer une fonction requise du produit ..."

• un effet de défaut peut (engl. Défaillance) conduire à

"La manifestation d'une erreur interne dans l'exécution [du programme] en tant que comportement ou résultat incorrect ou en tant que défaillance du système."

Exemple de division par zéro : Action incorrecte : Zéro comme valeur d'entrée possible n'a pas été vérifié / exclu ; Statut d'erreur : Le programme est (éventuellement inaperçu) défectueux ; Échec : la saisie d'une valeur nulle provoque une erreur d'exécution lors de l' exécution de la commande .

Des expressions telles que problème, défaut, écart, anomalie, carence sont également utilisés comme un synonyme de « erreur » ou en complément. Cela signifie que la « gravité de l'erreur » peut également être différenciée de manière conceptuelle, par ex. B. enfreignant les règles de style de programmation , en fournissant des résultats incorrects ou en mettant fin au programme .

"Bug" comme synonyme d'erreur de programme

Page de journal de bord du calculateur de relais Mark II Aiken avec le premier bug (1947)

Le mot bug signifie en anglais « Schnabelkerf ; Insecte "et familièrement" arthropode rural "ou" vermine (ressemblant à un insecte) ". Dans le jargon des ingénieurs américains , la signification « dysfonctionnement » ou « erreur de construction » est attestée depuis la fin du 19e siècle ; Cette utilisation du mot est basée sur l'idée (en plaisantant) que de petits bovins rampants jouent avec la boîte de vitesses, la ligne, etc. La preuve la plus ancienne est deux lettres de Thomas Edison de 1878 à William Orton , le président de la société de télégraphe Western Union , et Tivadar Puskás , l'inventeur du standard téléphonique , dans lesquelles il est écrit :

comme

Edison n'est pas un inventeur, mais au moins un témoin clé d'un sens du mot qui circulait à l'époque. L'association du terme avec les ordinateurs remonte peut-être à la pionnière de l'informatique Grace Hopper . Ils ont répandu l'histoire que le 9 septembre 1945, un papillon de nuit a fait fonctionner un relais dans l'ordinateur Mark II Aiken Relay Calculator . Le papillon a été retiré, collé dans le journal de bord et a reçu la note suivante : « Premier cas réel de bogue trouvé. ”(Allemand:“ La première fois qu'une 'vermine' a été trouvée. ”). La légende de la recherche du terme persiste, bien que l'entrée du journal de bord indique que le terme était déjà utilisé auparavant. De plus, Grace Hopper se trompait sur l'année : l'incident s'est en réalité produit le 9 septembre 1947. La page correspondante du journal de bord a été conservée au Naval Surface Warfare Center Computer Museum de l' US Navy à Dahlgren , Virginie jusqu'au début des années 1990 . Cette page de journal de bord avec le papillon est actuellement au Smithsonian Institute .

Types de bogues

En génie logiciel (voir aussi), une distinction est faite entre les types d'erreurs suivants dans les programmes :

• Les erreurs lexicales sont des chaînes de caractères non interprétables, c'est-à-dire des identifiants indéfinis (variables, fonctions, littéraux ...)
• Les erreurs de syntaxe sont des violations des règles grammaticales du langage de programmation utilisé , par exemple une utilisation incorrecte de symboles réservés (par exemple, des crochets manquants), des conflits de type, un nombre incorrect de paramètres.

Les erreurs lexicales et syntaxiques empêchent généralement la compilation du programme défectueux et sont donc reconnues à un stade précoce. Dans les langages de programmation interprétés de manière séquentielle , le programme ne s'interrompt généralement qu'au point syntaxiquement / lexicalement incorrect.

• Les erreurs sémantiques sont des erreurs dans lesquelles une instruction programmée est syntaxiquement correcte, mais toujours incorrecte en termes de contenu, par exemple confusion du code de commande, ordre de paramètre incorrect qui ne peut pas être reconnu syntaxiquement.
• Les erreurs logiques consistent en une approche de résolution de problèmes incorrecte dans les détails, par exemple en raison d'une conclusion erronée, d'une spécification mal interprétéeou simplement d'un oubli ou d'une erreur typographique. Exemples : plus au lieu de moins, plus petit au lieu de plus petit/égal, etc. La tolérance à de telles erreurs et la grammairedes attributs des langages de programmation quivisent à les restreindre, comme lacompatibilité d' affectation des types de données , sonttrès différentesselon sur le langage de programmation utiliséet il peut être difficile de comprendre les failles de sécurité et provoquer des plantages du programme .
• Les erreurs de conception sont des erreurs dans le concept de base, soit dans la définition des exigences du logiciel, soit dans le développement de la conception du logiciel sur la base de laquelle le programme est développé. Les erreurs dans la définition des exigences sont souvent basées sur une méconnaissance du domaine pour lequel le logiciel est écrit ou sur des malentendus entre utilisateurs et développeurs. D'un autre côté, les erreurs directement dans la conception du logiciel peuvent souvent être attribuées à un manque d'expérience de la part du développeur du logiciel , à une programmation non structurée ou à des erreurs ultérieures dues à des erreurs dans la spécification des exigences . Dans d'autres cas, la conception s'est développée au fil du temps et devient confuse au fil du temps, ce qui peut à son tour conduire à des erreurs de conception lorsque le programme est développé davantage. Souvent, la programmation est effectuée directement sans concept correct , ce qui peut conduire à des erreurs de conception, surtout si le logiciel est plus complexe. Pour les erreurs dans la définition des exigences ainsi que dans la conception du logiciel, les contraintes de coût ou de temps sont souvent un problème. Une erreur de conception typique est la répétition de code , qui ne conduit pas directement à des erreurs de programme, mais peut très facilement être négligée lors de la maintenance du logiciel , de la modification ou de l'extension du code du programme et conduit alors inévitablement à des effets indésirables.
• Erreur dans le concept de fonctionnement. Le programme se comporte différemment de ce à quoi s'attend un ou plusieurs utilisateurs, bien qu'il soit techniquement exempt d'erreurs.

Autres termes d'erreur

• Erreurs d'exécution : Alors que les erreurs mentionnées ci-dessus signifient un programme vraiment défectueux qui ne peut pas être exécuté ou fournit des résultats incorrects, un programme "correct" peut également entraîner des erreurs lors de son exécution. Les erreurs d'exécution sont tous les types d'erreurs qui se produisent pendant le traitement du programme. Selon la situation, la cause peut être, par exemple, un environnement de programme inadapté (par exemple uneversionincorrecte du système d'exploitation , des paramètres incorrectslors de l'appel du programme (également en tant que sous - routine ), des données d'entrée incorrectes, etc.)

Les erreurs d'exécution peuvent apparaître de différentes manières. Le programme présente souvent un comportement indésirable, dans des cas extrêmes, l'exécution du programme est interrompue (« crash ») ou le programme passe dans un état dans lequel il n'accepte plus les entrées de l'utilisateur (« freeze », « hang »).

Lire un fichier multimédia

Exemple d'impact d'une erreur de programme

Si, dans les langages de programmation sans ramasse-miettes automatique (par exemple C ou C++ ), la mémoire n'est plus libérée après utilisation, le programme occupera de plus en plus de mémoire à la longue. Cette situation s'appelle une fuite de mémoire . Cependant , des problèmes similaires peuvent également survenir dans les langages de programmation avec ramasse-miettes automatique (par exemple Java ou C# ) si, par exemple, des objets sont accumulés de manière incontrôlée en raison d' une programmation de bas niveau . Encore plus critiques sont les zones mémoire libérées accidentellement par le programmeur , qui sont souvent encore référencées par des pointeurs suspendus , car cela peut conduire à un comportement complètement incontrôlé du logiciel. Certains environnements d'exécution ne permettent donc généralement pas de telles libérations de mémoire programmables. Il existe également des bugs d'interaction avec d'autres programmes.

• Erreurs dans le compilateur, l'environnement d'exécution ou d'autres bibliothèques. De telles erreurs sont généralement particulièrement difficiles à comprendre car le comportement du programme dans de tels cas ne correspond pas à sa sémantique. En particulier, le compilateur et l'environnement d'exécution devraient donc être particulièrement fiables.
• Un bogue de régression ( régression signifie "pas en arrière") est une erreur qui n'apparaît que dans une version ultérieure du programme. Ce sont souvent des effets secondaires non détectés de corrections de bogues ou de changements de programme ailleurs.
• Erreurs dues aux conditions physiques de fonctionnement. Une grande variété d'événements tels que les champs électromagnétiques, les rayonnements, les fluctuations de température, les vibrations, etc. peuvent également entraîner des erreurs dans les systèmes qui sont par ailleurs correctement configurés et exploités conformément aux spécifications. Les erreurs de ce type sont très improbables, sont très difficiles à détecter et peuvent avoir des conséquences fatales dans les applications temps réel. Pour des raisons statistiques, elles ne peuvent cependant pas être exclues. La fameuse "chute d'un bit" dans la mémoire ou sur le disque dur due aux influences décrites est, par exemple, une telle erreur. Comme les effets d'une telle erreur (ex. été endommagé ) dont les autres erreurs de programme sont généralement très difficiles à distinguer, on soupçonne souvent une autre cause, d'autant plus qu'une telle erreur n'est souvent pas reproductible.
• Erreurs de programme vs erreurs logicielles : Dans la mesure où ces deux termes ne sont pas compris comme synonymes, une définition plus large peut également s'appliquer aux « erreurs logicielles » - conformément à la différence de sens entre programme informatique et logiciel : Selon cela, erreurs ou déficiences dans la documentation seraient également des erreurs logicielles, indépendamment du fait qu'elles aient conduit à des programmes défectueux. Des données incorrectes (ce terme est également attribué au logiciel en fonction de la définition) ne doivent guère être considérées comme une erreur de programme, mais plutôt, voire pas du tout, comme une erreur de logiciel.

Dans certains projets, le terme bogue n'est pas utilisé, mais plutôt, par exemple, des métabogues, dans lesquels un bogue est un élément d'une liste de tâches. Dans certains projets, le terme « problèmes » est utilisé à la place, car ce terme ne se limite pas aux bogues.

Des exemples spécifiques d'erreurs avec un impact média particulier peuvent être trouvés dans la liste des exemples d'erreurs de programme .

Sens économique

Les erreurs logicielles sont bien plus que de simples circonstances ennuyeuses pour les développeurs de logiciels ; elles entraînent des coûts considérables d'un point de vue commercial et économique . L'étude IX 1/2006 a montré z. B. les valeurs suivantes déterminées pour l'Allemagne :

• Les pertes annuelles dues aux erreurs logicielles dans les moyennes et grandes entreprises s'élèvent à environ 84,4 milliards d'euros
• Environ 14,4 milliards d'euros par an (35,9 % du budget informatique) sont utilisés pour éliminer les erreurs de programmation ;
• Les pertes de productivité dues aux pannes informatiques dues à des logiciels défectueux s'élèvent à environ 70 milliards d'euros

La même étude examine également l'évolution de la qualité des logiciels pour la période de 2002 à 2004 - avec le résultat :

• le taux de projets échoués est passé de 15% à 18%
• le taux de projets réussis est passé de 34 % à 29 %
• le taux de projets avec dépassement de coûts est passé de 43 % à 56 %
• le taux de projets en retard d'échéance est passé de 82 % à 84 %
• le taux de projets avec des fonctionnalités adaptées est passé de 67% à 64%

Un rapport de la Cour suprême des comptes pour les nouveaux projets (1985) de l'administration fédérale américaine fait état d'un nombre particulièrement élevé d'échecs, selon lequel

• 27% des logiciels payés n'ont jamais été livrés,
• 52% n'ont jamais travaillé,
• 18% n'ont été utilisés qu'après une rénovation importante.
• Seuls 3% des logiciels commandés remplissaient les conditions contractuelles convenues.

Le Standish Group International a déclaré : En moyenne, les projets dépassent

• les coûts du projet initialement prévus de 89 %
• les rendez-vous prévus de 222%.

Ewusi-Menach a identifié les facteurs suivants comme raisons des annulations de projets en raison de la mauvaise qualité du logiciel :

• Objectif peu clair
• Occupation incorrecte de l'équipe de projet
• Assurance qualité insuffisante
• Manque de savoir-faire technique
• Prise en compte insuffisante de la situation initiale
• Manque d'implication des utilisateurs

Évitement et correction des erreurs de programme

En général, plus l'erreur se produit tôt dans le processus de développement et plus elle est découverte tardivement, plus la correction de l'erreur prendra du temps.

Lors de la planification

La chose la plus importante est une bonne et appropriée planification du processus de développement. Il existe déjà un certain nombre de modèles procéduraux parmi lesquels un modèle approprié peut être sélectionné.

En phase d'analyse

Un problème est que l'exactitude d'un programme ne peut être prouvée que par rapport à une spécification formalisée de manière appropriée. Cependant, la création d'une telle spécification peut être aussi compliquée et sujette aux erreurs que la programmation du programme lui-même.

Le développement de paradigmes de programmation et de styles de programmation de plus en plus abstraits tels que la programmation fonctionnelle , la programmation orientée objet , la conception par contrat et la programmation orientée aspect servent, entre autres, à éviter les erreurs et à simplifier le dépannage. Une technique appropriée doit être choisie parmi les techniques disponibles pour le problème. Un point important ici est que des programmeurs expérimentés doivent être disponibles pour le paradigme respectif, sinon l'effet inverse se produit souvent.

Il est également très utile de laisser les outils de développement gérer autant de tâches d'évitement d'erreurs que possible de manière fiable et automatique. B. est facilité à l'aide d' une programmation structurée . D'une part, cela concerne les contrôles tels que les règles de visibilité et la sécurité de type , ainsi que l'évitement des références circulaires qui peuvent être adoptées par le compilateur avant la traduction des programmes , mais aussi les contrôles qui ne peuvent être effectués qu'à l' exécution , tels que des contrôles d' index pour les champs de données ou des contrôles de type pour les objets de la programmation orientée objet.

En phase de conception

Les experts en logiciels s'accordent à dire que pratiquement tous les programmes non triviaux contiennent des bogues. Des techniques ont donc été développées pour traiter les erreurs au sein des programmes de manière tolérante. Ces techniques incluent la programmation défensive , la gestion des exceptions , la redondance et la surveillance des programmes (par exemple, à l' aide de temporisateurs de surveillance ), ainsi que le contrôle de plausibilité du programme pendant le développement et des données pendant l'exécution du programme.

Lors de la programmation

De plus, un certain nombre d'applications avancées sont proposées qui analysent soit le code source, soit le code binaire et tentent de trouver les erreurs fréquemment commises de manière automatisée. Cette catégorie comprend les programmes de surveillance de l'exécution, qui détectent généralement de manière fiable les accès mémoire incorrects et les fuites de mémoire . Les exemples sont l'outil disponible gratuitement Valgrind et le commercial Purify . Une autre catégorie de programmes de test comprend des applications qui analysent de manière statique le code source ou binaire, telles que la recherche et le rapport de ressources non fermées et d'autres problèmes. Ceux-ci incluent FindBugs , Lint et Splint .

Lors des tests

Il est parfaitement logique que le test soit développé avant le programme réel. Cela garantit qu'un test n'est pas écrit qui correspond au programme qui a déjà été écrit . Cela peut être fait pendant la phase d'analyse ou de conception en déterminant les cas de test sur la base de la spécification . La détermination des cas de test à ce stade précoce du développement du logiciel permet également de vérifier les exigences du programme en termes de testabilité et d'exhaustivité. Les cas de test déterminés sur la base de la spécification constituent la base des tests d'acceptation - qui sont affinés en permanence tout au long du processus de développement et z. B. peut être préparé pour l' automatisation des tests .

Certains fournisseurs de logiciels effectuent parfois des phases de test publiquement et publient des versions bêta afin que les conditions d'utilisation imprévisiblement diverses des différents utilisateurs puissent être testées et commentées par eux.

Opérationnel

Si une erreur survient en cours d'exploitation, il faut s'efforcer de réduire au maximum ses effets et de contenir sa sphère d'activité en créant des « murs de protection » ou des « garde-fous ». Cela nécessite, d'une part, la capacité de détecter les erreurs et, d'autre part, d'être capable de réagir de manière adéquate à une erreur.

Un exemple de détection d'erreurs pendant l'exécution d'un programme informatique sont les assertions , à l'aide desquelles des conditions sont interrogées qui sont toujours remplies conformément à la conception du programme. D'autres mécanismes sont la gestion des exceptions telles que le trap et l'exception.

En implémentant du code porteur de preuves , le logiciel peut garantir et assurer sa fiabilité dans une certaine mesure pendant l'exécution.

Impeccable

L'absence totale d'erreurs pour les logiciels dépassant une certaine limite de complexité n'est pratiquement ni réalisable ni vérifiable. Avec une complexité croissante, la vue d'ensemble diminue, surtout si plusieurs personnes sont impliquées dans la programmation. Même les logiciels coûteux ou largement testés contiennent des erreurs de programmation. Dans le cas de programmes utilisables, on parle alors de robustesse plutôt que d'être exempt d'erreurs . Un logiciel est considéré comme robuste si les erreurs ne se produisent que très rarement et ne causent alors que des inconvénients mineurs et ne causent pas de dommages ou de pertes majeurs.

Dans des cas particuliers , il est possible de prouver qu'un programme est exempt d'erreurs (en ce qui concerne les exigences spécifiées). En particulier dans les domaines dans lesquels l'utilisation de logiciels est associée à des risques financiers, économiques ou humains élevés, tels que Par exemple, dans les logiciels utilisés à des fins militaires ou médicales ou dans l'industrie aérospatiale, une méthode appelée « vérification (formelle) » est également utilisée, dans laquelle l'exactitude du logiciel est prouvée mathématiquement. Cependant, en raison de l'énorme effort impliqué, cette méthode a des limites strictes et est donc pratiquement impossible à réaliser avec des programmes complexes (voir aussi la prévisibilité ). Cependant, il existe maintenant des outils qui, selon leurs propres informations, peuvent fournir cette preuve de manière rapide et fiable, au moins pour des zones partielles ( erreurs d'exécution ).

En plus de la vérification mathématique, il existe également une forme pratique de vérification, qui est décrite par la norme de gestion de la qualité ISO 9000 . Avec elle, une erreur n'est formellement établie que si une exigence n'est pas remplie. A l'inverse, un résultat de travail (et donc aussi un logiciel ) peut être décrit comme « sans erreur » s'il répond manifestement à toutes les exigences. La satisfaction d'une exigence est déterminée par des tests . Si tous les tests définis pour une exigence apportent les résultats attendus, l'exigence a été satisfaite. Si cela s'applique aux tests de toutes les exigences (en supposant des tests corrects et complets), il est conclu qu'il n'y a pas d'erreurs en ce qui concerne les exigences. Si les exigences sur lesquelles les tests sont basés sont défectueuses ou incomplètes, le logiciel ne fonctionnera toujours pas "comme souhaité".

Classification des défauts

Les erreurs qui surviennent sont généralement traitées systématiquement dans la gestion des erreurs . Selon la norme IEEE 1044 (classification des anomalies logicielles), chaque erreur passe par un processus dit de classification, composé des quatre étapes de reconnaissance, d'analyse (enquête), de traitement (action) et de conclusion (disposition). À chacune de ces étapes, les activités administratives d'enregistrement, de classification et d'identification de l'impact sont réalisées.

Les critères selon lesquels les erreurs peuvent être classées comprennent : (avec exemples) :

• Le type d'erreur : On distingue : les erreurs lexicales (référence inconnue), les erreurs syntaxiques (point-virgule oublié), les erreurs sémantiques ( déclaration incorrecte ), les erreurs d'exécution (données d'entrée mal formatées) et les erreurs logiques (plus au lieu de moins, boucle erreurs , ...)
• la cause de l'erreur : spécification imprécise, nombres tournés, formule incorrecte, données d'entrée non vérifiées (incorrectes) ...
• le moment où l'erreur s'est produite (« action incorrecte ») : déjà dans la spécification du programme, dans le projet de code, dans le codage, ...
• L'heure à laquelle l'erreur se produit (« effet d'erreur ») : une différence fondamentale réside dans le fait que l'erreur se produit pendant le développement du programme, par exemple pendant les tests (ici il s'agit d'un cas normal) ou en fonctionnement productif (où elle représente souvent un la faute).
• le temps de découverte : plus le "temps de maintien de l'erreur" est long, plus le temps est long i. A. L'action corrective se poursuivra.
• le(s) effet(s) de l'erreur : erreurs d'affichage, résultats erronés, arrêt du programme, effets externes...
• Effort et durée de dépannage : minimes... très élevés ; immédiatement ... très longue durée;
• Statut du traitement : survenu, examiné, ordre de correction en cours, retest possible, ..., terminé

À l'aide de métriques, « les résultats [et les constatations sur les erreurs] devraient également être une raison pour rechercher les causes des problèmes ». « Les classifications des erreurs constituent la base des procédures normalisées de traitement des erreurs et soutiennent également l'amélioration continue de la qualité au sens de la gestion de la qualité . » Des informations supplémentaires pour chaque erreur, telles qu'une description détaillée de l'erreur, les programmes concernés, les personnes impliquées, etc. accompagnent les mesures de éliminer les erreurs et les documenter. Pour plus d'informations, consultez le guide BITKOM.

Par souci de simplicité, les erreurs de programme dans le processus de gestion des erreurs ne sont souvent divisées qu'en catégories / classes telles que A, B, C ... ou 1, 2, 3 ... etc. en fonction de la gravité de l' erreur, qui comprend également l'effet de l'erreur et l'effort requis pour la rectifier. Pour des exemples, voir les directives BITKOM, notamment en annexe.

Conséquences des erreurs de programme

Les conséquences des erreurs de programme peuvent varier considérablement et se manifester de différentes manières. Si des erreurs sont découvertes au cours du processus de développement, les conséquences de l'erreur sont également limitées à la révision du logiciel (corrections de code, révision de concept, documentation ...) - selon la situation avec un effet plus ou moins important sur le budget du projet et la durée du projet. D'autre part, les erreurs qui ne sont reconnues que dans le fonctionnement productif ont souvent un effet plus critique, par exemple elles peuvent provoquer des interruptions de processus ou des arrêts de production, nuire à l'image, provoquer la perte de clients et de marchés, déclencher des obligations de recours ou même mettre en danger l'existence de l'entreprise. Dans le pire des cas, des erreurs dans les applications techniques peuvent conduire à des catastrophes.

Des exemples spécifiques d'erreurs de programme et de leurs conséquences peuvent être trouvés dans la liste d' exemples d'erreurs de programme .

Reproductibilité des erreurs de programme

Certaines erreurs de programme sont extrêmement difficiles ou impossibles à reproduire de manière fiable. Si un processus précédemment échoué est répété dans des conditions apparemment inchangées, il y a une probabilité que ces erreurs ne soient pas exprimées à nouveau. Il y a deux raisons possibles à ce comportement : D'une part, il peut y avoir des délais entre l'activation de l'erreur et le problème qui se produit finalement, par exemple un plantage du programme, qui masque la cause réelle et la rend difficile à identifier. D'autre part, d'autres éléments du système logiciel (matériel, système d'exploitation, autres programmes) peuvent influencer le comportement des erreurs dans le programme considéré. Un exemple de ceci sont les erreurs qui se produisent dans des environnements concurrents avec une synchronisation insuffisante (plus précisément : le séquençage ). En raison des conditions de concurrence qui en résultent , les processus peuvent être traités dans une séquence qui entraîne une erreur d'exécution. Si la même action est répétée, il est possible que l'ordre des processus soit différent et qu'aucun problème ne se pose.

Autres sujets

• Pour le principe de livraison d'un logiciel « immature », voir le principe de la banane # Banana ware .
• Logiciel qui (souvent offert gratuitement) par ex. B. présente des lacunes en matière de sécurité, de clarté ou de fonctionnalité utilisable ; voir merde

Littérature

• William E. Perry : Tests de logiciels. Mitp-Verlag, Bonn 2002, ISBN 3-8266-0887-9 .
• Elfriede Dustin, Jeff Rashka, John Paul : Tester le logiciel automatiquement. Procédure, manipulation et performance. Springer, Berlin et al. 2001, ISBN 3-540-67639-2 .
• Cem Kaner, Jack Falk, Hung Quoc Nguyen : Test de logiciels informatiques. 2e édition. John Wiley & Sons, New York NY et al. 1999, ISBN 0-471-35846-0 .

liens web

Wiktionnaire : bugs  - explications de sens, origines des mots, synonymes, traductions

• Les 25 erreurs de programmation les plus dangereuses (Anglais)
• SQS : Les erreurs logicielles les plus spectaculaires de 2012. Dans : Computerwoche. 17 janvier 2013, consulté le 20 janvier 2013 . 

Preuve individuelle

1. ↑ ^{a b c} M. Pol, T. Koomen, A. Spillner : Gestion et optimisation du processus de test. dpunkt.Verlag, Heidelberg 2002, ISBN 3-89864-156-2 .
2. ↑ Spillner et al. Test de logiciel de connaissances pratiques - exemple de lecture de gestion de test chap. 1.1 Connaissances de base / définition des erreurs ( Memento du 17 décembre 2010 dans Internet Archive ) (PDF) dpunkt.de
3. ↑ Merriam-Webster Unabridged Dictionary (iOS-App, 2016) : bogue : a) un insecte ou autre invertébré rampant ou rampant… b) l'un de certains insectes communément considérés comme particulièrement odieux… c) un insecte de l'ordre des hémiptères , en particulier : a membre du sous - ordre des hétéroptères ...
4. ↑ Les Papiers de Thomas A. Edison, vol. 4, éd. Paul B. Israel, Baltimore et Londres, 1993. En ligne [1]
5. ^ Fred R. Shapiro : Étymologie du bogue informatique : Histoire et folklore . Dans : American Speech 62 : 4, 1987, pp. 376-378.
6. ↑ ^{un b} informatik.uni-oldenburg.de
7. ↑ iX-Magazin , Study Software Test Management , était auparavant disponible dans le IX Kiosk ( Memento du 9 janvier 2013 dans Internet Archive )
8. ↑ ^{a b} Wallmüller: Software Quality Management in Practice, beck-shop.de (PDF; 612 kB), Hanser, Munich 2001, ISBN 978-3-446-21367-8 .
9. ↑ Junginger : Contrôle des risques axé sur la valeur dans la gestion de l'information . 2005, ISBN 3-8244-8225-8 .
10. ^ Georg Edwin Thaller test du logiciel, vérification et validation 2002, ISBN 978-3-88229-198-8 .
11. ↑ my.safaribooksonline.com
12. ↑ Classification standard IEEE pour les anomalies logicielles. (PDF) IEEE Standards Board, 1993, page 32 , consulté le 22 novembre 2014 (Livre blanc ; document derrière Paywall). 
13. ↑ ^{a b c} Classification des défauts pour le logiciel. BITKOM, décembre 2007, archivé à partir de l' original le 16 avril 2019 ; consulté le 11 avril 2021 .