Test strutturali: Differenza tra test di ripristino, sicurezza, performance e carico

Test strutturali: Differenza tra test di ripristino, sicurezza, performance e carico

Test strutturali

Nell’ambito del testing software, il test strutturale (o structural testing) verifica la correttezza tecnica dell’architettura applicativa, la completezza e la correttezza tecnica dei singoli componenti. Verifica cioè che la progettazione sia corretta dal punto di vista tecnico e della sua gestione operativa.

Lo scopo principale dei test strutturali è di verificare che:

  • la progettazione sia corretta dal punto di vista tecnico;
  • le tecnologie utilizzate siano state implementate in modo corretto e coerente;
  • i componenti siano stati progettati in modo da risultare coesi e disaccoppiati;
  • le singole parti del sistema siano in grado di funzionare come un insieme unico una volta

Non è quindi obiettivo di questo test verificare la correttezza funzionale dell’applicativo.

I test strutturali indirizzano solitamente le seguenti caratteristiche dell’applicativo:

  • Test di ripristino (Backup and Recovery);
  • Test di sicurezza;
  • Test di prestazione (Performance);
  • Test di carico (Stress e Volumi).

Test strutturali: Differenza tra test di ripristino, sicurezza, performance e carico

Test di ripristino (Backup and Recovery)

Descrizione

La funzione di ripristino (“recovery”) è la capacità del sistema di ripristinare le condizioni iniziali, dopo una sua caduta procurata dal verificarsi di una condizione di errore o a seguito della chiusura forzata da parte del gestore dell’applicazione. Il processo di ripristino richiede una funzione di “memorizzazione” (“backup”) dello stato del sistema transazioni, dati, altre informazioni vitali in diversi momenti del ciclo operativo. Lo stato del sistema memorizzato deve essere in grado di salvaguardare l’integrità del sistema in oggetto. Ogni stato memorizzato deve permettere di ripristinare le condizioni iniziali (prima della caduta) rieseguendo le transazioni interrotte senza perdita di dati.

Gli elementi critici da tenere presente in fase di progettazione delle funzioni di ripartenza sono molteplici, tra cui: la natura e la complessità dell’applicazione, il volume delle transazioni, la progettazione interna dell’applicativo per gestire il processo di ripartenza, la competenza e l’esperienza del personale preposto a gestire le procedure di ripartenza, la documentazione e le procedure messe a disposizione per la funzione di ripartenza.

Le singole funzioni di ripristino è bene eseguirle nell’ambito del test di sistema. La verifica completa e finale è invece eseguita durante il test di operabilità, quando i requisiti di continuità operativa sono cruciali per il sistema.

A determinare il livello di profondità ed estensione di questo tipo di test è sempre il livello di rischio associato alla caduta del sistema e relativa perdita di dati.

Obiettivi

Gli obiettivi principali del test di “backup and recovery” sono quelli di verificare e assicurare che:

  • il sistema sia in grado di continuare ad operare dopo una caduta;
  • i dati necessari a ripristinare il sistema siano memorizzati;
  • i dati di backup siano accessibili e ripristinabili;
  • le procedure di backup e di recovery siano ben documentate e disponibili;
  • le persone responsabili di gestire le procedure di backup and recovery ricevano un’adeguata formazione.

Esempi

Alcune modalità di esecuzione del test di backup and recovery possono essere:

  • Simulare un ambiente di test simile a quello di produzione in termini di dati e volumi;
  • Provocare la caduta del sistema e verificare che le procedure di recovery siano adeguate a gestire la condizione verificatasi.

Test di sicurezza

Descrizione

La sicurezza di un’applicazione deve garantire la protezione delle informazioni del sistema in oggetto e di tutti gli altri sistemi ad esso connessi. La protezione delle informazioni riguarda la loro “perdita” e “utilizzo non consentito”, sia intenzionale che accidentale.

Il livello di profondità ed estensione dei test di sicurezza dipendono dal livello di rischio associato alle informazioni gestite dal sistema. I test di sicurezza devono estendersi e limitarsi alle sole funzioni di sicurezza sviluppate, in accordo alle politiche di sicurezza ed in linea con le modalità operative previste. I test di sicurezza sono eseguiti durante la fase di test di sistema, continuano durante il collaudo di accettazione e si concludono con il test di operatività, se previsto.

I test di sicurezza richiedono competenze tecniche specifiche e quindi sono generalmente eseguiti da “esperti di sicurezza”.

Obiettivi

Obiettivo principale del test di sicurezza è di verificare e assicurare che:

  • i dispositivi di sicurezza sviluppati non siano elusi, alterati o distrutti;
  • i rischi di sicurezza siano stati identificati, valutati ed indirizzati appropriatamente;
  • la sicurezza sviluppata dal sistema funzioni correttamente.

