Testing. Definizioni. incomprensione umana nel tentativo di comprendere o risolvere un problema, o nell uso di strumenti

Transcript

1 Definizioni Problemi del testing:criterio di selezione dei casi di test Test Funzionale: suddivisione in classi di equivalenza e analisi dei valori limite Test Strutturale: basato sul flusso di controllo e dei dati Valutazione dei risultati del testing Criterio di terminazione del testing Livelli di testing Test di programmi OO Pianificazione, Specifica, esecuzione e rapporto del test 1 Definizioni Errore (umano) incomprensione umana nel tentativo di comprendere o risolvere un problema, o nell uso di strumenti Difetto (fault o bug) Manifestazione nel software di un errore umano, e causa del fallimento del sistema nell eseguire la funzione richiesta Malfunzionamento (failure) incapacità del software di comportarsi secondo le aspettative o le specifiche un malfunzionamento ha una natura dinamica: accade in un certo istante di tempo e può essere osservato solo mediante esecuzione 2 1

2 Relazione fra Errore, Difetto e Malfunzionamento errore causa Difetto causa Malfunzionamento 1..* 1..* 1..* 3 Definizioni Il (collaudo) è un processo di esecuzione del software allo scopo di scoprirne i malfunzionamenti osservando i malfunzionamenti possiamo dedurre la presenza di difetti Tesi di Dijkstra: Il testing non può dimostrare l assenza di difetti, ma può solo dimostrare la presenza di difetti Il Debugging è il processo di scoperta dei difetti a partire da malfunzionamenti noti L Ispezione è un processo di analisi del software per scoprirne i difetti 4 2

3 Problemi del testing Criterio di selezione dei casi di test Valutazione dei risultati del test Criterio di terminazione del testing 5 Valutazione dei risultati del test Condizione necessaria per effettuare un test: conoscere il comporatmento atteso per poterlo confrontare con quello osservato L oracolo conosce il comportamento atteso per ogni caso di prova Oracolo umano si basa sulle specifiche o sul giudizio Oracolo automatico generato dalle specifiche (formali) stesso software ma sviluppato da altri versione precedente (test di regressione) Software da testare Casi di test Comparatore Oracolo Risultati del test 6 3

4 Terminazione del testing Quando il programma si può ritenere analizzato a sufficienza Criterio temporale: periodo di tempo predefinito Criterio di costo: sforzo allocato predefinito Criterio di copertura: percentuale predefinita degli elementi di un modello di programma legato ad un criterio di selezione dei casi di test Criterio statistico MTBF (mean time between failures) predefinito e confronto con un modello di affidabilità esistente 7 Problema della selezione dei casi di test Un programma è corretto se è corretto per ogni dato d ingresso Un programma è esercitato da un caso di test (sottoinsieme dei dai di input) Un test è formato da un insieme di casi di test L esecuzione del test consiste nell esecuzione del programma per tutti i casi di test Un test ha successo se rileva uno o più malfunzionamenti del programma Un test è ideale se l insuccesso del test implica la correttezza del programma Un test esaustivo è un test che contiene tutti i dati di ingresso al programma un test esaustivo è un test ideale un test esaustivo non è pratico e quasi sempre non è fattibile Obiettivo realistico: selezionare casi di test che approssimano un test ideale 8 4

5 Criterio di selezione di test Specifica le condizioni che devono essere soddisfatte da un test Consente di selezionare più test per uno stesso programma Un criterio di selezione di test è affidabile per un programma se per ogni coppia di test selezionati, T1 e T2, se T1 ha successo anche T2 ha successo e viceversa (ossia ogni insieme di casi di test che sddisfano il criterio rilevano gli stessi errori) Un criterio di selezione di test è valido per un programma se, qualora il programma non è corretto, esiste almeno un test selezionato che ha successo Teorema di Goodenough e Gerhart Il fallimento di un test T per un programma P, selezionato da un criterio C affidabile e valido, permette di dedurre la correttezza del programma P 9 Esempio Program raddoppia (input, output); var x, y: integer; begin read(x); y:= x*x; write(y); end Criterio affidabile ma non valido: T deve contenere sottoinsiemi di {0, 2} Criterio valido ma non affidabile: T deve contenere sottoinsiemi di {0,1, 2, 3, 4} Criterio valido e affidabile: T deve contenere almeno un valore maggiore di

