Possiamo garantire che un programma non vada mai male?

Direi di no!

In teoria la risposta è no, possiamo solo testare per: -

• un numero limitato di ambienti.
• un numero limitato di scadenze.
• un numero limitato di casi di test.

Questo è considerevolmente inferiore al numero totale possibile di ambienti, tempi e casi che il programma potrebbe incontrare nel corso della sua vita. Inoltre, abbiamo poca conoscenza del futuro se doveste programmare un inflazione del 10.000%, il vostro programma dovrebbe far fronte a una nuova architettura a 31 bit super dupla?

La teoria è supportata dall'esperienza che ho personalmente riscontrato: -

• I programmi si rompono quando vengono spostati in una diversa localizzazione. Verifica di "MAGGIO" quando il mese era "MAI".
• Programmi che non hanno superato test su una nuova versione del compilatore, Un bug nella versione precedente in combinazione con un bug nel programma ha prodotto il risultato corretto.
• Programmi che si infrangono su una nuova versione del sistema operativo. Quando Solaris ha aumentato il numero predefinito di voci della directory, SMALLINT restituito da ftok () ha sempre restituito zero per il primo file nella directory.
I programmi
• si rompono perché era la prima volta che incontravano una particolare combinazione di input, che erano sia validi che inaspettati e non sarebbero mai stati testati: tassi di interesse negativi sui depositi, articoli a peso zero da spedire, articoli di tali valore basso che l'IVA non può essere calcolata ecc. ecc.

In teoria, se inizi con uno stato identico, il risultato sarà identico. In realtà, assicurare un identico stato iniziale in apparecchiature "server" è praticamente impossibile.

Prendi le variabili non inizializzate. Guarda questo codice:

  short i;

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

Ciò produrrà risultati imprevisti una volta in 65536 esecuzioni. E se non assicuri che la memoria sarà nello stesso stato prima di ogni corsa, i sarà interamente casuale.

Ci sono centinaia di modi per far apparire gli errori in seguito a elementi imprevedibili dello stato iniziale che qualcuno ha dimenticato di sovrascrivere, o casi di confine che si verificano raramente - condizioni di competizione in ambiente multi-thread, accesso ai confini fuori limite, I / O su disco danneggiato filesystem, e così via.

Se riesci a dimostrare che il programma è privo di bug, ci sono solo i raggi cosmici che possono romperlo. Ma la dimostrazione matematica della correttezza di qualsiasi cosa più complessa di due loop annidati va ben oltre la portata dei sistemi più grandi (e costa una piccola fortuna), e per tutto il resto puoi solo sperare.

Now my question is, will a computer program suddenly go wrong without any logical reason?

Se si ha esattamente lo stesso ambiente di calcolo, allora dare un input X ad un programma produrrà sempre lo stesso risultato R. In pratica, raramente è in esecuzione un singolo programma in isolamento. L'applicazione più semplice oggi viene eseguita in un sistema operativo e condivide la memoria con altri programmi che possono essere "caricati" in memoria contemporaneamente. Questi programmi possono alterare la memoria in un modo che rende un determinato malfunzionamento del programma. Questo è un famoso problema con variabili di tipo 'puntatore' per esempio. Solitamente tali errori causano comportamenti anomali del sistema e non risultati di calcolo errati.

Nel tuo caso, suppongo che il problema potrebbe essere (e di solito è) non quello che ho descritto sopra. Il problema potrebbe essere questo:

• il programma ha utilizzato i tipi di dati errati per calcolare il risultato, tale errore si manifesta solo quando vengono utilizzati valori speciali.
• il programma ha riscontrato un errore nel calcolo (a causa di una condizione logica) ma non ha gestito l'errore e ha comunque prodotto il risultato. (ad esempio mescolando il float e l'aritmetica dei numeri interi)
• una regola aziendale o una condizione logica non è stata codificata correttamente, i dati immessi rappresentano questa condizione ma è stato utilizzato il calcolo errato. (ad esempio, sottrarre l'importo dall'account prima di controllare l'importo nell'account).
• utilizzando formule che si applicano solo a determinati intervalli di numeri ma i dati contengono un intervallo diverso. (ad esempio calcolando un tasso di interesse in base a un intervallo di valori)

A causa di quanto sopra e di molte altre ragioni per cui il software spende così tante risorse nel tentativo di creare software corretto, tuttavia, si verificano ancora errori software, ma gli errori sono "logici" e hanno una ragione, è solo che la ragione non è ovvio per alcuni senza una buona ricerca. Quindi, in generale, il software testato è prevedibile e non produce risultati casuali. A causa della complessità di alcuni programmi e di altri fattori, anche i programmi testati possono andare male, ma quando ciò accade, gli errori sono per un motivo logico.

If I slam on the server machine, will one of the number which the computer is calculating, become another number and make the calculation wrong?

La risposta è no in generale, il software non è fragile in questo senso.

Quello che puoi fare è isolare i casi in cui si è verificato l'errore, trovare la somiglianza tra questi insiemi di dati che causano l'errore e trovare la differenza tra i gruppi di tesi e gli altri set che producono il risultato corretto. Potresti essere in grado di identificare il set di valori specifico che causa il problema. Ad esempio potresti scoprire che ogni volta che una variabile ha un valore negativo, il risultato è sbagliato.

Informazioni aggiornate sugli errori di corruzione della memoria: Per favore vedi Corruzione della memoria

Puoi garantire che un programma non abbia bug e non possa mai andare storto? No, sfortunatamente no.

Puoi dimostrare che un programma ha un numero sufficientemente piccolo di bug che il costo di trovarli e risolverli supera di gran lunga i benefici di quell'azione? Mi sembra che tu abbia già.

