13: Il test del software. 13Test.1

Транскрипт

1 13: Il test del software 13Test.1

2 Concetti fondamentali Costo estremamente elevato Filosofia distruttiva Eseguire un programma con l intento di trovare degli errori; Un caso di test e ben studiato se ha un alta probabilita di scoprire un errore Un test ha successo se scopre un errore rimasto sino a quel momento nascosto Un test non prova l assenza di difetti ma mostra (eventualmente) qualcuno di quelli presenti Principi generali I test vanno condotti tenendo in considerazione i requisiti utente La fase di test va progettata e pianificata in anticipo Le attivita di test partono dall analisi delle singole funzioni per coinvolgere l intera struttura del progetto Un attivita di test esaustiva e impossibile in molti casi (tipicamente esponenziale) Le attivita di test dovrebbero essere condotte da terzi 13Test.2

3 Progettare il SW pensando alla fase di test SW: Praticabile (pochi bug, non bloccanti, decomposizione) Osservabile (stati interni e variabili, funzioni semplici tra I e O) Controllabile (codice raggiungibile, accesso alle variabili) Decomponibile (moduli indipendenti tra loro) Semplice (funzioni, codice, struttura) Stabile (pochi cambiamenti, controllati ed indipendenti dai test) Comprensibile(progetto, relazioni tra moduli, documentazione) 13Test.3

4 Difetti, errori e malfunzionamenti Il difetto e' una caratteristca fisica di una porzione di codice o di una sezione di un testo di documentazione L'errore e' l'azione umana che ha generato il difetto Il malfunzionamento e' la conseguenza di un difetto che si manifesta durante l'utilizzo del prodotto software 13Test.4

5 CLASSIFICAZIONE DEI MALFUNZIONAMENTI I malfunzionamenti si possono suddividere in quattro categorie: Funzionali Strutturali Relativi alla interfaccia Mancato rispetto dei requisiti non funzionali 13Test.5

6 Tecniche di progettazione dei casi di test Evidenziare un numero prefissato di difetti minimizzando il costo Utilizzare al meglio un budget prefissato Cercare il minimo della funzione globale del costo costo CNC Costo della non conformità CNC+COC Punto di costo minimo COC Costo della conformità Basso impegno in attività di prevenzione e verifica Alto 13Test.6

7 ARTICOLAZIONE DEL PROCESSO DI TEST Progettazione dei casi di test Progettazione delle condizioni di test: individuare, tra tutte le possibili situazioni che si possono presentare durante l'utilizzo del prodotto, le sole che si intende riprodurre nel test; Individuazione dei casi di test: individuare, per ogni condizione di test e per ciascun dato di input, l'insieme dei valori di tale dato (classe di equivalenza) che rendono vera la condizione; Scelta dei valori di input: scegliere per ciascun caso di test (o classe di casi di test equivalenti) uno specifico valore per ciascun dato di input. Esecuzione del software per ciascun caso di test e registrazione del comportamento del prodotto Confronto tra il comportamento atteso e quello reale 13Test.7

8 TECNICHE STRUTTURALI (WHITE BOX) Tecniche di copertura dei cammini Tecniche di integrazione Completano il quadro le tecniche di controllo dei requisiti non funzionali 13Test.8

9 TECNICHE FUNZIONALI (BLACK BOX) Vengono utilizzate per: Determinare il manifestarsi dei malfunzionamenti funzionali Evidenziare il mancato rispetto di qualche requisito non funzionale 13Test.9

10 UN BREVE CENNO VA COMUNQUE DEDICATO AD ALCUNE TECNICHE DI ANALISI STATICA (CHE RIENTRANO PIÙ PROPRIAMENTE NELLE ATTIVITÀ DI CONTROLLO QUALITÀ) HANNO LO SCOPO DI INDIVIDUARE DIFETTI MEDIANTE UN ESAME DEL PRODOTTO, SENZA ESECUZIONE DEL SOFTWARE LE PIÙ NOTE TRA QUESTE TECNICHE SONO: DESK-CHECKING WALKTROUGH TEMPORALMENTE LA LORO APPLICAZIONE PRECEDE L ESECUZIONE DEI VERI E PROPRI CASI DI TEST 13Test.10

11 DESK-CHECKING IL PRODOTTO OGGETTO DEL TEST VIENE ESAMINATO DA UNA SOLA PERSONA L ESAME VIENE EFFETTUATO: RICERCANDO LA PRESENZA DEI DIFETTI CONTENUTI IN UN' APPOSITA LISTA SIMULANDO LE ESECUZIONI A CUI DAREBBERO LUOGO SPECIFICI VALORI DI INPUT 13Test.11

12 WALKTROUGH IL PRODOTTO OGGETTO DI CONTROLLO VIENE ESAMINATO DA UN GRUPPO DI PERSONE LE SINGOLE PERSONE HANNO VISIONATO IL PRODOTTO PRIMA DI INCONTRARSI IN GRUPPO VENGONO INDIVIDUATI ALCUNI INSIEMI SIGNIFICATIVI DI VALORI DI INPUT AL PRODOTTO A FRONTE DI CIASCUN INSIEME VIENE SIMULATA L' ESECUZIONE DEL PRODOTTO PUÒ ESSERE VISTO COME UN PARTICOLARE TIPO DI SEDUTA DI REVISIONE 13Test.12

13 TESTING DI TIPO WHITE BOX Copertura delle istruzioni Copertura delle decisioni Copertura delle condizioni Copertura delle decisioni/condizioni Copertura di una base di cammini indipendenti 13Test.13

14 Copertura delle istruzioni Occorre individuare un insieme di casi di test sufficiente a far eseguire almeno una volta tutte le istruzioni E un criterio necessario ma non sufficiente per un test "ragionevole" Es.... float x,y; A scanf( %f %f,&x, &y); B if (x! = 0 ) C x=x+10; D y=y/x; E printf( %f %f, x, y)... x == 0 A B C x!= 0 Il caso di test {x!=0 ; y=qualsiasi} copre le istruzioni D E 13Test.14

15 COPERTURA DELLE DECISIONI Occorre individuare un insieme di casi di test sufficiente a garantire che ciascuna decisione assuma i valori vero e falso almeno una volta. Include propriamente la copertura delle istruzioni (ma non e vero il viceversa) Es.... float x,y; A scanf( %f %f,&x, &y); B if (x! = 0 ) C x=x+10; D y=y/x; E printf( %f %f, x, y)... Il caso di test {x=20 ; y=30} {x=0 ; y=30} copre le decisioni (e quindi le istruzioni) e scopre l errore di divisione per 0 in D x == 0 A B D E C x!= 0 13Test.15

16 COPERTURA DELLE DECISIONI (2) Se le condizioni sono composte (AND, OR) la copertura delle decisioni puo rivelarsi insufficiente Es.... float x,y; A scanf( %f %f,&x, &y); B if (x = = 0 y>0) C y=y/x; D else y=y+2/x; E printf( %f %f, x, y)... False D E A B True C Il caso di test {x= 5 ; y= 5} {x= 5 ; y= -5} copre le decisioni ma non scopre il rischio di divisione per 0 in C. 13Test.16

17 COPERTURA DELLE CONDIZIONI Far assumere ad ogni singola variabile che appare nelle condizioni i valori T e F Es.... float x,y; A scanf( %f %f,&x, &y); B if (x == 0 y>0) C y=y/x; D else x=y+2/x; E printf( %f %f, x, y)... False D E A B True C Il caso di test {x= 0 ; y= 5} {x= 5 ; y= -5} copre le condizioni e scopre la divisione per 0 in C ma non percorre D (non copre le decisioni) 13Test.17

18 Copertura decisioni e condizioni Far assumere ad ogni singola variabile che appare nelle condizioni i valori T e F Far assumere ad ogni decisione i valori T e F Es.... float x,y; A scanf( %f %f,&x, &y); B if (x= = 0 y>0) C y=y/x; D else x=y+2/x; E printf( %f %f, x, y)... False D E A B True C Il caso di test {x= 0 ; y= -5} {x= 5 ; y= 5} {x= 5 ; y= -5} copre le decisioni e condizioni 13Test.18

19 WhiteBox: Basis Path Testing Test che implica la copertura delle condizioni e delle decisioni introdotto da McCabe nel 76. Utilizza la complessita ciclomatica per individuare un upperbound della complessita. Si individuano i cammini di base e li si testano tutti numero ciclomatico V = E - N + 2 (E=numero di archi, N=numero di nodi) oppure V = R (R=numero di regioni) oppure V = P+1 (P=numero nodi predicato) until sequenza istruzioni if semplice while case 13Test.19