6 Selezione dei casi di test Teorema di Howden Non esiste un algoritmo che, dato un programma arbitrario P, generi un test ideale finito, e cioè un test definito da un criterio affidabile e valido Al di là di casi banali, non è possibile costruire un criterio di selezione generale di test valido e affidabile che non sia il test esaustivo Obiettivi pratici massimizzare il numero di malfunzionamenti scoperti (richiede molti casi di test) minimizzare il numero di casi di test (e quindi il costo del testing) E preferibile usare più di un criterio di selezione dei test 11 Classi di criteri di selezione Criteri black-box o funzionali dipendono solo dalle specifiche del software Criteri white-box o strutturali dipendono dalla struttura interna del software Suddivisione in classi di equivalenza Analisi dei valori limite Grafi causa-effetto Criteri basati sul flusso di controllo Criteri basati sul flusso dei dati Analisi mutazionale Sono spesso usati in maniera complementare 12 6

7 Suddivisione in classi di equivalenza Il dominio dei dati di ingresso è suddiviso in classi di casi di test in modo tale che, se il programma è corretto per un caso di test, si possa dedurre ragionevolmente che è corretto per ogni caso di test in quella classe Una classe di equivalenza rappresenta un insieme di stati validi o non validi per una condizione sulle variabili d ingresso 13 Definizione delle classi di equivalenza Se la condizione sulle variabili d ingresso specifica: intervallo di valori una classe valida per valori interni all intervallo, una non valida per valori inferiori al minimo, e una non valida per valori superiori al massimo valore specifico una classe valida per il valore specificato, una non valida per valori inferiori, e una non valida per valori superiori elemento di un insieme discreto una classe valida per ogni elemento dell insieme, una non valida per un elemento non appartenente valore booleano una classe valida per il valore TRUE, una classe non valida per il valore FALSE 14 7

8 Selezione dei casi di test dalle classi di equivalenza Ogni classe di equivalenza deve essere coperta da almeno un caso di test Un caso di test per ogni classe non valida Ciascun caso di test per le classi valide deve comprendere il maggior numero di classi valide ancora scoperte 15 Esercizio L utente può chiamare la banca usando il proprio computer collegato via modem, digitare una password di 6 cifre, e digitare vari comandi che consentono di accedere alle varie funzioni bancarie (trasferimento fondi, estratto conto, saldo, fine sessione). L utente non può trasferire meno di lire e più di un milione per telefonata Selezionare i casi di test mediante partizione in classi di equivalenza 16 8

9 Le condizioni sull input password Condizioni d ingresso: La password può avere una valore compreso tra e Classi di equivalenza: Valida CE 1 : PASSWORD Non valide CE 2 : COD < CE 3 : COD > Le condizioni sull input comando Condizioni di ingresso: Il comando può essere di tipo: trasferimento fondi, estratto conto, saldo, fine sessione Classi di equivalenza Valide CE 5 : COMANDO = trasferimento fondi CE 6 : COMANDO = estratto conto CE 7 : COMANDO = saldo CE 8 : COMANDO = fine sessione Non valida CE 9 : COMANDO = moltiplica 18 9

10 Le condizioni sull input importo Condizioni di ingresso: L importo non può essere maggiore di nè minore di Classi di equivalenza Valida CE 10 : <= IMPORTO<= Non valide CE 11 : IMPORTO< CE 12 : IMPORTO> Selezione dei casi di test CONDIZIONI Valore della password tra e Tipo di comando: CE 4 CE 5 CE 6 CE 7 L importo deve essere tra e CLASSI DI EQUIVALENZA #CE Valide #CE Non valide CE password CE 2 password< AND CE 3 password > password CE 9 Trasferimento Estratto conto Saldo Fine sessione importo AND importo CE 8 Moltiplica CE 10 CE 11 importo< importo >

11 Scelta dei casi di test... Test case TC1 TC2 TC3 password comando trasferimento estratto conto saldo importo Classi coperte CE1, CE4, CE9 CE1, CE5, CE9 CE1, CE6, CE9 Test case TC4 TC5 TC6 password comando fine sessione estratto conto saldo importo Classi coperte CE1, CE7, CE9 CE2, CE5, CE9 CE3, CE6, CE9 21 Scelta dei casi di test Test case TC7 TC8 TC9 password comando moltiplica estratto conto saldo importo Classi coperte CE1, CE8, CE9 CE1, CE5, CE10 CE1, CE6, CE

12 Analisi dei valori limite I casi di test che esplorano condizioni limite spesso rilevano la presenza di malfunzionamenti Le condizioni limite: sono direttamente agli estremi immediatamente al di sopra immediatamente al di sotto degli estremi di: classi di equivalenza di ingresso classi di equivalenza di uscita Le condizioni limite possono essere molto sottili usare la creatività per cercare altre situazioni estreme 23 Criteri basati sul flusso di controllo Criteri di selezione Copertura dei comandi (statement test) Copertura delle decisioni (branch test) Copertura delle condizioni (condition test) Copertura delle decisioni e delle condizioni Copertura dei cammini (path test) Copertura dei cammini indipendenti Criteri di adeguatezza n.ro comandi eseguiti/ n.ro comandi eseguibili n.ro archi percorsi/ n.ro archi percorribili n.ro cammini percorsi/ n.ro cammini percorribili n.ro cammini indip. percorsi/ n.ro ciclomatico 24 12

13 UN MODELLO DI RAPPRESENTAZIONE DEI PROGRAMMI: il Control-Flow Graph Il grafo del flusso di controllo (Control-Flow Graph) di un programma P: dove: CFG (P) = <N, AC, ni, nf> <N, AC> è un grafo diretto con archi etichettati, {ni, nf} N, N- {ni, nf} = Ns Np Ns e Np sono insiemi disgiunti di nodi istruzione e nodi predicato; AC N-{nF} N-{nI } {vero, falso, incond} rappresenta la relazione flusso di controllo; ni ed nf sono detti rispettivamente nodo iniziale e nodo finale. Un nodo n Ns {ni} ha un solo successore immediato e il suo arco uscente è etichettato con incond. Un nodo n Np ha due successori immediati e i suoi archi uscenti sono etichettati rispettivamente con vero e falso. 25 procedure Quadrato; var x, y, n: integer; begin 1. read(x); 2. if x > 0 then begin 3. n := 1; 4. y := 1; 5. while x > 1 do begin 6. n := n + 2; 7. y := y + n; 8. x := x - 1; end; 9. write(y); end; end; true true I 1 2 false false I 1,2 true 3,4,5 true false 6,7,8 9 F false F 26 13

14 Copertura dei comandi (statement test) ogni nodo del CFG deve essere eseguito almeno una volta durante il testing; è un criterio di copertura debole, che non assicura la copertura sia del ramo true che false di una decisione Copertura delle decisioni (branch test) ciascun arco del CFG deve essere attraversato almeno una volta; ogni decisione è valutata sia nel caso true che false; un limite è legato alle decisioni in cui più condizioni (legate da operatori logici AND ed OR) sono valutate Copertura delle condizioni (condition test) ciascuna condizione nei nodi decisione di un CFG deve essere valutata sia per valori true che false. int check (x);// controlla se un intero è fra 0 e 100 int x; { if ((x>=0) && (x<= 200)) check= true; else check = false; } TC={x=5, x=-5 } valuta la decisione sia per valori True che False, ma non le condizioni Copertura delle decisioni e delle condizioni non basta assicurare la copertura delle condizioni, ma anche quella delle decisioni 27 Criteri di copertura dei cammini Copertura dei cammini (path test) spesso gli errori si verificano eseguendo cammini che includono particolari sequenze di nodi decisione non tutti i cammini eseguibili in un CFG possono essere eseguiti durante il test (un CFG con loop può avere infiniti cammini eseguibili) Copertura dei cammini indipendenti ci si limita ad eseguire un insieme di cammini indipendenti di un CFG, ossia un insieme di cammini in cui nessun cammino è completamente contenuto in un altro dell insieme, nè è la combinazione di altri cammini dell insieme ciascun cammino dell insieme presenterà almeno un arco non presente in qualche altro cammino il numero di cammini indipendenti coincide con la complessità ciclomatica del programma 28 14

15 Complessità ciclomatica di un programma 0 1 Dato un grafo G di n nodi ed e archi il numero ciclomatico è dato da: true true 2 false false V(G) = e- n+ 2 oppure: V(G)= d + 1 d= # nodi branch 3 4 V(G)= 3 =>3 cammini indipendenti Compessità ciclomatica del programma è 3 5 c1= c2= c3= Principi I test vanno pianificati in anticipo I test devono cominciare in piccolo e proseguire in grande Livelli di testing Bisogni del cliente Requisiti Progetto Test di accettazione Test di sistema Test di integrazione Codice Test di unità Modifiche Test di regressione 30 15

16 LIVELLI DI TESTING livello produttore unit testing ( di Unità) integration testing ( di Integrazione) system testing ( di Sistema) livello cooperativo produttore-cliente privilegiato alpha testing beta testing livello cliente o utente acceptance testing ( di accettazione) 31 di unità (..detta anche di modulo..) il testing é applicato isolatamente ad una unità o ad un modulo di un sistema software; obiettivo fondamentale é quello di rilevare errori (logica e dati) nel modulo; prassi diffusa é che esso venga realizzato dal programmatore che ha prodotto l'unità sotto test. unità: elemento definito nel progetto di un sistema software e testabile separatamente; nel testing unità e modulo sono spesso usati come sinonimi

17 d integrazione il testing é applicato ad un aggregato di due o più unità di un sistema software; l'obiettivo é quello di rilevare errori nelle interazioni fra le unità e nelle funzioni che l'aggregato deve assolvere; non é compito dei programmatori che hanno prodotto le unità componenti le unità da integrare sono selezionabili in base a criteri funzionali ricavabili dal progetto (architettura del sistema); partendo da una architettura organizzata gerarchicamente, le integrazioni possono essere realizzate con approccio top-down o bottom-up 33 di sistema il testing é applicato al sistema software completo ed integrato; l'obiettivo è quello di valutare l'adesione del sistema ai requisiti specificati; va effettuato dal team addetto al testing i requisiti del sistema non sono solo le funzionalità esterne; fondamentali sono i requisiti di qualità, stabiliti ad esempio sulla base di un modello di qualità del prodotto opportunamente istanziato 34 17

18 di accettazione testing effettuato sull'intero sistema sulla base di un piano e di procedure approvate dal cliente (o utente); l'obiettivo é quello di mettere il cliente, l'utente o altri a ciò preposti ( collaudatori o enti ad hoc) in condizione di decidere se accettare il prodotto; segna il passaggio del sistema dal produttore all'ambiente operativo;..é più 'una dimostrazione che un test' é a carico del committente; 35 2 livelli di test di accettazione alpha testing uso del sistema da parte di utenti reali ma nell'ambiente di produzione e prima della immissione sul mercato beta testing: installazione ed uso del sistema in ambiente reale prima della immissione sul mercato tipicamente adottati dai produttori di packages per mercato di massa 36 18

19 di programmi orientati agli oggetti I criteri black-box non sono influenzati La struttura OO può avere impatto sui criteri white-box Test di unità operazioni di una classe: stessi criteri applicabili classe di oggetti:sono necessari altri criteri è l oggetto che può essere testato, non la classe all interno di una classe non c è un unico flusso di controllo (a causa dello scambio di messaggi) lo stato di un oggetto influenza il risultato problemi dovuti all uso di ereditarietà problemi legati all uso di binding dinamico 37 Piano di test Documento relativo all intero progetto Struttura specifica delle unità di test (per un dato livello di test) Es. Modulo, gruppi di moduli, programma, sottosistemi, intero sistema Caratteristiche da testare: funzionalità, prestazioni, vincoli di progetto, sicurezza Approccio: criterio di selezione dei test, criterio di terminazione, strumenti Prodotti del test: es. Casi di test, rapporto finale, diario del test, statistiche di copertura Schedulazione: quando effettuare il testing e lo sforzo per attività Allocazione del personale 38 19

20 Specifica dei casi di test Per ogni livello di test n.ro di caso di test input condizione da testare output atteso Effettuato il test, si può completare con output osservato Le specifiche ed i casi di test possono essere riusati per il test di regressione 39 Esecuzione del test Costruzione di Moduli guida (invocano l unità sotto test) Moduli fittizi (sono invocati dall unità sotto test) Modulo guida Unità sotto test Modulo fittizio 40 20

21 Rapporti sul test Diario del test descrive i dettagli del test per come si è svolto effettivamente la specifica dei casi di test può essere completata e usata come diario Riepilogo del test Rivolto al management del progetto numero totale di casi di test eseguiti numero e tipo di malfunzionamenti osservati numero e tipo di difetti scoperti Sommario dei malfunzionamenti Rivolto a chi deve effettuare il debugging o la correzione 41 21