Ingegneria del Software - ICAR

Transcript

Ingegneria del Software
Testing - Strategie di Collaudo del
Software
Corso di Ingegneria del Software
Ing. Antonio Coronato
Università “Federico II” di Napoli
Consiglio Nazionale delle Ricerche
Testing del Software
Il testing è quell’
quell’attività
attività di “esercizio”
esercizio” del
software tesa all’
all’individuazione dei
malfunzionamenti prima della messa
in esercizio
Construction
Testing
Deployment
Cosa mostra il Testing?
malfunzionamenti
conformità
conformità coi requisiti
indicazioni di performance
indicazione di qualità
qualità
Faults, Errors e Failures
• Failure
– Si manifesta quando il servizio offerto dal sistema
devia dalle specifiche
• Error
– Si ha quando il sistema si porta in uno stato
scorretto che può essere causa di un fallimento
• Fault
– E’ la causa che provoca un errore
Un Esempio di Software Fault
• Un sistema di gestione degli accessi a servizi
pubblici e privati.
Specifiche:
– Gli utenti possono avere due livelli di diritti 1 e 0.
– I servizi privati richiedono livello di diritti pari ad 1
– L’accesso ad un servizio è accordato se il servizio è
disponibile ed il livello di diritti utente coincide col
livello richiesto
Un Esempio di Software Fault (2)
Caso 1
Utente Marco Rossi
Diritti = 1
Richiede Servizio Pubblico
Servizio disponibile
Fault Latente
Nessun Errore
Nessun Fallimento
Caso 2
…
if(ServizioPrivato)
Caso 3
Fault
{
Utente Giorgio Bianchi
…
Diritti = 0
if(Diritti = 1)
Richiede Servizio Privato
Autorizzato = true;
Servizio NON disponibile
else
Autorizzato = false;
…
if(Autorizzato && ServizioDisponibile)
cout<<"Accesso garantito"<<endl;
Caso 4
…
}
Fault Mascherato
Nessun Errore
Nessun Fallimento
Utente Marco Rossi
Diritti = 1
Fault Attivo
Errore
Nessun Fallimento
Diritti = 0
Ing. Antonio
Coronato
Servizio
disponibile
Fault Attivo
Errore
Fallimento
Software Faults nel Ciclo di Vita del
Sistema
• La presenza di errori nel software sviluppato è da
considerarsi una condizione normale
– Per sistemi software complessi non è realistico pensare di
ottenere dalla fase di sviluppo release immuni da errori
– Adottare processi di sviluppo di qualità riduce la quantità di
errori presenti nel software sviluppato
• E’ necessario eliminare (o quantomeno ridurre) gli
errori software prima della messa in esercizio del
sistema
– Azioni di collaudo guidate da opportune strategie individuano
errori presenti nel software
– Azioni correttive aumentano la qualità del prodotto finale
Tesi di Dijkiastra
• Il testing NON PUÒ dimostrare l’assenza di
difetti, ma può solo dimostrare la presenza di
difetti
Chi Testa il Software?
developer
independent tester
Comprende bene il sistema
ma è inconsciamente “gentile”
gentile”
nell’
nell’attività
attività di testing
Deve imparare il sistema
ma è più
più critico ed esigente
Testing guidato dalla consegna
Testing guidato dalla qualità
qualità
Sviluppatori e tester indipendenti cooperano e svolgono entrambi attività
attività di testing
Verifica e Convalida
• Verifica
– Insieme delle attività tese ad accertare la
correttezza funzionale
• Convalida (o Validazione)
– Insieme delle attività tese a verificare la
implementazione dei requisiti software
!
" #$#%$ ##%
&
'
((
'
" #$#%$ ##%
'
*
)
)
((
Strategie di Testing
• Le attività di testing necessitanto di una vera e
propria strategia
– Pianificazione
– Progettazione dei test case
– Esecuzione dei test case
– Raccolta dei risultati
– Valutazione dei risultati
Pianificazione del Testing
• Quando possiamo ritenere concluse le attività di
testing?
• Diversi criteri per decidere quando terminare il testing
– Criterio temporale
• Si definisce un periodo di tempo massimo per le attività di testing
– Criterio di costo
• Si assegna un badget massimo per le attività di testing
– Criterio di copertura
• Percentuale predefinita degli elementi di un modello di
programma
• Legato ad un criterio di selezione dei casi di test
– Criterio statistico
• Si ripetono attività di testing fino al raggiungimento di un MTBF
(mean time between failures) obiettivo
• Legato ad un criterio di selezione dei casi di test
+
*
,,,
" #$#%$ ##%
*
'
*
Progettazione dei Casi di Test
• Un caso di test è un sottoinsieme dei possibili
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
Progettazione dei Casi di Test (2)
• 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
• 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)
Valutazione dei Risultati del Test
•
•
Condizione necessaria per
effettuare un test:
– conoscere il comportamento
atteso per poterlo
confrontare con quello
osservato
L’oracolo conosce il
comportamento atteso per
ogni caso di prova
– Oracolo umano
• si basa sulle specifiche o sul
giudizio
– Oracolo automatico
• generato dalle specifiche
(formali)
• stesso software ma
sviluppato da altri
• versione precedente (test di
regressione)
Strategie di Testing
unit test
system
test
integration
test
validation
test
Approccio Bottom-Up
• Si parte dal “testing in piccolo” e si va verso il
“testing in grande”
Collaudo
di Sistema
Collaudo
di Convalida
Collaudo
di Integrazione
Collaudo
Unità
Collaudo
Unità
Collaudo
Unità
Chi fa cosa?
• Due ruoli coinvolti
Collaudo
di Sistema
independent tester
Collaudo
di Convalida
Collaudo
di Integrazione
Collaudo
Unità
Collaudo
Unità
Collaudo
Unità
developer
Altre Attività di Testing
• Testing del produttore
–
–
–
–
Testing di unità
Testing di integrazione
Testing di convalida
Testing di sistema
• Testing cooperativo produttore-cliente (privilegiato)
– Alpha testing
• uso del sistema da parte di utenti reali ma nell'
ambiente di
produzione e prima della immissione sul mercato
– Beta testing
• uso del sistema da parte di utenti reali ma nell'
ambiente di
produzione e prima della immissione sul mercato
• Testing del cliente
– Testing di accettazione
Testing delle Applicazioni
• Applicazioni Function-Oriented
– Le unità di testing sono rappresentate dai moduli sorgente
– Focus sulle funzionalità
• Applicazioni Object-Oriented
– Le unità di testing sono rappresentate dalle singole classi
– Focus sulle comunicazioni e collaborazioni tra classi (oltre che
sulle funzionalità)
• Applicazioni Component-Based
– Le unità di testing sono rappresentate dai singoli componenti o
dalle classi dei singoli componenti
– Focus sulle problematiche di integrazione (oltre che sulle
collaborazioni e sulle funzionalità)
Testing di Unità
Unità
Unità
da Testare
results
software
engineer
test cases
Testing di Unità (2)
Modulo da
testare
Interfacce
Strutture dati locali
Cammini indipendenti
Cammini di gestione degli errori
test cases
Ambiente di Testing per le Unità
•
Generalmente le unità di testing non costituisco elementi software
eseguibili indipendentemente => E’ necessario definire ambienti di
testing
Modulo pilota
Interfacce
Strutture dati locali
Modulo
Da testare
Cammini indipendenti
Cammini di gestione degli errori
Modulo
fittizio
Modulo
fittizio
test cases
Risultati
Strategie di Testing di Integrazione
•
Testing dell’intero sistema
– Si integrano tutte le unità del
sistema e successivamente
si procede al testing
– Può essere particolarmente
oneroso nel caso di sistemi
complessi
•
Testing incrementale
– Le unità sono integrate in
maniera incrementale
– Dopo ogni incremento si
procede al testing di
integrazione
Integrazione con approccio Top-Down
•
Passi del processo di
integrazione:
1. Testing del modulo di
controllo (modulo pilota)
2. Sostituzione di un
modulo fittizio con il
corrispondente reale
3. Test di integrazione
dopo ogni sostituzione
4. Ritorna al passo 2 fino
al completamento
dell’integrazione
•
Modi di integrazione:
–
–
Depth-first
Breadth-first
A
Modulo pilota
Modulo reale
B
F
G
Modulo fittizio
C
D
E
Difficoltà
Difficoltà di testing per i moduli fittizzi che
devono restituire risultati di elaborazione
Integrazione con approccio Bottom-Up
•
A
Passi del processo di
integrazione:
1. Aggregazione delle
unità di basso livello in
gruppi (cluster)
2. Predisposizione di un
modulo pilota per il
cluster
3. Test del cluster
4. Sostituzione dei moduli
pilota (fittizi) con i
moduli reali
5. Ritorna al passo 2 fino
al completamento
dell’integrazione
B
C
D
E
cluster
F
G
Integrazione con approccio a Sandwitch
A
B
F
I moduli di controllo sono
testati con moduli fittizzi
G
C
I moduli che sviluppano funzionalità
funzionalità
sono ragruppati in cluster
D
E
cluster
Ulteriori Livelli di Testing
• Testing di Convalida
– Verifica che il sistema funzioni secondo le
aspettative del cliente
• Le aspettative del cliente sono stabilite dai requisiti
• Le prove di convalida possono essere specificate nel
documento SRS
• Può includere alpha e beta testing
• Alpha/Beta testing
– Focus sull’utilizzo da parte dell’utente
-
.
(
+ /
(
+ /
(
)
" %$#%$ ##%
)
Ulteriori Livelli di Testing (2)
• Testing di sistema
– Focalizza sull’intero sistema
– Può includere testing di affidabilità, sicurezza,
performance e stress
• Testing di affidabilità
– Si forza il sistema a fallire per verificarne le capacità
di recovery
– Si sollecita il sistema con dati scorretti, iniettando
errori, esercitando le sezioni di gestione delle
eccezioni
Ulteriori Livelli di Testing (3)
•
Testing di sicurezza
– Si attenta alle caratteristiche di sicurezza del sistema per evidenziare
vulnerabilità
– Si esercitano i servizi di:
•
•
•
•
•
Authentication
Access control
Privacy
…
Testing di performance
– Si esercita il sistema in condizioni operative “normali” per verificarene
le performace
•
Testing di stress
– Si sollecita il sistema con volumi di carico particolarmente elevati, ad
esempio un ordine di grandezza superiore alle normali condizioni
Debugging
Definizione
• Il Debugging è il processo di scoperta dei fault
a partire dai malfunzionamenti (failures)
individuati dal testing
• Include l’ispezione del software, cioè l’analisi
del codice sorgente
Risultati del Testing
• Nel caso del sistema di gestione degli accessi
a servizi pubblici e privati
Failure!
? Qual è la
causa?
Test Case
Diritti = 0
Grant
Access!
tester
Risultati delle Attività di Debugging
• Individuare le cause dei fallimenti evidenziati
dal testing
…
if(ServizioPrivato)
Fault
{
…
if(Diritti = 1)
Autorizzato = true;
else
Autorizzato = false;
…
if(Autorizzato && ServizioDisponibile)
cout<<"Accesso garantito"<<endl;
…
}
Il Processo di Debugging
test cases
Testing
regression
tests
corrections
results
new test
cases
suspected
causes
Debugging
identified
causes
Degugging Effort
tempo necessario
per correggere l’errore
e condurre test di regressione
tempo necessario per
diagnosticare il fallimento,
fallimento,
analizzare I sintomi e
determinare la causa
Sintomi e Cause
•
Sintomi e cause possono
essere geograficamente
separati
•
I sintomi possono scomparire
quando un altro errore viene
corretto
– Correlazione tra errori
•
symptom
Casi di failure intermittenti
– Sincronizzazione di thread
cause
•
Fault d’ambiente
– Malfunzionamenti introdotti da
compilatori, sistemi operativi…
Conseguenze di un Software Fault
infectious
damage
catastrophic
extreme
serious
disturbing
mild
annoying
Bug Type
Bug Categories: functionfunction-related bugs,
systemsystem-related bugs, data bugs, coding bugs,
design bugs, documentation bugs, standards
violations, etc.
Tecniche di debugging
brute force / testing
backtracking
induction
deduction
Riferimenti Bibliografici
• Pressman, cap. 13

Ingegneria del Software - ICAR

Transcript

Documenti analoghi

Uno signo de sangue suo - Scienze dell`antichità

Curriculum Vitae

cv salvatore laguardia

Aurelio De Laurentiis

Liceo Mercalli

dalla conoscenza all`impresa innovativa per un ingegnere elettrico

A.I.I.M.B. - Associazione Italiana di Ingegneria Medica e Biologica

Curriculum Vitae - Istituto Motori

networking day - INFN - Napoli