20 If composto if (a b) x; else y; if (a && b) x; else y; a==f a a==t a==t a a==f b==f b b==t x b==t b b==f y y x x y Test.20

21 nodo predicato nodo Cammini e regioni D E A B C arco while ( ) { if ( ) { } else { } } F regione V= = 3 Cammini A-F A-B-D-E-A-F A-B-C-E-A-F 13Test.21

22 Esempio Es.... float x,y; A scanf( %f %f,&x, &y); B if (x= = 0 y>0) C y=y/x; D else x=y+2/x; E printf( %f %f, x, y)... x!= 0 A B x == 0 y>0 B y<=0 C D E C Il caso di test {x=0 ; y=-5} {x=5 ; y=5} {x=5 ; y=-5} copre tutti i cammini base (e quindi le decisioni e condizioni) V=8-7+2=3 A-B-C-E A-B-B -D-E A-B-B -C-E 13Test.22

23 Alcune considerazioni Se prevediamo iterazioni nei cammini il problema diventa intrattabile Occorre quindi restringere il tiro limitare il numero delle iterazioni dei cicli ad n (n-copertura dei cicli) eseguire solo alcuni cicli limitare il numero dei cammini da esplorare tramite pesi sugli archi e funzioni da massimizzare probabilita di esecuzione occupazione di risorse (memoria/tempo) limitare il numero dei cammini individuando i cammini che definiscono ed usano le variabili del programma (Data Flow Testing) definizione del valore di una variabile uso di tale valore in un test 13Test.23

24 Data Flow Testing B... A int x,y,a,b; B scanf( %d %d,&x, &y); C a=x; D b=y E while (a!=b) F if(a>b) G a=a-b; H else b=b-a; I printf( %d,a);... a!=b F a>b G C D E a<=b H a==b I Per x ed y non occorre eseguire il ciclo (0-copertura) per la definizione di a e b occorre eseguire 1 volta il ciclo (1-copertura) per la definizione ed uso di a e b occorre eseguire 2 volte il ciclo (2-copertura) 13Test.24

25 TECNICHE FUNZIONALI (BLACK BOX) La progettazzione dei casi di test avviene prescindendo dalla conoscenza della struttura interna del prodotto ed operando solo sulle specifiche. Sono impiegate nella fase finale delle attivita di test a complemento di quelle white box FANNO PARTE DI TALI TECNICHE: TECNICA DI COPERTURA DELLE FUNZIONALITA TECNICA DI COPERTURA DELLE CLASSI DI EQUIVALENZA TECNICA DI ANALISI DEI VALORI ESTREMI 13Test.25

26 TECNICA DI COPERTURA DELLE FUNZIONALITA Lo scopo della fase di test e verificare che un prodotto sw: faccia cio' che si supponeva dovesse fare; non faccia cio' che si supponeva non dovesse fare. Per sapere quello che un prodotto SW dovrebbe o non dovrebbe fare occorre riferirsi alle sue specifiche: specifiche formali specifiche informali 13Test.26

27 ...TECNICA DI COPERTURA DELLE FUNZIONALITA Occorre analizzare e dividere le specifiche in modo da definire con esattezza: Quali sono le funzioni elementari che il prodotto deve svolgere e per ciascuna di esse se la funzionalita' e' testabile; se non lo e' quale e' la causa. Le funzionalita' individuate devono avere le seguenti due caratteristiche: Indipendenza: non esiste nessun altra funzionalita che sia sempre esercitata o non esercitata contemporaneamente alla funzionalita in questione Elementarita : non e divisibile in sottofunzionalita esercitabili indipendentemente 13Test.27

28 ...TECNICA DI COPERTURA DELLE FUNZIONALITA Quindi: - Identificare ogni funzionalita nelle specifiche - Identificare le combinazioni di funzionalita presenti nelle specifiche - Rendere ciascuna funzionalita (o combinazione) accessibile ad un test indipendente - Assegnare un identificativo univoco a ciascuna funzionalita - Collegare ciascuna funzionalita ad un caso di test finale - Identificare i requisiti non funzionali da verificare con il test - Procedere rispetto a tali requisiti in modo analogo a quanto definito per le funzionalita. 13Test.28

