Verifica e Validazione del Software Argomenti trattati

Transcript

Verifica e Validazione del Software
Tecniche avanzate di Software Testing
Ingegneria del Software 2
Software Testing
1
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
Software Testing
2
1
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)
Software Testing
3
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).
Software Testing
4
2
• Richiami sul Software Testing
Software Testing
5
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.
Software Testing
6
3
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
Software Testing
7
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
Software Testing
8
4
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
Software Testing
9
Un esempio
ERRORE di editing/digitazione
Function
RADDOPPIA ( )
....
read (x);
y := x*x;
write (y)
...
DIFETTO
=> “*” invece di “+”
DIFETTO causato da un errore
MALFUNZIONAMENTO
=> il valore visualizzato è errato
Possibile MALFUNZIONAMENTO in
esecuzione…
(può verificarsi o meno: dipende
dall’input)
Software Testing
10
5
Relazione fra Errore, Difetto e
Malfunzionamento
causa
errore
1..*
causa
Difetto
1..*
1..*
Malfunzionamento
*
Software Testing
11
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è esibisce
malfunzionamenti)
Il testing può sono dimostrare la presenza dei difetti,
ma non la loro assenza!! (Tesi di Dijkstra)
Software Testing
12
6
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 sono
stati più riscontrati difetti), altrettanto possa fare alla (n+1)esima
Impossibilità di produrre tutte le possibili configurazioni di
valori di input (test case) in corrispondenza di tutti i possibili
stati interni di un sistema software
Software Testing
13
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
Software Testing
14
7
Software Testing
Software Testing
15
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!!!
Software Testing
16
8
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!
17
Software Testing
Il Processo di Software Testing
Test
cases
Design test
cases
Test
data
Prepar e test
data
Test
results
Run pr ogram
with test da ta
Software Testing
Test
repor ts
Compar e results
to test cases
18
9
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à di
ripristinarlo
• Potrebbe non essere possibile se nel software ci sono degli
elementi indeterministici
– Ovvero dipendenti da input non controllabili
Software Testing
19
Software Testing
20
• Livelli di Testing
10
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
21
Software Testing
Fasi del Testing (a livello Produttore)
Component
testing
Software developer
System
testing
Independent testing team
Software Testing
22
11
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.
Software Testing
23
Livello Produttore
• Test di Integrazione
– Richiede la costruzione del sistema a partire dai suoi
componenti ed il testing del sistema risultante per scoprire
problemi che nascono dall’interazione fra I vari componenti.
– Richiede l’identificazione di gruppi di componenti che realizzano
le varie funzionalità del sistema e la loro integrazione mediante
componenti 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.
Software Testing
24
12
Strategie per il Testing di Integrazione
Top-down testing
Bottom-up testing
Sandwich testing
driver driver driver
UI Layer
UI Layer
stub stub stub
Database Network
layer
layer
UI Layer
Functional layer
Functional layer
Database Network
layer
layer
stub stub stub
Database Network
layer
layer
stub stub stub
UI Layer
Fully Functional layer
integrated
Network
system Database
layer
layer
25
Software Testing
Esecuzione del testing di integrazione
• Costruzione di Moduli guida (driver)
– invocano l’unità sotto test, inviandole opportuni
valori, relativi al test case
Modulo
guida
Unità
sotto test
• 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)
Modulo
fittizio
• Quando la funzione chiamata viene realizzata e
testata, si sostituisce lo stub con la funzione stessa
Software Testing
26
13
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 packages
per mercato di massa!
Software Testing
27
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'
Software Testing
28
14
• Il Testing dei Requisiti Non Funzionali
Software Testing
29
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 si
pianificano test in cui il carico viene incrementato
progressivamente finché le prestazioni diventano
inaccettabili.
Il carico deve essere progettato in modo da
rispecchiare le normali condizioni di utilizzo.
Software Testing
30
15
Stress testing
•
•
•
•
Nello stress testing si sollecita il sistema con un carico
superiore a quello massimo previsto: in queste
condizioni in genere I difetti vengono alla luce.
Stressando il sistema si può testare il comportamento
in 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.
Software Testing
31
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 components
involved in the execution of an application does not make it
feasible 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 as
browser configurations disabling graphical visualization, or
scripting execution), or of users with physical disabilities (such as
blind people).
Software Testing
32
16
Altri tipi di Testing
• Testing di Sicurezza
– Aims to verify the effectiveness of the overall system
defenses against undesired access of unauthorized
users, 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
Software Testing
33
• Problemi dei Processi di testing
Software Testing
34
17
Problemi chiave di un processo di testing
•
•
•
Selezione dei Casi di Test
Valutazione dei risultati del Test
Terminazione del Testing
Test
cases
Design test
cases
Test
data
Prepar e test
data
Test
results
Run pr ogram
with test da ta
Test
repor ts
Compar e results
to test cases
Software Testing
35
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)
Software Testing
36
18
Il ruolo dell’Oracolo
Casi di test
Software
da
testare
Oracolo
Comparatore
Risultati del test
Software Testing
37
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
Software Testing
38
19
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
Software Testing
39
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
Software Testing
40
20
Criterio di Selezione dei Test
• Specifica le condizioni che devono essere soddisfatte da un test
e 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 generato
da C per un programma non corretto avrà successo.
Software Testing
41
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
Software Testing
42
21
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 !
Software Testing
43
Software Testing
44
• Tecniche di Testing
22
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 sulla
base della sola conoscenza dei requisiti del sistema (o di
suoi 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.
Software Testing
45
1- Testing basato sui requisiti
•
Il principio della verificabilità dei requisiti afferma
che i requisiti dovrebbero essere testabili, cioè
scritti in modo da poter progettare test che
dimostrino che il requisito è stato soddisfatto.
•
Il testing basato sui requisiti è una tecnica di
convalida dove vengono progettati vari test per
ogni requisito .
Software Testing
46
23
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.
Software Testing
47
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
Software Testing
48
24
2- Testing delle Partizioni (o delle Classi di
Equivalenza)
•
I dati di input ed output possono essere in genere
suddivisi in classi dove tutti I membri di una stessa
classe 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 membro
della classe.
•
I casi di Test dovrebbero essere scelti all’interno di
ciascuna partizione.
Software Testing
49
Equivalence partitioning
Invalid inputs
Valid inputs
System
Outputs
Software Testing
50
25
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.
Software Testing
51
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
Software Testing
52
26
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
Software Testing
53
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.
Software Testing
54
27
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
Software Testing
55
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 valide
CE2 : GIORNO < 1
CE3 : GIORNO > 31
CE4 : GIORNO non è un numero intero
Software Testing
56
28
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 valida
CE6: MESE ? M
Software Testing
57
Le condizioni sull’input ‘anno’
•Condizioni di ingresso:
– Deve essere compreso tra 1900 e 2000
•Classi di equivalenza
•
Valida
CE7: 1900<= ANNO<=2000
•
Non valide
CE8: ANNO< 1900
CE9: ANNO> 2000
CE10: ANNO non è un numero intero
Software Testing
58
29
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
Classi coperte
CE1, CE6, CE7
CE2, CE55, CE7
CE3, CE56, CE7
CE4, CE57, CE7
Ogni TC copre al più una CE non valida!
59
Software Testing
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
Classi coperte
CE1, CE58, CE7
CE1, CE59, CE7
CE1, CE510, CE7
CE1, CE511, CE7
Test case
TC13
Giorno
1
Mese
dicembre
Anno
1980
Classi coperte
CE1, CE512, CE7
Software Testing
60
30
Problemi
• A volte é necessario tenere conto delle pre-condizioni e postcondizioni di una funzione nella scelta delle classi di equivalenza.
• Ad esempio la ricerca di un elemento in un vettore darà esito
diverso 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.
Software Testing
61
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!
Software Testing
62
31
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.
Software Testing
63
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…
Software Testing
64
32
Un esempio di Tabella di decisione
Varianti
Con
dizio
ni
1
2
3
4
5
Numero
incidenti
0
0
1
1
Tra 2 e Tra 2 e 5 o più
4
4
Età
assicurato
<=25
>=26
<=25
>=26
<=25
>=26
Qualsias
i
50
25
100
50
400
200
0
Lettera
No
No
Sì
no
Sì
Sì
No
Polizza
Cancellata
No
No
No
No
No
No
Sì
Azion Aumento
i
Premio ($)
6
7
Software Testing
65
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!
Software Testing
66
33
Generazione dei Test
• Un possibile Criterio di Copertura della Tabella:
– Copertura di tutte le varianti esplicite
– Un Test Case per ogni variante
Software Testing
67
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).
Software Testing
68
34
Il Grafo Causa-Effetto per l’esempio precedente
Età<=25
?
?
?
?
Età>=26
0 Incidenti
1 Incidenti
$25
?
$50
$100
?
?
Tra 2 e 4 Inc.
$200
$400
?
Lettera di avviso
>=5 Incidenti
?
Cancellazione polizza
= AND, ?
=OR, ~= NOT
69
Software Testing
Varianti
Con
dizio
ni
1
2
3
4
5
6
7
Numero
incidenti
0
0
1
1
Tra 2 e 4
Tra 2 e 4
5o
più
Età
<=25
>=26
<=25
>=26
<=25
>=26
Qual
siasi
Aumento
Premio
($)
50
25
100
50
400
200
0
Lettera
No
No
Sì
no
Sì
Sì
No
Polizza
No
Cancellat
a
No
No
No
No
No
Sì
assicurat
o
Azio
ni
Software Testing
70
35
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 causaeffetto (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
Software Testing
71
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
Software Testing
72
36
• Macchine a Stati e State-Base Testing
• Ref. R. Binder “Testing Object-Oriented SystemsModels, Patterns and Tools”, Addison Wesley
Software Testing
73
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
Software Testing
74
37
Le azioni possono essere
associate sia agli stati che
alle transizioni
Software Testing
75
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
Software Testing
76
38
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)
Software Testing
77
La Macchina di Mealy corrispondente
Software Testing
78
39
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
Software Testing
79
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 del
codice:
– È 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)
Software Testing
80
40
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
Software Testing
81
… 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
Software Testing
82
41
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)
Software Testing
83
Esempio di Difetto: Transizione Mancante
Software Testing
84
42
Esempio di Difetto: Transizione Scorretta
Software Testing
85
Esempio di Difetto: Azioni Mancanti
Software Testing
86
43
Esempio di Difetto: Azione Scorretta
Software Testing
87
Esempio di Difetto: Sneak Path
Software Testing
88
44
Esempio di Difetto: Trap Door
Software Testing
89
Strategie per il Progetto dei Test
nello State-based testing
• Si usano gli stessi concetti di Copertura visti nel testing
white-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.
Software Testing
90
45
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
Software Testing
91
Esempio: All-states Coverage
Software Testing
92
46
All-transitions coverage
Software Testing
93
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
Software Testing
94
47
• Testing Strutturale (o White Box)
Software Testing
95
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 formulare
criteri di copertura più precisi di quelli formulabili
con testing Black Box
– Test White Box che hanno successo possono fornire maggiori
indicazioni al debugger sulla posizione dell’errore
Software Testing
96
48
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
Software Testing
97
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
Software Testing
98
49
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 relazione
flusso 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.
99
Software Testing
Strutture di controllo di base nel CFG
if
t
f
f
v
f
v
If-then-else
Repeat … until C
Software Testing
While C do
100
50
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 il
Control Flow
Graph
101
Software Testing
Un esempio
I
procedure Quadrato;
var x, y, n: integer;
begin
1. read(x);
2. if x > 0
then begin
3.
n := 1;
4.
y := 1;
5.
while x > 1 do
begin
6.
n := n + 2;
7.
y := y + n;
8.
x := x - 1;
end;
9.
write(y);
end;
end;
I
1
1,2
2
true
false
true
3
false
3,4,5
true
4
5
true
6
false
false
6,7,8
7
9
8
F
9
F
Software Testing
102
51
Criteri di copertura
• 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)
Software Testing
103
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
Software Testing
104
52
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
100
int 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
Software Testing
105
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!
Software Testing
106
53
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
• Copertura delle condizioni e decisioni
Software Testing
107
Cammini linearmente indipendenti (McCabe)
• Un cammino è un’esecuzione del modulo dal nodo iniziale
del Cfg al nodo finale
• Un cammino si dice indipendente (rispetto ad un insieme di
cammini) se introduce almeno un nuovo insieme di
istruzioni 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 cammini
sono generati da una combinazione lineare di quelli di base.
• Dato un programma, l’insieme dei cammini di base non è
unico.
Software Testing
108
54
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
Software Testing
109
Esempio
0
1
true
false
2
true
false
3
4
5
Complessità ciclomatica
del programma è 3
V(G)= 3 =>3 cammini indipendenti
c1= 0-1-2-4-5
c2= 0-1-2-3-2-4-5
c3= 0-1-5
Software Testing
110
55
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 eseguiti
durante 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
Software Testing
111
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 indipendenti
implica la copertura dei nodi e la copertura delle
decisioni
• La copertura dei cammini è un test ideale ed implica
tutti gli altri
Software Testing
112
56
Problemi
• E’ possibile riconoscere automaticamente quale cammino
linearmente indipendente viene coperto dall’esecuzione di
un 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 cicli
eseguiti, per i quali sarebbe necessaria la copertura di tutti I
cammini, che però rappresenta il testing esaustivo!
Software Testing
113
• Testing di Sistemi Object Oriented
Software Testing
114
57
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
Software Testing
115
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
Software Testing
116
58
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
Software Testing
117
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 information
hiding) 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)
Software Testing
118
59
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 invariate
ma influenzate dal nuovo contesto
– Può essere necessario verificare la compatibilità di
comportamento tra metodi omonimi in una relazione classesottoclasse
– Riuso test, e test specifici
– Ereditarietà produce nuova forma di Integrazione/ Interazione
Software Testing
119
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
Software Testing
120
60
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 (binding
dinamico)
Software Testing
121
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?
Software Testing
122
61
Polimorfismo e Binding Dinamico: esempio
Software Testing
123
Esempio
Software Testing
124
62
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 generare
casi di test e ulteriori metriche di copertura per valutare
l’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
Software Testing
125
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)
Software Testing
126
63
Approcci per il Testing OO
Berard [93] propose il seguente approccio al
testing OO:
1. Associare ogni test alla classe da testare
2. Specificare lo scopo del Test
3. 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.
Software Testing
127
Metodi per il Testing OO
• Fault-based testing
– Il tester si fa guidare dai possibili difetti presenti nel codic e, 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, alla
classe, all’ereditarietà, all’astrazione della classe, etc..
– Spesso tali classificazioni si costruiscono a partire dai bug
report di applicazioni esistenti.
Software Testing
128
64
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…
Software Testing
129
Tipici Difetti in OO code
• Polimorfismo ‘a spaghetti’ che produce perdita del
controllo (il problema dello ”yo-yo” causato dal dynamic
binding 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.
Software Testing
130
65
• 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.
Software Testing
131
Esempi di Use Cases e Scenari
Software Testing
132
66
Dai Casi d’uso ai Test Case
Software Testing
133
Specifica delle Varianti per un Caso d’uso
Software Testing
134
67
Progetto dei Test Case
Software Testing
135
• 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 oggetti
giacchè le informazioni da testare non sono localizzate (ma distribuite
nella gerarchia di ereditarietà).
– L’ereditarietà non permette di risparmiare sul testing delle classi
derivate che, invece, dovranno essere ritestate comunque.
Software Testing
136
68
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
Software Testing
137
Es.: interfaccia dell’oggetto Weather station (Stazione Meteo)
WeatherStation
identifier
repor tWeather ()
calibrate (instruments)
test ()
star tup (instruments)
shutdown (instruments)
Software Testing
138
69
State diagram della Stazione Meteo
Operation
calibrate ()
Calibrating
calibration OK
test ()
star tup ()
Waiting
Shutdown
Testing
transmission done
shutdown ()
test complete
Transmitting
clock
collection
done
repor tWeather ()
Summarising
weather summary
complete
Collecting
Software Testing
139
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 eventi
che causano tali transizioni.
•
Ad esempio:
–
Waiting -> Calibrating -> Testing -> Transmitting ->
Waiting
Software Testing
140
70
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
Software Testing
141
Generazione di Casi di Test a partire
dai diagrammi di Interazione
• I diagrammi di interazione (quali i sequenze diagram
UML) 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
Software Testing
142
71
Esempio
Software Testing
143
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 elevato
numero di complesse dipendenze dinamiche
•
L’allocazione dinamica di oggetti crea delle dipendenze tra classi a tempo di
esecuzione
– 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)
Software Testing
144
72
Software Testing
145
• La Documentazione del Testing
Software Testing
146
73
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
Software Testing
147
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
Software Testing
148
74
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 del
test, statistiche di copertura…
– Schedulazione: quando effettuare il testing e lo sforzo per
attività
– Allocazione del personale
Software Testing
149
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
Software Testing
150
75

Verifica e Validazione del Software Argomenti trattati

Transcript

Documenti analoghi

14-002950-PR01 PB-A01-02-IT-01.cdr

Attività

RIF COD 28303 – NEOLAUREATI IN INGEGNERIA ATS – DIP

Dalla Qualità all`Affidabilità: pianificare il - valore

Documento allegato - Policlinico S.Orsola

UNIVERSITA` DEGLI STUDI e-CAMPUS FACOLTA` DI INGEGNERIA

Caratteristiche EJ200 Flight testing

curriculum vitae

“Development of novel ISRU and ISFR technologies for space

alessandropaghi.it