Verifica e Validazione del Software - unina.stidue.netunina.stidue.net/Ingegneria del Software...

1

Software TestingIngegneria del Software 2 1

Verifica e Validazione del Software

Tecniche avanzate di Software Testing


Argomenti trattati

• Le attività di Verifica e Validazione del Software– Le differenze fra l’approccio statico e dinamico– L’approccio del Testing Dinamico

• Richiami di concetti di base• Livelli di Testing• Tecniche di Testing Black-box e White-Box• Testing di Sistemi Object Oriented

2


Verifica e Validazione del Software

• La Verifica e Validazione (V & V) punta a mostrare che il software è conforme alle sue specifiche (Verifica) e soddisfa le aspettative del cliente (Validazione). – Verifica: Are we making the right product? – Validazione: Are we making the product right?

• Due approcci complementari alla verifica:– Approccio sperimentale (test, o analisi dinamica,

del prodotto)– Approccio analitico (analisi statica del prodotto e

della sua documentazione)


Gli approcci per le attività di Verifica e Validazione

• Analisi dinamica: processo di valutazione di un sistema software o di un suo componente basato sulla osservazione del suo comportamento in esecuzione. – Di solito solo queste tecniche si identificano come testing.

• Analisi statica: processo di valutazione di un sistema o di un suo componente basato sulla sua forma, struttura, contenuto, documentazione senza che esso sia eseguito. Esempi sono: revisioni, ispezioni, recensioni, analisi data flow

• Analisi formale: uso di rigorose tecniche matematiche per l’analisi di algoritmi.– E’ usata soprattutto per la verifica del codice e dei

requisiti, specie quando questi sono specificati con linguaggi formali (es. Z, VDM).

3


• Richiami sul Software Testing


Definizioni IEEE per il Testing

Standard IEEE 610.12-1990 :• (1) The process of operating a system or component under

specified conditions, observing or recording the results, and making an evaluation of some aspect of the system or component.

IEEE Std.729-1983• (2) The process of analyzing a software item to detect the

differences between existing and required conditions (that is, bugs) and to evaluate the features of the software item.

• See also: acceptance testing; benchmark; checkout; component testing; development testing; dynamic analysis; formal testing; functional testing; informal testing; integration testing; interface testing; loopback testing; mutation testing; operational testing; performance testing; qualification testing; regression testing; stress testing; structural testing; system testing; unit testing.

4


Alcune definizioni

• 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


Scopi del Testing

• Il testing può avere diversi obiettivi:• Dimostrare al cliente e allo sviluppatore che il software

soddisfa i suoi requisiti– Si parla di Test di Convalida– Verifica che il software si comporti adeguatamente

usando un insieme di casi di test che riflette l’uso previsto

– Tale test ha successo se tutto funziona come ci si aspetta

• Scoprire gli errori o difetti del software– Si parla di Test dei Difetti

5


Definizioni

• 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


Un esempio

ERRORE di editing/digitazione

DIFETTO=> “*” invece di “+”

DIFETTO causato da un errore

MALFUNZIONAMENTO=> il valore visualizzato è errato

Possibile MALFUNZIONAMENTO in esecuzione…(può verificarsi o meno: dipende dall’input)

Function RADDOPPIA ( )....read (x);y := x*x;write (y)...

6


Relazione fra Errore, Difetto e Malfunzionamento

errore Difetto

1..*1..*

Malfunzionamento

1..*1..* 1..* 1..*

causa causa

*


Test dei Difetti

• Ha lo scopo di scoprire I difetti di un programma.• Approccio usato: scoprire la presenza di difetti

osservando I malfunzionamenti!• Un test dei difetti ha successo se porta il programma a

comportarsi in maniera scorretta (cioè esibiscemalfunzionamenti)

• Il testing può sono dimostrare la presenza dei difetti, ma non la loro assenza!! (Tesi di Dijkstra)

7


Problemi e Limitazioni

• La correttezza di un programma è un problema indecidibile!

• Problemi:– non vi è garanzia che se alla n-esima prova un modulo od

un sistema abbia risposto correttamente (ovvero non sonostati più riscontrati difetti), altrettanto possa fare alla (n+1)-esima

– Impossibilità di produrre tutte le possibili configurazioni divalori di input (test case) in corrispondenza di tutti i possibilistati interni di un sistema software


Ulteriori Problemi

• In molti campi dell’ingegneria, il testing è semplificato dall’esistenza di proprietà di continuità– Se un ponte resiste ad un carico di 1000 tonnellate, allora

resisterà anche a carichi più leggeri

• Nel campo del software si ha a che fare con sistemi discreti, per i quali piccole variazioni nei valori d’ingresso possono portare a risultati scorretti– Il testing esaustivo (ideale) è condizione necessaria per

poter valutare la correttezza di un programma a partire dal testing

8


Software Testing


L’impossibilità del Testing Esaustivo!

Se il ciclo fosse eseguito al più 20 volte, ci possono essere oltre 100.000 miliardi di possibili

esecuzioni diverse!!!

Se ogni test fosse elaborato in 1 ms, sarebbero necessari 3170 anni!!!

9


Il processo di Software Testing

• Un processo di testing non può dimostrare la correttezza, ma …

• può consentire di acquistare fiducia nel software, mostrando che esso è pronto per l’uso operativo!

• … Grande esigenza di approcci ingegneristici per ridurre lo sforzo (inteso come impiego di risorse umane, tecnologiche e di tempo) per poter individuare il massimo numero possibile di difetti (con il minimo numero di test case possibile) prima che il prodottto sia rilasciato!


Il Processo di Software Testing

Design testcases

Prepar e testdata

Run pr ogramwith test da ta

Compar e resultsto test cases

Testcases

Testdata

Testresults

Testrepor ts

10


La qualità di un Processo di Testing

• Il Testing deve essere:– Efficace

• Condotto attraverso strategie che consentano la scoperta di quanti piùdifetti possibili;

– Efficiente• In grado di trovare difetti provando il minor numero possibile di casi di

test• circa il 40% dei costi di produzione del software per il raggiungimento di

ragionevoli livelli di qualità sono richiesti dal testing– Ripetibile

• Potrebbe non essere possibile se l’esecuzione del caso di test influenza l’ambiente di esecuzione senza la possibilità diripristinarlo

• Potrebbe non essere possibile se nel software ci sono deglielementi indeterministici

– Ovvero dipendenti da input non controllabili


• Livelli di Testing

11


Diversi Livelli di Testing

• Livello Produttore:– Testing di Unità (o di Componente)– Testing di Integrazione– Testing di Sistema

• Livello Cooperativo Produttore-Utente Privilegiato:– Alpha testing– Beta testing

• Livello Utente:– Testing di Accettazione


Fasi del Testing (a livello Produttore)

Componenttesting

Systemtesting

Software developer Independent testing team

12


Livello Produttore

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


Livello Produttore

• Test di Integrazione– Richiede la costruzione del sistema a partire dai suoi

componenti ed il testing del sistema risultante per scoprireproblemi che nascono dall’interazione fra I vari componenti.

– Richiede l’identificazione di gruppi di componenti che realizzanole varie funzionalità del sistema e la loro integrazione mediantecomponenti che li fanno lavorare insieme.

– Partendo da una architettura organizzata gerarchicamente, le integrazioni possono essere realizzate con approccio top-down o bottom-up o misto.

13


Strategie per il Testing di Integrazione

stub stub stub

UI Layer

stub stub stub

UI Layer

Functional layer

UI Layer

Functional layer

Database layer

Network layer

Functional layer

Database layer

Network layer

driver driverdriver

Database layer

Network layer

driver driverdriver

stub stub stub

UI Layer

Top-down testing Bottom-up testing Sandwich testing

Database layer

Network layer

driver driverdriver

Fully integrated

system


Esecuzione del testing di integrazione

• Costruzione di Moduli guida (driver)– invocano l’unità sotto test, inviandole opportuni

valori, relativi al test case

• Moduli fittizi (stub)– sono invocati dall’unità sotto test;– emulano il funzionamento della funzione chiamata

rispetto al caso di test richiesto (tenendo conto delle specifiche della funzione chiamata)

• Quando la funzione chiamata viene realizzata e testata, si sostituisce lo stub con la funzione stessa

Modulo guida

Unitàsotto test

Modulo fittizio

14


Livello produttore-utente privilegiato

• Alpha testing:– uso del sistema da parte di utenti reali ma nell'ambiente di

produzione e prima della immissione sul mercato.

• Beta Testing:– installazione ed uso del sistema in ambiente reale prima

della immissione sul mercato.

• tipicamente adottati dai produttori di packagesper mercato di massa!


Testing di Accettazione

• Testing effettuato sull’intero sistema sulla base di un piano e di procedure approvate dal cliente (o utente);

• l’obiettivo é quello di mettere il cliente, l'utente o altri a ciò preposti (collaudatori o enti ad hoc) in condizione di decidere se accettare il prodotto;

• Occorre provare che il software fornisce tutte le funzionalità, le prestazioni, l’affidabilità, etc. richieste, e che non fallisca.

• É in genere un testing black-box (a scatola nera):– Basato solo sulle specifiche del software;

– I Tester non accedono al suo codice.

• è a carico del committente;• .. è più 'una dimostrazione che un test'

15


• Il Testing dei Requisiti Non Funzionali


Performance testing

• Dopo che il sistema è stato completamente integrato, è possibile testarne le proprietà emergenti, come le prestazioni ed affidabilità.

• I test di prestazione in genere riguardano il carico e sipianificano test in cui il carico viene incrementatoprogressivamente finché le prestazioni diventanoinaccettabili.

• Il carico deve essere progettato in modo darispecchiare le normali condizioni di utilizzo.

16


Stress testing

• Nello stress testing si sollecita il sistema con un caricosuperiore a quello massimo previsto: in questecondizioni in genere I difetti vengono alla luce.

• Stressando il sistema si può testare il comportamentoin caso di fallimento.

• L’eventuale fallimento dovrebbe essere ‘leggero’ e non produrre effetti catastrofici. Si deve controllare che non ci siano perdite inaccettabili di servizio e di dati.

• Lo Stress testing è particolarmente rilevante per sistemi distribuiti che possono mostrare severe degradazioni delle prestazioni quando la rete è sommersa di richieste.


Altri tipi di Testing (di requisiti Non-Funzionali)

• Testing di Compatibilità– will have to uncover failures due to the usage of different

platforms or different releases or configurations of them. The large variety of possible combinations of all the componentsinvolved in the execution of an application does not make itfeasible to test all of them, so that usually only most common combinations are considered. As a consequence, just a subset of possible compatibility failures might be uncovered.

• Testing di Accessibilità– Aims to verify that access to the content of the application is

allowed even in presence of reduced hardware/ software configurations on the client side of the application (such asbrowser configurations disabling graphical visualization, or scripting execution), or of users with physical disabilities (such asblind people).

17


Altri tipi di Testing

• Testing di Sicurezza– Aims to verify the effectiveness of the overall system

defenses against undesired access of unauthorizedusers, as well as their capability to preserve system resources from improper uses, and to grant the access to authorized users to authorized services and resources.

• Testing di Usabilità– aims to verify to what extent an application is easy

to use


• Problemi dei Processi di testing

18


Problemi chiave di un processo di testing

• Selezione dei Casi di Test • Valutazione dei risultati del Test• Terminazione del Testing

Design testcases

Prepar e testdata

Run pr ogramwith test da ta

Compar e resultsto test cases

Testcases

Testdata

Testresults

Testrepor ts


1. 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. Due tipi di Oracolo:

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

19


Il ruolo dell’Oracolo

Software da

testareOracolo

Compara-tore

Risultati del test

Casi di test


2. 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:

• percentuale predefinita degli elementi di un modello di programma• legato ad un criterio di selezione dei casi di test

– Criterio statistico• MTBF (mean time between failures) predefinito e confronto con un

modello di affidabilità esistente

20


3. Problema della selezione dei casi di test

• Premesso che:• 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


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

21


Criterio di Selezione dei Test

• Specifica le condizioni che devono essere soddisfatte da un teste consente di selezionare più test per uno stesso programma.

• Un criterio di selezione di test C è affidabile per un programma se per ogni coppia di test selezionati da C, T1 e T2, se il test T1 ha successo, allora anche T2 ha successo e viceversa.– Quindi tutti i possibili esemplari di test generati dal criterio C hanno la

stessa capacità di ricerca di un malfunzionamento

• Un criterio di selezione di test C è valido per un programma se, qualora il programma non è corretto, esiste almeno un test selezionato da C che ha successo.

• Se un criterio è affidabile e valido, allora qualsiasi test T generatoda C per un programma non corretto avrà successo.


Esempio

• Program raddoppia

• (input, output);• var x, y: integer;• begin• read(x);• y:= x*x;• write(y);• end

• Criterio affidabile ma non valido:• T deve contenere sottoinsiemi di

{0, 2}

• Criterio valido ma non affidabile:• T deve contenere sottoinsiemi di

{0,1, 2, 3, 4}

• Criterio valido e affidabile:• T deve contenere almeno un

valore maggiore di 3

22


Selezione dei casi di test

• Teorema di Goodenough e Gerhart• Il fallimento di un test T per un programma P, selezionato da

un criterio C affidabile e valido, permette di dedurre la correttezza del programma P

• 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

• Al di là di casi banali, non è possibile costruire un criterio di selezione generale di test 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 !


• Tecniche di Testing

23


Due principali Tecniche di Testing

