Pouvons-nous garantir qu'un programme ne se trompera jamais?

Nous avons un système ici. Récemment, il y a un mauvais calcul dans l'un des nombres du rapport généré par le système. Tout au long de notre expérience, nous n'avons jamais rencontré de problème / erreur dans ce système depuis quelques années.

Parce que l'auteur de ce système était déjà parti, nous pouvons à peine retracer les programmes. Mais nous avons vérifié les données d'entrée, le réglage et ils sont corrects.

Maintenant ma question est, un programme informatique va-t-il soudainement mal tourner sans raison logique? Si je claque sur la machine serveur, l'un des nombres calculés par l'ordinateur deviendra-t-il un autre nombre et fera-t-il un mauvais calcul?

Je suis d'accord que mon idée est assez folle, mais je veux juste savoir, comment pouvons-nous savoir que le problème n'est pas causé par le programme et l'entrée, mais par d'autres facteurs?

PS Ce système fou n'a pas de journal.

Je dirais non!

En théorie, la réponse est non, nous ne pouvons tester que: -

• un nombre limité d'environnements.
• un certain nombre d'échelles de temps.
• un nombre limité de cas de test.

C'est considérablement moins que le nombre total possible d'environnements, de temps et de cas que le programme peut rencontrer au cours de sa durée de vie. De plus, nous avons peu de connaissances sur l'avenir si vous programmez face à une inflation de 10 000%, si votre programme doit faire face à une nouvelle architecture 31 bits super duper?

La théorie est appuyée par l'expérience que j'ai personnellement rencontrée: -

• Les programmes se brisent lorsqu'ils sont déplacés vers un autre lieu. Vérification de "MAI" lorsque le mois était "MAI".
• Programmes ayant échoué aux tests sur une nouvelle version du compilateur, Un bogue dans la version précédente en conjonction avec un bogue dans le programme a produit le résultat correct.
• Programmes cassant sur une nouvelle version du système d'exploitation. Lorsque Solaris augmente le nombre d'entrées de répertoire par défaut, le SMALLINT renvoyé par ftok () renvoie toujours zéro pour le premier fichier du répertoire.
• la rupture des programmes parce que c'était la première fois qu'ils rencontraient une combinaison particulière d'intrants qui étaient à la fois valides et inattendus et n'auraient jamais été testés - taux d'intérêt négatifs sur les dépôts, articles à poids zéro à expédier, articles d'une valeur si faible que La TVA n'a pas pu être calculée, etc. etc.

En théorie, si vous commencez avec un état identique, le résultat sera identique. En réalité, assurer un état initial identique dans un équipement "de taille serveur" est quasiment impossible.

Prenez des variables non initialisées. Regardez ce code:

  short i;

  if(i==-1)
  {
        //do something special
  }
  else
  {
        i=0;
        //do something else
  }

Cela produira des résultats inattendus une fois en 65536 exécutions. Et à moins que vous n'assuriez que la mémoire sera dans le même état avant chaque exécution, ielle sera entièrement aléatoire.

Il existe des centaines de façons similaires de faire apparaître des erreurs à la suite d'éléments imprévisibles de l'état initial que quelqu'un a oublié de remplacer, ou de limiter les cas qui se produisent rarement - conditions de concurrence dans un environnement multithread, accès au tableau hors limites, E / S disque sur un système de fichiers corrompu, et bientôt.

Si vous pouvez prouver que le programme est exempt de bogues, seuls les rayons cosmiques peuvent le briser. Mais la preuve mathématique de l'exactitude de quelque chose de plus complexe que deux boucles imbriquées est à peu près au-delà de la portée des plus grands systèmes (et coûte une petite fortune), et pour tout le reste, vous ne pouvez qu'espérer.

Maintenant ma question est, un programme informatique va-t-il soudainement mal tourner sans raison logique?

Si vous avez exactement le même environnement informatique, alors donner une entrée X à un programme produira toujours le même résultat R. En pratique, il est rarement d'avoir un seul programme s'exécutant de manière isolée. Aujourd'hui, l'application la plus simple s'exécute dans un système d'exploitation et partage la mémoire avec d'autres programmes qui peuvent être «chargés» en même temps. Ces programmes peuvent altérer la mémoire d'une manière qui provoque des dysfonctionnements d'un programme donné. C'est un problème connu avec les variables de type 'pointeur' par exemple. De telles erreurs provoquent généralement des comportements anormaux du système et non des résultats de calcul erronés.

Dans votre cas, je suppose que le problème n'est pas (et n'est généralement pas) ce que j'ai décrit ci-dessus. Le problème peut être que:

• le programme a utilisé le ou les mauvais types de données pour calculer le résultat, cette erreur ne se manifeste que lorsque des valeurs spéciales sont utilisées.
• le programme a rencontré une erreur de calcul (en raison d'une condition logique) mais n'a pas géré l'erreur et a tout de même produit le résultat. (par exemple, mélange d'arithmétique flottante et entière)
• une règle métier ou une condition logique n'a pas été codée correctement, les données saisies représentent cette condition mais un mauvais calcul a été utilisé. (par exemple, soustrayez le montant du montant du compte avant de vérifier d'abord le montant dans le compte).
• en utilisant des formules qui s'appliquent uniquement à une certaine plage de nombres mais les données contiennent une plage différente. (par exemple, calcul d'un taux d'intérêt basé sur une plage de valeurs)

En raison de ce qui précède et de nombreuses autres raisons pour lesquelles les gens dépensent autant de ressources en logiciels pour essayer de créer un logiciel correct, cependant, des erreurs de logiciel se produisent toujours, mais les erreurs sont «logiques» et ont une raison, c'est juste que la raison n'est pas évidente à certains sans bonne recherche. Ainsi, en général, les logiciels testés sont prévisibles et ne produisent pas de résultats aléatoires. En raison de la complexité de certains programmes et d'autres facteurs, même les programmes testés peuvent mal tourner, mais lorsque cela se produit, les erreurs sont pour une raison logique.

Si je claque sur la machine serveur, l'un des nombres calculés par l'ordinateur deviendra-t-il un autre nombre et fera-t-il un mauvais calcul?

La réponse est non en général, les logiciels ne sont pas fragiles en ce sens.

Ce que vous pouvez faire est d'isoler les cas où l'erreur se produit, de trouver la similitude entre ces ensembles de données à l'origine de l'erreur et de trouver la différence entre ces ensembles et les autres ensembles qui produisent le résultat correct. Vous pourrez peut-être identifier l'ensemble de valeurs spécifiques à l'origine du problème. Par exemple, vous pouvez constater que chaque fois qu'une variable a une valeur négative, le résultat est incorrect.

Informations mises à jour sur les erreurs de corruption de mémoire: voir la corruption de mémoire

Pouvez-vous garantir qu'un programme n'a pas de bogues et ne se trompera jamais? Non, malheureusement non.

Pouvez-vous démontrer qu'un programme a un nombre de bogues suffisamment petit pour que le coût de leur recherche et de leur correction dépasse de loin les avantages de cette action? Il me semble que vous l'avez déjà fait.

Pour paraphraser une vieille maxime de statistiques, tous les programmes sont faux, mais certains programmes sont utiles.

Je suis enclin à dire non , vous ne pouvez pas prouver qu'un programme ne se trompera jamais ou ne fournira pas un résultat incorrect, même si vous pouvez supposer une entrée parfaite.

Raku a mentionné une preuve formelle d'exactitude. C'est une chose à considérer, mais à moins que je ne me trompe complètement, cela devra encore supposer un environnement d'exécution parfait. Donc, avec un peu de temps et d'efforts, vous pouvez peut-être prouver que le programme est correct , mais cela ne prouve pas nécessairement qu'il produira toujours les bons résultats , même avec une entrée parfaite. L'environnement d'exécution est important. Et je me méfierais de supposer que l'entrée est toujours parfaite non plus.

C'est pourquoi, dans certaines situations de haute disponibilité, plusieurs implémentations et environnements d'exécution complètement indépendants sont utilisés et les résultats sont comparés pour s'assurer qu'ils se trouvent dans une marge d'erreur acceptable les uns des autres. Dans certaines situations, cette marge peut très bien être nulle. Même dans les années 1960, cela était jugé suffisamment important pour inclure des ensembles distincts de matériel informatique dans les vaisseaux spatiaux. Même si une décharge statique errante, un rayon cosmique ou quoi que ce soit devait affecter les deux ordinateurs simultanément, les chances que les deux soient affectés de la même manière (en particulier s'ils fonctionnent et produisent des résultats valides) sont minuscules. Les chances qu'un même bogue se glisse dans deux implémentations complètement séparées sont également extrêmement faibles. Etc.

La plupart des calculs (standard) sont déterministes, je pense.

Si possible, configurez-le pour effectuer un lot de 1 000 ou 10 000, etc., itérations avec les mêmes données d'entrée et vérifiez que les résultats sont identiques.

Assurez-vous que les valeurs actuelles entrant dans le calcul provoqueraient un débordement ou un dépassement n'importe où (s'il s'agit d'un système plus ancien, il n'est peut-être pas prévu qu'il soit utilisé aussi longtemps).

Y2K11 quelqu'un?

À moins que vous ne puissiez contrôler chaque bit de la machine et chaque impulsion électrique circulant dans les circuits, vous ne pouvez pas garantir avec une certitude absolue que quelque chose ne va pas mal avec votre programme. Les modules de mémoire échouent, les processeurs peuvent surchauffer et introduire des erreurs, les disques durs peuvent brouiller les données et les blocs d'alimentation peuvent introduire du bruit dans le système. Plus le matériel est cher et plus le matériel est redondant, moins ces choses se produiront, mais à un moment donné, le matériel peut échouer.

Ensuite, vous avez le système d'exploitation, avec des bogues qui peuvent être chatouillés par les moyens les plus obscurs imaginables. Les compilateurs peuvent également avoir des bogues obscurs qui n'attendent que de transformer habilement votre code vierge en bogues difficiles à tracer. C'est une jungle là-bas, et votre pauvre logiciel est vulnérable à tout cela. ATTENTION!

Et d'après mon expérience, le plus souvent, chaque fois qu'il y a un bug dans un calcul, nous n'avons jamais à creuser aussi loin pour trouver le coupable. De manière générale, presque tous les bogues que j'ai vus dans le monde de l'entreprise sont faciles à trouver avec les bons outils de débogage et un peu d'huile de coude.

En d'autres termes, bien que le matériel et le système d'exploitation ne soient pas parfaits, vous n'aurez probablement jamais à vous soucier de ce niveau de détail. Il suffit de trouver quelqu'un qui connaît la langue et qui est à portée de main avec un débogueur et de creuser.

"Des explications plus simples sont, toutes choses étant égales par ailleurs, généralement meilleures que des explications plus complexes." - Résumé du rasoir d'Occam.

Oui, frapper un système pourrait plier et / ou déplacer suffisamment de pièces pour provoquer un circuit ouvert temporaire (ou éventuellement un court-circuit, bien que ce soit probablement moins probable).

Le premier ordinateur que je possédais était un Altair 8080 avec 256 octets de mémoire. L'entrée provenait de commutateurs de console et la sortie de quelques voyants clignotants. Si vous interdisez les rayons cosmiques et les pannes matérielles, je crois que je pourrais prouver que certains programmes sur lesquels je l'ai exécuté produiraient toujours les mêmes résultats.

Depuis lors, non.

Les tests montrent la présence, pas l'absence de bugs (Edsger W. Dijkstra)

Si vous essayez de prouver que votre programme fonctionne correctement en testant, cela ne fonctionnera pas.

Cependant, il existe certaines approches en informatique théorique où vous développez une preuve formelle du logiciel que vous avez écrit. Selon la complexité de votre système, cela peut cependant être un processus fastidieux. Cependant, si votre système fonctionne sur un ensemble restreint de commandes, vous pouvez réussir avec cette approche.

Les environnements matériels et logiciels sont en constante évolution. Les pièces mobiles, l'électricité, la température, la poussière et les modifications du code du système d'exploitation en sont des exemples.

Par conséquent, je ne pense pas qu'il soit même probable ou prévu qu'un programme informatique se comportera toujours de la même manière, car l'environnement est en constante évolution.

Le logiciel peut fonctionner pendant longtemps comme prévu, mais finalement, soit une petite modification du logiciel du système d'exploitation hôte changera, ce qui affecterait le programme en question, soit le matériel sera valorisé.

Je parle des ordinateurs actuels.

Maintenant ma question est, un programme informatique va-t-il soudainement mal tourner sans raison logique? Si je claque sur la machine serveur, l'un des nombres calculés par l'ordinateur deviendra-t-il un autre nombre et fera-t-il un mauvais calcul?

La réponse à cette question est inconnue. Il est impossible de prouver que quelque chose est toujours vrai de l'univers dans lequel nous vivons. Au lieu de cela, nous faisons des hypothèses et prouvons que si les hypothèses se vérifient, alors certaines propriétés compliquées se maintiendront également. C'est ce que garantissent les programmes officiellement vérifiés. Cependant, la plupart des programmes ne sont pas officiellement vérifiés, ils essaient plutôt de renforcer la confiance en fournissant des tests. Ces tests vous donnent l'assurance que, à condition qu'ils fassent ce pour quoi ils ont été conçus et que les hypothèses que vous avez formulées, le programme que vous utilisez fonctionnera au moins une partie du temps.

Il est à peine possible que le problème soit causé par une défaillance de la RAM, mais cela est relativement (très) peu probable. Exécutez un test de mémoire, mais soyez prêt à parcourir le code.