Esempi

Alcuni test di sicurezza possono includere:

  • Tentativo di logon al sistema senza alcuna autorizzazione (quando questa sia richiesta);
  • Verifica che la password non sia visibile sui dispositivi di input/output (schermate, stampe);
  • Tentativo di fornire l’autorizzazione a funzioni riservate da parte di noi stessi;
  • Tentativo di accedere on-line a transazioni non autorizzate e verifica che il sistema sia in grado di proteggersi da tali intrusioni e di segnalare opportunamente i tentativi.

Test di performance

Descrizione

Il test di performance è progettato per verificare se il sistema sia in grado di mantenere le prestazioni richieste nell’ambiente di produzione. Le caratteristiche relative alle prestazioni riguardano i tempi di risposta, l’utilizzo delle risorse, i volumi elaborati o prodotti nell’unità di tempo ed altre considerazioni tecniche relative alla progettazione del sistema. I test di performance sono condotti nel sistema di produzione o simulandone uno simile.

L’attenzione alle prestazioni del sistema sono poste sin dalla fase di disegno. In questa fase sono stabiliti i criteri per l’implementazione e la verifica delle prestazioni. In questa fase possono essere costruiti modelli di prestazioni se richiesti dalle caratteristiche particolari del progetto.

Possono essere eseguite misure delle prestazioni del sistema non appena fossero disponibili parti rilevanti del prodotto, anche se non ancora prive di errore.

Obiettivi

Gli obiettivi principali del test di performance sono quelli di verificare e assicurare che:

  • il sistema “performa” come atteso (tempi di risposta, utilizzo delle risorse, quantità di lavoro eseguito nell’unità di tempo, ).

Esempi

Le prestazioni del sistema possono essere testate tramite:

  • l’utilizzo di strumenti di simulazione e monitoraggio delle prestazioni del sistema;
  • la memorizzazione dei tempi di risposta delle transazioni durante il test di sistema;
  • utilizzando prodotti per il monitoraggio delle prestazioni identificando “colli di bottiglia”, condizioni di stallo (deadlock) e transazioni particolarmente lente, sia in condizioni normali che durante picchi di lavoro.

Test di carico (Stress test)

Descrizione

Il test di carico è definito come l’esecuzione contemporanea di un numero rilevante di transazioni in un determinato periodo di tempo e con prestazioni definite. Esso tende a verificare che il sistema sia in grado di far fronte ad un picco di lavoro senza degradare le prestazioni (per esempio, elaborare un numero molto alto di transazioni contemporanee con tempi di risposta accettabili per ogni singola transazione).

I fattori di carico si riferiscono ai diversi aspetti del sistema: numero di transazioni eseguite, numero di output prodotti, numero di tabelle interne generate, numero di comunicazioni stabilite, capacità elaborativa del sistema, quantità di lavoro prodotto (throughput), spazio disco occupato, utilizzo dei sistemi di I/O, ecc.

Il test di carico non dovrebbe essere eseguito prima che tutte le funzioni siano state completamente testate e rese stabili. Le caratteristiche del test di carico sono definite nella fase di progettazione ed il test stesso può iniziare appena sono disponibili e stabili nell’ambiente operativo i componenti principali del sistema.

Non è quindi necessario che sia pronto l’intero sistema per poter iniziare il test di carico; è sufficiente che lo siano per parti principali cui è affidato lo smaltimento dei carichi di lavoro (gestione degli I/O, gestione delle code, gestione della memoria, gestione del mulltitasking, ecc.).

Obiettivi

Obiettivo principale del test di carico è di verificare ed assicurare che:

  • il sistema di produzione sia in grado di elaborare il numero di transazioni previste nell’intervallo di tempo stabilito;
  • l’architettura del sistema e la sua realizzazione siano in grado di elaborare il volume di dati previsto;
  • i componenti hardware e software siano adeguati per elaborare i volumi previsti;
  • il sistema abbia a disposizione le risorse adeguate a garantire i tempi di risposta previsti;
  • le funzioni a supporto dell’elaborazione degli output (per esempio, le stampanti) siano in grado di supportare i volumi previsti.

Esempi

Alcune modalità per l’esecuzione del test di carico sono:

  • Testare le condizioni di “overflow” del sistema caricandolo con volumi di lavoro superiori a quelli previsti dalle tabelle interne, dalle code delle transazioni, dalla memoria del sistema, ecc.
  • Testare le linee di trasmissione dei dati caricandole con picchi prodotti da simulatori;
  • Utilizzare generatori di dati e terminali multipli per stressare il sistema on-line per un periodo di tempo più lungo di quello previsto e per stressare il sistema batch sottomettendo più lavoro di quello previsto.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *