Post on 01-May-2015
1
Defect testing L’obiettivo: scoprire difetti in un programma Un test ha successo se forza il programma a
comportarsi in modo anomalo I test provano la presenza (non l’assenza) di
errori: solo un testing esaustivo proverebbe l’assenza di difetti.
2
I test devono sondare le caratteristiche globali del sistema nel suo insieme più che le singole componenti
Se il sistema è una nuova versionedi un sistema esistente, è più importante testare le vecchie caratteristiche che testare le nuove caratteristiche
Testare le situazioni tipiche è più importante che testare i valori alla frontiera
Priorità nel testing
3
Dati di test L’insieme di input che devono essere costruiti per testare il sistema
Casi di test L’insieme di input per testare il sistema e gli output previsti in corrispondenza di questi input se il sistema soddisfa la sua specifica
Dati di test e casi di test
4
Terminologia
Per definire i Casi di Test devo adottare un criterio:
Criterio C affidabile tutti i test selezionati da C hanno successo o
nessuno lo ha
Criterio C valido qualora P non sia corretto, un T selezionato C che
ha successo
5
Esempio
Se C seleziona solo {0,2} è affidabile, non valido
Se C seleziona tutti i sottoinsiemi di {0,1,2,3,4} è valido, non affidabile
Se C seleziona insiemi che contengono tutti almeno un elemento < 3 è valido e affidabile
program RADDOPPIA .......read (x);y = x*x;write (y);...
6
Elementi di teoria dei test
Teorema di Goodenough e Gerhart
Se
Esiste un C affidabile e valido per P
e
T è selezionato da C
e
T non ha successo su P
allora
P è corretto
7
Elementi di teoria dei test
Teorema di Howden
Non si può costruire meccanicamente (mediante un programma) un test finito che soddisfi un criterio affidabile e valido
8
Il processo di defect testing
Design testcases
Prepare testdata
Run programwith test data
Compare resultsto test cases
Testcases
Testdata
Testresults
Testreports
9
Approcci al defect testing
Interfacetesting
Functionaltesting
Structuraltesting
Sub-systemSystemUnit andmodule
Testingteam
Developmentteam
10
Black-box testing Approccio al testing in cui il sistema è visto come
una “scatola nera” I casi di test sono basati sulla specifica del
sistema La pianificazione può iniziare molto presto nel
processo software
11
Black-box testingIe
Input test data
OeOutput test results
System
Inputs causinganomalousbehaviour
Outputs which revealthe presence ofdefects
12
Equivalence partitioning
System
Outputs
Invalid inputs Valid inputs
13
Partiziona gli input e gli output del sistema in “insiemi equivalenti” Se l’input è un intero di 5 digits tra 10,000 e 99,999,
le classi di equivalenza sono: < 10.000 da 10.000 a 99.999 (compresi) >= 100.000
Scegli i casi di test ai confini di questi insiemi 0, 9.999, 10000, 99.999, 100.000, 150.000
Equivalence partitioning
14
Partizioni
Between 10000 and 99999Less than 10000 More than 99999
999910000 50000
10000099999
Input values
Between 4 and 10Less than 4 More than 10
34 7
1110
Number of input values
15
Specifica di una routine di ricercaprocedure Search (Key : ELEM ; T: ELEM_ARRAY; Found : in out BOOLEAN; L: in out ELEM_INDEX) ;
Pre-condition-- the array has at least one elementT’FIRST <= T’LAST
Post-condition-- the element is found and is referenced by L( Found and T (L) = Key)
or -- the element is not in the array( not Found and
not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))
16
Input che soddisfano le precondizioni Input dove una precondizione non vale Input dove l’elemento chiave è un membro
dell’array Input dove l’elemento chiave non è un membro
dell’array
Partizioni di input
17
Linee guida sul testing (arrays) Testare il programma con array che hanno solo
un singolo elemento Usa array di dimensioni diverse nei diversi test Costruisci i test in modo che gli elementi primo,
mediano e ultimo dell’array vengano visitati Testare il programma con array di lunghezza
zero (se consentito dal linguaggio di programmazione)
18
Routine di ricerca: partizioni di input
Array ElementSingle value In arraySingle value Not in arrayMore than 1 value First element in arrayMore than 1 value Last element in arrayMore than 1 value Middle element in arrayMore than 1 value Not in array
19
Routine di ricerca: casi di test
Input array (T) Key (Key) Output ( Found, L)17 17 true, 117 0 false, ??17, 29, 21, 23 17 true, 141, 18, 9, 31, 30, 16, 45 45 true, 717, 18, 21, 23, 29, 41, 38 23 true, 421, 23, 29, 33, 38 25 false, ??
20
Chiamato talvolta white-box testing I casi di test sono ottenuti a partire dalla
struttura del programma. La conoscenza del programma viene utilzzata per identificare altri ulteriori casi di test
Obiettivo: vagliare tutti i comandi del programma (non tutti i cammini di computazione)
Testing strutturale
21
Criteri White-box
Sono criteri di selezione dei casi di test basati su concetti di “copertura” della struttura interna del programma
Congettura: se un programma è stato poco sollecitato dai dati di test, potenzialmente contiene anomalie
Definito il livello desiderato di “copertura” è possibile valutare quanto progressivamente ci si avvicina all’obiettivo
22
White-box testing
Componentcode
Testoutputs
Test data
DerivesTests
23
1. Copertura delle istruzioni
Obiettivo: esercitare almeno una volta ogni istruzione durante il test Motivazione: se no, ci possono essere computazioni scorrette o
computazioni mai osservate
Copertura
24
1 Program statement (input, output);2 var3 x,y : real;4 begin5 read(x);6 read(y);7 if x > 0 then x:=x+10;8 y:=y/x;9 write(x);10 write(y);11 end.
5
6
78
9
10
read(x)
read(y)
x:=x+10x>0
not(x>0)
y:=y/x
write(x)
write(y)S = {(x = 20, y = 30)} soddisfa il criterio
Esempio
25
2. Copertura delle decisioni
Ogni arco del flusso di controllo deve venire percorso
S = {(x = 20, y = 30), (x = -3, y = 100} soddisfa il criterioMa continua a non scoprire il malfunzionamento!
Copertura
26
Utilizzare valori “ai limiti” dei campi di variabilità delle decisioni, oltre a valori “all’interno”
Esempiose deve essere x 0,
provare con x = 0, oltre che con x > 0
Attitudine “fare l’avvocato del diavolo”
Arricchimento del criterio
27
1 read (x,y);2 if x = 10 then3 x := x - 104 else x := |x| +1;5 if y <= 0 then6 y := (y+1)/x7 else y := x/y;8 ...
T = {(10, 5), (0, -3)} copre tutte le decisioniCosì facendo si coprono i cammini “then...else” e “else...then”, non il cammino “then...then” che genera un malfunzionamento.
Esempio
28
3. Copertura dei cammini
Test strutturale esaustivo: tutti i cammini… ma il numero di cammini è infinito!
Occorre limitare il numero: quali? Criteri empirici per limitare il numero delle iterazioni Il numero dei dati di test tende comunque a crescere in maniera
non controllabile.....
Copertura
29
Ricerca binaria (Ada)procedure Binary_search (Key: ELEM ; T: ELEM_ARRAY ; Found: in out BOOLEAN ; L: in out ELEM_INDEX ) is
- Preconditions-- T’FIRST < =T’LAST and-- forall i: T’FIRST..T’LAST-1, T (i) <= T(i+1)
Bott : ELEM_INDEX := T’FIRST ; Top : ELEM_INDEX := T’LAST ; Mid : ELEM_INDEX;begin L := (T’FIRST + T’LAST ) / 2; Found := T( L ) = Key; while Bott <= Top and not Found loop Mid := (Top + Bott) mod 2; if T( Mid ) = Key then Found := true; L := Mid; elsif T( Mid ) < Key then Bott := Mid + 1; else Top := Mid - 1; end if ;
end loop ;end Binary_search;
30
Chiave nell’array Chiave non nell’array
Array di input con un solo elemento Array di input con numero pari di elementi Array di input con numero dispari di elementi
Ricerca binaria: partizioni di input
31
Mid-point
Elements < Mid Elements > Mid
Equivalence class boundaries
Ricerca binaria: partizioni di input
32
Ricerca binaria: casi di test
Input array (T) Key (Key) Output (Found, L)17 17 true, 117 0 false, ??17, 21, 23, 29 17 true, 19, 16, 18, 30, 31, 41, 45 45 true, 717, 18, 21, 23, 29, 38, 41 23 true, 417, 18, 21, 23, 29, 33, 38 21 true, 312, 18, 21, 23, 32 23 true, 421, 23, 29, 33, 38 25 false, ??
33
Descrivono il flusso di controllo nel programma usati per calcolare la complessità ciclomatica
Complessità = Numero di archi - Numero di nodi +2
Grafi di flusso del programma
34
Rappresentazione di un grafo di flusso di un programma
if-then-else loop-while case-of
35
1
2
3
54
76
98
10
1112
13
(if not Found then...)
(while Bott <= Top loop)
(If T (mid) = Key then...)
(if T (mid) < Key then...)
36
1, 2, 3, 4, 12, 13 1, 2,3, 5, 6, 11, 2, 12, 13 1, 2, 3, 5, 7, 8, 10, 11, 2, 12, 13 1, 2, 3, 5, 7, 9, 10, 11, 2, 12, 13 1, 2, 3, 5, 7, 9, 10, 11, 2, 3, 4, 12, 13 Bisogna costruire dei casi di test in modo che tutti
questi cammini siano percorsi Si può utilizzare un analizzatore dinamico per
verificare che i cammini siano stati eseguiti
Cammini indipendenti
37
Il numero di test per controllare tutti i comandi di controllo è uguale alla complessità ciclomatica
La complessità ciclomatica è uguale al numero di condizioni booleane nel programma
E’ utile se usata con attenzione. Non è sempre adeguata come test e non può essere usata per programmi data-driven
Complessità ciclomatica
38
Controllo e programmi data-drivencase A is when “One” => i := 1 ; when “Two” => i := 2 ; when “Three” => i := 3 ; when “Four” => i := 4 ; when “Five” => i := 5 ; end case ;
Strings: array (1..4) of STRING := (“One”, “Two”, “Three”, “Four”, “Five”); i := 1 ; loop exit when Strings (i) = A ; i := i + 1 ;end loop ;
39
Questo tipo di testing va fatto quando vengono integrati moduli o sottosistemi per creare sistemi più grandi
L’obiettivo in questo caso è trovare errori dovuti alle interfacce o ad assunzioni sulle interfacce che non sono valide
È particolarmente importante nello sviluppo object-oriented, in quanto gli oggetti sono definiti a partire dalle loro interfacce
Testare le interfacce
40
Tipi di interfacce Interfacce realizzate con parametri
I dati sono trasmessi da una procedura all’altra
Interfacce a memoria condivisa Due o più procedure condividono la stessa memoria
Interfacce procedurali Sottosistemi incapsulano un insieme di procedure
che devono essere chiamate da altri sottosistemi
Interfacce a passaggio di messaggi I sottosistemi richiedono servizi da altri sottosistemi
41
Testare le interfacceTestcases
BA
C
42
Errori nelle interfacce Cattivo uso delle interfacce
Una componente chiamante chiama un’altra componente e commette un errore nell’uso dell’interfaccia di quest’ultima, ad esempio chiamando i parametri nell’ordine sbagliato
Incomprensione di interfacce Una componente chiamante fa delle assunzioni sul
comportamento della componente chiamata che non sono valide
Errori di temporizzazione La componente chiamante e la componente chiamata operano a
velocità diversa e ciò impedisce di utilizzare informazione aggiornata
43
Linee guida per testare interfacce Progetta i test in modo che i parametri attuali delle
procedure siano agli estremi del loro rango Testa sempre parametri di tipo riferimento con valore
NIL Progetta test che causano il fallimento della
componente Usa uno stress testing nel sistema di scambio di
messaggi Nei sistemi a memoria condivisa, cambia l’ordine in cui
le componenti sono attivate