• Testing funzionale (o Black Box):– Richiede l’analisi degli output generati dal sistema (o da suoi

componenti) in risposta ad input (test cases) definiti sullabase della sola conoscenza dei requisiti del sistema (o disuoi componenti).

– Testing basato sui requisiti;– Testing delle partizioni;– Test basato su Tabelle di Decisione;– Test basato su Grafi Causa-Effetto.

• Testing strutturale (o White Box).– fondato sulla conoscenza della struttura del software, ed in

particolare del codice, degli input associati e dell’oracolo, per la definizione dei casi di prova.


1- Testing basato sui requisiti

• Il principio della verificabilità dei requisiti affermache i requisiti dovrebbero essere testabili, cioèscritti in modo da poter progettare test chedimostrino che il requisito è stato soddisfatto.

• Il testing basato sui requisiti è una tecnica diconvalida dove vengono progettati vari test per ogni requisito.

24


Un esempio: I Requisiti di LIBSYS

L’utente deve poter eseguire ricerche o in tutti i database o in un sotto-insieme di essi.

Il sistema dovrebbe fornire appropriati visualizzatori per leggere i vari documenti offerti.

Ad ogni ordine dovrebbe essere associato un identificatore(ORDER_ID) che l’utente deve poter copiare nella sua area di memoria buffer.


Testing di LIBSYS

• Inizializzare le ricerche utente di elementi che sono sia presenti che non presenti, con l’insieme dei database fatto da un solo database.

•Inizializzare le ricerche utente di elementi che sono sia presenti che non presenti, con l’insieme di database fatto da 2 database.

•Inizializzare le ricerche utente di elementi che sono sia presenti che non presenti, con l’insieme di database fatto da più di 2 database.

•Selezionare un database e inizializzare ricerche di articoli presenti e non presenti.

•Selezionare più di un database e inizializzare ricerche di articoli presenti e non presenti

25


2- Testing delle Partizioni (o delle Classi diEquivalenza)

• I dati di input ed output possono essere in generesuddivisi in classi dove tutti I membri di una stessaclasse sono in qualche modo correlati.

• Ognuna delle classi costituisce una classe di equivalenza(una partizione) ed il programma si comporterà(verosimilmente) nello stesso modo per ciascun membrodella classe.

• I casi di Test dovrebbero essere scelti all’interno diciascuna partizione.


Equivalence partitioning

System

Outputs

Invalid inputs Valid inputs

26


Suddivisione in classi di equivalenza

• Le partizioni sono identificate usando le specifiche del programma o altra documentazione.

• Una possibile suddivisione è quella in cui la classe di equivalenza rappresenta un insieme di stati validi o non validi per una condizione sulle variabili d’ingresso.


Esempio

• Una condizione di validità per un input passwordè che la password sia una stringa alfanumerica di lunghezza compresa fra 6 e 10 caratteri.

• Una classe valida CV1 è quella composta dalle stringhe di lunghezza fra 6 e 10 caratteri.

• Due classi non valide sono:• CNV2 che include le stringhe di lunghezza <6• CNV3 che include le stringhe di lunghezza >10

27


Generalizzando…

• Se la condizione sulle variabili d’ingresso specifica:– intervallo di valori

• una classe valida per valori interni all’intervallo, una non valida per valori inferiori al minimo, e una non valida per valori superiori al massimo

– valore specifico• una classe valida per il valore specificato, una non valida per

valori inferiori, e una non valida per valori superiori

– elemento di un insieme discreto• una classe valida per ogni elemento dell’insieme, una non valida

per un elemento non appartenente

– valore booleano• una classe valida per il valore TRUE, una classe non valida per

il valore FALSE


Selezione dei casi di test dalle classi di equivalenza

• Ogni classe di equivalenza deve essere coperta da almeno un caso di test

– Un caso di test per ogni classe non valida– Ciascun caso di test per le classi valide deve comprendere il

maggior numero di classi valide ancora scoperte.

28


Esercizio

• In un modulo Web bisogna inserire la propria data di nascita, composta di giorno (numerico), mese (stringa che può valere gennaio … dicembre), anno (numerico, compreso tra 1900 e 2000)

• Selezionare i casi di test mediante partizionamento in classi di equivalenza


Le condizioni sull’input ‘giorno’

•Condizioni d’ingresso:• Il giorno può essere compreso tra 1 e 31

•Classi di equivalenza:• Valida

CE1 : 1 ? GIORNO ? 31

• Non valideCE2 : GIORNO < 1

CE3 : GIORNO > 31CE4 : GIORNO non è un numero intero

29


Le condizioni sull’input ‘mese’

•Condizioni di ingresso:– Il mese deve essere nell’insieme M=(gennaio, febbraio, marzo,

aprile, maggio, giugno, luglio, agosto, settembre, ottobre, novembre, dicembre)

•Classi di equivalenza– Valide

CE51: MESE = gennaio, CE52: MESE = febbraio, CE53: MESE = marzo, …. (Tot. 12 classi di equivalenza)

- Non validaCE6: MESE ? M


Le condizioni sull’input ‘anno’

•Condizioni di ingresso:– Deve essere compreso tra 1900 e 2000

•Classi di equivalenza• Valida

CE7: 1900<= ANNO<=2000

• Non valideCE8: ANNO< 1900

CE9: ANNO> 2000CE10: ANNO non è un numero intero

30


Scelta dei casi di test ...

Test case TC1 TC2 TC3 TC4

Giorno 1 1 1 1

Mese gennaio febbraio marzo aprile

Anno 1980 1492 2018 duemila

Classi coperte CE1, CE51, CE7 CE1, CE52, CE8 CE1, CE53, CE9 CE1, CE54, CE10

Test case TC5 TC6 TC7 TC8

Giorno 1 0 35 primo

Mese brumaio maggio giugno luglio

Anno 1980 1980 1980 1980


Ogni TC copre al più una CE non valida!


Scelta dei casi di test

Test case TC9 TC10 T11 TC12

Giorno 1 1 1 1

Mese agosto settembre ottobre novembre

Anno 1980 1980 1980 1980


Test case TC13

Giorno 1

Mese dicembre

Anno 1980

Classi coperte CE1, CE512, CE7

31


Problemi

• A volte é necessario tenere conto delle pre-condizioni e post-condizioni di una funzione nella scelta delle classi di equivalenza.

• Ad esempio la ricerca di un elemento in un vettore darà esitodiverso a seconda delle precondizioni:– Pre-condizione 1: elemento presente nel vettore– Pre-condizione 2: elemento non presente

• Potrò definire ulteriori classi di equivalenza :

– CE1: gli input validi che sono contenuti nel vettore– CE2: gli input validi che non appartengono al vettore.


Problemi

• L’appartenenza ad una classe di equivalenza puòdipendere dallo stato dell’applicazione (es. Lo stato del vettore dell’esempio precedente)

•– Non sempre è possibile determinare lo stato nè settare

precondizioni e postcondizioni.– Comunque, questo problema deve essere affrontato al

