Possiamo garantire che un programma non andrà mai male?

Abbiamo un sistema qui. Recentemente c'è un calcolo errato in uno dei numeri nel rapporto generato dal sistema. Attraverso la nostra esperienza, non abbiamo mai riscontrato problemi / errori in questo sistema per alcuni anni.

Poiché lo scrittore di questo sistema era già sparito, difficilmente possiamo tracciare i programmi. Ma abbiamo verificato i dati di input, l'impostazione e sono giusti.

Ora la mia domanda è: un programma per computer andrà improvvisamente storto senza alcun motivo logico? Se sbatto sul server, uno dei numeri calcolati dal computer diventerà un altro numero e il calcolo sarà errato?

Sono d'accordo che la mia idea sia piuttosto folle, ma voglio solo sapere, come possiamo sapere che il problema non è causato dal programma e dall'input, ma da alcuni altri fattori?

PS Questo sistema pazzo non ha log.

Direi di no!

In teoria la risposta è no, possiamo solo verificare: -

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

Questo è notevolmente inferiore al numero totale possibile di ambienti, tempi e casi che il programma può riscontrare nella sua vita. Inoltre, abbiamo una scarsa conoscenza del futuro se il programma deve far fronte all'inflazione del 10.000%, il programma dovrebbe far fronte a una nuova architettura a 31 bit super duper?

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

• Programmi che si interrompono quando vengono spostati in un'altra lingua. Verifica "MAGGIO" quando il mese era "MAI".
• Programmi che non superano i test su una nuova versione del compilatore, un errore nella versione precedente in combinazione con un errore nel programma ha prodotto il risultato corretto.
• Programmi interrotti su una nuova versione del sistema operativo. Quando Solaris aumenta il numero predefinito di voci della directory, SMALLINT restituito da ftok () restituisce sempre zero per il primo file nella directory.
• programmi che si rompono perché era la prima volta che incontravano una particolare combinazione di input, che erano sia validi che inattesi e che non sarebbero mai stati testati: tassi di interesse negativi sui depositi, articoli a peso zero da spedire, articoli di così basso valore che IVA non calcolabile ecc. Ecc.

In teoria, se inizi con uno stato identico, il risultato sarà identico. In realtà, è praticamente impossibile garantire lo stato iniziale identico in apparecchiature "di dimensioni server".

Prendi 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 a 65536 esecuzioni. E a meno che non si assicuri che la memoria sarà nello stesso stato prima di ogni esecuzione, isarà del tutto casuale.

Esistono centinaia di modi simili per la comparsa di errori a seguito di elementi imprevedibili dello stato iniziale che qualcuno ha dimenticato di ignorare o casi limite che si verificano raramente: condizioni di competizione in ambiente multi-thread, accesso array fuori limite, I / O disco su file system danneggiato e presto.

Se puoi provare che il programma è privo di bug, ci sono solo i raggi cosmici che possono romperlo. Ma la prova matematica della correttezza di qualcosa di più complesso di due anelli nidificati va ben oltre la portata dei sistemi più grandi (e costa una piccola fortuna), e per tutto il resto puoi solo sperare.

Ora la mia domanda è: un programma per computer andrà improvvisamente storto senza alcun motivo logico?

Se hai esattamente lo stesso ambiente di elaborazione, quindi dare un input X a un programma produrrà sempre lo stesso risultato R. In pratica, raramente un singolo programma viene eseguito in modo isolato. 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 modo da causare malfunzionamenti a un determinato programma. Questo è un problema famoso, ad esempio con variabili di tipo 'pointer'. Di solito tali errori causano comportamenti anomali del sistema e risultati di calcolo non errati.

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

