Testing software: Testing dei sistemi Safety Critical

I Critical System, in italiano sistemi critici, possono essere classficati principalmente in base allo scopo e al dominio applicativo:

1. Safety-critical: sistemi il cui fallimento (failure) può causare ferimenti, perdite di vita, o seri danni ambientali (e.g. sistema di controllo per un impianto
   chimico);
2. Mission-critical: sistemi il cui fallimento (failure) può causare il fallimento di attività guidate da obiettivo (per esempio un sistema di navigazione di una navetta spaziale);
3. Business-critical: sistemi il cui fallimento (failure) può causare ingenti perdite di denaro (per esempio un sistema di gestione dei conti correnti in una banca).

Safety Critical System

In contesti applicativi in cui è messa in pericolo la vita umana, il concetto di rischio assume una notevole importanza. Nonostante ciò, la complessità dei sistemi cresce a ritmi sostenuti, incrementando evidentemente le difficoltà di gestione degli stessi e le probabilità che essi possano fallire in maniera catastrofica. E’ possibile definire come mishap un evento, o una serie di eventi non previsti, che possono causare danni fisici a persone o compromettere l’ambiente circostante. Un sistema safety critical è caratterizzato, pertanto, dalla probabilità di occorrenza di un mishap.
E’ evidente che una riduzione dei rischi, ovvero la minimizzazione delle probabilità di occorrenza di fallimenti catastrofici, comporta un aumento dei costi, tirando in gioco anche aspetti economici nella gestione di un sistema critico. Occorre stabilire in quale misura la riduzione dei rischi può ritenersi accettabile.

Considerato che la tecnologia è sempre più controllata dal software, una buona parte dei rischi è rimessa nelle mani degli ingegneri del software, in quanto la qualità del software da essi prodotto ne influenza sensibilmente l’occorrenza. Nella maggior parte dei casi un rischio non produce alcun tipo di effetto; tuttavia nel peggiore dei casi questo è in grado di produrre conseguenze catastrofiche capaci di minare la salute, o in certi casi, la vita di esseri umani. Pertanto appare evidente come, in tali ambienti, il software assuma un ruolo fondamentale nonché critico.
Si consideri che ad oggi il software costituisce un componente imprescindibile in sistemi di controllo nucleari, negli autoveicoli e nei sistemi per la difesa militare e per il controllo del traffico aereo. In questi contesti un rischio può essere definito come un insieme di condizioni ambientali e di eventi che possono causare un incidente.

In un sistema software, inoltre, un difetto può risultare dormiente, e dunque non rilevabile, finché un particolare insieme di condizioni operative non ne provoca la manifestazione.

Testing dei Safety Critical System

Il testing verifica che i requisiti di sicurezza del software siano soddisfatti dal sistema e che l’analisi dei rischi sia corretta.
I requisiti di sicurezza spesso descrivono condizioni invarianti che devono verificarsi in tutte le circostanze; il testing in questi casi verifica che il sistema sia tollerante al verificarsi di eventuali errori del software (fault-tolerance); il testing, inoltre, può anche dimostrare che il software risponda appropriatamente a situazioni anomale. A tal proposito i casi di test devono marcare le condizioni di inizio e di fine (startup e shutdown) e le condizioni anomale (individuazione e correzione degli errori), poiché da una gestione impropria di questi stati vulnerabili possono derivare dei mishap.
Il testing di un sistema sicuro viene notevolmente complicato da problematiche legate al:

1. Dominio. Un sistema può risultare pericoloso a causa di errati presupposti sul dominio nel quale il sistema stesso opera; ciò può accadere per esempio nello sviluppo di software per mezzi spaziali in cui è facile effettuare valutazioni errate sull’ambiente. Le incertezze riguardanti il dominio di applicazione complicano l’individuazione del punto esatto in cui il sistema muta; esso può, infatti, mutare in uno stato non sicuro, complicando le eventuali correzioni in grado di riportarlo in uno stato sicuro. Una giusta modellazione del dominio di tali sistemi risulta quindi essenziale per una corretta determinazione dei casi di test.
2. Utente. Allo stesso modo assunzioni errate sull’utente o sull’operatore contribuiscono a rendere un sistema non sicuro; un utente può, ad esempio, utilizzare il sistema in modo non corretto, compromettendone quindi la sicurezza. Pertanto i fattori umani sono da non sottovalutare, ed è solo nel corso del testing che tali discordanze vengono alla luce.