momento di eseguire il test, non quando si progettano I test!

32


3-Testing basato su Tabelle di Decisione

• Le tabelle di Decisione sono uno strumento per la specifica black-box di componenti in cui:– A diverse combinazioni degli ingressi corrispondono

uscite/azioni diverse;– Le varie combinazioni possono essere rappresentate come

espressioni booleane mutuamente esclusive;– Il risultato non deve dipendere da precedenti input o output,

né dall’ordine con cui vengono forniti gli input.


Costruzione della Tabella di Decisione

• Le colonne della Tabella rappresentano le combinazioni degli input a cui corrispondono le diverse azioni.

• Le righe della tabella riportano i valori delle variabili di input (nella Sezione Condizioni) e le azioni eseguibili (nella Sezione Azioni)

• Ogni distinta combinazione degli input viene chiamata una Variante.

• Un esempio: la tabella di decisione per la procedura di rinnovo annuale delle polizze automobilistiche di una compagnia di assicurazioni…

33


Un esempio di Tabella di decisione

SìNoNoNoNoNoNoPolizza Cancellata

NoSìSìnoSìNoNoLettera

0200400501002550AumentoPremio ($)

Azioni

Qualsiasi

>=26<=25>=26<=25>=26<=25Età assicurato

5 o piùTra 2 e 4

Tra 2 e 4

1100Numero incidenti

Con

dizioni

7654321

Varianti


Varianti Esplicite ed Implicite

• Nella tabella, l’operatore logico fra le condizioni è di And;

• Nell’esempio precedente abbiamo 6 condizioni sugli input e 7 varianti significative, ma in generale esistono più combinazioni possibili.

• Quante combinazioni di condizioni sono in generale possibili?– Per n condizioni, 2n varianti (ma non tutte sono plausibili)- sono

dette varianti implicite.– Il numero di varianti esplicite (significative) è in genere

minore!

34


Generazione dei Test

• Un possibile Criterio di Copertura della Tabella:– Copertura di tutte le varianti esplicite

– Un Test Case per ogni variante


4-Testing basato su Grafi Causa-Effetto

• I Grafi Causa-Effetto sono un modo alternativo per rappresentare le relazioni fra condizioni ed azioni di una Tabella di Decisione.

• Il grafo prevede un nodo per ogni causa (variabile di decisione) e uno per ogni effetto (azione di output). Cause ed Effetti si dispongono su linee verticali opposte.

• Alcuni effetti derivano da una singola causa (e sono direttamente collegati alla relativa causa).

• Altri effetti derivano da combinazioni fra cause esprimibili mediante espressioni booleane (con operatori AND, OR e NOT).

35


Il Grafo Causa-Effetto per l’esempio precedente

Età<=25

Età>=26

0 Incidenti

Tra 2 e 4 Inc.

>=5 Incidenti

1 Incidenti

$25

$50

$100

$200

$400

Lettera di avviso

Cancellazione polizza

??

??

?

?

?

?

? = AND, ? =OR, ~= NOT


SìNoNoNoNoNoNoPolizza Cancellata

NoSìSìnoSìNoNoLettera

0200400501002550AumentoPremio ($)

Azioni

Qualsiasi

>=26<=25>=26<=25>=26<=25Età

assicurato

5 o più

Tra 2 e 4Tra 2 e 41100Numero incidenti

Condizioni

7654321

Varianti

36


Grafi Causa- Effetto

• Vantaggi: – rappresentazione grafica ed intuitiva,– È conveniente sviluppare tale grafo se non si ha già a

disposizione una tabella di decisione– È possibile derivare una funzione booleana dal grafo causa-

effetto (che consente di esprimere in maniera compatta tutte le possibili combinazioni di cause)

– Può essere usata facilmente per la verifica del comportamento del software

• Svantaggi– al crescere della complessità della specifica, il grafo può

divenire ingestibile


Generazione dei Test

• Copertura di tutte le possibili combinazioni d’ingresso– Può diventare impraticabile, al crescere delle combinazioni– Una semplificazione: si può partire dagli effetti e percorrere il

grafo all’indietro cercando alcune combinazioni degli ingressi che rendono vero l’effetto considerato.

– Non tutte le combinazioni possibili saranno considerate, ma solo alcune che soddisfano alcune specifiche euristiche.

• Es. combinazione di OR di cause che deve essere vera -> si considera una sola causa vera per volta

• AND di cause che deve essere falsa-> si considerano combinazioni con una sola causa falsa

37


• Macchine a Stati e State-Base Testing

• Ref. R. Binder “Testing Object-Oriented Systems-Models, Patterns and Tools”, Addison Wesley


Macchina a Stati (State Machine)

• Macchina a Stati: è un modello (o specifica) del comportamento dinamico di un sistema, indipendente dalla sua implementazione.

• Si basa sui seguenti elementi fondamentali:

• stato: situazione astratta nel ciclo di vita di una entità (ad esempio,lo stato del contenuto di un oggetto)

• evento: un particolare input (es. un messaggio, o chiamata di un metodo)

• azione: il risultato, l’output o l’operazione che segue un evento• transizione: una sequenza ammessa fra due stati, ossia un

cambiamento di stato causato da un evento. • guardia: una espressione predicativa associata ad un evento, che

stabilisce una condizione Booleana che deve essere verificata affinchè la transizioni scatti

38


Le azioni possono essere associate sia agli stati chealle transizioni


Diversi Tipi di Macchine a Stati

• Automa a Stati Finiti (FSM) – senza guardie, né azioni associate a stati né a transizioni

• Macchina di Mealy– le azioni sono associate solo alle transizioni, e non agli stati, che sono

stati passivi• Macchina di Moore

– azioni associate solo agli stati, non alle transizioni• Statechart

– Sono possibili Stati gerarchici, o super-stati (ossia aggregati di altri stati)

• State transition diagram: è una rappresentazione in forma di grafo di una Macchina a Stati

• State transition table: rappresentazione tabellare della Macchina a Stati

39


Un esempio di Macchina di Mealy

• Per rappresentare la dinamica di un video-gioco (es. ping-pong, squash, etc.) fra due giocatori.

• Ciascun giocatore ha un bottone di start e uno di reset• Il giocatore che preme lo start per primo, comincia a servire• Il giocatore corrente serve e viene eseguito un lancio:

– Se chi ha servito sbaglia il colpo, l’avversario guadagna il servizio

– Se l’avversario di chi ha servito sbaglia il colpo, il punteggio di chi ha il servizio viene incrementato e questi continua a servire;

– Se l’avversario di chi ha servito perde la palla ed il punteggio di chi ha il servizio è a -1 punto dalla vittoria, questi diventa il vincitore (es. si vince a 21 punti)


La Macchina di Mealy corrispondente

40


Proprietà Generali delle Macchine a Stati

• Sono tipicamente modelli incompleti (per problemi di scalabilità):– Solo stati, eventi e transizioni più importanti vengono rappresentate– In genere solo gli eventi leciti sono associati a transizioni; eventi

illeciti (quali p1_Start dallo stato Player 1 served) non sono specificati• Può essere Deterministico o Non Deterministico

– Deterministico: ogni tripla stato/evento/guardia innesca una sola transizione

– Non Deterministico: la stessa tripla stato/evento/guardia può innescare varie transizioni, a seconda dei casi

• Può avere vari stati finali (o nessuno: computazione infinita)• Può avere eventi vuoti (transizioni di default )• Può essere concorrente: la macchina (statechart) può essere in vari

stati contemporaneamente


Il ruolo delle Macchine a Stati nel software testing

• Supportano l’esecuzione di attività di model testing, dove un modello eseguibile (la state machine) del sistema viene eseguito o simulato con sequenze di eventi che costituiscono i casi di test, ancor prima dell’implementazione.

• Consentono di eseguire il testing dell’implementazione del sistema rispetto ad una sua specifica (la state machine)

• Supportano la generazione automatica di test cases a livello delcodice:– È richiesto un mapping esplicito fra gli elementi della macchina

(states, events, actions, transitions, guards) ed i corrispondenti elementi dell’implementazione (e.g., classes, objects, attributes, messages, methods, expressions)

– Lo stato corrente della macchina deve essere verificabile o dall’ambiente di runtime o dall’implementazione stessa (built-in tests con asserzioni e invarianti di classe)

41


Il problema della Validazione delle Macchine a Stati

• Per eseguire sia il Model Testing o il Testing dell’implementazione occorre usare delle Checklist per verificare che la macchina a stati sia completa e consistente:– deve esserci uno stato iniziale con sole transizioni uscenti;– deve esserci almeno uno stato finale con sole transizioni entranti; – non deve presentare stati equivalenti(cioè stati per i quali

qualunque sequenza di eventi produce identiche sequenze di azioni risultanti)

– Ogni stato deve essere raggiungibile dallo stato iniziale– Deve esserci almeno uno stato finale raggiungibile da ogni stato– Ogni evento ed azione devono apparire in almeno una transizione (o

stato)– Tranne che per gli stati iniziale e finale, ogni stato ha almeno una

transizione entrante ed una uscente


… Checklist per la validazione

• for deterministic machines, the events accepted in a particular state are unique or differentiated by mutually exclusive guard expressions;

• the state machine is completely specified: every state/event pair has at least one transition, resulting in a defined state; or there is an explicit specification of an error-handling or exception-handling mechanism for events that are implicitly rejected (with no specified transition)

• the entire range of truth values (true, false) must be covered by the guard expressions associated with the same event accepted in a particular state

• the evaluation of a guard expression does not produce any side effects in the implementation under test

• no action produces side effects that would corrupt or change the resultant state associated with that action

• a timeout interval (with a recovery mechanism) is specified for each state• state, event and action names are unambiguous and meaningful in the

context of the application

42


Difetti sul Controllo rispetto alle State Machine

• Un difetto sul controllo consente a sequenze scorrette di eventi di essere accettate, o produce sequenze scorrette di azioni di output.

• Nell’eseguire il testing basato su macchine a stati, occorre cercare di verificare la presenza dei seguenti tipi di difetto sul controllo:– Transizioni mancanti (non accade nulla a seguito di un evento)– Transizioni scorrette (verso stati scorretti)– Eventi mancanti o scorretti– Azioni mancanti o scorrette (cose scorrette accadono a seguito di una

transizione)– Uno stato extra, mancante, o corrotto (comportamento impredicibile)– Uno sneak path (un evento è accettato quando non dovrebbe)– Una trap door (l’implementazione accetta eventi non previsti)


Esempio di Difetto: Transizione Mancante

43


Esempio di Difetto: Transizione Scorretta


Esempio di Difetto: Azioni Mancanti

44


Esempio di Difetto: Azione Scorretta


Esempio di Difetto: Sneak Path

45


Esempio di Difetto: Trap Door


Strategie per il Progetto dei Test nello State-based testing

• Si usano gli stessi concetti di Copertura visti nel testingwhite-box:

• Test Case = sequenza di eventi di input– all-events coverage: ogni evento della macchina a stati viene

incluso nella test suite (fa parte di almeno un test case)– all-states coverage: ogni stato della macchina è esercitato almeno

una volta da qualche test della test suite– all-actions coverage: ogni azione è eseguita almeno una volta

• Questi criteri non definiscono una adeguata copertura in quanto:– posso riuscire ad esercitare tutti gli eventi, ma non visitare tutti gli

stati o produrre tutte le azioni; posso visitare tutti gli stati, ma perdere eventi od azioni; posso mancare coppie evento/azione scorrette.

46


Altri Criteri di Copertura • all-transitions: ogni transizione è esercitata almeno una volta

– implica le coperture all-events, all-states, e all-actions– Posso rilevare transizioni mancanti, coppie evento/azione scorrette o mancanti (mi

accorgo che l’azione associata ad un evento è scorretta), che lo stato risultante raggiunto è scorretto (se lo stato è osservabile), o che viene raggiunto un extra stato

– Se lo stato non è osservabile, non si può provare che viene raggiunto uno stato scorretto; inoltre, non si rileva la presenza di extra-transizioni.

• all n-transition sequences: ogni sequenza di transizioni di n eventi deve essere esercitata almeno una volta– all transitions = all 1-transition sequences– all n-transition sequences implies (subsumes) all (n-1)-transition sequences– Si possono scoprire alcuni stati scorretti o corrotti

• all round-trip paths: ogni sequenza di transizioni che parte e termina nello stato stato viene esercitata almeno una volta– Può rilevare tutte le coppie evento/azione scorrette o mancanti

• exhaustive: ogni cammino sulla macchina a stati è esercitato almeno una volta– In genere impossibile e quasi sempre impraticabile


Esempio: All-states Coverage

47


All-transitions coverage


Applicazioni dello State Based Testing

• Nasce per il testing di Circuiti (Hardware)

• È stato adottato per il testing software fin dagli anni ’70

• Tipicamente usato per il testing di unità per software Object-Oriented

• Usato anche per il testing di GUI e di Sistema

48


• Testing Strutturale (o White Box)


Testing Strutturale (White Box)

• Il Testing White Box è un testing strutturale, poichèutilizza la struttura interna del programma per ricavare i dati di test.

• Tramite il testing White Box si possono formularecriteri di copertura più precisi di quelli formulabilicon testing Black Box

– Test White Box che hanno successo possono fornire maggioriindicazioni al debugger sulla posizione dell’errore

49


Criteri di Copertura

• Fondate sull’adozione di metodi di Copertura degli oggetti che compongono la struttura dei programmi:

• istruzioni – strutture controllo – flusso di controllo -…

• definizione di un insieme di casi di test (input data) in modo tale che gli oggetti di una definita classe (es. istruzioni, archi del GFC, predicati, strutture di controllo, etc.) siano attivati (coperti) almeno una volta nell'esecuzione dei casi di test


Criteri di Copertura e relative Misure di Test Effectiveness

• Criteri di selezione• Copertura dei comandi

(statement test)• Copertura delle decisioni

(branch test)• Copertura delle condizioni

(condition test)• Copertura delle decisioni e

delle condizioni• Copertura dei cammini

(path test)• Copertura dei cammini

indipendenti

• Criteri di adeguatezza• n.ro comandi eseguiti/ • n.ro comandi

eseguibili • n.ro archi percorsi/ • n.ro archi percorribili

• n.ro cammini percorsi/ • n.ro cammini

percorribili• n.ro cammini indip.

percorsi/n.ro ciclomatico

50


UN MODELLO DI RAPPRESENTAZIONE DEI PROGRAMMI: il Control-Flow Graph

• Il grafo del flusso di controllo (Control-Flow Graph) di un programma P:

• CFG (P) = <N, AC, nI, nF>

dove:

• <N, AC> è un grafo diretto con archi etichettati,

• {nI, nF} ? ?N, N- {nI, nF} = Ns? Np

• Ns e Np sono insiemi disgiunti di nodi istruzione e nodi predicato;

• AC ? ?N-{nF}? ?N-{nI } ? ?{vero, falso, incond} rappresenta la relazioneflusso di controllo;

• nI ed nF sono detti rispettivamente nodo iniziale e nodo finale.

•Un nodo n? ?Ns?? ?{nI} ha un solo successore immediato e il suo arco uscente è etichettato con incond.

•Un nodo n? Np ha due successori immediati e i suoi archi uscenti sono etichettati rispettivamente con vero e falso.


Strutture di controllo di base nel CFG

if

t f

If-then-elseRepeat … until C While C do

v

ff

v

51


Esercizio

• int tent=0,x=7,num=0;• while ((tent<4)&&(num!=x)) {• cout<<"Indovina il numero :";

cin>>num;• tent++;• if (num>x)• cout<<"Un po' di meno\n";• else• if (num<x)• cout<<"Un po' di piu'\n";• }• if (num==x)• cout<<"Bravo";• if (tent==4)• cout<<“Hai perso!";• return 0;

Disegnare ilControl Flow

Graph


procedure Quadrato;var x, y, n: integer;begin

1. read(x);2. if x > 0

then begin3. n := 1;4. y := 1;5. while x > 1 do

begin6. n := n + 2;7. y := y + n;8. x := x - 1;

end;9. write(y);

end;end;

I

1

2

3

4

5

6

7

8

9

F

true false

falsetrue

true false

true false

I

1,2

3,4,5

6,7,8

9

F

Un esempio

52


• Copertura dei comandi (statement test)

– Richiede che ogni nodo del CFG venga eseguito almeno una volta durante il testing;

– è un criterio di copertura debole, che non assicura la copertura sia del ramo true che false di una decisione.

– Es. nella Procedura quadrato, la test suite TS={x=2} garantisce la copertura di tutti i nodi, ma non dell’arco (1-2, Fine)

Criteri di copertura


Criteri di copertura

• Copertura delle decisioni (branch test)– Richiede che ciascun arco del CFG sia attraversato

almeno una volta; • In questo caso ogni decisione è stata sia vera che

falsa in almeno un test case

• Nella procedura Quadrato, la TS={x=2, x=-1} garantisce la copertura delle decisioni

– un limite è legato alle decisioni in cui più condizioni (legate da operatori logici AND ed OR) sono valutate

53


Copertura delle condizioni (condition test)

– Ciascuna condizione nei nodi decisione di un CFG deve essere valutata sia per valori true che false.

– Esempio:

int check (x);// controlla se un intero è fra 0 e 100int x;{ if ((x>=0) && (x<= 200))

check= true;else check = false;}

TS={x=5, x=-5 } valuta la decisione sia per valori True che False, ma non le condizioni

TS1={ x= 3, x=-1, x=199, x=210} è una Test suite che copre tutte le condizioni


Copertura delle condizioni e decisioni

• Occorre combinare la copertura delle condizioni in modo da coprire anche tutte le decisioni.

– Es. If (x>0 && y>0) …– TS1={(x=2, y=-1), (x=-1, y=5)} copre le condizioni ma non

le decisioni!– TS2={(x=2, y=1), (x=-1, y=-55)} copre sia le condizioni

che le decisioni!

54


Costi del test per i vari criteri di copertura

• Copertura degli statement :– Numero di casi di test richiesti =1

• Copertura delle decisioni– Numero di casi di test richiesti= 2

• Copertura delle condizioni– Numero di casi di test richiesti= 4

• Copertura delle condizioni e decisioni– Numero di casi di test richiesti= 4


Cammini linearmente indipendenti (McCabe)

• Un cammino è un’esecuzione del modulo dal nodo inizialedel Cfg al nodo finale

• Un cammino si dice indipendente (rispetto ad un insieme dicammini) se introduce almeno un nuovo insieme diistruzioni o una nuova condizione– in un CfG un cammino è indipendente se attraversa

almeno un arco non ancora percorso• L’insieme di tutti i cammini linearmente indipendenti di un

programma forma i cammini di base; tutti gli altri camminisono generati da una combinazione lineare di quelli di base.

• Dato un programma, l’insieme dei cammini di base non è unico.

55


Numero di cammini linearmente indipendenti

• Il numero dei cammini linearmente indipendenti di un programma è pari al numero ciclomatico di McCabe:– V(G) = E - N +2

• Dove E: n.ro di archi in G - N: n.ro di nodi in G

– V(G) = P + 1• Dove P: n.ro di predicati in G

– V(G) = n.ro di regioni chiuse in G + 1

• Test case esercitanti i cammini di base garantiscono l’esecuzione di ciascuna istruzione almeno una volta


Esempio

true false

true false

0

1

2

3

4

5

V(G)= 3 =>3 cammini indipendenti

c1= 0-1-2-4-5c2= 0-1-2-3-2-4-5c3= 0-1-5

Complessità ciclomaticadel programma è 3

56


Criteri di copertura dei cammini• Copertura dei cammini (path test)

– spesso gli errori si verificano eseguendo cammini che includono particolari sequenze di nodi decisione

– non tutti i cammini eseguibili in un CFG possono essere eseguitidurante il test (un CFG con loop può avere infiniti cammini eseguibili)

• Copertura dei cammini indipendenti– ci si limita ad eseguire un insieme di cammini indipendenti di un

CFG, ossia un insieme di cammini in cui nessun cammino è completamente contenuto in un altro dell’insieme, nè è la combinazione di altri cammini dell’insieme

– ciascun cammino dell’insieme presenterà almeno un arco non presente in qualche altro cammino

– il numero di cammini indipendenti coincide con la complessità ciclomatica del programma


Relazioni tra i criteri di copertura

• La copertura delle decisioni implica la copertura dei nodi

• La copertura delle condizioni non sempre implica la copertura delle decisioni

• La copertura dei cammini linearmente indipendentiimplica la copertura dei nodi e la copertura delledecisioni

• La copertura dei cammini è un test ideale ed implicatutti gli altri

57


Problemi

• E’ possibile riconoscere automaticamente quale camminolinearmente indipendente viene coperto dall’esecuzione diun dato test case

• E’ indecidibile il problema di trovare un test case che va a coprire un dato cammino– Alcuni cammini possono risultare non percorribili

(infeasible)

• La copertura dei cammini linearmente indipendenti non garantisce da errori dovuti, ad esempio, al numero di ciclieseguiti, per i quali sarebbe necessaria la copertura di tutti I cammini, che però rappresenta il testing esaustivo!


• Testing di Sistemi Object Oriented

58


Impatto delle caratteristiche OO sul Testing

• ... astrazione sui dati, ereditarietà, polimorfismo, binding dinamico, genericità, ... impattano concetti ed attività del testing

• Nuovi livelli di test– il concetto di classe, come stato + operazioni, cambia il concetto di

unità– le modalità di interazione ed integrazione degli oggetti impatta il test

di integrazione

• Nuova infrastruttura– driver e stub devono considerare lo stato (information hiding)– lo stato non può essere ispezionato con tecniche tradizionali


Impatto delle caratteristiche OO sul Testing

• Nuove tecniche di generazione di casi di test e criteri di terminazione che tengano conto di:– Stato– Polimorfismo e binding dinamico– Ereditarietà– Genericità– Eccezioni

–

59


1- Nuovi Livelli di Test

• I livelli di Test tradizionali mal si adattano al caso di linguaggi OO:

• Da cosa è rappresentata l'unità?– un oggetto ? una classe ? un’operazione di una classe?

• Cosa è un modulo in un sistema OO?– Esistono diverse scuole di pensiero

• Una possibile suddivisione:– Basic unit testing: test di una singola operazione di una classe– Unit testing: test di una classe nella sua globalità– Integration testing: test delle interazioni tra più classi


2- Stato ed Information Hiding

• Componente base: Classe = struttura dati + insieme di operazioni– oggetti sono istanze di classi– la verifica del risultato del test non è legata solo all’output, ma anche

allo stato,definito dalla struttura dati

• La ‘opacità’ dello stato (v. incapsulamento ed informationhiding) rende più difficile la costruzione di infrastruttura e oracoli– è sufficiente osservare le relazioni tra input e output?– lo stato di un oggetto può essere inaccessibile– lo stato “privato” può essere osservato solo utilizzando metodi

pubblici della classe (e quindi affidandosi a codice sotto test)

60


3- Nuove Tecniche di generazione dei Test

• Test ed Ereditarietà– l'ereditarietà è una relazione fondamentale tra classi– nelle relazioni di ereditarietà alcune operazioni restano invariate

nella sotto-classe, altre sono ridefinite, altre aggiunte (o eliminate)

• Ci si può “fidare” delle proprietà ereditate?– È necessario identificare le proprietà che devo ri-testare:

operazioni aggiunte, operazioni ridefinite, operazioni invariatema influenzate dal nuovo contesto

– Può essere necessario verificare la compatibilità di comportamento tra metodi omonimi in una relazione classe-sottoclasse

– Riuso test, e test specifici– Ereditarietà produce nuova forma di Integrazione/ Interazione


4- Test e Genericità

• I moduli generici sono presenti nella maggior parte dei linguaggi OO– la genericità è un concetto chiave per la costruzione di librerie

di componenti ri-usabili• Le classi parametriche devono essere instanziate per

poter essere testate– Bisognerebbe prevedere test per ogni possibile istanziazione

della classe parametrica (test esaustivo???)

• Quali ipotesi dover fare sui parametri?– Servono classi “fidate” da utilizzare come parametri

• Quale metodologia seguire quando si testa un componente generico che è ri-usato?– Non esistono tecniche o approcci maturi in letteratura

61


5- Polimorfismo e Binding Dinamico

• Un riferimento (variabile) può denotare oggetti appartenenti a diverse classi di una gerarchia di ereditarietà (polimorfismo), ovvero il tipo dinamico e il tipo statico dell’oggetto possono essere differenti

– più implementazioni di una stessa operazione– il codice effettivamente eseguito è identificato a run-time, in

base alla classe di appartenenza dell’oggetto (bindingdinamico)


Polimorfismo e problemi per il testing

• Il test strutturale può diventare non praticabile:

• Come definire la copertura in un’invocazione su un oggetto polimorfico?

• Come creare test per “coprire” tutte le possibili chiamate di un metodo in presenza di binding dinamico?

• Come gestire i parametri polimorfici?

62


Polimorfismo e Binding Dinamico: esempio


Esempio

63


6- Altri Problemi: Gestione delle Eccezioni

• Le eccezioni modificano il flusso di controllo senza la presenza di un esplicito costrutto di tipo test and branch, rendendo inefficace il CFG per modellare il flusso di controllo.

• E’ necessario introdurre ulteriori metodi per generarecasi di test e ulteriori metriche di copertura per valutarel’effettiva copertura di tutte le eccezioni– copertura ottimale: sollevare tutte le possibili eccezioni in tutti i punti

del codice in cui è possibile farlo (può non essere praticabile)– copertura minima: sollevare almeno una volta ogni eccezione


Altri Problemi: Concorrenza

• Problema principale: non-determinismo– risultati non-deterministici– esecuzione non-deterministica

• Casi di test composti solo da valori di Input/Output sono poco significativi

• Casi di test composti da valori di Input/output e da una sequenza di eventi di sincronizzazione (occorre però forzare lo scheduler a seguire una data sequenza)

64


Approcci per il Testing OO

Berard [93] propose il seguente approccio al testing OO:

1. Associare ogni test alla classe da testare2. Specificare lo scopo del Test3. Specificare una sequenza di passi di test, contenente:

• Elenco di stati per l’oggetto da testare• Elenco di messaggi ed operazioni che saranno eseguite come

conseguenza del test• Elenco di eccezioni che potrebbero verificarsi durante il test• Elenco di condizioni esterne (dell’ambiente esterno) che

devono sussistere per eseguire il test• Ulteriori informazioni per capire ed implementare il test.


Metodi per il Testing OO

• Fault-based testing– Il tester si fa guidare dai possibili difetti presenti nel codice, e

progetta i casi di test cercando di metterli in evidenza. Necessità di una classificazione (tassonomia) dei difetti ricorrenti.

– Es. esistono varie categorie di difetti proposte in letteratura relativi ai metodi, alle variabili di istanza, ai messaggi, allaclasse, all’ereditarietà, all’astrazione della classe, etc..

– Spesso tali classificazioni si costruiscono a partire dai bugreport di applicazioni esistenti.

65


Tipici Difetti in OO code …

• Interazioni scorrette fra metodi (individualmente corretti) di superclassi e subclassi.

• Mancata nuova specifica di un metodo ereditato (overriding) in una subclasse, in una profonda gerarchia di ereditarietà.

• La subclasse eredita metodi non appropriati dalle superclassi.• Fallimenti in chiamate polimorfiche di una subclasse la cui

interfaccia è conforme alle interfacce delle superclassi.• Mancata o scorretta inizializzazione della superclasse nelle

subclassi• Scorretto aggiornamento di variabili di istanza di una superclasse

all’interno delle subclassi…


Tipici Difetti in OO code

• Polimorfismo ‘a spaghetti’ che produce perdita del controllo (il problema dello ”yo-yo” causato dal dynamicbinding e oggetti self e super)

• Subclassi violano il modello di stato o l’invariante della superclasse.

• Istanziazioni di classi generiche con un tipo di parametro non testato.

• Relazioni di controllo inter-modulo scorrette, a causa della delocalizzazione di funzionalità in classi piccole e incapsulate.

66



• Scenario-Based Test Design– È un testing in cui ci si concentra su ciò che fa

l’utente, piuttosto che su ciò che fa il software. – Richiede che vengano catturati i task eseguibili

dall’utente (es. i casi d’uso), per poi usarli insieme ai loro scenari alternativi come casi di test.

– In pratica, si andranno a coprire con i casi di test tutte le varianti di comportamento di un caso d’uso.


Esempi di Use Cases e Scenari

67


Dai Casi d’uso ai Test Case


Specifica delle Varianti per un Caso d’uso

68


Progetto dei Test Case



• Testing della Classe e della Gerarchia di classi– La completa copertura di una classe richiede di:

– Testare tutte le operazioni di un oggetto;– Settare ed interrogare tutti gli attributidi un oggetto;– Esercitare l’oggetto in tutti I possibili stati.

– L’ereditarietà rende più difficile la scelta dei casi di test degli oggettigiacchè le informazioni da testare non sono localizzate (ma distribuitenella gerarchia di ereditarietà).

– L’ereditarietà non permette di risparmiare sul testing delle classi derivate che, invece, dovranno essere ritestate comunque.

69


Testing degli stati di una classe di oggetti

– Il testing white box di una classe deve tenere in conto di tutti i possibili stati e cambiamenti di stato degli oggetti di quella classe

• Uso di State Chart per rappresentare tale evoluzione• Uso di vari Criteri di copertura • Copertura degli Stati, delle Transizioni, ..• Copertura dei cammini tra stato iniziale e stato finale di

un oggetto

• Non basta valutare solo gli output restituiti dai metodi ma anche lo stato dell’oggetto dopo la chiamata … ma alcuni attributi potrebbero essere privati o protetti


Es.: interfaccia dell’oggetto Weather station (Stazione Meteo)

identifier

repor tWeather ()calibrate (instruments)test ()star tup (instruments)shutdown (instruments)

WeatherStation

70


State diagram della Stazione Meteo

transmission done

calibrate ()

test ()star tup ()

shutdown ()

calibration OK

test complete

weather summarycomplete

clock collectiondone

Operation

repor tWeather ()

Shutdown Waiting Testing

Transmitting

Collecting

Summarising

Calibrating


Il testing di Weather station

• Occorre definire test cases per tutti I singoli metodi: reportWeather, calibrate, test, startup e shutdown.

• Usando un modello a stati, bisogna identificare le transizioni di stato da testare e le sequenze di eventiche causano tali transizioni.

• Ad esempio:– Waiting -> Calibrating -> Testing -> Transmitting ->

Waiting

71


Integration Testing- Testing Inter-classi

• Gli oggetti collaborano nella realizzazione di funzionalità complesse. Occorre testare tali collaborazioni.

• La generazione dei casi di test può essere effettuata a partire dai diagrammi di interazione UML (tratti dalle specifiche)

• Opportuno costruire diagrammi di interazione anche dal codice e verificare la corrispondenza con le specifiche …

• Problemi– Ereditarietà– Polimorfismo e binding dinamico


Generazione di Casi di Test a partire dai diagrammi di Interazione

• I diagrammi di interazione (quali i sequenze diagramUML) indicano possibili sequenze di messaggi

• Dovrebbero indicare i casi frequenti e quelli particolari• Selezione immediata:

– generare un test per ogni diagramma di interazione

• Selezione più accurata:– per ogni diagramma individuare possibili alternative e per ogni

alternativa selezionare un ulteriore insieme di casi di test

72


Esempio


Problemi per l’automazione dell’ OOT

• Scarsa controllabilità, osservabilità e testabilità del sistema, a causa del numero elevato di piccoli oggetti incapsulati

• Difficoltà nell’analizzare la copertura white-box, a causa di un elevatonumero di complesse dipendenze dinamiche

• L’allocazione dinamica di oggetti crea delle dipendenze tra classi a tempo diesecuzione– Diventa difficile capire quanti e quali stub dover creare per poter testare una

classe indipendentemente dalle altre– Diventa difficile capire in che ordine svolgere il testing di integrazione

bottom-up• Difficoltà nel produrre drivers, stubs, e test suites che tengano conto

della struttura di ereditarietà del sistema• Possibilità di riusare i test case di superclassi nel (regression) testing di

subclasses• Spesso il codice dell’applicazione non è completamente disponibile (se si

usano ad esempio object-oriented frameworks)

73



• La Documentazione del Testing

74


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 equivalenz a

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

• 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

75


Piano di test• Documento relativo all’intero progetto• Struttura

– specifica delle unità di test (per un dato livello di test) Es.Modulo, gruppi di moduli, programma, sottosistemi, intero sistema

– Caratteristiche da testare: funzionalità, prestazioni, vincoli di progetto, sicurezza…

– Approccio: criterio di selezione dei test, criterio di terminazione, strumenti

– Prodotti del test: es. Casi di test, rapporto finale, diario deltest, statistiche di copertura…

– Schedulazione: quando effettuare il testing e lo sforzo per attività

– Allocazione del personale


Rapporti sul test

• Diario del test– descrive i dettagli del test per come si è svolto effettivamente– la specifica dei casi di test può essere completata e usata come

diario

• Riepilogo del test– Rivolto al management del progetto

• numero totale di casi di test eseguiti• numero e tipo di malfunzionamenti osservati

• numero e tipo di difetti scoperti

• Sommario dei malfunzionamenti– Rivolto a chi deve effettuare il debugging o la correzione

Verifica e Validazione del Software - unina.stidue.netunina.stidue.net/Ingegneria del Software...

Documents

Transcript of Verifica e Validazione del Software - unina.stidue.netunina.stidue.net/Ingegneria del Software...