1 Defect testing Lobiettivo: scoprire difetti in un programma Un test ha successo se forza il programma a comportarsi in modo anomalo I test provano la.

Presentazione sul tema: "1 Defect testing Lobiettivo: scoprire difetti in un programma Un test ha successo se forza il programma a comportarsi in modo anomalo I test provano la."— Transcript della presentazione:

1 1 Defect testing Lobiettivo: scoprire difetti in un programma Un test ha successo se forza il programma a comportarsi in modo anomalo I test provano la presenza (non lassenza) di errori: solo un testing esaustivo proverebbe lassenza di difetti.

2 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 3 Dati di test Linsieme di input che devono essere costruiti per testare il sistema Casi di test Linsieme 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 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 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 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 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 8 Il processo di defect testing

9 9 Approcci al defect testing

10 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 11 Black-box testing

12 12 Equivalence partitioning

13 13 Partiziona gli input e gli output del sistema in insiemi equivalenti Se linput è 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 14 Partizioni

15 15 Specifica di una routine di ricerca procedure Search (Key : ELEM ; T: ELEM_ARRAY; Found : in out BOOLEAN; L: in out ELEM_INDEX) ; Pre-condition -- the array has at least one element TFIRST <= TLAST 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, TFIRST >= i <= TLAST, T (i) = Key ))

16 16 Input che soddisfano le precondizioni Input dove una precondizione non vale Input dove lelemento chiave è un membro dellarray Input dove lelemento chiave non è un membro dellarray Partizioni di input

17 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 dellarray vengano visitati Testare il programma con array di lunghezza zero (se consentito dal linguaggio di programmazione)

18 18 Routine di ricerca: partizioni di input

19 19 Routine di ricerca: casi di test Input array( T )Key( )Output( Found, L ) 17 true, 1 170false, ?? 17, 29, 21, 2317true, 1 41, 18, 9, 31, 30, 16, 4545true, 7 17, 18, 21, 23, 29, 41, 3823true, 4 21, 23, 29, 33, 38 25false, ??

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

22 22 White-box testing

23 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 24 1Program statement (input, output); 2var 3x,y : real; 4begin 5read(x); 6read(y); 7if x > 0 then x:=x+10; 8y:=y/x; 9write(x); 10write(y); 11end. 5 6 7 8 9 10 read(x) read(y) x:=x+10 x>0 not(x>0) y:=y/x write(x) write(y) S = {(x = 20, y = 30)} soddisfa il criterio Esempio

25 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 criterio Ma continua a non scoprire il malfunzionamento! Copertura

26 26 Utilizzare valori ai limiti dei campi di variabilità delle decisioni, oltre a valori allinterno Esempio se deve essere x 0, provare con x = 0, oltre che con x > 0 Attitudine fare lavvocato del diavolo Arricchimento del criterio

27 27 1read (x,y); 2if x = 10 then 3x := x - 10 4elsex := |x| +1; 5if y <= 0 then 6y := (y+1)/x 7elsey := x/y; 8... T = {(10, 5), (0, -3)} copre tutte le decisioni Così facendo si coprono i cammini then...else e else...then, non il cammino then...then che genera un malfunzionamento. Esempio

28 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 29 Ricerca binaria (Ada)

30 30 Chiave nellarray Chiave non nellarray 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 31 Ricerca binaria: partizioni di input

32 32 Ricerca binaria: casi di test

33 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 34 Rappresentazione di un grafo di flusso di un programma

35 35

36 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 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 38 Controllo e programmi data-driven case 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 39 Questo tipo di testing va fatto quando vengono integrati moduli o sottosistemi per creare sistemi più grandi Lobiettivo 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 40 Tipi di interfacce Interfacce realizzate con parametri I dati sono trasmessi da una procedura allaltra 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 41 Testare le interfacce

42 42 Errori nelle interfacce Cattivo uso delle interfacce Una componente chiamante chiama unaltra componente e commette un errore nelluso dellinterfaccia di questultima, ad esempio chiamando i parametri nellordine 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 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 lordine in cui le componenti sono attivate