Verifica parte IIC. Rif. Ghezzi et al

Transcript

1 Verifica parte IIC Rif. Ghezzi et al

2 Sommario (recap) Test In piccolo White box Black box Condizioni di confine Problema dell' Oracolo In grande Test di modulo Test di integrazione Test di Sistema Test di Accettazione

3 Test funzionali (black box) l Il test white-box non rileva la mancata implementazione di funzionalità. l Test black-box, basati sulla specifica di un programma, anziché sulla loro implementazione. l I test set si individuano in base a casistiche ricavate dalla specifica (formale o informale). Verifica 2C 3

4 Esempio di specifica Il programma riceve in ingresso una registrazione che descrive una fattura (viene fornita una descrizione dettagliata del formato della registrazione). La fattura deve essere inserita in un file di fatture ordinato per data. La fattura deve essere inserita nella posizione corretta del file. Se esistono altre fatture che riportano la stessa data, la nuova fattura deve essere inserita dopo l ultima già presente. Inoltre devono essere eseguite alcune verifiche di coerenza: il programma dovrebbe verificare se il cliente è già presente nel corrispondente archivio dei clienti, se i dati del cliente nei due file corrispondono, etc. Verifica 2C 4

5 Approccio intuitivo al test 1. Si fornisce una fattura la cui data corrisponde alla data corrente 2. Si fornisce una fattura la cui data precede la data corrente (illegale?). Sottocasi: 1. Fattura con stessa data di una fattura già presente 2. Fattura con data diversa da tutte quelle già presenti 3. Si forniscono diverse fatture scorrette Verifica 2C 5

6 Tecniche sistematiche black-box l Test guidato da specifiche logiche l Test guidato da sintassi l Test basato su tavole di decisione l Test basato su grafi causa-effetto Verifica 2C 6

7 Specifica logica l x, z: variabili di tipo invoice (strutture con campi customer, amount, date, etc.) l current_date: il giorno in cui un operazione viene eseguita l f: variabile di tipo invoice_file. f(i) i-esimo elemento di f. l file di tipo customer_file, etc. Verifica 2C 7

8 Specifica logica l dato un file f di record (senza ripetizioni) e un record x, pos(x,f) restituisce la posizione i di x in f l predicato sorted_by_date con argomento di tipo invoice_file: sorted_by_date(y) º" i,j in Integers (i<j f(i).date f(j).date) l result e warning: variabili booleane che indicano rispettivamente successo e anomalia di un operazione di inserimento Verifica 2C 8

9 Specifica logica for all x in Invoices, f in Invoice_Files {sorted_by_date(f) and not exist j, k (j k and f(j) =f(k)} insert(x, f) {sorted_by_date(f) and for all k (old_f(k) = z implies exists j (f(j) = z)) and for all k (f(k) = z and z x) implies exists j (old_f(j) = z) and exists j (f(j).date = x.date and f(j) x) implies j < pos(x, f) and result º x.customer belongs_to customer_file and warning º (x belongs_to old_f or x.date < current_date or...) } Verifica 2C 9

10 Riscrittura della postcondizione TRUE implies sorted_by_date(f) and for all k old_f(k) = z implies exists j (f(j) = z) and for all k (f(k) = z and z x) implies exists j (old_f(j) = z) and (x.customer belongs_to customer_file) implies result and not (x.customer belongs_to customer_file and...) implies not result and x belongs_to old_f implies warning and x.date < current_date implies warning and... Verifica 2C 10

11 Applicazione del criterio di copertura delle condizioni l Qualunque caso di test: verifica che il file contenga solo le fatture precedenti e quella nuova, e che sia ordinato l Almeno un caso di test in cui il campo customer di una fattura è presente in customer_file, e uno in cui è assente l Almeno un caso di test in cui il campo date della fattura è lo stesso di una fattura esistente, e uno in cui non lo è Verifica 2C 11

12 Test syntax-driven l Utilizzato nella verifica di compilatori (e di altri software basati su linguaggi formali). l Grammatica utilizzata per definire insiemi di test. l Esempio: test set in cui ogni produzione sintattica BNF è utilizzata almeno una volta. Verifica 2C 12

13 Test syntax-driven l Interprete per il seguente linguaggio: <expression> ::= <expression> + <term> <expression> - <term> <term> <term> ::= <term> * <factor> <term> / <factor> <factor> <factor> ::= ident ( <expression>) Verifica 2C 13

14 Test syntax-driven l Applicazione del principio di completa copertura alle regole della grammatica l Generazione di un test per ogni regola della grammatica l Alcuni test possono coprire più di una regola l La specifica è formale, quindi la generazione del test può essere automatizzata Verifica 2C 14

15 Esempio l Regola da testare <term> ::= <term> * <factor> l Produzione di un caso di test: l <expression> Þ l <expression> + <term> Þ Partenza dallo scopo della grammatica Utilizzo della regola l <expression> + <term> * <factor> Þ l <term> + <term> * <factor> Þ l <factor> + <factor> * <factor> Þ l ident + ident * ident Verifica 2C 15

16 Test basato su tabelle di decisione Le tabelle di decisione sono un formalismo semplice per descrivere come combinazioni diverse di ingressi possono generare uscite diverse Verifica 2C 17

17 Test basato su tabelle di decisione: specifica Il word processor può presentare le porzioni di testo in tre formati diversi: testo normale (plain, p), testo in grassetto (boldface, b) e testo in corsivo (italics, i). I seguenti comandi possono essere applicati a ciascuna porzione del testo: rendere il testo normale (P), rendere il testo in grassetto (B), rendere il testo in corsivo (I), enfatizzare (E) e super-enfatizzare (SE). Esistono, inoltre, comandi per specificare dinamicamente il fatto che E possa significare o B o I (questi comandi vengono denotati rispettivamente come E = B e E = I). Analogamente si può specificare dinamicamente che SE indichi B (comando SE = B), I (comando SE = I) o B e I (comando SE = B + I). Verifica 2C 18

18 Tabella di decisione P B I E SE E = B E = I SE = B SE = I SE = B + I ac tion * * * * * * * * * * * * * * * p b i b i b i b,i b,i Righe rappresentano condizioni Colonne rappresentano regole: azioni come risultato delle condizioni Esplosione di casi di tesi Verifica 2C 19

19 Test l Applicazione del principio di completa copertura: generazione dei test in modo da esercitare ogni colonna. l Applicazione esaustiva può essere molto costosa: in generale, a n condizioni possono corrispondere 2 n colonne Verifica 2C 20

20 Grafi causa-effetto l n condizioni, m effetti l Fissato un ordine per le condizioni, (es.: B, I, P, E, SE, E=B, E=I, SE=B, SE=I, SE=B+I) un comando di ingresso (combinazione di condizioni) si può rappresentare come n-pla di variabili booleane (es.: E=B ed E come <f,f,f,t,f,t,f,f,f,f>) l Fissato un ordine per gli effetti (es.: b, p, i), un uscita (combinazione di effetti) come m-pla di variabili booleane (es. p come <f,f,t>) Verifica 2C 21

21 Grafi causa-effetto Relazione ingresso-uscita come funzione booleana (es. grafico and/or) B I P O R b E E = B SE A N D i E = I SE = B SE = I O R A N D p SE = B + I Verifica 2C 22

22 Vincoli fra variabili logiche l e, al più uno; i, almeno uno; o, uno e uno solo; l a richiede (implies) b; a maschera (implies not) b Verifica 2C 23

23 Grafo con vincoli (causa-effetto) B m I P m O R b E E = B A N D i SE E = I SE = B SE = I O R A N D m p m SE = B + I Verifica 2C 24

24 Criterio di copertura l Generare tutte le possibili combinazioni di input e controllare l output rispetto alla specifica. l Esempio: il comando E ed E=B dovrebbe dare l uscita b. l Il grafo può mostrare incoerenza (uscita corrispondente a ingressi inammissibili) e incompletezza (nessun ingresso porta a un uscita ammissibile) Verifica 2C 25

25 Riduzione del numero di test l Per ogni combinazione dei valori di uscita, generazione di alcune combinazioni di input che li generano (scelte euristicamente) e propagazione all indietro. l Nodo OR con output t: l combinazioni con un solo input vero l Nodo AND con output f: l combinazioni con un solo input falso Verifica 2C 26

26 Test di condizioni di confine l Partizione dei domini di input in classi l Sia per il testing white-box che black-box, abbiamo supposto che il comportamento dei programmi per tutti gli elementi di una classe sia simile l Molti errori di programmazione (come l uso di < al posto di ) hanno effetti al confine fra le classi. l Criterio: utilizzo di casi di test al confine fra le classi. Verifica 2C 27

27 Esempio if x > y then else S1 S2 l Suddividendo il dominio nei due casi x>y e x y, spesso si scelgono valori tali che x > y o x < y, trascurando x = y, che sarebbe significativo nel caso dell uso di > al posto di. Verifica 2C 28

28 Il problema dell oracolo l Oracolo: entità in grado di dire se un output è corretto per un dato input. l Necessario per l attività di test. l L unica implementazione dell oracolo potrebbe essere il programma stesso! l Spesso la correttezza è definita in base a proprietà facili da verificare, che possono essere utilizzate come oracolo. Verifica 2C 29