Porfirio Tramontana » 19.Testing: definizioni

Verifica e Validazione

Verifica
Consiste nello stabilire/controllare se un software esegue le funzioni per le quali è stato realizzato in maniera corretta, senza malfunzionamenti.

Validazione
Consiste nel valutare se il software soddisfa i requisiti e le specifiche per esso stabilite;
Rientra nella validazione anche la valutazione del soddisfacimento dei requisiti di qualità.

Definizioni

• Errore (Error)
  • incomprensione umana nel tentativo di comprendere o risolvere un problema, o nell’uso di strumenti.
• Difetto o anomalia (fault o bug)
  • Manifestazione nel software di un errore umano, e causa del fallimento del sistema nell’eseguire la funzione richiesta.
• Malfunzionamento o fallimento (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.

Relazione fra Errore, Difetto e Malfunzionamento

Testing, Debugging, Ispezione

Il Testing (collaudo) è un processo di esecuzione del software allo scopo di scoprirne i malfunzionamenti;
Osservando i malfunzionamenti possiamo dedurre la presenza di difetti.

Il Debugging è il processo di scoperta dei difetti a partire dai malfunzionamenti rilevati.

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

Adeguatezza dei test

Un test t rileva un malfunzionamento se il programma P non è corretto per t, ovvero se produce risultati diversi da quelli attesi.

• t ha successo per un programma P se rileva uno o più malfunzionamenti presenti in P

Un insieme di test T è inadeguato se esistono dei malfunzionamenti in P che il test T non è in grado di rilevare.

Tesi di Dijkstra

Il testing non può dimostrare l’assenza di difetti (e dunque la correttezza del programma), ma può solo dimostrare la presenza di difetti.
La correttezza di un programma è un problema indecidibile!
Un processo di testing deve consentire di acquistare fiducia nel software, mostrando che esso è pronto per l’uso operativo!

Test Ideale ed Esaustivo

Un test è ideale se l’insuccesso del test implica la correttezza del programma.
Un test esaustivo è un test che contiene tutti le combinazioni dei 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.

Obiettivi del testing

• Deve aiutare a localizzare i difetti
  Per facilitare il debugging.

• Dovrebbe essere ripetibile
  Potrebbe non essere possibile se l’esecuzione del caso di test influenza l’ambiente di esecuzione senza la possibilità di ripristinarlo;
  Potrebbe non essere possibile se nel software ci sono degli elementi indeterministici;
  Ovvero dipendenti da input non controllabili.

• Dovrebbe essere preciso.

Terminazione del testing

Dal momento che il testing esaustivo è, in generale, irraggiungibile, altri criteri sono proposti per valutare quando il testing possa essere terminato.

• Criterio temporale: periodo di tempo predefinito;
• Criterio di costo: sforzo allocato predefinito;
• Criterio di copertura
  • Ad esempio provare almeno una volta tutte le righe del programma oppure tutti gli scenari descritti nei casi d’uso.
• Criterio statistico
  • Ad esempio terminare quando gli ultimi k test non hanno rilevato malfunzionamenti.

Selezione dei casi di test

Posto che non esiste (e non sapremmo riconoscere) l’insieme ideale di casi di test, la loro bontà si può misurare in termini di:

Efficacia
Numero di malfunzionamenti trovati / numero di malfunzionamenti da trovare.

Efficienza
Numero di test in grado di scoprire malfunzionamenti / numero di test totali.

Efficacia ed Efficienza

Per massimizzare entrambe, contemporaneamente, bisognerebbe trovare il massimo numero possibile di malfunzionamenti con il minimo numero possibile di casi di test.
In realtà l’efficacia in generale non è calcolabile perchè non conosciamo il numero totale di malfunzionamenti.
Molte strategie di testing riescono ad aumentare una delle due diminuendo l’altra.

L’efficacia va privilegiata quando si vuole un software affidabile.
L’efficienza va privilegiata se si vuole un testing meno costoso (in particolare se non può essere eseguito automaticamente).

Caratteristiche di un test case

Un test case dovrebbe sempre essere:

• Descritto in maniera univoca
• Ripetibile
• Dall’esito oggettivamente valutabile

Nella descrizione di un test case devono quindi esserci tutte le informazioni necessarie ad un tester (umano o automatico) per rieseguire identicamente il caso di test potendone valutare l’esito in maniera non ambigua.

Il processo di testing

• Test dei Componenti (o di Unità)
  • Testing di singole unità di codice (funzioni, oggetti, componenti riusabili);
  • É responsabilità di chi sviluppa il componente;
  • I test sono derivati in base all’esperienza dello sviluppatore.
• Test di Sistema
  • Testing di gruppi di componenti integrati per formare il sistema o un sotto-sistema;
  • É responsabilità di un team indipendente per il testing;
  • I test sono definiti in base alla specifica del sistema.

Testing di Unità

Il testing dei componenti (o test di unità) consiste nel testare i singoli componenti del sistema in isolamento.
É un processo di testing dei difetti.
Le unità da testare possono essere:

• Funzioni o metodi di un oggetto;
• Classi di oggetti con i loro attributi e metodi;
• Componenti composti che offrono una specifica interfaccia per accedere alle loro funzionalità.

Selezione dei casi di test

I casi di test (test suite) devono essere selezionati in modo da ottimizzare il più possibile efficacia ed efficienza.
Le due tipologie fondamentali di criteri di selezione sono:

• Testing Black Box;
• Testing strutturale (o White Box).