Per parafrasare una vecchia massima statistica, tutti i programmi sono sbagliati, ma alcuni programmi sono utili.

Sono propenso a dire no , non puoi provare che un programma non non va male o fornire un risultato errato, anche se puoi assumere un input perfetto.

Raku ha menzionato la prova formale di correttezza. Questa è una cosa da considerare, ma a meno che non mi sbagli completamente, sarà comunque necessario presupporre un ambiente di esecuzione perfetto. Quindi, con un po 'di tempo e sforzo, puoi forse provare che il programma è corretto , ma ciò non prova necessariamente che produrrà sempre i risultati , anche dato un input perfetto. L'ambiente di esecuzione è importante. E sarei cauto nell'assumere che l'input sia sempre perfetto,

Questo è il motivo per cui, in determinate situazioni ad alta disponibilità, vengono utilizzate implementazioni e ambienti di esecuzione multipli e completamente indipendenti, ei risultati vengono confrontati per assicurarsi che si trovino entro un margine di errore accettabile l'uno dall'altro. In alcune situazioni, tale margine potrebbe essere pari a zero. Già negli anni '60, ciò era ritenuto abbastanza importante da includere insiemi separati di hardware di calcolo in veicoli spaziali. Anche se una scarica statica errante, un raggio cosmico o qualsiasi altra cosa dovessero interessare entrambi i computer simultaneamente, le probabilità che entrambi fossero influenzati nello stesso modo (in particolare se entrambi stanno ancora funzionando e producendo risultati dall'aspetto valido) sono minuscole. Anche le probabilità dello stesso bug che si insinua in due implementazioni completamente separate sono estremamente ridotte. E così via.

A meno che tu non possa controllare ogni singolo bit nella macchina e ogni piccolo impulso elettrico che fluisce attraverso i circuiti, allora non puoi garantire con assoluta certezza che qualcosa non andrà storto nel tuo programma. I moduli di memoria non funzionano, le CPU possono surriscaldarsi e introdurre errori, i dischi rigidi possono confondere i dati e gli alimentatori possono introdurre rumore nel sistema. Più costoso è l'hardware e più è ridondante l'hardware, meno probabile sarà il verificarsi di queste cose, ma a un certo punto l'hardware può fallire.

Allora hai il sistema operativo, con bug che possono essere solleticati con i mezzi più arcani che si possano immaginare. I compilatori possono anche avere bug oscuri che aspettano solo di trasformare abilmente il tuo codice incontaminato in bug difficili da tracciare. È una giungla là fuori, e il tuo software scarso è vulnerabile a tutto questo. GUARDA!

E nella mia esperienza, il più delle volte, ogni volta che c'è un bug in un calcolo, non dobbiamo mai scavare così lontano per trovare il colpevole. In generale, quasi tutti i bug che ho visto nel mondo aziendale sono facilmente reperibili con gli strumenti di debug corretti e un po 'di gomito.

In altre parole, mentre l'hardware e il sistema operativo potrebbero non essere perfetti, probabilmente non dovrai mai preoccuparti di quel livello di dettaglio. Trova qualcuno che conosce la lingua, è a portata di mano con un debugger e scavare.

"le spiegazioni più semplici sono, a parità di altre condizioni, generalmente migliori di quelle più complesse." - Riepilogo del rasoio di Occam.

Sì, colpire un sistema potrebbe piegare e / o spostare parti abbastanza da causare un circuito aperto temporaneo (o eventualmente un cortocircuito, anche se probabilmente è meno probabile).

Il primo computer che possedevo era un Altair 8080 con 256 byte di memoria. L'input proveniva dagli switch di console e l'output proveniva da poche spie lampeggianti. Se non permetti i raggi cosmici e i guasti dell'hardware, credo che potrei provare che i alcuni programmi che ho eseguito genererebbero sempre gli stessi risultati.

Da allora, no.

Testing shows the presence, not the absence of bugs (Edsger W. Dijkstra)

Se stai provando a dimostrare che il tuo programma funziona correttamente testando, non funzionerà.

Tuttavia, ci sono alcuni approcci nell'informatica teorica in cui sviluppi una prova formale del software che hai scritto. A seconda della complessità del tuo sistema, tuttavia, questo può essere un processo noioso. Se il tuo sistema, comunque, funziona con un set limitato di comandi, potresti avere successo con questo approccio.

Gli ambienti hardware e software sono in costante stato di flusso. Parti mobili, elettricità, temperatura, polvere e modifiche al codice OS sono esempi.

Quindi non penso che sia anche probabile o previsto che un programma software per computer si comporti sempre nello stesso modo poiché l'ambiente cambia continuamente.

Il software può funzionare per un lungo periodo come previsto, ma alla fine cambierà una piccola modifica al software del sistema operativo host, il che influirà sul programma in questione o sull'hardware che valuterà.

Sto parlando dei computer di oggi.

Now my question is, will a computer program suddenly go wrong without any logical reason? If I slam on the server machine, will one of the number which the computer is calculating, become another number and make the calculation wrong?

La risposta a questa domanda è inconoscibile. È impossibile dimostrare che tutto è sempre vero per l'universo in cui viviamo. Invece facciamo assunzioni e proviamo che se le assunzioni valgono, allora terranno anche alcune proprietà complicate. Questo è ciò che i programmi verificati formalmente garantiscono. La maggior parte dei programmi non viene però formalmente verificata, ma cercano invece di aumentare la sicurezza fornendo test. Questi test ti danno la certezza che a condizione che i test facciano ciò che sono stati progettati per fare e che le supposizioni che hai fatto valere, il programma che stai usando funzionerà almeno una volta.

È appena possibile che il problema sia causato dalla mancanza di RAM, ma questo è relativamente (molto) improbabile. Esegui un test della memoria, ma sii pronto a consultare il codice.