Analysis of extra effort for Change in Scope

Software testing
Lezione 3 – Functional Testing
Federica Spiga
[email protected]
A.A. 2010-2011
Autori: A.Bei/F.Rabini/F.Spiga
1
Functional Testing
•Sotto la dicitura funzionale si raccolgono i criteri di progettazione dei test che si
basano solamente sui requisiti di un programma.
•Sono definiti come criteri black-box
•Nella progettazione dei test interverranno solamente le caratteristiche esterne del
programma: la sua interfaccia di ingresso/uscita e l’ambiente di esecuzione.
•I criteri funzionali prevedono di selezionare l’insieme dei dati di ingresso che
costituirà il test a partire dallo studio delle funzionalità di un programma.
• Si distinguono in base alle regole con cui sono individuati i casi rilevanti che
costituiranno la materia del test.
•Nel caso di specifiche espresse in linguaggio formale i criteri funzionali sono più
facilmente applicabili e spesso è possibile ricorrere a strumenti automatici per
generare direttamente i casi di test o, comunque, è possibile definire delle regole che
rendono il procedimento automatizzabile.
•Se le specifiche non sono espresse formalmente o sono espresse in linguaggio
naturale, i criteri funzionali risultano di più difficile applicazione e diventa
fondamentale l’esperienza dei professionisti incaricati di progettare i test
2
Black Box Vs White Box
3
Come deve essere un buon caso di test??
•Efficace: (in senso statistico) deve essere in grado di rilevare un
bug se questo è presente
•Deve rilevare problemi significativi
•Credibile (no “Corner Case”)
•Esito facilmente interpretabile
•Utile per il troubleshooting
•Complessità appropriata allo stato di maturità
•dell’applicazione
Un Test deve essere ragionevolmente in grado di fornire
Informazioni (Kaner)
4
Strategie di test funzionali black box
5
Smoke testing
• Eseguito non appena l’applicazione viene mandata in Test
•E’ un test non strutturato e non esaustivo che si focalizza solo su un alcune
funzionalità principali
• Valuta la stabilità dell’applicazione ai fini di test successivi
•Il termine “smoke test” deriva dal testing di componenti dell’HW:
inserendo un componente nuovo, se non usciva il fumo il test era
considerato “passed”
6
Function and Domain testing
•L’analisi di dominio (domain analysis) è uno strumento semplice ed efficace
per la selezione dei valori di test.
•Decomposizione delle funzionalità
•Per ogni funzionalità la scelta dei dati di input viene eseguita tramite tecniche
di decomposizione
•La progettazione dei casi di Test è formalizzata nei Test Case
•La scelta dei dati di Test è formalizzata nei TestScript
7
Function and Domain testing – progettazione test case
•Il test funzionale viene condotto a diversi livelli di
integrazione, ed in particolare:
―A livello del singolo modulo
―Al termine dell’integrazione tra due sottosistemi oppure
tra un sottosistema ed un singolo modulo A
―Al termine dell’integrazione dell’intero sistema.
•La metodologia adottata prevede la decomposizione
gerarchica di ciascuna funzionalità in:
―FTR, che indica la funzione a livello più alto
―TR, che descrive il caso di test o la funzione elementare
―TS che rappresenta la parte operativa del test stesso.
8
Function and Domain testing – progettazione test case
•Ad ogni TR può corrispondere uno o più Test Script (TS);
•Il TS rappresenta un’istanza del caso di test definita per
descrivere e soddisfare le condizioni alle quali sottoporre
la funzione applicativa, documentando univocamente i
passi operativi che permettono l’esecuzione del test.
•Gli script rappresentano quindi una sequenza di azioni
compiute sull’applicativo in esame. Dovendo essere
reiterabili, potrà risultare necessario considerare più dati
di input; si avrà, inoltre, l’indicazione delle condizioni di
output da verificare.
9
Function and Domain testing – progettazione test case
•I TS descrivono le condizioni da realizzare per verificare le
situazioni d’uso dell’applicazione sotto i seguenti aspetti:
Requisiti per l’esecuzione dello script;
Stato iniziale e finale dell’applicazione;
Operazioni da svolgere;
Dati di ingresso da utilizzare;
Dati sugli archivi;
Risultati attesi, positivi o negativi, in termini di dati o
messaggi restituiti, stati del sistema e dati sugli
archivi.
10
Function and Domain testing - progettazione test case
11
Scenario testing
•Testa lo scenario di Business
•Coinvolge più feature del sistema => Ad ogni scenario corrispondono più test cases
•È 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.
12
State Model Testing
•L’applicazione di questo criterio si basa sulla costruzione, ottenuta a partire dai
requisiti o dalle specifiche del programma, di un grafo che lega un insieme di
fatti elementari di ingresso (cause) e di uscita (effetti) in una rete combinatoria
che definisce delle relazioni di causa-effetto,
•I casi di test si ricavano risalendo il grafo a partire dalle combinazioni di fatti
elementari d’uscita e ottenendo le combinazioni di fatti elementari di ingresso
che le generano.
•Il grafo causa-effetto può essere costruito durante la fase di
validazione dei requisiti, per mettere in luce contraddizioni ed evidenziare parti
mancanti di logica.
13
State Model Testing
•Significa creare una catena di
test che permetta di visitare tutti i
nodi del grafo con sui sono
rappresentati gli stati
dell’applicazione
14
Exploratory testing
•Il tester non deriva i casi di test da documentazione formalizzata, ma li progetta
nel momento in cui testa l’applicazione
•Approccio incrementale: man mano che procede la test execution vengono
realizzate sempre nuove e migliori prove di test
•Il tester impara continuamente dall’applicazione che sta testando
•Il rischio è che si perda la visione d’insieme e si vada in profondita su parti del
prodotto, mentre se ne trascurano altre
15
Regression testing
•Viene eseguito dopo un generico ciclo di bug fixing
•Ha i seguenti obiettivi:
•Verificare che i bug dichiarati Fixed lo siano effettivamente
•Controllare che i cambiamenti non abbiano introdotto nuovi
bug
•Automatizzabile
•Poco efficace: la percentuale di bug rilevati su test dichiarati OK è
tra 5% e 20%
16
Risk Based testing
•Prioritizzare l’effort di test su aree/ funzionalità dell’applicazione
ritenute più rischiose
•Come valuto il rischio di una funzionalià/area?
•Probabilità della verifica di un fault
•Importanza della funzionalità del processo di Business
•Gravità delle conseguenze del fault
17
Test funzionale – Data based black box testing
 Boundary value
– Input indipendenti ed in quantità numeriche (es: età)
– Si sospettano errori se l’input è inserito nei limiti dell’intervallo consentito
 Equivalence partitioning
– Input indipendenti ed in quantità numeriche
– Si sospettano errori computazionali
– Si può assumere che l’input sia suddivisibile in classi di equivalenza
 Decision table
– Input dipendenti
– Si sospettano errori computazionali
18
Equivalence partitioning
 Per input numerici si suddivide il dominio in sottodomini (classi di
equivalenza). Si esegue un test case per ogni sottodominio
g
 Si assume:
f
 Partizionamento in classi di eq.independenti
e
 Ridondanza in ogni sottodominio
a
b
c
d x
 Il dominio dei dati di ingresso è ripartito in classi di equivalenza: due
valori d’ingresso appartengono alla stessa classe di equivalenza se, in
base ai requisiti, dovrebbero produrre lo stesso comportamento del
programma.
 La progettazione dei casi di test prosegue in modo da esercitare il
programma su valori rappresentanti di ognuna delle classi di
equivalenza. Il criterio è economicamente valido solo per quei
programmi per cui il numero dei possibili comportamenti è
sensibilmente inferiore alle possibili configurazioni d’ingresso.
19
Equivalence partitioning
Se una condizione di ingresso specifica un range di valori, identificare una classe di
equivalenza valida e due invalide.
Esempio: Se abbiamo l’insieme di valori {1, . . . . , 99} allora occorreranno le seguenti classi:

–
–
Classe di equivalenza valida {1, . . . , 99};
Classi di equivalenza invalide {x | x < 1} and {x | x > 99}
Se una condizione di ingresso specifica un insieme di valori di ingresso e ciascuno è
gestito in modo diverso, identificare una classe di equivalenza per ciascun elemento
dell’insieme e una invalida EC (Equivalent Class)
Esempio: Se l’ingresso è selezionato da un insieme di N “distinti” elementi allora
occorreranno N + 1 ECs:

–
–
Una valida EC per ciascun elemento dell’insieme {M1}, . .. , {MN};
Una invalida EC per gli elementi fuori dall’insieme {x | x ∉ {M1, . . . , MN}}.
Se si ritiene che il programma maneggia ciascun ingresso valido in modo distinto, allora
occorre definire una valida EC per ciascun ingresso valido.
Esempio: Se l’ingresso viene da un menu allora si definisce una valida EC per ciascun item
del menu.

21
Equivalence partitioning

Se le specifiche indicano N ingressi validi, si devono definire una valida EC e due invalide
EC per ciascun valore N dell’ingresso
–


Se un condizione di ingresso specifica una situazione del tipo “must be”, identificare una
valida EC e una invalida EC.
Esempio: Il primo carattere di un input deve essere numerico allora occorreranno due
EC
–
–

Classe di equivalenza valida {1, . . . , 99};
una valida EC {s | il primo carattere di s è numerico}
una invalida EC {s | il primo carattere non è numerico}
Se gli elementi in una EC sono trattati in modi diversi dal programma, allora la EC deve
essere splittata in EC più piccole.
22
Boundary value testing
 Anche questo criterio è basato su una partizione dei dati di ingresso.
 Le classi di equivalenza possono essere realizzate o in base all’eguaglianza del
comportamento indotto sul programma o in base a considerazioni inerenti il tipo dei
valori d’ingresso.
 Come dati di test sono considerati i valori estremi di ogni classe di equivalenza.
 Questo criterio richiama i controlli sui valori limite tradizionali in altre discipline
ingegneristiche per cui è vera la proprietà del comportamento continuo.
maximal value 
nominal value 
y
d
minimal value  c
a
b
x
23
Boundary value testing
Utilizza come input i valori limite del dominio
Boundary value
 Per input interi nel dominio [a,b], testare
nell’intorno di a and b
maximal value 
nominal value 
y
d
minimal value  c
 # test = per n variabili di input, 4n+1
combinazioni di input
Robustness boundary value
a
b
x
d
 Input fuori dal dominio
 # tests = per n variabili, 6n+1 combinazioni
di input
c
a
b
x
24
Varianti
y
d
Worst-case boundary value
Ipotizza fault multipli
# tests = per n variabili di input
c
n
5 test case
a
b
x
a
b
x
y
Worst-case robustness boundary value
d
 ipotizza fault multipli, test anche fuori dal dominio
 # tests = per n variabili di input
n
test7case
c
25
Decision table testing
 Conosciuto anche come grafo causa effetto
 Rileva difetti relativi ad errori computazionali
 Il dominio di Input è partizionato tramite condizioni
 Ipotesi: variabili dipendenti
 #tests = dipende dalla granuralità di condizioni/azioni
conditions/actions
rule 1
c1: x>=0?
y
c2: x<=y?
y
c3: z even?
_
a1: correct answer type 1
x
a2: correct answer type 2
a3: faulty inputs
rule 2-3
n
n
rule 4
y
n
n
x
rule 5-8
y
- : don’t care
_ : fixed value
x
x
26
Bibliography
 Lecture notes of “Software Testing” (2IW30) course (technisce universiteit
eindhoven) by Judi Romijn (2006).
27