29 Tecniche basate sull utilizzo di grafi Per la copertura delle specifiche si utilizzano, tipicamente, formalismi basati su grafi Uno tra i piu usati e detto grafo causa-effetto: le specifiche di ingresso vengono ridotte a condizioni booleane, rappresentanti fatti (dati) di ingresso e uscita (e.g., cliente e di riguardo, puo pagare con assegno) fatti elementari corrispondenti a dati di ingresso possono corrispondere a fatti di uscita (cliente di riguardo=si implica paga con assegno=si) nel disegnare un grafo si utilizzano i connettivi logici AND, OR, NOT e possibile ridurre tali grafi in forma matriciale, utile per generare le opportune sequenze di ingresso ad esempio se i fatti A, B, C verificandosi congiuntamente causano l effetto D il grafo corrispondente sara del tipo: A B C AND D A=conto <X B=in possesso di un documento C=l assegno non risulta rubato D=puo pagare con assegno A B C D Test.29

30 ...Tecniche basate sull utilizzo di grafi Altri formalismi sono utilizzati per: modellare transazioni modellare automi a stati finiti flusso di dati (Data Flow) temporizzazioni La tecnica utilizzata e sempre del tipo: verificare che le relazioni tra nodi siano soddisfatte (copertura dei cammini) 13Test.30

31 TECNICA DI COPERTURA DELLE CLASSI DI EQUIVALENZA ESSENDO IMPOSSIBILE IL TESTING ESAUSTIVO DOBBIAMO INDIVIDUARE IL SOTTOINSIEME DEI DATI DI INGRESSO CON LA MAGGIORE PROBABILITÀ DI SCOPRIRE ERRORI. UN BUON CASO DI TEST, OLTRE AD AVERE UNA RAGIONEVOLE PROBABILITÀ DI TROVARE UN ERRORE, DOVREBBE: RIDURRE IL NUMERO DI ALTRI CASI DI TEST DA SVILUPPARE RAPPRESENTARE UN INTERO INSIEME DI CASI DI TEST, AL DI LÀ DEGLI EFFETTIVI VALORI DI INGRESSO 13Test.31

32 TECNICA DI COPERTURA DELLE CLASSI DI EQUIVALENZA LE DUE PROPRIETÀ SI RIFERISCONO AD OBBIETTIVI DIVERSI: MINIMIZZARE IL NUMERO TOTALE DI CASI DI TEST CERCARE CASI DI TEST SIGNIFICATIVI ED AFFIDABILI A QUESTO SCOPO, IL DOMINIO DI INGRESSO VA RIPARTITO IN UN NUMERO FINITO DI CLASSI DI EQUIVALENZA: SOTTOINSIEME DEI DATI DI INPUT TALE CHE IL TEST DI UN SUO ELEMENTO SIA EQUIVALENTE AL TEST DI OGNI ALTRO ELEMENTO DELLA STESSA CLASSE (STESSO COMPORTAMENTO DEL PRODOTTO SOFTWARE). 13Test.32

33 TECNICA DI COPERTURA DELLE CLASSI DI EQUIVALENZA 1. IDENTIFICARE UN INSIEME DI CONDIZIONI INTERESSANTI DA SOTTOPORRE A TEST (CONSEGUIMENTO DEL SECONDO DEI DUE PRECEDENTI OBBIETTIVI). IN QUESTO MODO SI INDIVIDUANO LE CLASSI DI EQUIVALENZA. 2. DEFINIRE IL MINIMO INSIEME DI CASI DI TEST IN GRADO DI COPRIRE TALI CONDIZIONI (CONSEGUIMENTO DEL PRIMO OBBIETTIVO) ESEMPIO UN PROGRAMMA RICEVE COME INPUT ESTERNO TRE VALORI, CHE RAPPRESENTANO LA LUNGHEZZA DEI LATI DI UN TRIANGOLO. IL PROGRAMMA DEVE INVIARE UN MESSAGGIO CHE INDIVIDUI IL TIPO DI TRIANGOLO (EQUILATERO, ISOSCELE O SCALENO) 13Test.33

34 TECNICA DI COPERTURA DELLE CLASSI DI EQUIVALENZA ESEMPIO A.CLASSI DI EQUIVALENZA ESTRATTE DALLE SPECIFICHE DEL PROGRAMMA TRIANGOLO : 1. TRE NUMERI INTERI MAGGIORI DI ZERO 2. TRE NUMERI INTERI TALI CHE LA SOMMA DI DUE DI ESSI SIA SEMPRE MAGGIORE DEL TERZO 3. TRE NUMERI UGUALI IL CASO DI TEST A = 2; B = 2; C = 2 COPRE LE TRE CLASSI 13Test.34

35 IDENTIFICAZIONE DELLE CLASSI LE CLASSI DI EQUIVALENZA SONO PARTIZIONI (NON MUTUAMENTE ESCLUSIVE) DEL DOMINIO DI INGRESSO A FRONTE DI CONDIZIONI SUI DATI DI INPUT. LE CLASSI POSSONE ESSERE: - VALIDE (QUANDO RAPPRESENTANO VALORI DI INPUT VALIDI) - NON VALIDE 13Test.35

36 IDENTIFICAZIONE DELLE CLASSI LE CLASSI VENGONO IDENTIFICATE CONSIDERANDO ATTENTAMENTE OGNI CONDIZIONE DI INGRESSO. DA UN PERIODO, O DA UNA FRASE, NELLE SPECIFICHE (QUANDO LE CONDIZIONI DI INGRESSO NON SONO ESSE STESSE FORMALIZZATE) DERIVANO UNA PIÙ CLASSI VALIDE, UNA O PIÙ CLASSI NON VALIDE. UNA VOLTA IDENTIFICATE LE CLASSI VANNO ELENCATE E A CIASCUNA VA ATTRIBUITO UN CODICE IDENTIFICATIVO. I CRITERI UTILI PER LA RICERCA POSSONO ESSERE LA CONSIDERAZIONE DI: INTERVALLI DI VALORI NUMERO DI VALORI INSIEMI DI VALORI CONDIZIONI VINCOLANTI 13Test.36

37 INTERVALLI DI VALORI SE UNA CONDIZIONE DI INGRESSO SPECIFICA UN INTERVALLO DI VALORI VANNO IDENTIFICATE: UNA CLASSE DI EQUIVALENZA VALIDA (PER I VALORI COMPRESI NELL INTERVALLO) DUE CLASSI DI EQUIVALENZA NON VALIDE (UNA PER I VALORI INFERIORI ALL ESTREMO DI VARIAZIONE MINIMO, L ALTRA PER I VALORI SUPERIORI ALL ESTREMO DI VARIAZIONE MASSIMO) CONDIZIONI ESTERNE VALIDE CLASSI DI EQUIVALENZA NON VALIDE VALORE DEL CODICE CLIENTE FRA 1 E Ø CODICE CLIENTE Ø 999 CODICE CLIENTE < CODICE CLIENTE > Test.37

38 NUMERO DI VALORI SE UNA CONDIZIONE DI INGRESSO SPECIFICA IL NUMERO DI VALORI VANNO IDENTIFICATE: UNA CLASSE DI EQUIVALENZA VALIDA (PER UN NUMERO COMPRESO FRA IL MINIMO ED IL MASSIMO SPECIFICATI) DUE CLASSI DI EQUIVALENZA NON VALIDE (UNA PER I NUMERI INFERIORI AL MINIMO, L ALTRA PER I NUMERI SUPERIORI AL MASSIMO) CONDIZIONI ESTERNE VALIDE CLASSI DI EQUIVALENZA NON VALIDE NUMERO DI PRODOTTI IN UN SINGOLO ORDINE NON PUO ESSERE SUPERIORE A 6 1 Ø N.RO PRODOTTI Ø 6 N.RO PRODOTTI < N.RO PRODOTTI > Test.38

39 INSIEMI DI VALORI SE UNA CONDIZIONE DI INGRESSO SPECIFICA UN INSIEME DI VALORI VANNO IDENTIFICATE: TANTE CLASSI DI EQUIVALENZA VALIDE QUANTI SONO GLI ELEMENTI DELL INSIEME (SE C È MOTIVO DI RITENERE CHE CIASCUNO DEGLI ELEMENTI È TRATTATO DIVERSAMENTE, ALTRIMENTI CONVIENE RAGGRUPPARE GLI ELEMENTI) UNA CLASSE DI EQUIVALENZA NON VALIDA (PER UN ELEMENTO NON APPARTENENTE ALL INSIEME) CONDIZIONI ESTERNE VALIDE CLASSI DI EQUIVALENZA NON VALIDE TIPO DI CLIENTE: TIPO CL. = PRIVILEGIATO TIPO CL. = DIFFICILE PRIVILEGIATO, NORMALE O 1 POTENZIALE 4 TIPO CL. = NORMALE 2 TIPO CL. = POTENZIALE 3 13Test.39

40 CONDIZIONI VINCOLANTI SE UNA CONDIZIONE DI INGRESSO SPECIFICA UNA SITUAZIONE DEL TIPO DEVE ESSERE, VANNO IDENTIFICATE: UNA CLASSE DI EQUIVALENZA VALIDA (PER GLI ELEMENTI CHE VERIFICANO LA CONDIZIONE) UNA CLASSE DI EQUIVALENZA NON VALIDA (PER GLI ELEMENTI CHE NON VERIFICANO LA CONDIZIONE). CONDIZIONI ESTERNE VALIDE CLASSI DI EQUIVALENZA NON VALIDE IL TIPO DI PRODOTTO DEVE ESSERE FABBRICATO TIPO PRODOTTO = FABBRICATO TIPO PRODOTTO = 1 ACQUISTATO 2 13Test.40

41 PROGETTAZIONE DEI CASI DI TEST OBBIETTIVI: MINIMIZZARE IL NUMERO COMPLESSIVO DI CASI DI TEST OTTENERE CASI DI TEST SIGNIFICATIVI (AFFIDABILI) I DUE OBBIETTIVI POSSONO ESSERE CONTRASTANTI 13Test.41

42 PROGETTAZIONE DEI CASI DI TEST CLASSI VALIDE PROGETTARE TANTI CASI DI TEST DA COPRIRE TUTTE LE CLASSI DI EQUIVALENZA VALIDE, CON IL VINCOLO CHE CIASCUN CASO DI TEST INCLUDA IL MAGGIOR NUMERO POSSIBILE DI CLASSI. TALVOLTA QUESTO CRITERIO PUÒ CONTRASTARE LA FACILITÀ DI LOCALIZZAZIONE DEGLI ERRORI 13Test.42

43 CLASSI VALIDE CONDIZIONI ESTERNE 1. VALORE DEL CODICE CLIENTE FRA 1 E NUMERO DI PRODOTTI NON SUPERIORE A 6 3. IL TIPO PRODOTTO DEVE ESSERE FABBRICATO VALIDE ESEMPIO: 1 Ø CODICE CLIENTE Ø Ø N. RO PROD. Ø 6 (4) TIPO PRODOTTO = FABBRICATO CLASSI DI EQUIVALENZA (7) (1) NON VALIDE COD. CL. < 1 (2) COD. CL. > 999 (3) N.RO PROD. < 1 (5) N.RO PROD. > 6 (6) TIPO PROD. = ACQUISTATO (8) IL CASO DI TEST: COD. CLIENTE = 5 N.RO DI PROD. = 4 TIPO PROD. = FABBRICATO COPRE LE CLASSI (1), (4), (7). 13Test.43

44 PROGETTAZIONE DEI CASI DI TEST CLASSI NON VALIDE PROGETTARE TANTI CASI DI TEST DA COPRIRE TUTTE LE CLASSI DI EQUIVALENZA NON VALIDE, CON IL VINCOLO CHE CIASCUN CASO DI TEST COPRA UNA ED UNA SOLA DELLE CLASSI NON VALIDE. LE CLASSI NON VALIDE VANNO COPERTE INDIVIDUALMENTE PER EVITARE MASCHERAMENTI FRA ERRORI 13Test.44

45 CLASSI NON VALIDE CONDIZIONI ESTERNE 1. VALORE DEL CODICE CLIENTE FRA 1 E 999 VALIDE 1 Ø CODICE CLIENTE Ø 999 CLASSI DI EQUIVALENZA NON VALIDE COD. CL. < 1 (2) (1) COD. CL. > 999 (3) 2. NUMERO DI PRODOTTI NON SUPERIORE A 6 3. IL TIPO PRODOTTO DEVE ESSERE FABBRICATO 1 Ø N. RO PROD. Ø 6 (4) TIPO PRODOTTO = FABBRICATO (7) N.RO PROD. < 1 (5) N.RO PROD. > 6 (6) TIPO PROD. = ACQUISTATO (8) I CASI DI TEST E LE CLASSI COPERTE SONO: (2) (3) (5) (6) (8) COD. CLIENTE = N.RO DI PROD. = TIPO PROD. = (1) (1) (1) (1) (2) DOVE (1) = FABBRICATO, (2) = ACQUISTATO 13Test.45

46 TECNICA DI ANALISI DEI VALORI ESTREMI L ESPERIENZA MOSTRA CHE I CASI DI TEST CHE ESPLORANO CONDIZIONI ESTREME SONO MOLTO PRODUTTIVI LE CONDIZIONI ESTREME (O LIMITE) SONO QUELLE SITUAZIONI DIRETTAMENTE SUGLI ESTREMI IMMEDIATAMENTE AL DI SOPRA IMMEDIATAMENTE AL DI SOTTO DEGLI ESTREMI DI CLASSI DI EQUIVALENZA D INGRESSO E DI USCITA 13Test.46

47 TECNICA DI ANALISI DEI VALORI ESTREMI L ANALISI DEI VALORI ESTREMI DIFFERISCE DALLA PARTIZIONE IN CLASSI DI EQUIVALENZA PER DUE ASPETTI 1. VENGONO SCELTI COME RAPPRESENTATIVI DELLA CLASSE DI EQUIVALENZA UNO O PIÙ VALORI IN UN INTORNO DI CIASCUN ESTREMO 2. I CASI DI TEST SONO DERIVATI CONSIDERANDO ANCHE LO SPAZIO DEI RISULTATI (CLASSI DI EQUIVALENZA DI USCITA) LA TECNICA RICHIEDE UNA BUONA CONOSCENZA DEL TEMA APPLICATIVO ED UNA BUONA DOSE DI CREATIVITÀ 13Test.47

48 TECNICA DI ANALISI DEI VALORI ESTREMI ALCUNE LINEE GUIDA 1. INTERVALLO DI VALORI SPECIFICATO DA UNA CONDIZIONE D INGRESSO: SCRIVERE CASI DI TEST VALIDI, PER I VALORI SUGLI ESTREMI DELL INTERVALLO NON VALIDI, PER VALORI IMMEDIATAMENTE SOTTO IL MINIMO O SOPRA IL MASSIMO 2. NUMERO DI VALORI SPECIFICATO DA UNA CONDIZIONE D INGRESSO: SCRIVERE CASI DI TEST: VALIDI, PER IL NUMERO MINIMO E PER IL MASSIMO NON VALIDI, PER I NUMERI IMMEDIATAMENTE SOTTO IL MINIMO O SOPRA IL MASSIMO 13Test.48

49 TECNICA DI ANALISI DEI VALORI ESTREMI 3. RIPETERE IL PROCESSO DI CUI AL PUNTO 1 PER CIASCUNA CONDIZIONE ANALOGA IN USCITA 4. RIPETERE IL PROCESSO DI CUI AL PUNTO 2. PER CIASCUNA CONDIZIONE ANALOGA IN USCITA 5. SE IN INGRESSO O IN USCITA AL PRODOTTO SOFTWARE C È UN INSIEME ORDINATO DI ELEMENTI OCCORRE PREVEDERE CASI DI TEST PER IL PRIMO E L ULTIMO ELEMENTO DELL INSIEME 6. USARE LA PROPRIA ABILITÀ PER RICERCARE ALTRE CONDIZIONI ESTREME 13Test.49

50 TECNICA DI ANALISI DEI VALORI ESTREMI LO SPAZIO DEI RISULTATI OCCORRE EFFETTUARE UN ANALISI ACCURATA DELLO SPAZIO DEI RISULTATI, CONSIDERANDO CHE: NON SEMPRE GLI ESTREMI DEL DOMINIO DI INGRESSO CORRISPONDONO AGLI ESTREMI DEL DOMINIO DI USCITA IN QUANTO NON SONO DETERMINATI DALLO STESSO INSIEME DI CIRCOSTANZE NON È SEMPRE POSSIBILE GENERARE UN RISULTATO AL DI FUORI DEGLI ESTREMI DEL DOMINIO VALIDO DI USCITA 13Test.50

51 TECNICA DI ANALISI DEI VALORI ESTREMI UN ESEMPIO CONDIZIONI ESTERNE VALIDE CLASSI DI EQUIVALENZA NON VALIDE LA SOMMA DI DUE LATI MAGGIORE DEL TERZO A + B > C A + B Ø C DUE POSSIBILI CASI DI TEST A = 3 B = 4 C = 5 A = 1 B = 2 C = 4 13Test.51

52 TECNICA DI ANALISI DEI VALORI ESTREMI SE NEL PRODOTTO SOFTWARE FOSSE PRESENTE L ISTRUZIONE A + B C ALLORA I CASI DI TEST PRECEDENTI NON RILEVEREBBERO L ERRORE, I DATI DI INGRESSO ERRATI A = 1 B = 2 C = 3 SAREBBERO CONSIDERATI UN TRIANGOLO SCALENO VALIDO. L ANALISI DEI VALORI ESTREMI ESPLORA LE SITUAZIONI SUGLI ESTREMI ED INTORNO AGLI ESTREMI STESSI DELLE CLASSI DI EQUIVALENZA 13Test.52

53 TECNICA DI ANALISI DEI VALORI ESTREMI CONCLUSIONI I CASI DI TEST OTTENUTI CON L ANALISI DEI VALORI ESTREMI RAPPRESENTANO ERRORI MOLTO COMUNI. UNA GENERAZIONE CASUALE DEI CASI DI TEST NON INDIVIDUA QUESTI ERRORI. L ANALISI DEI VALORI ESTREMI È UNA DELLE TECNICHE PIÙ UTILI NEL DISEGNO DEI CASI DI TEST. MALGRADO L APPARENTE SEMPLICITÀ LA TECNICA NON È BANALE, IN QUANTO LE CONDIZIONI ESTREME POSSONO ESSERE MOLTO SOTTILI. 13Test.53

54 Test di comparazione Software ridondante (situazioni estremamante critiche) Produzione di differenti versioni sulla base delle stesse specifiche Confronto delle varie versioni sugli stessi casi di test Facilmente automatizzabili Ovviamente se le specifiche sono errate... 13Test.54

55 Test di interfacce grafiche Notevole sovrapposizione di funzionalita (ambienti a finestra/menu/mouse) Possibilita di sviluppare delle checklist esaustive del tipo le funzionalita di movimento scrolling e ridimensionamento funzionano? il mouse permette di raggiungere tutti gli elementi presenti nella finestra? lo stato della barra dei menu e consistente? sono previsti dei comanti da tastiera per le funzionalita piu frequentemente usate? il formato dei dati di ingresso e corretto? (date, numeri, ecc.) i meccanismi grafici per l input dei dati funzionano correttamente? 13Test.55

56 Test di Integrazione Una volta testati i singoli moduli (blak&white) occorre integrarli tra di loro Il 75% degli errori nel progetto Apollo furono errori di interfaccia Il problema della integrazione va preso in considerazione fin dalle fasi iniziali del progetto Questo implica, tra l'altro, la pianificazione di opportuni livelli di test quali, ad eempio: ispezione a mano -> white -> black -> integrazione 13Test.56

57 Tecniche di integrazione A B C D E Albero delle chiamate F G H DRIVER A B Driver: sostituisce una parte chiamante trasmettendo i parametri (corretti!) STUB 1 STUB 2 STUB 3 Stub: sostituisce una parte chiamata restituendo i valori di ritorno (corretti!) 13Test.57

58 STRATEGIA NON INCREMENTALE STRATEGIE DI INTEGRAZIONE BIG-BANG Integrazione simultanea di tutte le parti STRATEGIA INCREMENTALE TOP-DOWN Integrazione effettuata procedendo dall'alto, procedendo verso le procedure piu' annidate BOTTOM-UP Integrazione effettuata dal basso, partendo dalle foglie 13Test.58

59 I L TESTING INCREMENTALE Vantaggi Gli errori vengono individuati prima e piu' facilmente E' piu' accurato Svantaggi Puo' richiedere la scrittura di un numero considerevole di driver e stub E' richiesto piu' tempo macchina per l'esecuzione Riduce il parallelismo 13Test.59

60 APPROCCIO TOP-DOWN APPROCCIO BOTTOM-UP A DRIVER A B C D DRIVER B C DRIVER D STUB E STUB F G E F G STUB H H Integrare prima possibile i componenti piu critici e di I/O 13Test.60

61 APPROCCIO TOP-DOWN Vantaggi Utile quando i difetti o la complessita' sono nella parte alta della struttura Si ottiene rapidamente uno "scheletro" del prodotto semifunzionante Approccio piu' naturale Svantaggi Gli stub da produrre sono tipicamente complessi Puo' ritardare il completamento del test di alcuni componenti Piu' difficile osservare i risultati 13Test.61

62 Approccio Bottom-UP Vantaggi Utile quando i difetti o la complessita' sono nella parte bassa della struttura Piu' facile da realizzarsi Piu' facile osservare i risultati del test Svantaggi La produzione di drivers e' meno "naturale" Il prodotto non e' completo sino a quando non vengono aggiunti i componenti "alti" 13Test.62