IL LIBRO

UDA 19 - Ciclo di vita e modelli di sviluppo del software - 19.4 Metodologie di test

19.4 Metodologie di test

Il collaudo del software (o testing) è il procedimento utilizzato per individuare le carenze di correttezza, completezza e affidabilità del software. L'importanza del collaudo è progressivamente cresciuta insieme allo sviluppo del software e già a partire dai primi anni '90, in contrapposizione al tradizionale modello di sviluppo a cascata, si è andata affermando una tendenza di sviluppo test driven (o guidata dal collaudo). Il concetto alla base è che le attività di collaudo devono procedere parallelamente allo sviluppo del software in modo che:

• quando si analizzano i requisiti del software da produrre si analizzano anche i requisiti del collaudo;
• quando si progetta l'architettura software si progetta anche l'architettura del collaudo;
• quando si scrive il codice si scrive anche il codice delle routine del collaudo automatizzato oppure si prepara la check list per il collaudatore manuale e si preparano i dati per il collaudo automatizzato o manuale;
• al termine della compilazione vengono automaticamente eseguite le routine di collaudo automatizzato oppure i test manuali.

Parlando di test del software occorre far distinzione tra malfunzionamenti e difetti. Un malfunzionamento indica un comportamento del software difforme dai requisiti e si verifica quando il sistema, in determinate condizioni, non si comporta come atteso. Il difetto, viceversa, è individuabile in una porzione di codice che, quando eseguita con particolari input, genera malfunzionamento. In altri termini, si ha malfunzionamento quando viene eseguito il codice che contiene il difetto con dei dati di input tali da evidenziare l'errore. Lo scopo principale del collaudo è di rilevare, partendo dall'osservazione dei malfunzionamenti, il maggior numero di difetti in modo da poterli poi correggere. Per rilevare il maggior numero possibile di difetti durante il collaudo occorre sollecitare il software in modo tale da eseguire la maggior quantità possibile di codice con differenti combinazioni di input. Può verificarsi che un errore nel codice sorgente si manifesti solo se si utilizza un particolare compilatore o interprete, oppure solo se il codice è eseguito su una particolare piattaforma. Per avere maggiori garanzie sulla bontà del collaudo pertanto può essere necessario collaudare il software in vari ambienti di sviluppo e con varie piattaforme di utilizzo. Nei progetti di sviluppo industriale nessun collaudo può garantire l'individuazione di tutti i possibili difetti, le combinazioni di input validi possono essere moltissime è non possibile o ragionevole pensare di riprodurle tutte, un buon collaudo però può rendere la probabilità di malfunzionamenti sufficientemente bassa e tale da essere accettabile in termini di qualità. La soglia di errore tollerabile dipende dal tipo di applicazione, per esempio, in software di tipo life-critical, cioè nei casi in cui un malfunzionamento può mettere a rischio la vita umana, come per esempio il software per apparecchiature biomedicali o aeronautiche, è accettabile solo con una probabilità di malfunzionamento molto bassa; in questi casi il collaudo deve essere particolarmente approfondito e rigoroso. Invece, per il software per cui non è necessariamente richiesta un'altissima qualità, come videogiochi o programmi di produttività personale, può essere sufficiente superare un collaudo meno approfondito. Nel processo industriale di realizzazione di software si assiste normalmente a due successive fasi di collaudo:

• Alpha test: il software prodotto viene di norma sottoposto a test in ambienti dedicati all'interno dell'azienda e sotto la supervisione del programmatore.
• Beta test: i test vengono eseguiti da un ristretto numero di utenti in condizioni reali; man mano che vengono corretti gli errori possono essere prodotte più versioni beta, poi quando la frequenza delle segnalazioni d'errore diventa sufficientemente bassa viene rilasciata la versione ufficiale.

Escludendo il caso delle piccole realtà, dove il collaudo è affidato in modo informale ad altre funzioni aziendali, normalmente il collaudo formale costituisce una fase importante dello sviluppo software e richiede un'adeguata pianificazione attraverso un apposito piano di collaudo. Il piano di collaudo prevede tipicamente due elementi fondamentali:

• Una check list, ovvero un elenco di prove (o test-case) opportunamente descritte e documentate, da eseguire manualmente o automaticamente.
• Degli scenari di collaudo, ovvero delle situazioni realistiche e non banali di utilizzo del software da collaudare in cui verificare tutti i passi che l'utente realisticamente percorrerebbe in tale situazione. Uno scenario può prendere in considerazione, a esempio, la tipologia di utente, la situazione verosimile e complessa in cui tale utente può venirsi a trovare etc..

Normalmente i test si distinguono fra due tipologie principali: test funzionali e test prestazionali.

Test funzionali

Come suggerisce il titolo, queste tipologie di test, che sono quelli più diffusi, tendono a indagare su eventuali difetti o regressioni funzionali dell'applicativo in reali condizioni di utilizzo.

In quest'ambito si distingue spesso fra due tipologie di test:

• black-box test effettuati accedendo al software solamente tramite l'interfaccia utente, oppure tramite interfacce di comunicazione tra processi. Spesso il collaudo “a scatola nera” è effettuato da persone esterne al gruppo di sviluppo o, con indubbi benefici sui costi e sulla qualità, può essere condotto in modo automatico.
• white-box test effettuati direttamente sul codice. Per poter eseguire il collaudo “a scatola bianca”, il collaudatore deve disporre della documentazione delle routine esportate dai moduli, se non addirittura del codice sorgente.

In ogni caso il test funzionale, indipendentemente dal fatto di essere automatico o manuale, dovrà essere di crescente granularità. Il test dovrà prendere in esame prima i singoli moduli software, singole routine o limitati insiemi di routine, in questo caso si parla di test di modulo e vengono preferibilmente utilizzati i test di tipo white-box.Poi si passa alla progressiva aggregazione dei moduli fino a costituire l'intero sistema, in questo caso si parla di test di sistema e vengono preferibilmente usati i test di tipo black-box.

Test prestazionali

I test prestazionali hanno lo scopo di verificare che l'applicazione soddisfi certi requisiti in termini di prestazioni. Vi sono varie tipologie di test di questo tipo tra cui i più frequenti sono i seguenti:

• test di performance: verifica i tempi di esecuzione in differenti condizioni;
• test di carico: misura le reazioni del sistema al crescere del carico al fine di evidenziare regressioni che potrebbero manifestarsi solo in regimi particolari;
• test di durata: verifica la robustezza del sistema nel tempo;
• test di stress: verifica il comportamento del sistema in fase di rottura.

• < Prec
• Succ >