Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

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.

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.

  • Oracolo umano
    • si basa sulle specifiche o sul giudizio.
  • Oracolo automatico
    • generato dalle specifiche (formali);
    • stesso software ma sviluppato da altri;
    • versione precedente (test di regressione).

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).

Specifica dei casi di test

Ogni caso di test, indipendentemente dalla sua tipologia, dovrebbe essere descritto quanto meno dai seguenti campi:

  • Numero Identificativo
  • Descrizione
    • Può indicare anche la funzionalità che si va testando
  • Precondizioni
    • Asserzioni che devono essere verificate affinchè il test possa essere eseguito
  • Valori di Input
  • Valori di Output Attesi
    • Rappresentano l’oracolo
    • In alcune tipologie di test si fornisce una classe di equivalenza attesa per gli output anziché un singolo valore
  • Postcondizioni Attese
    • Asserzioni assimiliabili agli output ma non verificabili direttamente dall’interfaccia utente.

Specifica dei casi di test (segue)

All’atto dell’esecuzione del test, verranno aggiunti i seguenti campi:

  • Output riscontrati
  • Postcondizioni riscontrate
  • Esito
    • Positivo (cioè malfunzionamento rilevato) se almeno un valore di output o una postcondizione riscontrati sono diversi da quelli attesi;
    • Negativo altrimenti.

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).

I materiali di supporto della lezione

Sommerville, Ingegneria del Software, 8° edizione, Capitoli 22-23-24.

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion