Testing software

INGEGNERIA DEL SOFTWARE FranK 1

IL TESTING O IL COLLAUDO

Il software deve essere collaudato per individuare gli errori che sono stati commessi inavvertitamente durante la

progettazione e la realizzazione. Anche per il collaudo del software occorre stabilire una strategia sistematica. Il

collaudo procede dal “piccolo al grande”. Con questo si intende che le prime operazioni di collaudo si concentrano su

un unico componente o su piccoli gruppi di componenti correlati in modo da individuare gli errori nei dati e nella logica

elaborativi che sono collocati all’interno dei componenti. Dopo che i singoli componenti saranno stati collaudati,

occorre integrarli in modo da realizzare un sistema completo. A questo punto occorre eseguire una serie di collaudi di

alto livello per verificare che il programma risponda alle richieste del cliente. Dopo aver individuato gli errori occorre

stabilirne una diagnosi e correggerli utilizzando un processo chiamato debugging.

Per documentare l’appoggio al collaudo da parte del team software vengono sviluppati dei documenti di specifica del

collaudo che definiscono un piano che descrive la strategia globale e una procedura che definisce i passi di collaudo e i

collaudi specifici che verranno condotti.

Definizione. Errore (umano) = incomprensione umana nel tentativo di comprendere o risolvere un problema, o nell’uso

di strumenti;

difetto (fault o bug) = manifestazione nel software di un errore umano, e causa del fallimento del sistema nell’eseguire

la funzione richiesta;

malfunzionamento (failure) = incapacità del software di comportarsi secondo le aspettative o le specifiche; un

malfunzionamento ha una natura dinamica: accade in un certo istante di tempo e può essere osservato solo mediante

esecuzione.

Il testing (collaudo) è un processo di esecuzione del software allo scopo di scoprirne i malfunzionamenti:

- osservando i malfunzionamenti possiamo dedurre la presenza di difetti.

Tesi di Dijkstra: il testing non può dimostrare l’assenza di difetti, ma può solo dimostrare la presenza di difetti.

Il debugging è il processo di analisi del software per scoprirne i difetti.

L’ispezione è un processo di analisi del software per scoprirne i difetti.

il collaudo del software fa parte di un tema più vasto, spesso chiamato verifica e convalida (o validazione). Per verifica

si intende un insieme di attività che assicurano che il software realizzi correttamente una determinata funzione. Per

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 2

convalida si intende un diverso insieme di attività che assicurano che il software costruito sia riconducibile ai requisiti

del cliente.

Verifica: Stiamo costruendo il prodotto nel modo giusto?

Convalida: Stiamo costruendo il prodotto giusto?

Il collaudo stabilisce la seconda chance per stabilire la qualità e per scoprire gli errori. Ma non si deve assolutamente

considerare il collaudo come una rete di salvataggio. Si suole dire che la qualità non può essere “iniettata” mediante il

collaudo: se mancava prima dei collaudi, mancherà dopo. La qualità deve essere incorporata nel software lungo tutto il

processo di ingegneria del software. Solo l’applicazione di metodi e tecniche valide, le revisioni tecniche formali,

adeguate misurazioni e una gestione attenta conducono alla qualità, che il collaudo può solo confermare.

Ecco alcune considerazioni da osservare:

1) lo sviluppatore del software non deve eseguire alcun collaudo;

2) il software deve essere consegnato a estranei che lo mettano alla prova in modo spietato;

3) le persone preposte al collaudo devono entrare nel progetto solo quando inizia tale attività.

Il precedente approccio è sbagliato! Lo sviluppatore di software è sempre responsabile del collaudo delle singole unità

(i moduli) del programma e deve assicurarne il funzionamento secondo la funzione per la quale sono state progettate.

Problemi del testing

• Criterio di selezione

• Valutazione dei risultati del test

• Criterio di terminazione del testing

Valutazione dei risultati del test. Condizione necessaria per effettuare un test: conoscere il comportamento atteso per

poterlo confrontare con quello osservato.

L’oracolo conosce il comportamento atteso per ogni caso di prova (può essere un oracolo umano, che si basa sulle

specifiche o sul giudizio) o un oracolo automatico.

Terminazione del testing

Quando il programma si può ritenere analizzato a sufficienza, in base a:

- un criterio temporale: periodo di tempo predefinito

- un criterio di costo: sforzo allocato predefinito

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 3

- un criterio di copertura: percentuale predefinita degli elementi di un modello di programma, legato ad un

criterio di selezione dei casi di test;

- un criterio statistico: MTBF (mean time between failures) predefinito e confronto con un modello di

affidabilità esistente.

Quindi volendo rispondere alla domanda, quando termina un collaudo? Si può dire, il collaudo non finisce mai,

semplicemente la sua responsabilità passa dallo sviluppatore al cliente. “I collaudi terminano quando non c’è più

tempo o sono finiti i soldi”.

Problema della selezione dei casi di test

Un programma è corretto se è corretto per ogni dato di ingresso.

Un programma è esercitato da un caso di test (sottoinsieme dei dati di input).

Un test è formato da un insieme di casi di test.

L’esecuzione del test consiste nell’esecuzione del programma per tutti i casi di test.

Un test ha successo se rileva uno o più malfunzionamenti del programma.

Un test è ideale se l’insuccesso del test implica la correttezza del programma.

Un test esaustivo è un test che contiene tutti i dati di ingresso al programma (un test esaustivo è un test ideale; un

test esaustivo non è pratico e quasi sempre non è fattibile).

Obiettivo realistico: selezionare casi di test che approssimano un test ideale.

Criterio di selezione di test

Specifica le condizioni che devono essere soddisfatte da un test.

Consente di selezionare più test per uno stesso programma.

Un criterio di selezione di test è affidabile per un programma se per ogni coppia di test selezionati, T1 e T2, essi si

comportano allo stesso modo (ossia ogni insieme di casi di test che soddisfano il criterio rilevano gli stessi errori).

Un criterio di selezione di test è valido per un programma se, qualora il programma non è corretto, esiste almeno

un test selezionato che ha successo.

Teorema di Goodenough e Gerhart. Il fallimento di un test per un programma P, selezionato da un criterio C

affidabile e valido, permette di dedurre la correttezza del programma P.

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

INGEGNERIA DEL SOFTWARE FranK 4

Selezione dei casi di test. Teorema di Howden – non esiste un algoritmo che, dato un programma arbitrario P,

generi un test ideale finito, e cioè un test definito da un criterio affidabile e valido.

Aldilà di casi banali, non è possibile costruire un criterio di selezione generale di test valido e affidabile che non sia

valido e affidabile che non sia il test esaustivo.

Obiettivi pratici:

- massimizzare il numero di malfunzionamenti scoperti (richiede molti casi di test);

- minimizzare il numero di casi di test (e quindi il costo del testing);

E’ preferibile usare più di un criterio di selezione dei test.

Osservazione. Ogni prodotto (ma anche molti altri oggetti) si può collaudare in due modi: 1) se si conoscono le

funzioni specifiche che il prodotto deve svolgere, si possono effettuare pr