• 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 es. miscelazione di float e numeri interi aritmetici)
• una regola aziendale o una condizione logica non sono state codificate correttamente, i dati immessi rappresentano questa condizione ma è stato utilizzato il calcolo errato. (ad es. sottrarre l'importo dall'importo del conto prima di verificare prima l'importo nel conto).
• utilizzando formule che si applicano solo a un determinato intervallo di numeri ma i dati contengono un intervallo diverso. (ad es. calcolo di un tasso di interesse basato su un intervallo di valori)

A causa di quanto sopra e di molti altri motivi per cui le persone software spendono 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 è ovvia 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 storti, ma quando ciò accade, gli errori sono per una ragione logica.

Se sbatto sul server, uno dei numeri calcolati dal computer diventerà un altro numero e il calcolo sarà errato?

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

Quello che puoi fare è isolare i casi in cui si verifica l'errore, trovare la somiglianza tra questi insiemi di dati che causano l'errore e trovare la differenza tra questi insiemi e gli altri insiemi che producono il risultato corretto. Potrebbe essere possibile identificare l'insieme specifico di valori che causano 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: vedere Corruzione della memoria

Potete garantire che un programma non abbia bug e non andrà mai male? 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 il beneficio di tale azione? Mi sembra che tu l'abbia già fatto.

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

Sono propenso a dire di no , non puoi provare che un programma non andrà mai storto o fornire un risultato errato, anche se puoi assumere un input perfetto.

Raku menzionò una prova formale di correttezza. Questa è una cosa da considerare, ma a meno che non mi sbagli completamente, dovrà comunque assumere un ambiente di esecuzione perfetto. Quindi, con un po 'di tempo e fatica, puoi forse dimostrare che il programma è corretto , ma ciò non dimostra necessariamente che produrrà sempre i risultati corretti , anche dato un input perfetto. L'ambiente di esecuzione è importante. E sarei diffidente nell'ipotizzare che anche l'input sia sempre perfetto.

Questo è il motivo per cui, in determinate situazioni di elevata disponibilità, vengono utilizzate più implementazioni e ambienti di esecuzione completamente indipendenti e i risultati vengono confrontati per assicurarsi che si trovino in un margine di errore accettabile l'uno dall'altro. In alcune situazioni, quel margine potrebbe benissimo essere zero. Già negli anni '60, questo era ritenuto abbastanza importante da includere set separati di hardware di calcolo nei veicoli spaziali. Anche se una scarica statica errata, un raggio cosmico o qualsiasi altra cosa influenzasse entrambi i computer contemporaneamente, le probabilità che entrambi vengano influenzati allo stesso modo (in particolare se entrambi funzionano ancora e producono 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.

La maggior parte del calcolo (standard) è deterministico, penso.

Se possibile, impostarlo per eseguire un batch di 1000 o 10000, ecc., Iterazioni con gli stessi dati di input e verificare che i risultati risultino uguali.

Assicurati che i valori correnti inseriti nel calcolo provochino un overflow o un underflow ovunque (se si tratta di un sistema più vecchio, potrebbe non essere stato progettato per essere utilizzato così a lungo).

Y2K11 qualcuno?

A meno che tu non possa controllare ogni singolo bit della macchina e ogni singolo impulso elettrico che fluisce attraverso i circuiti, non puoi garantire con assoluta certezza che qualcosa non andrà storto con il tuo programma. I moduli di memoria si guastano, le CPU possono surriscaldarsi e introdurre errori, i dischi rigidi possono confondere i dati e gli alimentatori possono introdurre rumori nel sistema. Quanto più costoso è l'hardware e tanto più ridondante è l'hardware, tanto meno probabile accadranno queste cose, ma a un certo punto l'hardware potrebbe non funzionare.

Quindi hai il sistema operativo, con bug che possono essere solleticati dai mezzi più arcani immaginabili. I compilatori possono anche avere bug oscuri che aspettano solo di trasformare abilmente il codice originale in bug difficili da rintracciare. È una giungla là fuori e il tuo povero software è vulnerabile a tutto questo. ATTENZIONE!

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 giusti e un po 'di grasso per i gomiti.

In altre parole, mentre l'hardware e il sistema operativo potrebbero non essere perfetti, probabilmente non dovrai mai preoccuparti di quel livello di dettaglio. Basta trovare qualcuno che conosca la lingua, che sia utile con un debugger e scavare.

"le spiegazioni più semplici sono, a parità di altre cose, generalmente meglio di quelle più complesse". - Riassunto del rasoio di Occam.

Sì, colpire un sistema potrebbe piegare e / o spostare le 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'ingresso proveniva da switch di console e l'output proveniva da alcune spie lampeggianti. Se si impediscono i raggi cosmici e guasti hardware, credo che potrei provare che alcuni programmi su cui ho eseguito avrebbero sempre prodotto gli stessi risultati.

Da allora, no.

I test mostrano la presenza, non l'assenza di bug (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 sistema, questo può essere un processo noioso. Se il tuo sistema, tuttavia, funziona con un set limitato di comandi, potresti avere successo con questo approccio.

Gli ambienti hardware e software sono in costante evoluzione. Le parti mobili, l'elettricità, la temperatura, la polvere e le modifiche al codice del sistema operativo sono esempi.

Pertanto non credo sia nemmeno probabile o prevedibile che un programma software per computer si comporterà sempre allo stesso modo poiché l'ambiente è in continua evoluzione.

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

Sto parlando dei computer attuali.

Ora la mia domanda è: un programma per computer andrà improvvisamente storto senza alcun motivo logico? Se sbatto sul server, uno dei numeri calcolati dal computer diventerà un altro numero e il calcolo sarà errato?

La risposta a questa domanda è inconoscibile. È impossibile provare che qualsiasi cosa sia sempre vera nell'universo in cui ci capita di vivere. Invece facciamo ipotesi e dimostriamo che se le ipotesi valgono, anche alcune proprietà complicate valgono. Questo è ciò che garantiscono i programmi verificati formalmente. Tuttavia, la maggior parte dei programmi non è formalmente verificata, ma cerca invece di creare confidenza fornendo test. Questi test ti danno la certezza che a condizione che i test facciano quello per cui sono stati progettati e che i presupposti che hai fatto valere, il programma che stai usando funzionerà almeno qualche volta.

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