• Regolamento Macrocategoria DEV
    Prima di aprire un topic nella Macrocategoria DEV, è bene leggerne il suo regolamento. Sei un'azienda o un hosting/provider? Qui sono anche contenute informazioni per collaborare con Sciax2 ed ottenere l'accredito nella nostra community!

Guida Tipi di bugs.

Aatrox

Utente Normale
Autore del topic
16 Agosto 2015
72
0
Miglior risposta
0
Salve,

sto avendo un bel po di tempo libero per dedicarmi completamente e dico completamente a Sciax2 poiché sto facendo delle belle guide, oggi tratterò un'argomento alquanto interessante.

TIPI DI BUG


bug.jpg


Come da titolo, in questo Thread vorrei condividere con tutti le mie conoscenze su codesto argomento, ossia i tipi di bug che ognuno di noi incontrerà (sempre purtroppo) nel momento in cui si sviluppa un sistema software (non programmini da 200 righe di codice ma parlo di programmi almeno con centinaia di migliaia di righe di codice).


Prima di incominciare a esaminare i bug è giusto fare alcune chiarificazione e introdurre la differenza tra una Failure, un Fault ed un Error. La differenza sostanziale tra i tre è la seguente:

• Fallimento / Failure: incapacità di una costituente o di un sistema di produrre i risultati corretti con uno specificato contesto.

Esempio: gli interessi di mora calcolati da un sistema sono diversi da quelli calcolati con l’applicazione corretta del calcolo degli interessi di mora, quando il ritardo di pagamento non è uguale per ogni versamento.


• Imperfezione / Fault: assenza o inesattezza di un pezzo di codice o di specifica.​

Esempio: l’espressione di una variabile ha operatori od operandi sbagliati o la condizione che domina un punto di decisione è espressa in modo errato.


• Errore / Error : è l'azione umana che sviluppa un difetto.​


Naturalmente, ci sono diversi tipi di fault, addirittura sono classificati in varie categorie quindi immaginate quanti tipi ce ne siano. Aggiungo anche che effettuare un manutenzione su un software per eliminare un failure è più costoso rispetto che eliminare un fault.
Or bene, l'obiettivo di un progettista SW è quello di scovare il prima possibile tutti i fault possibili ed immaginabili. Questo lo si fa attraverso dei test, delle ispezioni, la verifica e la validazione. (Magari tratterò di questi argomenti in un secondo articolo.


Adesso possiamo discutere dei fastidiosi bug che tanto ci piacciono!!! (Se siete masochisti).
Alcuni test specifici sono utili per rilevare certi tipi di Failure che si manifestano a causa di ben definiti Fault; questi tipi di failure sono chiamati Bohrbugs, alludendo al modello atomico semplice ed intelleggibile di Bohr.


Alcuni Fault producono malfunzionamenti che si diffondono nel sistema software e si manifestano con Failure in tempi e modalità non sistematiche; alcuni chiamano questi Heisenbugs, facendo riferimento al principio di indeterminazione di Heisenberg; la maggior parte li chiamano Mandelbugs, facendo riferimento ai frattali di
Mandelbrot.
Un sistema software affetto da Mandelbugs può raggiungere lo stato interno che genera Failure attraverso due modi (principalmente), ossia:

1. Un duraturo funzionamento che accumuli malfunzionamenti derivati da ripetute esecuzioni di percorsi, nei programmi, attivabili da poche e non frequenti azioni degli utilizzatori;
2. Una incessantemente riesecuzione di algoritmi il cui funzionamento si basi sui risultati errati delle esecuzioni precedenti di questi stessi algoritmi.​



UN MANDELBUG FAMOSO



Il software per riscontrare i Patriot che prevedeva la traiettoria dei missili Scud per intercettarli e farli esplodere prima che questi raggiungessero l’obiettivo. Per calcolare la traiettoria dello Scud, il software utilizzava la velocità e l’ora come valori reali; il sistema dava il tempo come il valore intero di decine di secondi trascorsi dalla sua accensione.
La trasformazione del valore intero in valore reale era inaccurato e questa inaccuratezza era tanto maggiore quanto maggiore era il valore di secondi che doveva trasformare, pertanto il software aveva tanto più la probabilità di sbagliare la previsione della traiettoria quanto più lungo era il suo funzionamento continuativo. Il 21/25 febbraio 1991 il funzionamento del software di controllo fu tanto lungo che molti Scud centrarono i loro obiettivi perché i Patriot prevedevano erroneamente l’area di intercettazione.



DIFESA E PROTEZIONE DAI MANDELBUGS


Ci sono due metodi:

• Ripartenza del sistema, in maniera che la condizione del sistema sia azzerata da eventuali errori precedenti ( contro la ri-esecuzione continuativa degli algoritmi)
• Uso di sistemi ridondanti che hanno storie diverse per rilevare tempestivamente gli errori derivanti dai lunghi funzionamenti.​



PREVENZIONE DAI MANDELBUGS


Per prevenirli bisogna fare dei test specifici (ossia test di invecchiamento e test di monitoraggio della condizione interna), inoltre per ogni failure rilevata si devono analizzare i log generati dal monitoraggio (test) per estrarre la storia che ha portato dal Fault o dai Faults alla Failure ed individuare le modifiche da apportare al software.



Spero che la discussione sia di vostro gradimento, se non è chiaro qualcosa potete contattarmi per maggiori spiegazioni. Grazie per l'attenzione!


Cordiali saluti,
Aatrox
 
Ultima modifica:
Secondo me tutte le tue guide riguardanti la sicurezza informatica dovrebbero essere in rilievo :soso: Questa è una bella guida, ma non so se è nella sezione adatta :emoji_confused:
 
Secondo me tutte le tue guide riguardanti la sicurezza informatica dovrebbero essere in rilievo :soso: Questa è una bella guida, ma non so se è nella sezione adatta :emoji_confused:
Beh si mi ha già risposto Danilo che non è che ogni guida che uno fa deve essere messa in rilievo, anche se le mie sono le migliori. Comunque grazie per il commento, grossomodo faccio un lavoro sempre in ambito (sicurezza) visto che lavoro in un'azienda che produce sistemi di sicurezza ad alto livello.
 
Ultima modifica: